SQL Server 2008 R2 : Database Backup and Restore (part 7) - Restoring Databases and Transaction Logs

• Restore an entire database.

• Perform a partial restore.

• Restore a file or page from a backup.

• Restore a transaction log.

• Restore a database to a point in time by using a database snapshot.

The following sections delve further into the restore options listed here. They focus on the means for accomplishing these restores and some of the common restore scenarios you might encounter.

Restores with T-SQL

The command to restore a database in SQL Server is aptly named RESTORE. The RESTORE command is similar to the BACKUP command in that it can be used to restore a database, part of a database, or a transaction log. You restore an entire database or part of a database by using the RESTORE DATABASE syntax. You do transaction log restores by using the RESTORE TRANSACTION syntax.

Database Restores with T-SQL

Listing 6 shows the full syntax for RESTORE DATABASE.

Listing 6. RESTORE DATABASE Syntax

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var }
[ FROM <backup_device> [ ,...n ] ]
[ WITH
   [ { CHECKSUM | NO_CHECKSUM } ]
   [ [ , ] { CONTINUE_AFTER_ERROR | STOP_ON_ERROR } ]
   [ [ , ] ENABLE_BROKER ]
   [ [ , ] ERROR_BROKER_CONVERSATIONS ]
   [ [ , ] FILE = { file_number | @file_number } ]
   [ [ , ] KEEP_REPLICATION ]
   [ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
   [ [ , ] MEDIAPASSWORD = { mediapassword |
                    @mediapassword_variable } ]
   [ [ , ] MOVE 'logical_file_name' TO 'operating_system_file_name' ]
                [ ,...n ]
   [ [ , ] NEW_BROKER ]
   [ [ , ] PARTIAL ]
   [ [ , ] PASSWORD = { password | @password_variable } ]
   [ [ , ] { RECOVERY | NORECOVERY | STANDBY =
          {standby_file_name | @standby_file_name_var }
   } ]
   [ [ , ] REPLACE ]
   [ [ , ] RESTART ]
   [ [ , ] RESTRICTED_USER ]
   [ [ , ] { REWIND | NOREWIND } ]
   [ [ , ] STATS [ = percentage ] ]
   [ [ , ] { STOPAT = { date_time | @date_time_var }
    | STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
             [ AFTER datetime ]
    | STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
            [ AFTER datetime ]
   } ]
   [ [ , ] { UNLOAD | NOUNLOAD } ]
]


					  

Once again, there are many available options for restoring a database, but a simple restore is fairly straightforward. The following example demonstrates a full restore of the AdventureWorks2008 database:

RESTORE DATABASE [AdventureWorks2008]
FROM DISK = N'C:\mssql2008\backup\AdventureWorks2008_FullRecovery.bak'
WITH FILE = 1,  NOUNLOAD,  REPLACE,  STATS = 10

For more sophisticated restores, you can specify options following the WITH clause. Table 2 briefly describes these options. Many of the options are the same as for the BACKUP command and provide similar functionality.

Transaction Log Restores with T-SQL

The syntax details and options for restoring a transaction log backup are similar to those for RESTORE BACKUP. The options not available with RESTORE LOG include ENABLE_BROKER, ERROR_BROKER_CONVERSATIONS, NEW_BROKER, and PARTIAL.

The RECOVERY | NORECOVERY | STANDBY options are particularly important when performing transaction log restores and also when restoring a database that will have transaction logs applied. If these options are used incorrectly, you can render your database inaccessible or unable to restore subsequent transaction log backups. With the RECOVERY option, any uncommitted transactions are rolled back, and the database is made available for use. When a restore (of either a database or transaction log) is run with this option, no further transaction logs can be applied. The NORECOVERY and STANDBY options do allow subsequent transaction logs to be applied. When the NORECOVERY option is specified, the database is completely unavailable after the restore and is left in a restoring state. In this state, you cannot read the database, update the database, or obtain information about the database, but you can restore transaction logs.

With the STANDBY option, the database is left in a read-only state that allows some database access. standby_file_name must be specified with the STANDBY option. The standby file contains uncommitted transactions rolled back to place the database in a consistent state for read operations. If subsequent transaction log backups are applied to the STANDBY database, the uncommitted transactions in the standby file are reapplied to the database.

Once again, many of these options are not required for most types of restores. For example, the following command uses basic options to restore a transaction log backup to the AdventureWorks2008 database:

RESTORE LOG [AdventureWorks2008] FROM
DISK =
N'C:\mssql2008\backup\AdventureWorks2008\AdventureWorks2008_backup_200906091215.trn'
WITH  FILE = 1,  NOUNLOAD,  STATS = 10, NORECOVERY


					  

Typically, the individual restore commands you will use are along the lines of the preceding example. The restores become more complicated when many restores of different types are involved in a recovery option. Fortunately, SSMS can help ease this pain.

Restoring by Using SSMS

The restore capabilities in SSMS are comprehensive and can reduce the amount of time needed to perform a restore and limit the number of errors. This is partly due to the fact that SSMS keeps track of the backups that have occurred on a server. When a restore operation is requested for a database, SQL Server reads from its own system tables and presents a list of backups that it knows about that can be restored. In situations in which many files need to be restored, SSMS can be an invaluable tool.

You access the restore functions in SSMS by right-clicking the database in the Object Explorer and selecting Tasks and then Restore. The options available for restore include Database, File and Filegroups, and Transaction Log. Which restore options are enabled depends on the state of the database being restored. The Transaction Log option is disabled for databases that were restored with the RECOVERY option or are set to simple recovery mode. Figure 6 shows an example of the restore screen that is displayed when you select a database restore for the AdventureWorks2008 database.

Figure 6. A database restore with SSMS.

The Restore Database window can show more than one type of backup, depending on what is available. The first backup shown in Figure 14.6 is a full backup, followed by a series of transaction log backups. The beauty of this screen is that the backups are shown in the order in which they should be applied. This order is very important with restores because they must be applied in the order in which they occurred. You can choose to apply all the backups or selectively choose the backups you want to apply. If you uncheck the first full database backup, all subsequent log backups are unchecked as well. If you recheck the full database backup and click one of the transaction log backups toward the bottom of the list, all the required backups that happened prior to the selected backups are also selected.

Figure 7 shows an example or the Options page of the Restore Database window for the AdventureWorks2008 database. The Options page allows you to specify many of the T-SQL RESTORE options reviewed previously. The Overwrite the Existing Database option is equivalent to the REPLACE parameter and forces a replacement of the restored database if it exists already. The Preserve the Replication Settings option is equivalent to KEEP_REPLICATION. The Restrict Access to the Restored Database option is the same as using the RESTRICTED_USER option with the T-SQL RESTORE command. The Prompt Before Restoring Each Backup option does not have a T-SQL equivalent; it displays a prompt before restoring each backup set to ask whether you want to restore it.

Figure 7. Restore options with SSMS.

The last three options on the Options page relate the recovery state of the last backup set restored. The first option is synonymous with the RECOVERY option, the second option is the same as NORECOVERY, and the last option is equivalent to the STANDBY option. The standby filename must be supplied with the STANDBY option and defaults to the default backup directory for the server. By default, the name of the file contains the name of the database being restored.

Restore Information

Backup files and system tables contain a wealth of information about what can be restored or already has been restored. You can retrieve information from the backup files by using variations of the RESTORE command. These variations do not actually perform the restore operation but provide information about the backups that can be restored. The RESTORE commands and some useful system tables are detailed in the following sections.

The RESTORE FILELISTONLY Command

The RESTORE FILELISTONLY command returns a result set that contains a list of the database and log files contained in the backup. An example of this command follows:

RESTORE FILELISTONLY
FROM DISK = 'C:\mssql2008\backup\AdventureWorks2008_Partial.bak'

The results from this type of restore include the logical and physical filenames, the type of each file, and the size of each file.

The RESTORE HEADERONLY Command

The RESTORE HEADERONLY command returns a result set that contains the backup header data for all backup sets on the specified backup device. This command is useful when multiple backup sets are written to the same device. An example of this command follows:

RESTORE HEADERONLY
FROM DISK = 'C:\mssql2008\backup\AdventureWorks2008_Partial.bak'

More than 50 columns are returned in the result set. Some particularly useful pieces of information include the start and finish time for the backup, recovery mode when the backup was taken, type of backup, and name of the computer from which the backup was performed.

The RESTORE VERIFYONLY Command

The RESTORE VERIFYONLY command verifies that a backup set is complete and readable. The restore does not attempt to verify the structure of the data in the backups, but it has been enhanced to run additional checks on the data. The checks are designed to increase the probability of detecting errors. An example of this command follows:

RESTORE VERIFYONLY
FROM DISK = 'C:\mssql2008\backup\AdventureWorks2008_Partial.bak'

/*Result from the prior RESTORE VERIFYONLY command
The backup set on file 1 is valid.
*/

The results from the prior example show that the RESTORE VERIFYONLY command does not contain much output, but the value of this command is in helping ensure that the backups are sound.

Backup and Restore System Tables

The system tables for backups and restores are found in the msdb system database. These system tables are used to keep historical information about the backups and restores that have occurred on the server. These system tables are listed in Table 3.

You are able to query these tables to obtain a variety of information related to backups and restores. You can tailor these queries to look at a specific database or a specific time frame. The following example retrieves restore information for the AdventureWorks2008 database:

select destination_database_name 'database', h.restore_date, restore_type,
 cast((backup_size/1024)/1024 as numeric(8,0)) 'backup_size MB',
  f.physical_device_name
 from msdb..restorehistory h (NOLOCK)
   LEFT JOIN msdb..backupset b (NOLOCK)
   ON h.backup_set_id = b.backup_set_id
   LEFT JOIN msdb..backupmediafamily f (NOLOCK)
   ON b.media_set_id = f.media_set_id
 where h.restore_date > getdate() - 5
    and UPPER(h.destination_database_name) = 'AdventureWorks2008'
 order by UPPER(h.destination_database_name), h.restore_date desc

This example displays information related to restores that have been executed in the past five days for the AdventureWorks2008 database. The restore date, type of restore, size of the backup, and physical location of the file used for the restore are displayed when you run this query.

Backup and Restore Report

A set of standard reports that come with SQL Server 2008 provide a variety of information about your databases, including recent restores and backups. You can access these reports by right-clicking on a database in the SSMS Object Explorer, then Reports, and then Standard Reports. You see over a dozen reports ready for you to run.

A report particularly useful for obtaining restore and backup information is named Backup and Restore Events. This report details the latest backup and restore events that have occurred on a particular database. An example of this report is shown in Figure 8.

Figure 8. Backup and Restore Events report.

The interactive report allows you to drill down into each backup or restore event to obtain more information. For example, the restore information shown in Figure 14.8 was obtained by clicking on the plus button next to the Successful Restore Operations label. You can then drill down into an individual restore to obtain more information, including the physical files involved in the operation.