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

Nielsen c40.tex V4 - 07/21/2009 2:20pm Page 952 www.getcoolebook.com Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 953 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 T he 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, g roups, 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. 953 www.getcoolebook.com 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? B ackup 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. 954 www.getcoolebook.com Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 955 Recovery Planning 41 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. 955 www.getcoolebook.com 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 the truncate log on checkpoint database option to true in 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. 956 www.getcoolebook.com Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 957 Recovery Planning 41 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 Time Sun Mon Tues Wed Thurs Fri Sat Best Practice S imple 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 U se 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. 957 www.getcoolebook.com 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 Log1000 Mon Log Tues Log Wed Log Thurs Log Fri Log Sat Log Log1200 Log Log Log Log Log Log Log1400 Log Log Log Log Log Log Log1600 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. 958 www.getcoolebook.com Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 959 Recovery Planning 41 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 INTO operations ■ WRITETEXT and UPDATETEXT BLOB operations ■ CREATE INDEX (including indexed views) ■ ALTER INDEX REBUILD or DBCC DBREINDEX operations ■ 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 the SELECT INTO/BULKCOPY database option to true. 959 www.getcoolebook.com Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 960 Part VI Enterprise Data Management Best Practice I t 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 EnterpriseEditions.ThePersonal 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 the ALTER DATABASE DDL command: ALTER DATABASE DatabaseName SET Recovery Option; The valid options are FULL, BULK_LOGGED,andSIMPLE. The following code sets the AdventureWorks2008 sample 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. 960 www.getcoolebook.com Nielsen c41.tex V4 - 07/23/2009 2:46pm Page 961 Recovery Planning 41 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 I t 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 backups. 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. 961 www.getcoolebook.com . 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 ■. 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. 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