Microsoft Press microsoft sql server 2005 PHẦN 6 ppsx

413 Chapter 11 Backing Up, Restoring, and Moving a Database Maintaining at least one copy of an operational database in case of a disaster is the most fundamental task a database administrator (DBA) can perform. And performing a database backup is the most common method for accomplishing this task. Just because performing a database backup is a common operation, however, does not mean it is unimportant. This chapter emphasizes how important database backups are to your restore strategy, which defines how you can recover your database while meeting business requirements for allowed amounts of downtime and maximum data loss. Without a restore strategy, backing up a database has virtually no purpose. After describing Microsoft SQL Server’s flexible options for backing up a database, this chapter explains how to restore those backups to recover data up to a specific point in time. You will also learn how to move databases by using backup/restore, detach/attach, or the Copy Database Wizard. MORE INFO SSMS backup and restore facilities In this chapter, we explore all the SQL Server 2005 backup and restore features by using the command syntax. Although you can access most of the features we cover via the SQL Server Management Studio (SSMS) graphical interface, walking through the screens does little to explain this subject. In addition, you cannot perform some options and restore processes through the graphical user interface (GUI). For details about using the SSMS backup and restore facilities, see the SQL Server 2005 Books Online reference page “Backing Up and Restoring How-to Topics.” SQL Server 2005 Books Online is installed as part of SQL Server 2005. Updates for SQL Server 2005 Books Online are available for download at www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx. C1162271X.fm Page 413 Friday, April 29, 2005 7:54 PM 414 Chapter 11 Backing Up, Restoring, and Moving a Database Exam objectives in this chapter: ■ Back up a database. ❑ Perform a full backup. ❑ Perform a differential backup. ❑ Perform a transaction log backup. ❑ Initialize a media set by using the FORMAT option. ❑ Append or overwrite an existing media set. ❑ Create a backup device. ❑ Back up filegroups. ■ Restore a database. ❑ Identify which files are needed from the backup strategy. ❑ Restore a database from a single file and from multiple files. ❑ Choose an appropriate restore method. ■ Move a database between servers. ❑ Choose an appropriate method for moving a database. Lessons in this chapter: ■ Lesson 1: Backing Up a Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 ■ Lesson 2: Restoring a Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 ■ Lesson 3: Moving a Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 Before You Begin To complete the lessons in this chapter, you must have ■ SQL Server 2005 installed. ■ A connection to a SQL Server 2005 instance. ■ A copy of the AdventureWorks sample database. ■ Completed Chapter 2, “Configuring SQL Server 2005,” in this book. C1162271X.fm Page 414 Friday, April 29, 2005 7:54 PM Before You Begin 415 Real World Michael Hotek I finally was going to be home for more than a couple of days straight and was looking forward to spending the day working on new projects on the lathe. But on my way through the house and to the woodshop, the phone rang. I didn’t know the desperate caller, who was from an organization that I had never heard of. But a DBA from an organization that I had worked with a couple of years ago had given him my phone number. The organization had a big problem: A disk in its drive array had failed, and the person who swapped in a new drive unfortunately chose the wrong drive and caused the entire system to shut down with a completely unrecoverable redun- dant array of inexpensive disks (RAID) array. I was apparently the organization’s last resort to try to fix a problem no one else had been able to solve. I’ve spent almost two decades doing emergency disaster recovery for hundreds of organi- zations around the globe, with a pretty high success rate. Most of the projects involved working to recover production systems that I had never seen before. The damages were caused by nearly every disaster you could think of: flood, fire, tornado, hurricane, tsunami, lightning, earthquake, water immersion, explo- sives, bullets, every “normal” hardware failure imaginable, security breeches, and even end-user error. After a virtual private network (VPN) into the organization’s system and a several- hour-long conference call to work through everything, we managed to recon- struct just about everything by using a combination of backups, data extracts to other systems, and Lumigent Technologies’ Log Explorer product. We could not recover a small amount of data that was damaged during an initial failed recovery operation, but the organization could manually reconstruct the data. About the time I was finishing up with this customer, an e-mail popped into my inbox, asking if I could help yet another organization. It seems its hosting provider had toasted the drive array on which its data was sitting. Even better, there were no backups for the database. For the hundredth time, I had to ask myself, when were people ever going to learn? Having a functional, tested backup and restore strat- egy, and deploying that strategy correctly, is the most fundamental part of any database implementation. Thankfully, I typically don’t get several of these calls daily and have even managed an entire month in the last decade when I didn’t have to deal with one. But I would have really liked to have spent a nice, relaxing day at my lathe, creating something that didn’t have to do with a computer… C1162271X.fm Page 415 Friday, April 29, 2005 7:54 PM 416 Chapter 11 Backing Up, Restoring, and Moving a Database Lesson 1: Backing Up a Database Maintaining a duplicate copy of data that you can recover in the event of data loss is critical. And SQL Server 2005 provides a variety of features that you can use to accom- plish this goal. The most common way to maintain duplicate copies of data is by using the backup capabilities built into SQL Server. Some of these capabilities will be famil- iar to anyone who has used a previous version of SQL Server. In addition, SQL Server 2005 includes a significant step forward in providing greater flexibility with ways to perform backups. This lesson will explain the basics of each option that is available within the SQL Server backup engine. IMPORTANT Understanding database and log structures To get a better understanding of the backup and restore architecture, you first need to be familiar with the basic structure of SQL Server databases, filegroups, extents, data pages, and transaction logs. Refer to Chapter 2 before starting this lesson. After this lesson, you will be able to: ■ Perform a full backup. ■ Perform a differential backup. ■ Perform a transaction log backup. ■ Perform a filegroup backup. ■ Initialize a media set by using the FORMAT option. ■ Append or overwrite an existing media set. ■ Create a backup device. Estimated lesson time: 45 minutes NOTE Backup permissions Unlike previous SQL Server versions, SQL Server 2005 aims to strengthen security by implementing the principle of least privilege, using only the minimum set of permissions required to perform an operation. So you need to know what permissions are required to execute backups. Backups, no matter how you initiate them, execute within the database engine under the security context of the SQL Server service account. You need to grant this account permissions to read and write to any directories or tape devices that you will be using to back up to; otherwise, your backups will fail due to insufficient permissions. To grant a user permissions to back up the database without allow- ing additional access, add the user as a member of the db_backupoperator role, which is allowed only to back up the database, log, or checkpoint in the database. No other access is allowed. C1162271X.fm Page 416 Friday, April 29, 2005 7:54 PM Lesson 1: Backing Up a Database 417 Performing Full Backups The purpose of a full database backup is to capture all the data that is stored in the database. The backup engine accomplishes this task by extracting every extent in the database that is allocated to an object. You can then use a full backup by itself to re-cre- ate the entire database. Note that this backup method is always available, regardless of the recovery model you configure for a database. NOTE Inside backup granularity You will find many books that say a SQL Server backup backs up a data page instead of an extent. This is inaccurate. SQL Server does not allocate a single data page to an object that needs space; it allocates a full extent. The backup engine works on the same principle. It extracts any pages allo- cated to an object, and because allocation occurs one extent at a time, the backup engine is in fact backing up all extents that SQL Server has allocated to objects, regardless of whether SQL Server has written data to all the pages within the extent. The backup engine is configured to perform a backup as quickly as possible while using a minimum of resources. When you initiate a backup, the backup engine writes pages to the backup device without regard to the order of pages. Because the backup is not concerned with the precise ordering of pages, SQL Server can open multiple threads to write data as fast as it can be accepted by the media. The only limiting factor in the backup speed is how fast data can be written to a device. Because a backup is not instantaneous and can occur while users are connected to the database and issuing queries, logical inconsistency in the database is a possibility. If a page of data were written to the backup media and then modified by another request, for example, restoring this backup would place the database in an inconsistent state. SQL Server, however, does not allow this to happen because it enforces the following specific series of steps during a full backup: 1. Lock the database, blocking all transactions. 2. Place a mark in the transaction log. 3. Release the database lock. 4. Back up all pages in the database. 5. Lock the database, blocking all transactions. 6. Place a mark in the transaction log. 7. Release the database lock. 8. Extract all transactions between the two log marks and append to the backup. C1162271X.fm Page 417 Friday, April 29, 2005 7:54 PM 418 Chapter 11 Backing Up, Restoring, and Moving a Database This process ensures that the database is completely consistent as of the time that the backup completes. The basic command to back up a database is as follows: BACKUP DATABASE <database name> TO DISK = ’<directo ry>\<filename>‘ WITH INIT You use the TO clause in the BACKUP DATABASE command to specify the backup device to send the backup to, which can be the name of a logical backup device that is created, or you can specify an explicit path to either DISK or TAPE. The WITH clause has more than a dozen parameters, all of which are optional. The INIT parameter, which is the most common, tells SQL Server to overwrite anything in the backup device that might already exist before starting the backup operation. MORE INFO Backup syntax For a complete discussion of the BACKUP DATABASE command, including all possible options, see the article “BACKUP (Transact-SQL)” in SQL Server 2005 Books Online. Performing Differential Backups A differential backup captures all the extents that have changed since the last full backup. And the main purpose of a differential backup is to reduce the number of transaction log backups that need to be restored. You use a differential backup along with a full backup. If a full backup does not exist, you cannot create a differential backup. As with a full backup, you can perform a differential backup of a database no matter what recovery model is specified for the database. Note that a differential backup is NOT an incremental backup. An incremental backup captures any changes since the previous incremental backup. Therefore, restoring an incremental backup requires all other incremental backups. A differential backup always captures every extent that has changed since the last full backup. So each differential backup contains everything that any previous differential backup taken after a full backup contains. For example, suppose that a full backup occurs at midnight, with differential backups taken every four hours during the day. The differ- ential backup at 04:00 contains all extents that have changed since midnight. The dif- ferential backup at 08:00 contains all extents that have changed since midnight. And the noon differential backup contains all extents that have changed since midnight. To determine the extents that need to be backed up by a differential backup, SQL Server maintains an extent map. An extent map is just another data page within the C1162271X.fm Page 418 Friday, April 29, 2005 7:54 PM Lesson 1: Backing Up a Database 419 database, with each bit on the page representing an extent. When SQL Server changes an extent, it changes the corresponding bit for that extent from 0 to 1. When you per- form a full backup, SQL Server resets all bits to 0. In this way, SQL Server has to inter- rogate only this page to determine which extents it needs to back up. Because databases can be an unlimited size and data pages are only 8 KB in size, SQL Server creates one of these mapping pages for approximately every 8,192 extents that it allo- cates to objects in the database. So a single page can cover thousands of data pages. The simplest command to perform a differential backup is as follows: BACKUP DATABASE <database name> TO DISK = ’<directo ry>\<filename>‘ WITH DIFFERENTIAL This command is almost exactly the same as the command to perform a full database backup except that it requires use of the DIFFERENTIAL parameter. All other options are the same as with a full backup. Transaction Log Backups You can perform transaction log backups only for databases you have configured to use the Full or Bulk-Logged recovery model and that have not yet had a minimally logged transaction executed. Transaction log backups are also allowed only after a full backup has been performed. A transaction log backup contains only a subset of data and requires that you also have at least a full backup to recover the database. A log backup backs up the active log. It starts at the Log Sequence Number (LSN) at which the previous log backup completed. SQL Server then backs up all subsequent transactions until the backup encounters an open transaction. After SQL Server encounters an open transaction, the log backup completes. Any LSNs that are backed up are then allowed to be removed from the transaction log, which enables the system to reuse log space. NOTE Transaction log, replication, and database mirroring If you are implementing either transactional replication or database mirroring, an additional requirement is imposed on a transaction log. Both these features guarantee delivery of data and therefore must ensure that data is successfully delivered before SQL Server can remove a transac- tion from the log, regardless of whether it has been backed up. When you are using these features, a transaction can be removed only when 1. It has been successfully committed to the distribution database. 2. It has been successfully committed on the mirror database. C1162271X.fm Page 419 Friday, April 29, 2005 7:54 PM 420 Chapter 11 Backing Up, Restoring, and Moving a Database The simplest way to execute a transaction log backup is to issue the following state- ment (see the SQL Server 2005 Books Online article noted previously for syntax details): BACKUP LOG <database name>TODISK=’<directory>\<filename>‘ WITH INIT Quick Check ■ How do full, differential, and transaction log backups interact with each other? Quick Check Answer ■ A full backup is required before you can perform either a differential or a transaction log backup. Differential and transaction log backups occur independently of each other. The main purpose of a differential backup is to reduce the number of transaction log backups that you must restore in the event of a database failure. Performing Filegroup Backups Filegroup backups provide an alternative backup strategy to full backups. Instead of backing up the entire database, you can perform a filegroup backup to back up indi- vidual filegroups within the database. The starting point for a filegroup backup strat- egy must include a backup of all filegroups within the database so that you can reassemble all the filegroups within that database. BEST PRACTICES Using filegroup backups You should select a filegroup backup method when the size of a database makes it impractical to either back up or restore an entire database while still meeting your recovery requirements. Because a filegroup backup enables you to back up portions of a database, it requires you to configure the database in the Full or Bulk-Logged recovery model so that you can perform a filegroup backup that is read/write. To restore, you can then use file- group, differential, and transaction log backups. NOTE Recovering from a filegroup backup If you are restoring one or more filegroups with backups taken at different times, transaction log backups are a minimum requirement to roll all filegroups forward to a consistent point in time. C1162271X.fm Page 420 Friday, April 29, 2005 7:54 PM Lesson 1: Backing Up a Database 421 The simplest way to perform a filegroup backup is as follows: BACKUP DATABASE <database name> FILEGROUP = ’<fil egroup name>‘ TO DISK = ’<directory>\<filen ame>‘ You can also take a differential backup on either a database or filegroup basis. The simplest form of a filegroup differential backup command is this: BACKUP DATABASE <database name> FILEGROUP = ’<fil egroup name>‘ TO DISK = ’<directory>\<filen ame>‘ WITH DIFFERENTIAL Performing Mirrored Backups Each backup operation creates a single copy of data on either disk or tape. It is then up to an administrator to create additional copies to protect your organization from media failure. This duplication process can be tedious and time-consuming, and the single backup becomes a potential single point of failure during the process. SQL Server 2005 introduces a new capability to the BACKUP command. You can create additional copies of a backup called mirrors during the backup operation. You accomplish this operation by using the following optional clause in the BACKUP command: [[MIRROR TO <backup_device > [ , n ]][ next-mirror]] You can create up to four mirrors, with three being specified in the MIRROR TO clause. A mirrored backup also places some restrictions on the media that you use. The media for each mirror must be of the same type as well as have the same number of devices. Each must also possess similar properties. For example, if you are backing up to disk, all mirrors must also be disks; if you are backing up to tape, all mirrors must be tape. NOTE Inside backup striping A media set generally contains a single physical device, such as a file or tape drive. However, a media set can be constructed of up to 64 devices. When a media set encompasses multiple physi- cal devices, the backup engine spawns one thread per physical device and writes a portion of the data within the backup to each device. This is not the same as the striping capability present in RAID technology, but it is similar in concept to what occurs with RAID 0. Each mirror must be iden- tical. Therefore, if you specify a media set that contains two disk devices, each mirror must also contain two disk devices. Similarly, if your media set contains 64 tape devices, the mirror must specify 64 tape devices. C1162271X.fm Page 421 Friday, April 29, 2005 7:54 PM 422 Chapter 11 Backing Up, Restoring, and Moving a Database When you use mirrored backups, SQL Server reads the page from the data files once and then creates multiple copies as it writes the page to disk or tape. This process has the effect of writing the same page of data to each mirror at the same time. The restric- tion on each mirror being of the same device type with similar properties is to ensure minimal performance impact when using this capability. NOTE Backup locations A common misconception is that devices you are using for backups must be physically attached to the SQL Server machine. Backups can be sent to locally attached devices. You can also send back- ups to a Universal Naming Convention (UNC) path. When sending backups to a UNC path, you must consider the backup’s impact on the network bandwidth. The following example backs up the PUBS database to a two-disk media set and cre- ates three mirrors of the backup. The first backup occurs to a locally attached disk, whereas each of the mirrors is a network resource accessed via a UNC path. BACKUP DATABASE PUBS TO DISK=‘C:\DEMO\BACKUP\PUBS1B.BAK’, DISK=‘C:\DEMO\BACKUP\PUBS1B.BAK’ MIRROR TO DISK=‘\\BAKSERVER1\BACKUP\PUBSMIRROR1A.BAK’, DISK=‘\\BAKSERVER1\BACKUP\ PUBSMIRROR1B.BAK’ MIRROR TO DISK=‘\\BAKSERVER2\BACKUP\PUBSMIRROR2A.BAK’, DISK=‘\\BAKSERVER2\BACKUP\ PUBSMIRROR2B.BAK’ MIRROR TO DISK=‘\\BAKSERVER3\BACKUP\PUBSMIRROR3A.BAK’, DISK=‘\\BAKSERVER3\BACKUP\ PUBSMIRROR3B.BAK’ WITH FORMAT GO NOTE FORMAT clause The FORMAT clause is normally an optional parameter. This parameter writes a new media header to each media set, overwriting the previous header and invalidating any other backups contained on the media. However, the FORMAT clause is required for a mirrored backup. Partial Backups It is possible to have databases in which some of the filegroups can be written to, whereas others are read-only. In previous versions of SQL Server, a full backup cap- tured all allocated extents in a database, even when a filegroup was marked as read- only, which meant that there were no changes to the data. SQL Server 2005 intro- duces an additional parameter to the BACKUP command to handle this situation. The READ_WRITE_FILEGROUPS clause causes the backup engine to skip any filegroups that are marked as read-only, saving time and space in the backup by having the backup engine gather only the set of extents that could change. C1162271X.fm Page 422 Friday, April 29, 2005 7:54 PM [...]... 463 ■ Lesson 4: Using DBCC CHECKDB 469 Before You Begin To complete the lessons in this chapter, you must have: ■ SQL Server 2005 installed ■ A connection to a SQL Server 2005 instance ■ A copy of the AdventureWorks sample database 447 C1 262 271X.fm Page 448 Friday, April 29, 2005 7:55 PM 448 Chapter 12 Using Transact -SQL to Manage Databases... ’C:\TEST\AdventureWorks_Log.ldf’) FOR ATTACH C1 162 271X.fm Page 438 Friday, April 29, 2005 7:54 PM 438 Chapter 11 Backing Up, Restoring, and Moving a Database MORE INFO Attach options For all options that you can use with the detach or attach command, see the SQL Server 2005 Books Online article “CREATE DATABASE (Transact -SQL) .” Using the Copy Database Wizard IMPORTANT Make sure SQL Server Integration Services is installed... longer being accessed by SQL Server To make the database accessible again, you only have to attach it This process adds an entry in the system tables for the database And SQL Server then enables access to the database NOTE Detach/attach performance The detach operation requires SQL Server only to close the files and remove an entry in the system tables And an attach requires SQL Server to simply open... Introduction C1 262 271X.fm Page 447 Friday, April 29, 2005 7:55 PM Chapter 12 Using Transact -SQL to Manage Databases Maintaining your databases is often a complex and time-consuming task that involves a multitude of steps you need to perform on a periodic basis Database administrators (DBAs) often perform their maintenance tasks by using the Maintenance Plan Wizard or the Microsoft SQL Server 2005 main graphical... your technical support staff back up a database without having to grant any other permission to a database or SQL Server instance, to which role should you add the staff member? A db_accessadmin B db_owner C db_backupoperator D sysadmin C1 162 271X.fm Page 4 26 Friday, April 29, 2005 7:54 PM 4 26 Chapter 11 Backing Up, Restoring, and Moving a Database 2 You perform a differential backup of the AdventureWorks... occurs when the backup media is damaged SQL Server 2005 now has an option for the RESTORE command that enables SQL Server to skip damaged media sectors and finish the restore operation By using the WITH CONTINUE_AFTER_ERROR option, damaged media sectors are skipped, and any readable parts of the media will be restored C1 162 271X.fm Page 434 Friday, April 29, 2005 7:54 PM 434 Chapter 11 Backing Up, Restoring,... instances SQL Server provides three ways to accomplish this task: ❑ ❑ Using attach/detach ❑ ■ Using backup/restore Using SMO through the Copy Database Wizard Using SMO through the Copy Database Wizard will move the database, but any server- level objects such as logins or linked servers that an application needs to work with the database have to be copied separately C1 162 271X.fm Page 441 Friday, April 29, 2005. .. However, SQL Server 2005 now performs the necessary checks, so you should execute this command every time you perform a backup C1 162 271X.fm Page 435 Friday, April 29, 2005 7:54 PM Lesson 2: Restoring a Database PRACTICE 435 Restoring the AdventureWorks Database Using the backups from Lesson 1, restore the AdventureWorks database to the current point in time 1 If necessary, launch SSMS, connect to your SQL. .. apply.) A Filegroup backup B Full backup C Transaction log backups D Filegroup differential backup C1 162 271X.fm Page 437 Friday, April 29, 2005 7:54 PM Lesson 3: Moving a Database 437 Lesson 3: Moving a Database Occasionally, databases need to be moved either within the same server or between servers SQL Server provides three mechanisms that you can use to move databases The first method, backup and restore,... detach/attach or SQL Management Objects (SMO) After this lesson, you will be able to: ■ Choose an appropriate method for moving a database Estimated lesson time: 20 minutes Moving a Database by Using Detach/Attach You can unmount databases from a SQL Server by detaching them This process removes the entries in the system tables for this database, causing it to no longer be accessible on the SQL Server instance . see the SQL Server 2005 Books Online reference page “Backing Up and Restoring How-to Topics.” SQL Server 2005 Books Online is installed as part of SQL Server 2005. Updates for SQL Server 2005. must have ■ SQL Server 2005 installed. ■ A connection to a SQL Server 2005 instance. ■ A copy of the AdventureWorks sample database. ■ Completed Chapter 2, “Configuring SQL Server 2005, ” in this. backup capabilities built into SQL Server. Some of these capabilities will be famil- iar to anyone who has used a previous version of SQL Server. In addition, SQL Server 2005 includes a significant