MaintainingYourDatabase•Chapter7 267 Most DBCC commands do not affect the live database. Instead, they are performed on a database snapshot. The snapshot is created, used for the command, and then dropped. Sometimes the snapshot cannot be created, for example, when the DBCC statement is run against the Master database. In this case, the statement is executed against the actual database. Using the snapshot instead of the actual database avoids congestion or locking through the DBCC affecting your live environment. FREEPROCCACHE Removes plans from the execution plan cache. SHRINKDATABASE Shrinks database files and log files for a database by a specified percentage. SHRINKFILE Shrinks database and log files. UPDATEUSAGE Shows and corrects page count and row count inaccuracies in catalog views. DBREINDEX Rebuilds indexes in a database. This option is deprecated and should be used for backwards compatibility only. INDEXDEFRAG Defragments indexes. This option is deprecated and should be used for backwards compat- ibility only. Other Statements Dllname (FREE) Frees the memory used by the specified extended stored procedure (xp) dll. FREESESSIONCACHE Flushes the distributed query cache for the current connection. FREESYSTEMCACHE Flushes all caches by releasing unused cache entries. Note that SQL Server cleans caches automatically in the background. HELP Shows the syntax for the specified DBCC command. TRACEON Enables trace flags used for diagnostic tracing. TRACEOFF Disables trace flags used for diagnostic tracing. Table 7.1 Continued. DBCC Options 268 Chapter7•MaintainingYourDatabase However, it is important to remember that most DBCC commands are processor intensive and should not be performed when the server is under a heavy load. TE s T Da y Ti p Don’t spend a lot of time memorizing the syntax of every DBCC option. Instead, perform the DBCC CHECKTABLE, DBCC CHECKDB, and DBCC SHRINKFILE examples to become familiar with more commonly used DBCC options. Some of the most powerful and frequently used DBCC commands are those that allow you to check data file fragmentation, validate the integrity of tables or databases, and reclaim space used by your databases and logs. Let’s examine these commands in more detail. Performing the examples will familiarize you with how these statements can be used. Using DBCC CHECKTABLE to Verify Table Integrity DBCC CHECKTABLE examines and optionally repairs the structural integrity of all pages in a specified table. Any inconsistencies in table structure are reported. Use the syntax shown in Example 7.16 to run DBCC CHECKTABLE. Example 7.16 Using DBCC CHECKTABLE—Syntax DBCC CHECKTABLE (table_name | view_name, { NOINDEX | index_id } |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ) [WITH ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, NO_INFOMSGS, TABLOCK, ESTIMATEONLY, PHYSICAL_ONLY | DATA_PURITY} When running DBCC CHECKTABLE, you can specify various options to alter the command behavior. The NOINDEX option specifies that checks should not be run on nonclustered indexes. This reduces the time it takes for the command to complete. Alternatively, you can specify the ID of the specific nonclustered index MaintainingYourDatabase•Chapter7 269 you wish to examine as the index_id. The table itself, whether stored as a heap or a clustered index, is always examined. You can choose to repair the errors found by the DBCC by using the REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST and REPAIR_REBUILD options. REPAIR_FAST is used for backwards compatibility only; it does not actually do anything. REPAIR_ALLOW_DATA_LOSS option specifies that data loss is acceptable during the repair operation. REPAIR_REBUILD does not allow data loss. The database must be in single user mode for any repair to occur. The ALL_ERRORMSGS option specifies that all error messages must be shown, otherwise only the first 200 are shown. The NO_INFOMSGS specifies that no informational messages are to be shown. The EXTENDED_LOGICAL_CHECKS option is a new option in SQL Server 2008. It instructs the DBCC to verify the logical structure of indexed views, XML indexes, and special indexes. This option is only available when the database compatibility level is set to SQL Server 2008 (100). The TABLOCK option instructs the DBCC not to create a database snapshot. Instead, the DBCC will obtain a table lock on the table. This reduces the time it takes for the DBCC CHECKTABLE statement to complete. However, it also means that other users cannot write to the table while DBCC is running. Running DBCC CHECKTABLE is a resource intensive task, and it consumes space in the tempdb database. By specifying ESTIMATEONLY, you will be shown the amount of space the operation will require in tempdb. The PHYSICAL_ONLY option forces the DBCC to perform only checks on the physical structure integrity of pages, row headers, and B-tree structures. This check is quicker than the full run of DBCC CHECKTABLE because it omits the extensive logical checks that are normally run. The PHYSICAL_ONLY check can detect common hardware failures that result in table corruption and torn pages. The DATA_PURITY option checks the validity of the data according to its data type. For example, the DATA_PURITY check will show all values that are not valid dates stored in columns of DateTime data type or values that are not valid integers stored in a column of int data type. SQL Server 2005 and 2008 perform this checking automatically. However, databases upgraded from SQL Server 2000 or earlier could contain such invalid column data. In this case, you must execute the DBCC CHECKTABLE WITH DATA_PURITY, manually correct all errors reported, and run DBCC CHECKTABLE WITH DATA_PURITY again to enable automatic column level integrity checking. Example 7.17 demonstrates the use of the DBCC CHECKTABLE. 270 Chapter7•MaintainingYourDatabase Example 7.17 Using the DBCC CHECKTABLE USE AdventureWorks; GO Perform default checks DBCC CHECKTABLE ("Person.Contact"); GO Results: DBCC results for 'Person.Contact'. There are 19982 rows in 567 pages for object "Person.Contact". DBCC results for 'sys.xml_index_nodes_341576255_256000'. There are 195 rows in 3 pages for object "sys.xml_index_nodes_341576255_256000". DBCC execution completed. If DBCC printed error messages, contact your system administrator. Perform physical checks without creating a snapshot. Do not check nonclustered indexes. DBCC CHECKTABLE ("Person.Contact", NOINDEX) WITH PHYSICAL_ONLY, TABLOCK; GO Results: DBCC execution completed. If DBCC printed error messages, contact your system administrator. Generate estimate of tempdb space that would be consumed by the DBCC CHECKTABLE operation. DBCC CHECKTABLE ("Person.Contact") WITH ESTIMATEONLY; GO Results: Estimated TEMPDB space needed for CHECKTABLES (KB) 8425 (1 row(s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. Repair the Contact table, without losing data. ALTER DATABASE AdventureWorks SET SINGLE_USER; GO DBCC CHECKTABLE ("Person.Contact", REPAIR_REBUILD); GO Results: DBCC results for 'Person.Contact'. There are 19982 rows in 567 pages for object "Person.Contact". DBCC results for 'sys.xml_index_nodes_341576255_256000'. There are 195 rows in 3 pages for object "sys.xml_index_ nodes_341576255_256000". MaintainingYourDatabase•Chapter7 271 DBCC execution completed. If DBCC printed error messages, contact your system administrator. ALTER DATABASE AdventureWorks SET MULTI_USER; GO Using the DBCC CHECKDB to Verify Database Integrity DBCC CHECKDB verifies the physical and logical integrity for all objects in a specified database and optionally attempts to repair integrity errors. DBCC CHECKDB runs DBCC CHECKALLOC, DBCC CHECKTABLE, and DBCC CHECKCATALOG on every applicable object in the database. If enabled DBCC CHECKDB validates the link between tables and FILESTREAM access, DBCC CHECKDB validates Service Broker data, if any. The syntax used to run DBCC CHECKDB is the same as DBCC CHECKTABLE, and all DBCC CHECKTABLE options apply to DBCC CHECKDB (see Example 7.18). Example 7.18 Using the DBCC CHECKDB - Syntax DBCC CHECKDB ( database_name | database_id | 0, [NOINDEX], [ REPAIR_ALLOW_ DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD ]) WITH [ ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, NO_INFOMSGS, TABLOCK, ESTIMATEONLY, PHYSICAL_ONLY | DATA_PURITY ] Study the options used with DBCC CHECKTABLE as these apply to DBCC CHECKDB also. DBCC CHECKDB checks every table in the database. If 0 is specified for the database_name or the database_name is not specified, the current database is used. Example 7.19 demonstrates the use of DBCC CHECKDB: Example 7.19 Using the DBCC CHECKDB Repair any errors in the AdventureWorks database, allowing data loss. ALTER DATABASE AdventureWorks SET SINGLE_USER; GO DBCC CHECKDB ('Adventureworks', REPAIR_ALLOW_DATA_LOSS) WITH EXTENDED_LOGICAL_CHECKS; GO Results: DBCC results for 'AdventureWorks'. . affect the live database. Instead, they are performed on a database snapshot. The snapshot is created, used for the command, and then dropped. Sometimes the snapshot cannot be created, for example,. shown, otherwise only the first 200 are shown. The NO_INFOMSGS specifies that no informational messages are to be shown. The EXTENDED_LOGICAL_CHECKS option is a new option in SQL Server 2008. . Alternatively, you can specify the ID of the specific nonclustered index MaintainingYourDatabase•Chapter7 269 you wish to examine as the index_id. The table itself, whether stored as a heap or