The Database Console Commands

The Database Console Commands (DBCC) 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 below lists some of the DBCC statements commonly used for database maintenance. Database Maintenance DBCC Statements

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

Detecting and Resolving Database Corruption 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 DBCC DBCC DBCC DBCC DBCC DBCC

CHECKDB CHECKALLOC CHECKCATALOG CHECKCONSTRAINTS CHECKFILEGROUP CHECKIDENT 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. Using DBCC to Set Trace Flags 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.