Redbooks Paper
Thorsten Busch
Alex Osuna
N Series SnapManager with Microsoft
SQL
Introduction
Backup and recovery of a SQL Server database is tightly associated with the
physical layout of the database. Understanding the layout is critical when you are
consolidating multiple SQL Server instances and databases, and it is an
important part of any database design, especially when multiple databases share
the same IBM® System Storage™ N series storage device.
This IBM Redpaper describes the relationships between the physical storage of
SQL Server and SnapManager for SQL Server (SMSQL). We analyze and
illustrate various methodologies for the layout of the physical structure of
database files on virtual disks, their implications for backup and restore, and the
use of SnapMirror. The main ideas we cover are:
򐂰
򐂰
򐂰
򐂰
򐂰
Database storage object definition and layouts, with a focus on using SMSQL
Database sizing and I/O load requirements
Consolidation of the storage of multiple SQL Server instances and databases
SMSQL and its functions
A checklist that refers to related sections
We use screen captures throughout this paper to illustrate selections or a point.
Some of the screen captures have been cropped to show only the important part
of a screen.
© Copyright IBM Corp. 2006. All rights reserved.
ibm.com/redbooks
1
Logical and physical layout of databases
The process of designing and implementing SQL Server databases is, in most
aspects, intuitive. It can also be critical for future growth and performance, and
important for optimal use of SMSQL. Understanding the relationship between
database files, virtual disks, and IBM N series storage system volumes is
important for optimal use of SMSQL. This section discusses database file
objects, explores various layouts of SQL Server databases, and describes ways
to utilize virtual disks that can be supported by SMSQL.
Both system and user databases deploy the same basic structure; therefore, the
given description covers system databases 1, demonstration databases 2, and
user-defined databases. The focus is not the logical structure of database files
but the physical files of a database and how they are accessed.
A database consists of two or three different physical file types with different
content. The file types use the following default file extensions:
򐂰 Idf is a transaction log. A database has at least one transaction log with the
information that is necessary to recover all database transactions.
򐂰 mdf is the primary data file. Every database has one primary data file that
keeps track of all other database files and internal database structure, in
addition to storing data.
򐂰 ndf is the secondary data file. A database can have zero or more secondary
data files that contain only data.
Data files can be logically grouped into file groups. A file group consists of one or
more physical data files.
Figure 1 on page 3, Figure 2 on page 4, Figure 3 on page 5, and Figure 4 on
page 6 illustrate different layouts of SQL Server databases, followed by a
description that includes advantages and disadvantages.
Common database layouts
The most common layout of a database is with two files: one primary data file
and one transaction log file (see Figure 1 on page 3). Both the data file and the
log file use the same virtual disk: disk M.
2
N Series SnapManager with Microsoft SQL
Figure 1 Basic structure of a SQL Server database
The advantages of the layout in Figure 1 are:
򐂰 Only one drive letter is used for the database.
򐂰 It is easy to administer and to understand the relationship between the files
and the database.
򐂰 Several databases can share a virtual disk when all files that belong to the
databases are located in the same virtual disk.
򐂰 Making SnapMirror copies is simple because only one filer volume is used by
the database.
The disadvantages are:
򐂰 If the volume fails, the database must be recovered from an archive of full
backup and backup transaction logs. A volume rarely fails, but it can happen.
Archiving backed up databases is important for disaster recovery.
򐂰 Synchronous access to the transaction log and random access to the data file
are mixed in the same volume, but that is only a potential issue with
environments that require high levels of I/O access. Database files can always
be migrated with SMSQL.
򐂰 The layout is not practical with very large databases (700 GB and higher).
Figure 2 on page 4 illustrates another common layout.
N Series SnapManager with Microsoft SQL
3
Figure 2 Database layout with two virtual disks
This layout is very similar to the one in Figure 1 on page 3, except that the
transaction log file and the data file are each located in separate virtual disks that
use a single volume. The transaction log is located in the X device and the data
file is located in the M device.
The advantages of the layout in Figure 2 are:
򐂰 SnapMirror transactions are simple when only one filer volume is used by the
database.
򐂰 I/O is distributed over two separate virtual devices so that the network traffic
can be divided between two distinct transport layers and volumes.
򐂰 The potential I/O throughput is greater.
The disadvantages are:
򐂰 The layout uses two drive letters.
򐂰 If the single volume fails, the database must be recovered from the archive
and backed up from transaction logs.
򐂰 The virtual disks cannot be shared by any other database.
Large databases with sequential I/O access
Large databases with sequential access can potentially increase I/O
performance when database objects (such as tables or indexes) are created in
file groups that consist of several data files. When the SQL Server detects that a
table or index has been created in a file group with several files, then SQL Server
extends the tablespace “round-robin” over available files. In practice, this means
that SQL Server allocates 64 KB in a round-robin over all files in the file group.
4
N Series SnapManager with Microsoft SQL
The database in Figure 3 has three data files in MyFilegroup and one transaction
log file. The files in MyFilegroup are all located in the M device and stored in one
volume. The transaction log file is stored in device X, which is located in a second
volume.
Figure 3 Database layout using two volumes
The advantages of the layout in Figure 3 are:
򐂰 You are likely to achieve higher concurrent I/O access when a table is
sequentially scanned.
򐂰 I/O is distributed over two separate volumes, so the sequential access to the
transaction log is in a different volume than the access to the data files.
Access to the transaction log is always sequential but access to data files is
potentially random. Access to online transaction processing (OLTP)
databases is generally random and access to data warehouses is mostly
sequential.
򐂰 If the database becomes too large for one volume, it is fairly easy to move one
of the data files to another volume or to expand the file group with a new file
that is located in another volume.
The disadvantages are:
򐂰 The layout uses two drive letters.
򐂰 The virtual disks cannot be shared by any other database.
򐂰 SnapMirror processes are more complicated.
Very large database with high I/O performance
Large databases with high I/O performance requirements can create large tables
in different file groups with multiple data files. Multiple data files can potentially
increase the physical I/O rate by making it possible for SQL Server to issue
concurrent I/O requests to each file in a file group. Data files in a file group can
N Series SnapManager with Microsoft SQL
5
be stored in one single device (Filegroup 1) or in several devices (Filegroup 2).
Figure 4 illustrates this layout.
Figure 4 Database layout with multiple filer
The reasons for using several filer groups are:
򐂰 The database has several large tables.
򐂰 A table and its indexes can be created in different file groups.
򐂰 The data files in the file group can easily be spread over multiple volumes,
which can potentially also increase the I/O performance.
The advantages of the layout in Figure 4 are:
򐂰 You can achieve more concurrent I/O access.
򐂰 A table and its indexes can be created in different file groups.
򐂰 I/O is distributed over two separate volumes; therefore, access to the
transaction log is in a different volume from the volume that contains the data
files. Access to the transaction log is always sequential, access to data files is
potentially random, access to OLTP databases is generally random, and
access to data warehouses is mostly sequential.
򐂰 If the database becomes too large for one volume, it is fairly easy to move
some of the data files to another volume or to expand the file group with new
files that are located in another volume.
6
N Series SnapManager with Microsoft SQL
The disadvantages are:
򐂰 Creating several filer groups uses many drive letters.
򐂰 The virtual disks cannot be shared by any other database.
򐂰 Backing up the files with SnapMirror is complicated.
򐂰 The layout is complicated and rarely needed. An IBM N series filer can load
balance I/O over available disks in a volume easily and effectively.
Several databases on one Windows server
Several databases can be controlled by one or more SQL Server instances
running on a single Windows® platform. Each Windows platform has a fixed
number of available drive letters, usually about 20, over which all databases filers
must be allocated. If there are more databases than drive letters, you must group
the databases together according to criteria that you specify and store them in
one virtual disk.
Deciding the physical layout for multiple databases that are spread over several
virtual disks can make the design complicated. Figure 5 illustrates two basic
concepts of controlling several databases from a single server.
Figure 5 Multiple databases
N Series SnapManager with Microsoft SQL
7
When a server must handle more databases than there are available drive
letters, you should sort all databases according to:
򐂰 Size: The larger a database, the greater the advantage of using SMSQL for
backup and restore. Grouping the largest database with the smallest
databases makes it possible to restore all databases if the large database
must be restored, or to restore a single smaller database if that has to be
restored as described in “Restore databases” on page 30.
򐂰 Acceptable downtime: Knowing the acceptable downtime makes it possible
for the database administrator to decide the order in which databases must be
restored. By selecting only the database that must be restored first (see
Figure 23 on page 28), the selected databases are restored and online first,
while the other databases are in a “loading” state (see Figure 24 on page 30).
The database administrator can apply transaction logs and take databases
online in the required order.
򐂰 How critical the database is: Databases that are critical can be located in
their own virtual disks. This might require that more of the remaining
databases be located together in the other virtual disks, but this is a trade-off
that has to be made.
Sizing
In addition to the space that is required for the virtual disk to store SQL Server
databases, free space is required to store data that changed between Snapshot
copies of the active file system of the virtual disk(s). Providing additional space
ensures that multiple Snapshot backups of the databases can be created. The
general considerations for creating an IBN N series volume are:
򐂰 To be able to create Snapshot backups, the volume must be at least twice the
size of the virtual disks that the volume stores.
򐂰 The volume must have enough free space to support the number of Snapshot
copies to be kept online.
The following data can help you estimate volume size and virtual disk size:
򐂰 Initial database size is the starting point for any sizing project.
򐂰 Database growth rate is important for sizing the virtual disks correctly so that
you do not have to expand them and the volumes too soon and too frequently.
򐂰 The change rate of the current database is important for estimating the
Snapshot space requirements.
򐂰 Free volume space requirements for Snapshot copies are at least equal to the
size of the virtual disk plus changed file blocks.
8
N Series SnapManager with Microsoft SQL
򐂰 We recommend using the default redundant array of independent disks
(RAID) group size.
򐂰 We recommend that you operate with additional free volume space. This
decreases the possible volume fragmentation rate and prevents sudden “out
of space” events. Also, when the free space of a volume is very limited, I/O
performance could suffer.
򐂰 Depending on the access pattern, a single disk drive can support about 150
I/O operations per second (IOPS) with current disk technology. Therefore, it is
important to understand the I/O rate during peak loads to estimate the
number of disk drives needed to support the I/O load. A RAID group size of
eight disk drives (seven data and one parity) can support about 1050 IOPS (7
x 150 IOPS).
Consider the following requirements for sizing a database:
򐂰 The initial database size is 100 GB.
򐂰 The database growth rate is estimated to be 10% per month.
򐂰 The change rate of the current database is estimated to be 15% per month.
򐂰 The backup requirement is 4 backups (Snapshot duplicates) per day, with a
total of 12 Snapshot copies (3 days).
򐂰 The default RAID group size is eight drives; the drive size is 72 GB.
򐂰 The administrator wants to expand the virtual disk (and volume) only every six
months.
򐂰 The growth and change rates are estimates, so extra space has been
requested. Also, the customer realizes that a volume has to operate with
some free space to decrease the possible fragmentation rate or I/O
performance could suffer. Therefore, an extra 20% free space per disk drive is
allocated as a free-space buffer.
򐂰 The average I/O rate is about 1.5 MB per second and the peak rate is about 3
MB per second.
The result of using these requirements is:
򐂰 The database size after six months will be about 180 GB.
򐂰 About 27 GB of the database will change every month after six months, which
is equal to 0.15 GB every four hours.
򐂰 The minimum space requirement after six months will be (180 GB x 2) + (0.15
GB x 12) = 362 GB.
򐂰 A 72 GB disk drive has 68 GB of usable file space, and because 20% is
allocated as extra free space, only 55 GB will be allocated per disk drive.
Therefore, six disk drives are needed for data and one disk drive for parity, for
N Series SnapManager with Microsoft SQL
9
a total of seven disk drives. However, it is important for performance reasons
to always configure complete RAID groups; therefore, the volume will be
created with eight disk drives. If the rate of growth is consistent over time, the
volume must be expanded with another RAID group after six or seven
months.
򐂰 The estimated peak load was 3 MB per second, which is equal to about 770
IOPS. Because seven data disk drives can support 1050 IOPS, a RAID group
size of eight is sufficient to support both space requirements and I/O load
requirements.
The above estimate does not account for the space that is required for the
database transaction log. Sizing space for a database transaction log requires an
understanding of the following factors:
򐂰 The rate of transactions that modify a database record
򐂰 The size of the transaction
򐂰 The frequency of the transaction log backup
򐂰 The fact that only the active part of the transaction log is backed up and not
the total size of the transaction log
The key to sizing requirements correctly for the database transaction log is to
monitor usage over time.
System database sizing
Except for tempdb, all system databases are fairly small. Tempdb is a work area
for all SQL Server temporary storage requirements. The size of tempdb depends
exclusively on the operations of the database applications, the number of
databases, and the number of users. Tempdb can become very large. It is very
hard to predict how big tempdb can become, but the I/O load can be very high
and, because it is recreated every time SQL Server starts up, it is never reused.
The tempdb should be located in a volume with no Snapshot copies.
Snaplnfo sizing
Snaplnfo contains metadata, streamed full backup of system databases,
streamed full backup of user-defined databases that share a virtual disk with a
system database, and backed up transaction logs. Space requirements for
Snaplnfo depend on the factors that are described in the previous sections,
including the number of databases, the size of streamed databases, number of
backups to be kept online, and the active size of the transaction log of the
database since the last time the transaction log was backed up.
10
N Series SnapManager with Microsoft SQL
Metadata per backup set is less than 10 KB. The size of each backed up system
database is less than 15MB.
The size of a backed up transaction log depends on the number of new
transactions that have been received since the last time the transaction log was
backed up and on the recovery model for the database. The full recovery model
is the most common recovery model and generates one record per transaction,
and the backed up transaction logs are approximately the same size as the
active part of a transaction log.
The bulk-logged recovery model is not used that often, but the size of a
backed-up transaction log when the recovery mode is bulk logged can become
much larger compared to full recovery mode. Bulk operations create minimal
logging, and bulk changed database pages are marked for inclusion in the next
backed-up transaction log. Therefore, when a bulk-logged database transaction
log is backed up, all bulk marked pages are written to the backup. Microsoft®
Perfmon can monitor the databases that are used and free space, including the
active part of the transaction log.
Full backup (Snapshot) of user defined databases only adds a set of metadata to
Snaplnfo.
General consolidation principles
It is quite common for companies to add new Windows 2000 servers whenever
new SQL Server applications are required for a business purpose. It is fairly easy
to add new hardware to network infrastructure, to install the application, and to
make the new environment available to end users. This works well for some
companies, but it can create administrative and maintenance issues for others.
Many companies begin to think about consolidation when they discover that it is
hard to maintain environments with multiple servers and locally attached storage,
which can become costly and complicated. This section describes important
considerations when consolidating SQL Server environments.
Figure 6 on page 12 shows a common infrastructure with a number of servers,
with each server supporting one SQL Server instance and application.
N Series SnapManager with Microsoft SQL
11
Figure 6 Before consolidating
Each server and its resources are independent from one another and must be
administered separately. The administration of each server includes:
򐂰
򐂰
򐂰
򐂰
򐂰
Performance monitoring and tuning
Capacity planning
Maintenance
System-level backup
Database backup
Not only is it complicated and time-consuming to administer many servers, but
also one server cannot use available resources another server, such as:
򐂰 Idle processors
򐂰 Memory
򐂰 Free files and disk space
Consolidating the environment that Figure 6 illustrates makes it easier to
administer and to share resources between applications. Consolidation projects
involve different but related projects.
Figure 7 on page 13 illustrates a situation where the disk storage has been
consolidated, making it much easier to share storage resources and do capacity
planning for SQL Servers. Consolidating server storage works well with limited
numbers of servers, such as when there is a one-to-one relationship between a
server and an IBM N series volume.
12
N Series SnapManager with Microsoft SQL
Figure 7 Storage consolidation
Even though it is possible for servers to share an IBM N series volume, it is
absolutely not recommended with SMSQL. Backups are volume-level Snapshot
copies, which makes it complicated when a single volume is shared among
servers; one volume per SQL Server platform is recommended with SMSQL.
It is advisable when the environment consists of many servers to consolidate
them so that it is possible to create a simple relationship between one server and
one volume.
Figure 8 on page 14 illustrates the final consolidation that consists of two SQL
Server platforms and a cluster of filers and exemplifies the total consolidation of
the environment in Figure 6 on page 12. All locally attached disk storage has
been consolidated into a cluster of filers, and the many smaller servers have
been consolidated into two larger servers.
N Series SnapManager with Microsoft SQL
13
Figure 8 Complete consolidation
Figure 8 also illustrates these important points:
򐂰 A virtual disk can be shared when all files that belong to the databases are
located in one virtual disk (MyDB1 and MyDB2).
򐂰 When the files for a database are located in different virtual disks, the virtual
disks cannot be shared with files of other databases (MyDB3 and
MYLargeDB).
򐂰 Snaplnfo cannot be located in a virtual disk with any transaction log file. The
authors recommend that Snaplnfo be located in its own virtual disk.
򐂰 There is a mapping between a virtual disk and a drive letter; a Windows
server™ has a maximum number of usable drive letters, usually about 20.
The advantages of the final consolidation are:
򐂰 It is much easier to administer and there is less administration work.
򐂰 It is much easier to monitor performance.
򐂰 It is much easier to share resources.
14
N Series SnapManager with Microsoft SQL
SnapMirror requirements
SnapMirror is important for disaster recovery services and database cloning for
reporting, testing, or development.
Figure 9 illustrates a SQL Server environment with one database stored in a
volume that has an active SnapMirror backup.
Figure 9 SnapMirror
Figure 9 also illustrates one reason to use multiple Snaplnfo directories, one
Snaplnfo for the mirrored database and another for unmirrored databases.
SnapDrive detects if a volume is mirrored during Snapshot creation and then
requests that the IBM N series storage system update the mirror.
It is also possible to update a mirror more frequently using rolling Snapshot
backups. Rolling Snapshot consists of two alternating Snapshot copies that are
created when executing an up_SnapMirror command from SnapDrive or from its
command line interface.
Two copies are replicated, a full backup and another, when the Snaplnfo directory
is updated. The Create Snapshot of Snaplnfo drive after backup setting is on
by default, but it is a good idea to check to be certain that it has not been
changed.
N Series SnapManager with Microsoft SQL
15
The authors recommend that all files that belong to the mirrored databases be
located in the same volume. It is technically possible to locate databases files in
different volumes and mirror each volume. However, the newest set of Snapshot
backups might be inconsistent because, if there is a disaster, it is possible that
not all volume replications will have been completed before the disaster. In this
case, the administrator must restore from an older full backup set.
SMSQL overview
The previous sections discussed possible valid database layouts with SMSQL.
This section discusses the relationships between SMSQL, SnapDrive, and SQL
Server, and the maximum configurations supported by SMSQL.
SMSQL, SnapDrive, and SQL Server
SMSQL depends on services that are provided by SnapDrive and SQL Server.
SMSQL runs user requests that must be coordinated with SnapDrive and SQL
Server 2000 (Figure 10).
Figure 10 SMSQL overview
Full backup, backup, and truncation of transaction logs are synchronized
between SMSQL and SQL Server. SQL Server quiesces databases and dumps
metadata to SnapInfo when a Snapshot copy is created. Backup and truncation
of transaction logs are requested by SMSQL but done by SQL Server, and are
dumped to SnapInfo by SQL Server. Databases are verified by SQL Server after
the virtual disk containing the databases has been restored as a writable
Snapshot file by SnapDrive.
SMSQL requests that SnapDrive create a Snapshot backup when a full backup
of a database is done. A copy of backed up transaction logs is created if that
option is turned on. SMSQL dumps metadata describing backup sets into the
Snapinfo directory.
If a volume is mirrored, SnapDrive updates the mirror every time a Snapshot
copy is created. SnapDrive restores virtual disks in Snapshot backups as
required by database restore operations or it restores a virtual disk as a writable
copy for database verification.
16
N Series SnapManager with Microsoft SQL
Maximum configuration
SMSQL is designed to manage a maximum number of SQL Server instances,
databases, files, and file groups (Figure 11).
Figure 11 Maximum configurations
Database migration
The SnapManager Configuration Wizard moves databases and their files to IBM
N series logical unit numbers (LUNs). You must run the configuration wizard even
when databases are already located on a virtual disk before SMSQL is installed.
The Configuration Wizard sets up SnapInfo and verifies settings to ensure that all
SMSQL functions work correctly. Even if no database has to be moved to the IBM
N series, the Configuration Wizard still must be run to create the mapping
between databases and SnapInfo.
The sections that follow discuss important information for migrating databases.
N Series SnapManager with Microsoft SQL
17
Migration basics
The first central page of the configuration wizard is “Where to move databases”
(Figure 12).
Figure 12 Where to move databases
The page has three panels:
򐂰 The top left panel shows SQL Server instances. Under each instance, you
see databases that can be moved to virtual disks but still be located on other
virtual disks. The panel shows that there are no local instances left.
򐂰 The top right panel shows virtual disks that databases can be moved to or
that can be used by SnapInfo. Here you see F, L, M, N, O, and P.
򐂰 The bottom panel shows SQL Server instances with databases stored on
virtual disks. The AA1 database is located on the L drive. The From and To
columns can easily be misunderstood. Think of From as the current location
from which the database is moved only if To shows a different drive letter. AA1
was already on L when the page opened, and AA1 will not be moved.
Figure 12 illustrates a point that was discussed in “Logical and physical layout of
databases” on page 2. A virtual disk can be shared by several databases when
all files belonging to the databases are located in one virtual disk. All files
belonging to AA1 are located in L, so other databases can be added to L, such
as AA2. That is why it is still shown as an available drive in the top right panel.
18
N Series SnapManager with Microsoft SQL
Migrating databases to one virtual disk
Migrating a database to a single virtual disk is easy (see Figure 12 on page 18):
1. Highlight the database that you want to move.
2. Highlight the virtual disk that you want the database to move to.
3. Click <--> and the database moves to the lower panel.
The files of a database can be spread over several virtual disks. The next section
illustrates how to move a database to a number of virtual disks.
Migrating one database to multiple virtual disks
A common issue when traditional local disks are used for storing database files is
load balancing the disk I/O over available disk drives. When a filer is used for
storing databases, Data ONTAP automatically load balances I/O evenly over
available disks. Most databases stored on IBM N series filers use just one virtual
disk, but there are exceptions and reasons for using multiple virtual disks that
utilize different IBM N series volumes:
򐂰 The transaction log file and data file are traditionally located in different
devices, primarily for safety reasons. If the volume with the data files has a
double disk failure, then the transaction log file is still available. Double disk
failure happens very rarely and the transaction log is only useful if the full
backup and backed up transaction logs have been archived.
򐂰 The access to the transaction log is sequential and the access to data files is
mostly random. Therefore, in a case of poor performance because the volume
disk drives have high utilization but low throughput, performance can be
improved by moving the transaction log to another virtual disk located in
another volume and decreasing the disk utilization.
򐂰 A volume must be large enough to contain the physical size of a database, its
growth, and Snapshots backups. There is no exact point when a database
becomes too big for one volume, but it is appropriate to start planning and to
analyze the I/O performance and space requirements when the database size
is around 700 GB to determine if moving to two volumes is appropriate.
򐂰 If the database consists of several very large tables with different access
patterns, locating each table in different file groups and locating each file
group in different volumes might increase I/O throughput.
Migrating the files of a database to different virtual disks requires two steps per
database file. Figure 13 on page 20 shows the expanded pubs database with its
two files, pubs and pubs log, located on the C drive.
N Series SnapManager with Microsoft SQL
19
Figure 13 Where to Move Databases
To move the pubs data file to the I drive and the pubs_log file to the Z drive:
1.
2.
3.
4.
5.
6.
7.
Expand pubs database so that all file groups and files are visible (Figure 13).
Highlight the pubs data file.
Highlight the I drive.
Click <--> to move the pubs database with the data file to the lower panel.
Highlight the pubs_log file.
Highlight the Z drive.
Click <--> so that all of the pubs databases move down to the lower panel.
When a database occupies more than one virtual disk, the disks cannot be
shared by any other database. Here, the I and Z drives are removed from the
available drive list.
SnapInfo
SnapInfo is a directory structure with metadata related to backup sets, copies of
backed up transaction logs, and streaming data when streaming backup is used.
The default is a single SnapInfo directory for all databases that SMSQL
manages.
20
N Series SnapManager with Microsoft SQL
Figure 14 shows the single page that opens when the default is activated.
Figure 14 Specify single Snaplnfo directory
You can also configure multiple SnapInfo directories by selecting Advanced
SnapInfo Directories (Figure 15).
Figure 15 Specify SnapInfo type
N Series SnapManager with Microsoft SQL
21
The advanced selection opens three different pages and is flexible so that the
administrator can configure the SMSQLs according to the local environment,
such as using different Snaplnfos for databases in a volume that is being
mirrored by SnapMirror and for databases using another volume that is not
mirrored.
The first page makes it possible to select different Snaplnfo directories for each
SQL Server instance (Figure 16).
Figure 16 SnapInfo per SQL Server instance
This example includes two SQL Server instances:
򐂰 SQL Server instance 8450-PMLAB01 has been configured with a Snaplnfo
directory on the S drive.
򐂰 SQL Server instance SQL_Server_2 has been configured with a Snaplnfo
directory on the Y drive.
Figure 17 on page 23 shows the next SnapInfo setup page.
22
N Series SnapManager with Microsoft SQL
Figure 17 SnapInfo per database
This process makes it possible to configure SnapInfo directories for each
database that does not share any virtual disk with any other database.
Figure 18 shows the structure and contents of Snapinfo.
Figure 18 Structure of SnapInfo
N Series SnapManager with Microsoft SQL
23
The structure is fixed but most of the names depend on the environment. The top
level is the SnapInfo directory. The second level is either the name of the SQL
Server instance or the name of the virtual disk, followed by the names of the
databases where backup information is located. The main information is under
each database subdirectory: FG__ (if a full backup has been created) and
LogBackup (if the transaction log has been backed up). The information in
Figure 18 on page 23 is important to know if a disaster occurs and the database
must be restored from the archive.
Migrating back to local disk
Migrating databases from local disks to virtual disks is, by default, the expected
action, but it is possible to turn on an option that makes it workable to migrate
databases back to local disks. To do this:
1. Select Configuration Wizard Option from the Tools menu (Figure 19).
Figure 19 Migrating back to local disk option
2. Select Migrating Database(s) Back to Local Disk.
3. After the option has been set, you can see and select local disks (see
Figure 20 on page 25).
24
N Series SnapManager with Microsoft SQL
Figure 20 Migrating back to local disk
You can migrate databases back to local only when they are present in the upper
left panel, and each migrating database must end up in the bottom panel.
Therefore, a database that is already located on a virtual disk and is located in
the bottom panel is reconfigured by first moving it to the top left panel.
Database consistency: DBCC CHECKDB
The authors strongly recommend that you check the consistency of a database
before you migrate it. There is nothing more frustrating than discovering that a
backed up database is inconsistent only because the original source was
inconsistent.
There are a couple of pages related to verifying databases for consistency. The
first opens during the initial setup by the configuration wizard (Figure 21 on
page 26). The default is to run DBCC before the database is migrated, which is
the recommended option. Verifying a database takes resources away from the
production environment, therefore, offloading verification to another remote SQL
Server instance is recommended.
N Series SnapManager with Microsoft SQL
25
Figure 21 DBCC options wizard
You can define general verification settings used during backup and recovery
setting in the SMSQL options menu as follows:
1. Highlight the Options menu.
2. Select Database Verification Setting.
3. Browse to the SQL Server that you want to run DBCC and that can be a
remote server.
4. Open the DBCC Options (Figure 22 on page 27).
26
N Series SnapManager with Microsoft SQL
Figure 22 DBCC CHECKDB options
5. The DBCC default verification options are PHYSICAL_ONLY and
NOINFORMSG.
Verifying a database takes resources and time; however, PHYSICAL_ONLY
takes the least time. Even so, it is not a quick operation.
The other DBCC CHECKDB options are:
򐂰 NOINDEX does not check table indexes on user tables.
򐂰 TABLOCK causes DBCC CHRCKDB to obtain shared table locks. TABLOCK
causes DBCC to run faster on a database under heavy load, but decreases
the concurrency available on the database while DBCC CHRCKDB is
running. A table lock allows the transaction to read table objects but not to
insert or change data before DBCC has finished checking that table.
򐂰 PHYSICAL_ONLY limits the checking of the integrity of the physical structure
of all pages, the record header, and the ID between the page ID and index ID.
Also, it detects torn pages.
N Series SnapManager with Microsoft SQL
27
Backup databases
The design and implementation of the physical layouts of the databases indirectly
dictates the methodology that the databases use for backup. Full backups of
user-defined databases through SMSQL are implemented using volume-level
Snapshot copies, which means that all databases that utilize virtual disks located
in the same volume are backed up together, except if the virtual disk contains a
system database. If this is the case, full backup is streaming-based and is done
per database, independent of other databases using the virtual disk or volume.
This is not recommended because streaming-based full backup is slower than
Snapshot technology-based full backup and streaming-based backup requires
much more space in the related SnapInfo directory.
Backup can be done with the help of the backup wizard or the SnapManager
Backup tab. Figure 23 shows the crucial page, which is the same for both tools.
Figure 23 Main backup page
28
N Series SnapManager with Microsoft SQL
This page presents several interesting points:
򐂰 SMSQL can only back up databases that are located on virtual disks.
򐂰 Databases using virtual disks located in the same filer volume can only be
backed up together. If you select or clear one of the databases, the action
affects all databases utilizing the same volume.
򐂰 A transaction log is logically truncated when it is backed up and not when a
full backup is created.
򐂰 Full backup can be followed by backup of the transaction log.
򐂰 Full backups use Snapshot and are quick.
򐂰 Transaction log backup is streaming-based and is done by SQL Server.
򐂰 The backup of system databases is streaming-based; see Figure 24 on
page 30.
򐂰 When a used database is sharing a virtual disk with a system database, the
backup is streaming-based backup.
򐂰 Backups can automatically be scheduled (set up through the Schedule
button). The SQL Server Agent must be running to schedule backup jobs.
All backup sets take space in their Snaplnfo directory for metadata, backed up
transaction logs, and streaming-based backed up databases:
򐂰 Metadata per backup set is only a few KB.
򐂰 The size of a backed up transaction log depends mostly on the number of new
transactions since the last transaction log backup.
򐂰 The size of a streaming-based full backup is roughly the same size as the
online database.
Correct backups are critical for recovering a corrupt database; therefore, the
authors strongly recommend that you check new backup reports daily for
possible errors. An example of a report is shown in Figure 24 on page 30.
N Series SnapManager with Microsoft SQL
29
Figure 24 Report of system database backup
Restore databases
It is critical to be able to restore a corrupt database quickly and efficiently when
needed. It is never possible to plan when a disaster might occur, and therefore,
we strongly recommend that you test the implemented backup and restore
processes occasionally. The process was indirectly decided upon when the
physical layout of the database was implemented.
Databases that are not sharing any virtual disks with another database can be
restored without any effect on any other database. The SnapManager Restore
Wizard or SnapManager Restore tab can be used for restoring databases. Both
tools use the same central page (Figure 25 on page 31).
30
N Series SnapManager with Microsoft SQL
Figure 25 Main restore screen
Checklist
This Redpaper has discussed how to lay out database files on IBM N series
virtual disks, and it has illustrated how to use SMSQL. We have made
recommendations and illustrated them throughout this paper. To help you with
the layout process, we provide a series of questions that you should ask and
considerations that you should make during the process:
1. What is the number of SQL Server instances per server?
2. What is the number of databases per SQL Server instance?
a. Are there more databases than available drive letters?
b. How will you group databases when storing them in a single virtual disk?
c. Is there one large database?
d. Are there small databases?
N Series SnapManager with Microsoft SQL
31
3. What are the space requirements?
a. What is the initial size per database?
b. What is the growth rate per database?
c. What is the change rate per database?
d. What is the physical I/O rate per database?
e. What is the space for the transaction log file?
f. What are the performance requirements?
g. What is the space for system databases?
h. What are the SnapInfo space requirements?
4. What is the number of Windows servers connected to one IBM N series
storage device?
A relationship of one volume per server is recommended.
5. Some SnapMirror considerations are:
a. How many SnapInfo directories are there?
b. We recommend that you locate all database files in one single volume.
c. Will you use rolling Snapshot backups to update the mirror more
frequently than when the database is backed up?
6. Some backup considerations are:
a. Is full backup done with Snapshot or streaming backup?
b. A drive letter must be available for verifying a backed up database.
c. Give some thought to truncating the transaction log.
7. Some restore considerations are:
a. Are there many databases in one virtual disk?
b. Is there one single database out of several in one virtual disk?
c. Are you planning to bypass database verification?
32
N Series SnapManager with Microsoft SQL
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Poughkeepsie
Center.
Thorsten Busch is an IT specialist for storage workshops at the Advanced
Technical Support Organization in Mainz, Germany. He teaches IBM storage
classes worldwide on IBM N series, San Volume Controller, and DS8000.
Alex Osuna is a Project Leader at the International Technical Support
Organization in Tucson, Arizona. He has 27 years of experience in the IT industry
and for more than 21 years has specialized in storage hardware and software.
He holds over 10 certifications from IBM, Microsoft, and Redhat and has a
Bachelor degree from Phoenix University.
Thanks to the following people for their contributions to this project:
Gerson Finlev, Network Appliance, Inc.
N Series SnapManager with Microsoft SQL
33
34
N Series SnapManager with Microsoft SQL
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright International Business Machines Corporation 2006. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
35
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
®
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
IBM®
™
Redbooks™
System Storage™
The following terms are trademarks of other companies:
Snapshot, SnapDrive, Data ONTAP, SnapRestore, SnapMirror, SnapManager, Network Appliance, The
Network Appliance logo, the bolt design,Camera-to-Viewer, Center-to-Edge, ContentDirector,
ContentFabric, NetApp Availability Assurance, NetApp ProTech Expert, NOW, NOW NetApp on the Web,
RoboCache, RoboFiler, SecureAdmin, Serving Data by Design, Smart SAN,The evolution of storage, Virtual
File Manager, and Web Filer are trademarks of Network Appliance, Inc. in the U.S. and other countries. All
other brands or products are trademarks or registered trademarks of their respective holders and should be
treated as such.
Microsoft, Windows server, Windows, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
36
N Series SnapManager with Microsoft SQL