The Real MTCS SQL Server 2008 Exam 70/432 Prep Kit- P60 ppsx

MaintainingYourDatabase•Chapter7 277 Backup Type Functionality Purpose Copy Only Same as the full backup, however, the copy-only backup does not mark the database as having been backed up. You cannot take differential backups based on a copy backup. Take an additional database backup without interfering with normal backup sequence. Transaction Log Back up all log entries since the last full backup. Multiple continuous log backups can be restored or “replayed” into a restore of a full backup, bringing the database up-to-date. Perform a fast and efficient backup of all changes since the last full backup. Unlike differential backup, you can restore or “replay” a log backup to a particular point-in-time. This allows you to roll back unwanted activity like malicious deletions. This also truncates the log file. Tail-Log Backup Backup of the transaction log performed just before a restore operation. If a database file is lost but the log file is still intact, replaying the tail-log backup into the restored database allows you to bring the database up-to-date and eliminate the loss of transactions that occurred after the backup. Table 7.2 Continued. SQL Server 2008 Backup Types TE s T Da y Ti p Study the various types of backup available and ensure that you understand the differences between them. Remember that although differential and transaction log backups are quicker to perform, they take a longer time to be replayed into a restored database. On the other hand, while backing up the entire database is time consuming, restoring it as a whole is faster than replaying numerous differential and transac- tion log backups into an initial restored database. 278 Chapter7•MaintainingYourDatabase Choosing a Database Backup Strategy Choosing the appropriate database backup strategy depends on your organization’s individual business continuity requirements, the size of your database, and the amount of time allocated for backup operations. The data loss tolerance is a measure defining how much data your organization is prepared to lose in the worst case scenario. For example, if your organizations data loss tolerance is one day, you must take some form of backup at least every day. If the data loss tolerance is six hours, you must take some form of backup at least every six hours. The challenge of any disaster recovery strategy is balancing the data loss tolerance against the amount of time it takes to perform a backup. For example, a full backup of a large database can take 24 hours or longer. This means that you cannot conduct full backups every six hours. In this situation, you may wish to settle for a full backup every weekend and a differential or log backup every six hours. Use the following best practices as your guide when selecting a backup strategy: For small databases, you can choose to take full backups only. Perform a full  backup as often as your data loss tolerance dictates, e.g., every day or every weekend. Restoring a full backup is the most complete and time-effective way to restore a database. Tail-log backups can be used in conjunction with a restore from a full database backup in the event that the database file is lost but the log file is not. Full + transaction log backup strategy is suitable to larger databases. For  example, you can choose to backup the database every weekend and trans- action logs every day. This achieves a reduction in backup time and a reduction in the space consumed by the backup while providing you with the complete backup of the daily database activity. The trade-off is in the restore time. It takes longer to replay every single log backup into the database than simply restoring the entire database from a full backup. When recovering the database protected by this backup strategy, you must first restore the latest full database backup. You must then restore every log backup, including the tail-log backup if desired. This is the only strategy that allows you to recover to a point-in-time. Full + differential backup strategy is suitable for very large databases, where  certain extents are updated more frequently than others. For example, you can choose to backup the database every weekend, and back up the differences every day. This gives you a complete backup of daily database activity as well as a reduction in backup time and a reduction in space con- sumed by the backup. Again, the trade off is in the restore time. It takes MaintainingYourDatabase•Chapter7 279 longer to replay all the daily differentials into a database than to restore the entire database from a full backup. When recovering the database protected by this backup strategy, you must first restore the latest full database backup. You can then restore the latest differential backup. Finally, you can restore any transaction log backups (including the tail-log backup) taken since the last differential backup. This strategy consumes less restore time than an equivalent full + log backup but more restore time than the full backup only. File or filegroup backup strategy consists of alternately backing up each  read/write file or filegroup that comprises the database. Additionally, the transaction log grown between file or filegroup backups is also backed up. This strategy is suitable for large partitioned databases. Although this strategy consumes less backup time than a full backup, it is more complicated. New & Noteworthy… Backup File Compression Compressing backups is a new feature of SQL Server 2008. Performing compressed backup is only available in the Enterprise edition of SQL Server 2008. All editions of SQL Server 2008 and later can restore com- pressed backups. Compressed backup offers performance advantages as the backup file is smaller. However, performing compressed backups is more processor intensive than performing uncompressed backups. Compressed backups cannot reside on the same media set (file or tape) with uncompressed backups or non-SQL Server backups. Compressed backups cannot be read by earlier versions of SQL Server. TE s T Da y Ti p Remember that only a transaction log backup can be used to restore a database to a point-in-time. You can only replay a transaction log backup into a restored database. For example, if you took a full data- base backup on 15 February at 1:00 a.m. and log backups every day until 20 February, you can restore the database from the full backup then bring it forward to any point in time between 15 February 1:01 a.m. and 20 February. You cannot, however, roll the database back to 14 February or any time before the full database backup. 280 Chapter7•MaintainingYourDatabase Restoring Databases When you wish to recover database data, you must restore the database from backup to an operational state. During a restore, the database is copied from backup, but the restore operation is not marked complete. At this point, any contiguous transactions recorded in the log can be applied to the restored database. This process is known as “roll forward”, because it advances the database state to a target recov- ery point. The recovery point is usually all available data. However, in certain circumstances you may wish to roll the database forward to a specific point in time. Once the restore is marked complete, no subsequent differential or log backups can be rolled forward into the database. There are multiple possible restore scenarios. The restore scenario you choose depends on your restore requirements and the type of backup you are restoring from. The restore scenarios are dependent on the database recovery model and the SQL Server edition. When you restore a database from a database backup, SQL Server re-creates the database. All database and log files are placed in their original location, unless new Configuring & Implementing… Performing Test Restores Disasters strike unexpectedly. To be prepared for disaster recovery, you must perform regular test restores. Performing a test restore can help you determine whether the recovery procedures defined in your disaster recovery strategy meet your organization’s objectives for data recovery. Test restores also help administrators understand the course of action to take in the event of a disaster. If a disaster occurs, they will be able to act in a competent manner. Test restores also validate the backup procedures. Only a successful test restore can assure that the backup is functioning, the backup hard- ware is working correctly, and the backup media is intact. When performing a test restore, you should consider doing so on a separate lab server. Alternatively, if this is not possible, you can restore the database under a different name onto the existing server. MaintainingYourDatabase•Chapter7 281 locations are explicitly specified. SQL Server databases are inherently portable. You can restore databases from backup on any SQL Server or even restore a copy of the database under a different name on the same server. Performing Online Restore During a full restore, the database is normally rendered inaccessible, and users cannot connect to or use the database. However, sometimes you may be restoring only a small part of the database like a file, filegroup, or individual page. In this case, it is possible to leave the database online, and all parts of the database, except the ones you are restoring, will be accessible to users. Online restore is the default when performing file, filegroup, or piecemeal (multiple filegroup) restores. To perform an online restore, follow these steps: 1. Restore the data file, filegroup, or page. 2. Restore the log. Use the WITH RECOVERY option for the last log restore (see Example 7.22). 3. The restored data will become accessible once the log has been replayed successfully. Example 7.22 Performing an Online Restore First, restore the filegroup A and C RESTORE DATABASE adb FILEGROUP='A',FILEGROUP='C' FROM partial_backup WITH PARTIAL, RECOVERY; Next, restore the filegroup B. At this point filegroups A and C are accessible to users. RESTORE DATABASE adb FILEGROUP='B' FROM backup WITH RECOVERY; Restoring Individual Pages Sometimes data corruption can result in “suspect” pages. These are pages that cannot be read by SQL Server or that result in errors when accessed. You can view the list of suspect pages for all databases by querying the suspect_pages table in the MSDB database. If the suspect page occurs in a nonclustered index, you can repair the index by rebuilding it. If the suspect page contains table data, you will have to restore it from backup. Page restores are performed online. Example 7.23 demonstrates the proper use of PAGE parameter with RESTORE DATABASE. . backups is a new feature of SQL Server 2008. Performing compressed backup is only available in the Enterprise edition of SQL Server 2008. All editions of SQL Server 2008 and later can restore. backup into the restored database allows you to bring the database up-to-date and eliminate the loss of transactions that occurred after the backup. Table 7.2 Continued. SQL Server 2008 Backup. restore, follow these steps: 1. Restore the data file, filegroup, or page. 2. Restore the log. Use the WITH RECOVERY option for the last log restore (see Example 7.22). 3. The restored data