Hướng dẫn học Microsoft SQL Server 2008 part 100 potx

The transaction log can be configured, based on your recovery needs, according to one of the following recovery models: ■ Simple: No transaction log backups ■ Bulk-logged: The bulk-logge

Nielsen c40.tex V4 - 07/21/2009 2:20pm Page 952

Recovery Planning

IN THIS CHAPTER Understanding the recovery models

Backing up user databases

Understanding and working with the transaction log

Recovering a lost database, a lost system database, or the entire server

The foundation for this book, the Information Architecture Principle

(introduced in Chapter 2), puts into words the reason why there must be

a solid recovery plan

Information is an organizational asset, and, according to its value and scope, must be

organized, inventoried, secured, and made readily available in a usable format for daily

operations and analysis by individuals, groups, and processes, both today and in the

future.

It goes without writing that for information to be ‘‘readily available both today

and in the future,’’ regardless of hardware failure, catastrophes, or accidental

dele-tion, there has to be a plan B

Obviously, this is an imperfect world and bad things do happen to good people

Since you’re bothering to read this chapter, I’ll be honest and agree that doing

backups isn’t very exciting In some jobs excitement means trouble, and this is

one of them To a good DBA, being prepared for the worst means having a sound

recovery plan that has been tested more than once

Consistent with the flexibility found in other areas of SQL Server, there are

mul-tiple ways to perform a backup, each suited to a different purpose SQL Server

offers three recovery models, which help organize the backup options and

sim-plify database administration

This chapter discusses the concepts that support the recovery effort, which entail

both backup and restoration It seems foolish to study backup without also

learn-ing about how restoration completes the recovery

Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 954

Part VI Enterprise Data Management

Recovery planning is not an isolated topic Transactional integrity (Chapter 66) is deeply involved in the theory behind a sound recovery plan Once the recovery strategy is deter-mined, it’s often implemented within a maintenance plan (Chapter 42) Because recovery is actually a

factor of availability, the high availability of log shipping (Chapter 46), database mirroring (Chapter 47),

and failover clustering (Chapter 48) is also a factor in recovery planning.

While backups tend to be boring, restores tend to occur when people are excited For this reason, it

makes sense to be as familiar with restoration as with backup Without restoring a backup, there is no

way to determine whether the backup is good and can be used when it is really needed

What’s New in SQL Server Recovery?

Backup compression is introduced in SQL Server 2008 Enterprise Edition This is one of the most frequently

requested features and I am happy that this is released now Although this feature is supported only in

Enterprise Edition, every SQL Server 2008 edition can restore a compressed backup

The following backup commands are no longer available in SQL Server 2008:

■ BACKUP LOG WITH NO_LOG

■ BACKUP LOG WITH TRUNCATE_ONLY

There is no replacement for these options in SQL Server 2008 These statements were used in previous

versions of SQL Server to manually force the transaction log to be truncated without taking a backup These

options broke the log chain and the database was not protected from media failure until the next full or

differential log backup

A new feature has been added to rebuilding SQL Server 2008 system databases The system databases used

for rebuilding the local system databases do not come from the original installation media and are located

locally in the\BINN\Templates folder and setup.exe in the 100\Setup Bootstrap\Release folder

Recovery Concepts

The concept of database recovery is based on the D in the transactional-integrity ACID

proper-ties — transactional durability Durability means that a transaction, once committed, regardless of

hardware failure, must be persistent

SQL Server accomplishes transactional durability with a write-ahead transaction log Every transaction is

written to the transaction log prior to being written to the data file This provides a few benefits to the

recovery plan:

■ The transaction log ensures that every transaction can be recovered up to the very last moment before the server stopped

■ The transaction log permits backups while transactions are being processed

■ The transaction log reduces the impact of a hardware failure because the transaction log and the data file may be placed on different disk subsystems

The strategy of a recovery plan should be based on the organization’s tolerance level, or pain level, for

lost transactions Recovery-plan tactics involve choosing among the various backup options, generating a

backup schedule, and off-site storage

SQL Server backup and recovery are very flexible, offering three recovery models from which to choose

The transaction log can be configured, based on your recovery needs, according to one of the following

recovery models:

■ Simple: No transaction log backups

■ Bulk-logged: The bulk-logged recovery model minimally logs bulk operations, although fully

logging other transactions

■ Full: All transactions are logged

In addition, SQL Server offers the following backup options:

■ Full: Complete backup of all data

■ Differential: Backup of all data pages modified since the last full backup

■ Partial: Backup of primary filegroup, every read/write filegroup, and any optionally specified

read-only files

■ Transaction log: Backup of all transactions in the log

■ File or filegroup: Backup of all the data in the file or filegroup

■ File differential: Backup of all data pages modified since the last file or filegroup backup

■ Copy-only: Backup of all the data without affecting the overall backup and restore procedures

for the database

Backing up the database may not be the only critical backup you have to perform If the

database-security scheme relies on Windows authentication, backing up the Windows users

is important as well The point is that the SQL Server recovery plan must fit into a larger IT recovery

plan.

Because SQL Server backups are very flexible, they can handle any backup-to-file ratio A single backup

instance can be spread across several backup files, creating a backup set Conversely, a single backup set

can contain multiple backup instances

Restoration always begins with a full backup Differential and transaction log backups then restore the

transaction that occurred after the full backup

Recovery Models

The recovery model configures SQL Server database settings to accomplish the type of recovery required

for the database, as detailed in Table 41-1 The key differences among the recovery models involve how

the transaction log behaves and which data is logged

While the durability of the transaction is configurable, the transaction log is still used as a write-ahead

transaction log to ensure that each transaction is atomic In case of system failure, the transaction log is

used by SQL Server to roll back any uncommitted transactions, as well as to complete any committed

transactions

Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 956

Part VI Enterprise Data Management

TABLE 41-1

SQL Server Recovery Models

Recovery

Model Description

Transaction Atomicity

Transaction Durability

Bulk-Copy Operations (SELECT INTO and BULK INSERT)

Simple Transaction log is

continuously truncated

on checkpoints

Yes No, can restore only

to the last full or differential backup

Minimally logged — high performance

Bulk-Logged

Bulked operations are minimally logged and all other transactions are fully logged

Minimal logging logs only the information required to recover the transaction but does not allow point-in-time recovery

Yes Maybe, can restore

only to the last full

or differential backup, or to the last transaction-log backup if no bulk-copy operations have been performed

Minimally logged — high performance

Full All transactions are

logged and stored until transaction-log backup

Yes Yes, can restore up

to the point of recovery

Slower than simple or bulk-logged

Simple recovery model

The simple recovery model is suitable for databases that require that each transaction be atomic, but not

necessarily durable The simple recovery model directs SQL Server to truncate, or empty, the transaction

log on checkpoints The transaction log will keep a transaction until it’s confirmed in the data file, but

after that point the space may be reused by another transaction in a round-robin style This is the reason

why the simple recovery model does not support transaction log backup

A simple recovery model has the benefit of keeping the transaction log small, at the cost of potentially

losing all transactions since the last full or differential backup Choosing the simple recovery model

is the equivalent of setting thetruncate log on checkpointdatabase option totruein SQL

Server 7.0

A recovery plan based on a simple recovery model might perform full backups once a week and

differ-ential backups every weeknight, as shown in Figure 41-1 The full backup copies the entire database,

and the differential backup copies all changes that have been made since the last full backup

When restoring from a simple recovery plan:

1 Restore the most recent full backup.

2 Restore the most recent (optional) single differential backup.

FIGURE 41-1

A typical recovery plan using the simple recovery model includes only full and differential backups

Simple Recovery Model

Backup Plan

2300

Full Diff Diff Diff Diff Diff Diff

Best Practice

Simple recovery is mostly used for test and development databases or databases containing mostly

read-only data Simple recovery should not be used where loss of data since the last full or differential

backup is unacceptable In these cases, the full recovery model is recommended The full recovery model is

also a requirement for database mirroring and log shipping

The full recovery model

The full recovery model offers the most robust recovery plan Under this model all transactions,

includ-ing bulk-logged operations, are fully logged in the transaction log Even system functions such as index

creation are fully logged The primary benefit of this model is that every committed transaction in the

database can be restored right up to the point when failure occurred

Best Practice

Use the full recovery model for production user databases where data loss since the last full or differential

backup is unacceptable While it will run on a single-drive system, the transaction log should be

located on a fault-tolerant disk subsystem physically separate from the data files to ensure a high level of

transactional durability

The trade-off for this high level of transactional integrity is a certain amount of performance:

■ Bulk-logged and select-into operations will be slower If the database doesn’t import data using

these methods, this is a moot point

Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 958

Part VI Enterprise Data Management

■ Depending on the database activities, the transaction log may be huge This can be controlled

by performing regular transaction log backups If copious drive space is available, this too is a moot point

■ Backing up and restoring the transaction log will take longer than it does with the other recovery models However, in a crisis, restoring all the data will likely be more important than quickly restoring partial data

The full recovery model can use all types of database backups A typical backup schedule is illustrated

in Figure 41-2

FIGURE 41-2

A typical recovery plan using the full recovery model, using full, differential, and transaction-log

backups

Time Sun

Log 1000

Mon

Log

Tues

Log

Wed

Log

Thurs

Log

Fri

Log

Sat

Log Log

1200 Log Log Log Log Log Log

Log

1400 Log Log Log Log Log Log

Log

1600 Log Log Log Log Log Log

2300

Full Recovery Model Backup Plan

Full Diff Diff Full Diff Diff Diff

A full recovery backup plan will typically do a full database backup twice a week, and differential

back-ups every other night The transaction log is backed up throughout the day, from as little as two times

to as often as every 15 minutes The frequency of the transaction log backup is based on the maximum

amount of data that will be lost For example, perform transaction log backup every 15 minutes if you

can afford to lose up to 15 minutes of data

When restoring from the full recovery model, do the following:

1 Back up the current transaction log This will capture all the log records since the last

transaction log backup

If the disk subsystem containing the transaction log is lost, the database is marked suspect

by SQL Server and it is not possible to back up the current transaction log In this case, the best recovery option is to restore to the last transaction-log backup Other reasons for a database to

be marked suspect would be that the database file itself has been removed or renamed.

2 Restore the most recent full backup.

3 Restore the most recent single differential backup, if one has been made since the last full

backup

4 Restore, in sequence, all the transaction-log backups made since the time of the last full or

differential backup If the last backup was a full backup, then restoring it is sufficient If the

last backup was a differential backup, you need to restore the most recent full backup before

restoring the most recent differential

The Management Studio restore form (discussed in the section ‘‘Performing the Restore with

Manage-ment Studio,’’ later in this chapter) automatically helps you choose the correct set of backups, so it’s not

as complicated as it sounds

Bulk-logged recovery model

The bulk-logged recovery model is similar to the full recovery model except that the following

opera-tions are minimally logged:

■ Bulk import operations (BCP,BULK INSERT, andINSERT SELECT * FROM

OPENROWSET (BULK ))

■ SELECT INTOoperations

■ WRITETEXTandUPDATETEXTBLOB operations

■ CREATE INDEX(including indexed views)

■ ALTER INDEX REBUILDorDBCC DBREINDEXoperations

■ DROP INDEX

Because this recovery model minimally logs these operations, they run very fast The transaction log

only marks that the operations took place and tracks the extents (a group of eight data pages) that are

affected by the bulk-logged operation When the transaction log is backed up, the extents are copied to

the transaction log in place of the bulk-logged marker

The trade-off for bulk-logged operation performance is that the bulk-logged operation is not treated as a

transaction While the transaction log itself stays small, copying all affected extents to the transaction-log

backup can make the log-backup file very large

Because bulk-logged operations are minimally logged, if a failure should occur after the bulk-logged

operation but before the transaction log is backed up, the bulk-logged operation is lost and the restore

must be made from the last transaction log Therefore, if the database is using the bulk-logged recovery

model, every bulk-logged operation should be immediately followed by a transaction-log backup

This model is useful only when the database sees a large number of bulk-logged operations, and if it’s

important to increase their performance If the database is performing adequately during bulk-logged

operations in the full recovery model, bypass the bulk-logged recovery model

The simple recovery model minimally logs bulk-copy operations too.

Using this setting is essentially the same as setting theSELECT INTO/BULKCOPYdatabase option

totrue

Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 960

Part VI Enterprise Data Management

Best Practice

It is recommended to minimally use the bulk-logged recovery model because you lose the capability to

do point-in-time recovery to any point covered by a transaction log backup that contains even a single

minimally logged operation The best practice for production user databases is to use the full recovery model,

take a transaction log backup before performing bulk operations, switch to the bulk-logged model, perform

the bulk operations, and then immediately switch back to the full recovery model and take a transaction log

backup This enables point-in-time recovery and fully protects the data

Setting the recovery model

The model system database’s recovery model is applied to any newly created database The full

recov-ery model is the default for the Standard and Enterprise Editions The Personal and Desktop editions use

the simple recovery model as their default, but you can change the default by setting the recovery model

for the model system database

Using Management Studio, you can easily set the recovery model on the Options tab of the Database

Properties dialog Select the database and right-click to get to the Database Properties dialog

In code, the recovery model is set with theALTER DATABASEDDL command:

ALTER DATABASE DatabaseName SET Recovery Option;

The valid options areFULL,BULK_LOGGED, andSIMPLE The following code sets the

AdventureWorks2008sample database to the full recovery model:

USE AdventureWorks2008;

ALTER DATABASE AdventureWorks2008 SET Recovery FULL;

It is recommended to explicitly set the recovery model in the code that creates the database

The current recovery model for every database can be determined from code using the

sys.databases catalog view:

SELECT name, recovery_model_desc FROM sys.databases;

Modifying recovery models

While a production user database is typically set to a full recovery model, there’s nothing to prevent you

from switching between recovery models during operation to optimize performance and suit the specific

needs of the moment

It’s perfectly valid to run during the day with the full recovery model for transaction durability, and then

to switch to bulk-logged during data imports in the evening

During recovery it’s the full, differential, and transaction-log backups that count The recovery operation

doesn’t care how they were made

Because the simple recovery model does not permanently log the transactions, care must be taken in

switching to or from the simple recovery model:

■ If you are switching to simple, the transaction log should be backed up prior to the switch

■ If you are switching from simple, a full database backup should be performed immediately

following the switch

■ Schedule regular transaction log backups and update your recovery plans

Backing Up the Database

The actual process of performing a backup presents as many options as the underlying concepts present

Backup destination

A backup may copy the data to any one of two possible destinations:

■ Disk subsystem: A backup can be performed either to a local disk (preferably not the same

disk subsystem as the database files) or to another server’s disk drive by using the Universal

Naming Convention (UNC) The SQL Server account must have write privileges to the remote

drive in order to save the backup file

Best Practice

It is recommended to back up the databases to a local disk (not the same disk where databases are stored)

and then copy the backup files to tape or DVD (for small databases) using the organization’s preferred IT

backup method This method is the fastest for SQL Server, and it enables the IT shop to continue using a

familiar single-tape backup-software technique

■ Tape: SQL Server can back up directly to most tape-backup devices

Several companies offer a third-party backup for SQL Server While you may find third-party backup useful, it is a good idea to become familiar with SQL Server’s built-in recovery methods before making the decision to use it.

A disk- or tape-backup file is not limited to a single backup event The file may contain multiple

back-ups and multiple types of backback-ups

Backup rotation

If the backup file is being copied to tape, then media retention or rotation, and the off-site media-storage

location, become important