272 Chapter7•MaintainingYourDatabase Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0. DBCC results for 'sys.sysrscols'. There are 1483 rows in 17 pages for object "sys.sysrscols". DBCC results for 'sys.sysrowsets'. There are 286 rows in 3 pages for object "sys.sysrowsets". DBCC results for 'sys.sysallocunits'. There are 334 rows in 5 pages for object "sys.sysallocunits". DBCC results for 'sys.sysfiles1'. (Truncated for brevity) ALTER DATABASE AdventureWorks SET MULTI_USER; GO Using the DBCC SHRINKFILE Option to Reclaim Database Space DBCC SHRINKFILE shrinks a database file or a log file by rearranging data in the file to reclaim empty space. It can also move all data from a data file to another data file in the same filegroup, allowing you to remove the empty file. Using DBCC SHRINKFILE, you can shrink the file to a smaller size than its minimum size setting. The minimum size setting will then be reset to reflect the actual size. Use the syntax shown in Example 7.20 to run DBCC SHRINKFILE. Example 7.20 Using the DBCC SHRINKFILE—Syntax DBCC SHRINKFILE ( file_name | file_id, [EMPTYFILE], [target_size], [NOTRUNCATE | TRUNCATEONLY] ) [ WITH NO_INFOMSGS] When running DBCC SHRINKFILE, you can specify various options to alter the command behavior. You must specify the logical file name or file ID of the database or log file you wish to manipulate. When the EMPTYFILE option is spec- MaintainingYourDatabase•Chapter7 273 ified, the DBCC moves all data from the specified file to other files in the same filegroup. SQL Server will no longer write to the file you have just emptied, allow- ing you to remove the empty file using the ALTER DATABASE statement. You can specify the target_size in megabytes. The DBCC will then attempt to shrink the file to the target size. It does so by moving all data from throughout the end pages to free space earlier in the file. The file shrinkage will only be achieved if enough free space is available in the file. The NOTRUNCATE option specifies that although the data in the file will be rearranged, the free space will not be released back to the operating system. This means that the actual file size of the file will not change. On the other hand, TRUNCATEONLY will rearrange the data and reclaim the free space to the oper- ating system, thereby shrinking the file. TRUNCATEONLY ignores the target_size, reclaiming all possible space. Both NOTRUNCATE and TRUNCATEONLY are applicable only to database files. The NO_INFOMSGS specifies that no informational messages are to be shown by the DBCC. Example 7.21 demonstrates the use of DBCC SHRINKFILE. Example 7.21 Using the DBCC SHRINKFILE USE AdventureWorks; GO SELECT file_id, name FROM sys.database_files; GO Reclaim all available free space from the data file DBCC SHRINKFILE ('AdventureWorks_Data', TRUNCATEONLY); Results: DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages 5 1 21760 21760 21432 21432 (1 row(s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. Shrink the log file to 5 MB DBCC SHRINKFILE (AdventureWorks_Log, 5); GO Empty a file ALTER DATABASE AdventureWorks ADD FILE ( NAME = NewData, FILENAME = 'C:\temp\newdata.ndf', SIZE = 5MB); GO Empty the data file. 274 Chapter7•MaintainingYourDatabase DBCC SHRINKFILE (NewData, EMPTYFILE); GO Remove the data file from the database. ALTER DATABASE AdventureWorks REMOVE FILE NewData; GO Results: DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages 5 3 640 640 0 0 (1 row(s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. The file 'NewData' has been removed. Backing Up and Restoring Data Every organization that values its databases must have a disaster recovery strategy that works when needed. The disaster recovery strategy defines procedures for backing up and restoring SQL Server databases. Defining and adhering to the disaster recovery strategy is a primary task of any database administrator. In this section, you will learn about various types of backup available with SQL Server, best practices for performing backups, and restoring databases from backup. Understanding Database Recovery Models The database recovery model determines how transaction logs are used by SQL Server for a specified database. Your choice of recovery model affects which operations are performed as nonlogged and whether the database can be recovered to a point in time. Three recovery models are available for SQL Server 2008 databases: Simple recovery model Full recovery model Bulk-Logged recovery model When the database recovery model is set to Simple, log files are reused as soon as they become full. This means that very little space is consumed by the transaction MaintainingYourDatabase•Chapter7 275 logs, and you don’t need to worry about log file management. However, when a database is set to Simple recovery model and the database file is lost, you will not be able to recover any changes made after the last full backup. You will also not be able to recover to a point in time as transaction details are stored in transaction logs that have been overwritten in this case. The Full recovery model could be said to be the opposite of the Simple recovery model. Transaction logs are kept, and all transactions without exception are written to the logs. This includes nonlogged operations like TRUNCATE TABLE and SELECT…INTO. Although you lose the performance advantages of nonlogged operations with this recovery model, all data is recoverable provided transaction logs are intact. You can also restore to a point-in-time if necessary. The Bulk-Logged recovery model is similar to Full recovery model, except that nonlogged operations are performed as nonlogged. This provides a performance advantage for Bulk-Logged operations. However, if a Bulk-Logged operation has occurred since the last full backup, you will not be able to recover any changes made since the last full backup. The Bulk-Logged recovery model does not support point-in-time recovery. In production environments, the full database recovery model is generally used as it ensures maximum recoverability. However, if the administrator wishes to perform a high performance nonlogged operation, they would temporarily switch the recovery model to Bulk-Logged, perform the operation, switch the recovery model back to Full, and perform a full backup. The Full recovery model is the default when creating databases in SQL Server. Backup Types SQL Server databases can be backed up using the Backup Database Wizard or the BACKUP DATABASE Transact-SQL statement. By specifying a particular backup type, you designate what data should be backed up. For example, you may choose to back up all data in a database or only the differences from the last full backup. All SQL Server backups are performed online. This means that users can continue to read and write to and from the database while the backup is being performed. However, backup is a resource and time intensive operation, especially for large databases. Therefore, backups should be scheduled at off-peak times to avoid performance degradation. Table 7.2 describes the types of backup available with SQL Server 2008. 276 Chapter7•MaintainingYourDatabase Backup Type Functionality Purpose Full Backup Backup all data stored in data files and a small part of the transaction log generated while the backup operation was taking place. To back up an entire database that can be restored as a whole. The most disk intensive and time consuming backup type. Differential Backup Backup the extents that were modified since the last full backup. Provides the ability to create a frequent, incremental backup which can then be restored into an earlier version of a database restored from full backup. Partial Backup Backup of the primary filegroup, all writeable filegroups, and optionally specified read-only filegroups. Also available in differential partial backup, which backs up only the extents changed since the last full or partial backup of the corresponding filegroup. Perform a more efficient, full or differential backup affecting only change- able data. Especially useful for large partitioned databases consisting of historical data that does not change and current data that does. Using partial backup, you can back up historical data only once and perform frequent partial backups of the current data. File or Filegroup A full backup of a specified database file or filegroup. Allows you to granularly back up specific files or file groups for databases consisting of multiple files. When database files are distributed across mul- tiple disks, you can restore the data file to the failed disk only, which is more efficient than restoring the entire database. Table 7.2 SQL Server 2008 Backup Types Continued . 273 ified, the DBCC moves all data from the specified file to other files in the same filegroup. SQL Server will no longer write to the file you have just emptied, allow- ing you to remove the empty. back to the operating system. This means that the actual file size of the file will not change. On the other hand, TRUNCATEONLY will rearrange the data and reclaim the free space to the oper- ating. in the file. The file shrinkage will only be achieved if enough free space is available in the file. The NOTRUNCATE option specifies that although the data in the file will be rearranged, the