Microsoft SQL Server 2008 R2 Unleashed- P45 pps

ptg
384
terms of server overhead because every transaction is captured and retained in the transac-
tion log so that they can be recovered in the event of a failure.
TIP
A common problem in SQL Server environments involves a database that is set to full
recovery but whose transaction log is never backed up. In this scenario, the transaction
log can grow to the point that it fills up the drive on which the transaction log is locat-
ed. You need to ensure that you have regularly scheduled backups of the transaction
log if you have set your database to full recovery. The transaction log backups allow
you to recover from a media failure and also remove the inactive portion of the transac-
tion log so that it does not need to grow.
Bulk-Logged Recovery
The bulk-logged recovery model is similar to full recovery, but it differs in the way that
bulk operations are captured in the transaction log. With full recovery mode, SQL Server
writes every row to the transaction log that is inserted with BCP or BULK INSERT. Bulk-
logged recovery keeps track of the extents that have been modified by a bulk load opera-
tion but does not write each row to the transaction log. This reduces the overall size of the
transaction log during bulk load operations and still allows the database to recover after a
bulk load operation has occurred.
The biggest downside to setting a database to bulk-logged recovery is that the log backups
for the databases can be large. The log backups are large because SQL Server copies all the
data extents that have been affected by bulk load operations since the last backup of the
transaction log. Remember that data extents consist of eight data pages each, and each
page is 8KB in size. This may not seem like much by today’s standards, but it can be
significant when you’re bulk loading a large table. For example, consider a table occupy-
ing 1GB of space that is truncated each week and reloaded with a bulk insert. The bulk
insert operation goes relatively fast because the rows are not being written to the transac-
tion log, but the backup of the transaction log is much larger.
NOTE
In testing we did on a table with approximately 2.4 million rows (that occupied 500MB

of space), the log file grew over 2GB during a bulk insert operation that reloaded all
rows in a full recovery mode database. In contrast, the same bulk insert operation on
the database with bulk-logged recovery grew the log by only 9MB. However, the backup
of the 9MB transaction log was approximately 500MB. This is much larger than the
actual log itself because the bulk operation caused all the modified extents from the
bulk insert operation to be stored in the log backup as well.
The other downside to bulk-logged recovery is that with it, you may sacrifice the ability to
restore to the most recent point in time. This situation occurs if a bulk insert operation
CHAPTER 14 Database Backup and Restore
Download from www.wowebook.com
ptg
385
Backup Devices
14
has occurred since the last database backup and a media failure occurs. In this case, the
restores can occur for any backups that were taken that do not contain a bulk insert opera-
tion, but any outstanding changes that were retained in the transaction log cannot be
applied. The reason is that bulk operations are not written to the log directly in this model
and cannot be recovered. Only bulk operations captured in a backup can be restored.
If transactions have occurred in a database since the last backup, and no bulk insert opera-
tions have occurred, you can recover those pending transactions as long as the media
containing the transaction log is still available. The tail of the transaction log can be
backed up and applied during a restore operation. The tail of the log and other restore
scenarios are discussed in the “Restore Scenarios” section, later in this chapter.
Simple Recovery
The simple recovery model is the easiest to administer, but it is the option that has the
greatest possibility for data loss. In this mode, your transactions log is truncated automati-
cally based on a checkpoint in the database. These checkpoints happen often, and they
cause the data in the transaction log to be truncated frequently.
NOTE

Prior to SQL Server 2000, the trunc. log on checkpoint database option was
used to truncate the log on a checkpoint and produce the same type of behavior as
simple recovery. This database option and the equivalent backup options NO_LOG and
TRUNCATE_ONLY are no longer supported. The only supported method for truncating
the transaction log in SQL Server 2008 is to switch the database to use the simple
recovery model.
The most important point to remember about the simple recovery model is that with it,
you cannot back up the transaction log that captures changes to your database. If a media
failure occurs, you are not able to recover the database activity that has occurred since the
last database backup. This is a major exposure, so simple recovery is not recommended for
production databases. However, it can be a good option for development databases where
the loss of some transactions is acceptable. In these types of environments, simple recov-
ery can equate to saved disk space because the transaction log is constantly truncated. The
administration in these environments is reduced as well because the transaction log
backups are not an option and thus do not need to be managed.
For a more detailed discussion of the transaction log, see Chapter 31, “Transaction
Management and the Transaction Log.”
Backup Devices
A backup device is used to provide a storage destination for the database backups created
with SQL Server. Backups can be written to logical or physical devices. A logical device is
essentially an alias to the physical device and makes it easier to refer to the device when
Download from www.wowebook.com
ptg
386
performing database backups. The physical backup devices that SQL Server can write to
include files on local disks, tape, and network shares.
Disk Devices
A disk device is generally stored in a folder on a local hard drive. This should not be the
same hard drive where your data is stored! Disk devices have several advantages, including
speed and reliability. If you have ever had a backup fail because you forgot to load a tape,

you can appreciate the advantage of disk backups. On the other hand, if backups are
stored on a local disk and the server is destroyed, you lose your backups as well.
NOTE
Disks have become increasingly popular media as the prices have fallen. Storage area
networks (SANs) and other large-scale disk solutions have entered mainstream usage
and offer a large amount of storage at a relatively inexpensive price. They also offer
redundancy and provide fault tolerance to mitigate the chance of losing data on a disk.
Finally, increased network bandwidth across LANs and WANs has allowed for the move-
ment of backups created on disk to alternate locations. This is a simple way to achieve
additional fault tolerance.
Tape Devices
Tape devices are used to back up to tape. Tape devices must be directly connected to the
server, and parallel backups to multiple drives are supported to increase throughput. Tape
backups have the advantage of being scalable, portable, and secure. Scalability is impor-
tant as a database grows; available disk space often precludes the use of disk backups for
large databases. Because tapes are removable media, they can easily be transported offsite,
where they can be secured against theft and damage.
SQL Server supports the Microsoft Tape Format (MTF) for backup devices, which means
that SQL Server backups and operating system backups can share the same tape. This capa-
bility is convenient for small sites with shared use servers and only one tape drive. You
can schedule your SQL Server backups and file backups without having to be onsite to
change the tape.
Network Shares
SQL Server 2008 allows the use of both mapped network drives and Universal Naming
Convention (UNC) paths in the backup device filename. A mapped network drive must be
mapped as a network drive in the session in which SQL Server is running. This is prone to
error and generally not recommended. UNC paths are much simpler to administer. With
UNC backup devices, the SQL Server service account must be able to see the UNC path on
the network. This is accomplished by granting the service account full control permission
on the share or by making the service account a member of the Administrators group on

the remote computer.
Keep in mind that backups performed on a network share should be done on a dedicated
or high-speed network connection, and the backup should be verified to avoid potential
CHAPTER 14 Database Backup and Restore
Download from www.wowebook.com
ptg
387
Backup Devices
14
corruption introduced by network error. The time it takes a backup to complete over the
network depends on network traffic, so you need to take this factor into consideration
when planning your backups.
Media Sets and Families
When you’re backing up to multiple devices, the terms media set and media family are used
to describe the components of the backup. A media set is the target destination of the
database backup and comprises several individual media. All media in a media set must be
of the same type (for example, all tape or all disk). A media family is the collection of
media associated with an individual backup device. For example, a media family could be
a collection of five tapes contained in a single tape device.
The first tape in the media family is referred to as the initial media, and the subsequent
tapes are referred to as continuation media. All the media families combined are referred to
as the media set. If, for example, a backup is written to 3 backup devices (each with 4
tapes), the media set would contain 3 media families and consist of a total of 12 tapes. It
is recommended to use the
MEDIANAME parameter of the BACKUP command to specify a
name for the media set. This parameter associates the multiple devices as members of the
media set. The MEDIANAME parameter can then be referenced in future backup operations.
Creating Backup Devices
You can create logical backup devices by using T-SQL or SSMS. The T-SQL command for
creating these logical backup devices is sp_addumpdevice, which has the following syntax:

sp_addumpdevice [ @devtype = ] ‘device_type’
, [ @logicalname = ] ‘logical_name’
, [ @physicalname = ] ‘physical_name’
[ , { [ @cntrltype = ] controller_type |
[ @devstatus = ] ‘device_status’ }
]
The following sample script demonstrates the creation of the different types of backup
devices:
Local Disk
EXEC sp_addumpdevice ‘disk’, ‘diskdev1’,
‘c:\mssql2008\backup\AdventureWorks2008.bak’
Network Disk
EXEC sp_addumpdevice ‘disk’, ‘networkdev1’,
‘\\myserver\myshare\AdventureWorks2008.bak’
Tape
EXEC sp_addumpdevice ‘tape’, ‘tapedev1’, ‘\\.\tape0’
To create backup devices with SSMS, you navigate to the Server Objects node in the
Object Explorer and right-click Backup Devices and then New Backup Device; the Backup
Download from www.wowebook.com
ptg
388
FIGURE 14.2 The Back Up Database window in SSMS.
Device screen appears. This screen includes a text box for the device name, along with a
section to select the destination for the device. This is the physical location, and you can
select either Tape or File.
Backing Up a Database
Now that you know the types of backups, the recovery models they relate to, and the
devices you can write to, you are ready to back up your database. You can create backups
with SQL Server 2008 by using either the SSMS or T-SQL. Some backups are supported
only through T-SQL, but the vast majority can be accomplished with either tool.

Creating Database Backups with SSMS
The backup options in SSMS are accessible through the Object Explorer. For example, you
can right-click the AdventureWorks2008 database in the SSMS Object Explorer, select Tasks
and Backup, and a backup window like the one shown in Figure 14.2 appears.
CHAPTER 14 Database Backup and Restore
The Source section on the Back Up Database window contains information relative to the
database that will be backed up. The target database is displayed in the first drop-down,
along with the recovery model set for the database. The backup types available in the
drop-down are dependent on the recovery model. For simple recovery, only full and differ-
Download from www.wowebook.com
ptg
389
FIGURE 14.3 The Back Up Database Options page in SSMS.
Backing Up a Database
14
ential backup types are available. For full recovery and bulk-logged recovery models, all
backup types are available in the drop-down.
The Backup Set section allows you to give the backup a meaningful name and specify
when the backup set will expire. When the backup set expires, the backup can be overwrit-
ten and is no longer retained. If the backup is set to expire after 0 days, it will never expire.
The Destination section identifies the disk or tape media that will contain the backup. You
can specify multiple destinations in this section by clicking the Add button. For disk
media, you can specify a maximum of 64 disk devices. The same limit applies to tape
media. If multiple devices are specified, the backup information is spread across those
devices. All the devices must be present for you to be able to restore the database. If no
tape devices are attached to the database server, the Tape option is disabled.
You can select several different types of options for a database backup. Figure 14.3 shows
the options page available when you back up a database by using SSMS.
The Overwrite Media section allows you to specify options relative to the destination
media for the backup. Keep in mind that a given media set can contain more than one

backup. This can occur if the Append to the Existing Backup Set options is selected. With
this option, any prior backups contained on the media set are preserved, and the new
backup is added to it. With the Overwrite All Existing Backup Sets option, the media set
contains only the latest backup, and no prior backups are retained.
Download from www.wowebook.com
ptg
390
CHAPTER 14 Database Backup and Restore
You can use the options in the Reliability section to ensure that the backup that has been
created can be used reliably in a restore situation. Verifying the backup when finished is
highly recommended, but doing so causes the backup time to be extended during the veri-
fication. Similarly, the Perform Checksum Before Writing to Media option helps ensure
that you have a sound backup, but again, it causes the database backup to run longer.
The options in the Transaction Log section are available for databases in the full recovery
or bulk-logged model. These options are disabled in the simple recovery model. The
Truncate the Transaction Log option causes any inactive portion of the transaction log to
be removed after the database backup is complete. The inactive portion of the log and
other detail of the transaction log are discussed in more detail in Chapter 30 “Transaction
Management and the transaction log”. This option, the default, helps keep the size of the
transaction log manageable. The Back Up the Tail of the Log option is related to point-in-
time restores and is discussed in more detail in the “Restore Scenarios” section later in
this chapter.
The set of options in the Tape Drive section are enabled only when tape has been selected
for the destination media. Selecting the Unload the Tape After Backup option causes the
media tape to be ejected when the backup completes. This option can help identify the
end of a backup and prevent the tape from being overwritten the next time the backup
runs. The Rewind the Tape Before Unloading option is self-explanatory; it causes the tape
to be released and rewound before you unload the tape. The last set of options relate to
compressed database backups. The options for compressed backups are discussed in detail
in the Compressed Backup secion later in this chapter.

NOTE
Keep in mind that all backups can be performed while the database is in use. SQL
Server is able to keep track of the changes occurring during the backup and can main-
tain transactional consistency as of the end of the backup. You need to consider some
performance overhead during the actual backup, but the backup can occur during active
database hours. However, it is still a good idea to schedule your database backups
during off-hours, when database activity is at a minimum.
Creating Database Backups with T-SQL
The T-SQL BACKUP command offers a myriad of options to perform all the backup opera-
tions available in SSMS. However, SSMS does not support some backup operations that can
be performed only with T-SQL.
The BACKUP command comes in three different flavors. The first flavor involves the backup
of a database. The command syntax starts with BACKUP DATABASE, followed by the relevant
parameters and options. The second flavor involves the backup of a file or filegroup that is
part of the database. The command syntax for this type of backup also utilizes the BACKUP
Download from www.wowebook.com
ptg
391
Backing Up a Database
14
DATABASE command, but a file or filegroup is specified after the database name to identify
which parts of the database should be backed up. The last flavor involves the backup of
the database’s transaction log. The syntax for backing up the transaction log starts with
BACKUP LOG. Each flavor shares many of the same options. The basic syntax for backing up
a database follows:
BACKUP DATABASE { database_name | @database_name_var }
TO < backup_device > [ , n ]
[ [ MIRROR TO < backup_device > [ , n ] ] [ next-mirror ] ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]

[ [ , ] { CHECKSUM | NO_CHECKSUM } ]
[ [ , ] COMPRESSION | NO_COMPRESSION]
[ [ , ] COPY_ONLY ]
[ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ]
[ [ , ] DESCRIPTION = { ‘text’ | @text_variable } ]
[[,] DIFFERENTIAL ]
[ [ , ] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] { FORMAT | NOFORMAT } ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] MEDIADESCRIPTION = { ‘text’ | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage
] ]
]
The number of options is extensive, but many of them are optional. A BACKUP DATABASE
command can be as simple as the following example:
BACKUP DATABASE [AdventureWorks2008]
TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_COPY.bak’
The first part of the BACKUP command is related to the database you want to back up
(database_name), followed by the location to which you want to write the backup
(backup_device). The remainder of the syntax relates to the options that can be specified
following the WITH clause. These options determine how your backup will be created and

the properties of the resulting backup. Table 14.1 outlines these options.
Download from www.wowebook.com
ptg
392
CHAPTER 14 Database Backup and Restore
TABLE 14.1 BACKUP DATABASE Options
Option Description
BLOCKSIZE
The physical block size that will be used to create the backup.
The default is 64KB.
CHECKSUM | NO_CHECKSUM When CHECKSUM is specified, a checksum is calculated before
the backup is written to validate that the backup is not corrupt.
The default is NO_CHECKSUM.
COMPRESSION |
NO_COMPRESSION
This new option in SQL Server 2008, available only with the
Enterprise or Developer Edition, causes the backup file to be
compressed. The default is NO_COMPRESSION.
STOP_ON_ERROR |
CONTINUE_AFTER_ERROR
This option is used in conjunction with the CHECKSUM option. The
STOP_ON_ERROR option, which is the default, causes the backup
to fail if the checksum cannot be validated.
DESCRIPTION
This is a 255-character description of the backup set.
DIFFERENTIAL
This option causes a differential backup to occur, which captures
changes only since the last backup.
EXPIREDATE
This option specifies the date on which the backup set will expire

and be overwritten.
RETAINDAYS
This option specifies the number of elapsed days before the
backup set can be overwritten.
PASSWORD
This is a password that must be specified when restoring the
backup set.
FORMAT | NOFORMAT FORMAT causes the existing media header and backup set to be
overwritten. The default is NOFORMAT.
INIT | NOINIT The INIT option causes a backup set to be overwritten. The
backup set is not overwritten if the backup set has not expired or
if it does not match the media name specified with the NAME
option. NOINIT, which is the default, causes the backup set to
be appended to the existing media.
NOSKIP | SKIP NOSKIP, which is the default, allows backup sets to be overwrit-
ten if they have expired. The SKIP option skips expiration and
media name checks and is used to prevent the overwriting of
backup sets.
MEDIADESCRIPTION
This is a 255-character description for the entire backup media
containing the backup sets.
Download from www.wowebook.com
ptg
393
Backing Up the Transaction Log
14
TABLE 14.1 BACKUP DATABASE Options
Option Description
MEDIANAME
This is a 128-character name for the backup media. If it is speci-

fied, the target media must match this name.
MEDIAPASSWORD
This is a password for the media set. When media is created
with this password, the password must be supplied to be able to
create a backup set on that media or to restore from that media.
NAME
This is a 128-character name for the backup set.
NOREWIND | REWIND This option is used for tape operations. REWIND, which is the
default, causes the tape to be released and rewound after it fills.
NOUNLOAD | UNLOAD This option is used for tape operations. NOUNLOAD, which is the
default, causes the tape to remain in the tape drive after a
backup completes. UNLOAD causes the tape to be rewound and
unloaded when the backup completes.
RESTART
This option has no effect and is in place only for backward
compatibility.
STATS
This option causes completion statistics to be displayed at the
specified interval to assess progress.
COPY_ONLY
This option allows a backup to be made without affecting the
normal sequence of backups.
The “Backup Scenarios” section, later in this chapter, provides some examples of how to
use these options.
Backing Up the Transaction Log
As discussed, the full and bulk-logged recovery models cause transactions to be written to
the database’s transaction log. These transactions should be backed up periodically for two
main reasons. First, the transaction log backups can be used in case of a media failure to
restore work completed in the database. These backups limit your exposure to data loss
and enable you to reapply changes that have occurred.

The second reason for backing up the transaction log is to keep the size of the log
manageable. Keep in mind that SQL Server is a write-ahead database management system
(DBMS) and thus writes most changes to the transaction log first, before it updates the
actual data files. This type of DBMS is great for recovery purposes, but it can be a real
headache if you do not periodically clear those transactions from the log. Without a
Download from www.wowebook.com