Microsoft SQL Server 2008 R2 Unleashed- P45 pps

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.. For a more detaile

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 transacopera-tion 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 transactransac-tion 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

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 transacopera-tions 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

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

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

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

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

FIGURE 14.3 The Back Up Database Options page in SSMS

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

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 operaopera-tions 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

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

TABLE 14.1 BACKUP DATABASE Options

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

TABLE 14.1 BACKUP DATABASE Options

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