Those of you familiar with previous versions of SQL Server might know the DBCC statements as the Database Consistency Checker. All documentation now refers to them as the Database Console Commands, probably in deference to the fact that not all of them are used for database consistency checks.
Running DBCC statements are an integral part of database maintenance. Some, such as DBCC CHECKDB, can be run on a scheduled basis (this is the one the wizard runs) as a preventative measure, and others, such as DBCC SHRINKFILE, you can choose to run when needed. Table 17.1 lists some of the DBCC statements commonly used for database maintenance.
DBCC | Function |
---|---|
CHECKDB | Checks allocation and integrity of all DB objects |
CHECKALLOC | Checks the consistency of disk space allocation |
CHECKTABLE | Checks the integrity of the specified table and its indexes |
SHRINKDATABASE | Attempts to shrink all data files in the specified database |
SHRINKFILE | Attempts to shrink a specified data file |
SHOWCONTIG | Displays fragmentation information on a table and its indexes |
DBREINDEX | Rebuilds indexes for a specified table |
INDEXDEFRAG | Defragments indexes for a specified table or view |
Several of the DBCC statements have the ability to detect and attempt to repair corruption in the database. Power failures or spikes, hardware glitches, or even internal SQL Server errors can cause this corruption. The primary validation DBCCs are the CHECK statements listed here:
DBCC CHECKDB
DBCC CHECKALLOC
DBCC CHECKCATALOG
DBCC CHECKCONSTRAINTS
DBCC CHECKFILEGROUP
DBCC CHECKIDENT
DBCC CHECKTABLE
Of these, DBCC CHECKDB is the most functional, as it checks all objects in the database. The others, with the exception of CHECKCATALOG and CHECKALLOC, check specific objects within the database. CHECKCATALOG checks for database consistency with the system catalog, and CHECKALLOC checks the consistency of disk space structures.
The DBCC statements CHECKDB, CHECKALLOC, and CHECKTABLE have options to attempt to repair any problems they encounter. The CHECKDB statement is safest, as it also encompasses all the checks of the other two statements. It is, however, more time- and resource-consuming, so you might opt for using one of the others. For instance, if only allocation errors are being reported, running CHECKALLOC might be more efficient. The three repair options are as follows:
REPAIR_FAST? Attempts minor repairs that can be performed quickly with no chance of data loss.
REPAIR_REBUILD? Performs all repairs of REPAIR_FAST and also performs index rebuilds. No loss of data will result.
REPAIR_ALLOW_DATA_LOSS? Encompasses the repairs of the first two options and also includes allocation and deallocation of rows and pages for correcting errors, and deletion of corrupted text objects. This can result in data loss.
To speed up the processing of DBCC statements, The Enterprise and Developer editions of SQL Server can take advantage of multiple processors, and will perform parallel execution of DBCC statements. The DBCC CHECKDB statement performs a serial scan of the database, but parallel scans of multiple objects as it proceeds to the limit of the system "max degree of parallelism" option. This speeds up the operation substantially over previous versions. Another option is to run DBCC CHECKDB or DBCC CHECKTABLE with the NOINDEX option. This speeds the operation of the DBCC statement as it doesn't check the non-clustered indexes on user tables (system table indexes are always checked). Index corruption is not as critical an issue as data corruption, as no data is lost, and the index can always be dropped and re-created if necessary.
The DBCC statements DBCC TRACEON and DBCC TRACEOFF are used to enable and disable trace flags. Trace flags set various database characteristics and enable detailed reporting of various functions to help in troubleshooting. For example, DBCC TRACEON (1205) displays detailed deadlock information.