[Prior Post In Series] [Backup Series] [Next Post in Series]
In a time long long ago (last millennium), DBCC was known as Database Consistency Checker; today it stands for Database Console Command. It performs many functions similar to what the old utility FDISK did on hard drives -- checks for errors of various types and optionally fixes them. The many different commands available are listed in the documentation . Many functions have been moved out of DBCC into friendlier commands. The essential DBCC command to be familiar with is CHECKDB.
Like FDISK, you can ask for an analysis or for repair (if a problem is found).
One word of warning about breaking: DBCC executes using parallelism (multiple cores), if you break it, any rollback is single threaded (single core).
This command incorporates the following sub-commands.
Before you run DBCC CHECKDB on your production system, run it on your test system with a copy of the production system (to get the same volume of data). If DBCC CHECKDB runs for 7 days and it is executing against your production system, you may have some unhappy users. DBCC CHECKDB can be CPU intensive.
CheckDB uses lots of resources:
My usual recommendation (for simple cases) is to do
DBCC CHECKDB {DBNAME} WITH NO_INFOMSGS
This results in nothing but "Command(s) completed successfully" usually. There is no need to read through dozens of information messages. This command may take seconds, hours or days, depending on the size of your database and resources available.
With a long running query, it is nice to know how far along you are. The status may be obtained by executing in another query window the command below
The output is show below.
If the time to execute DBCC CHECKDB is excessive, fear not -- in a future post, I will build an infrastructure and automated code to decompose the steps and execute each step in a time window to minimize the impact on production.
If DBCC CHECKDB reports a problem, things can become messy. The best strategy is to restore the database; do not attempt a repair by yourself. I recall doing an FDISK repair on a hard drive and finding eight new generic folders contains thousands of 'recovered files'. The physical drive was fixed; but data on it was useless without a lot of work. The same situation can happen with DBCC repairs. The database physical structure is fixed, but data in it may be corrupted and could require a massive manual effort to make usable. In reality, you may have lost your database.
With a physical hard drive containing valuable information, you would send it out to a specialist hard drive recovery shop because the information is worth the cost. With SQL Server, contact Microsoft Support before attempting a repair. I quote directly from the documentation below (and Microsoft Support has shouted in my ear the same thing)
Use the REPAIR options only as a last resort . To repair errors, we recommend restoring from a backup . Repair operations do not consider any of the constraints that may exist on or between tables. If the specified table is involved in one or more constraints, we recommend running DBCC CHECKCONSTRAINTS after a repair operation. If you must use REPAIR, run DBCC CHECKDB without a repair option to find the repair level to use. If you use the REPAIR_ALLOW_DATA_LOSS level, we recommend that you back up the database before you run DBCC CHECKDB with this option. |
The good news is that 99+% of the time, you can restore the database from backups and transactions logs -- if properly done. You do not need to do a repair (or contact Microsoft Support).
I covered details of restoring from full backups, differential backups and transaction logs in another series of posts . Below I give a checklist to assist you in sequential order :
If there are problems following this sequence, do everyone a favor and contact Microsoft Support . The number of factors that need to be considered and explore are too many to explain in a blog or forum post.
DBCC has been around a long time and often things become deprecated (like thou hath) and modern ways are not acquired. The table below shows some of the deprecated DBCC commands and their modern equivalents. The deprecated commands are linked to the official documentation. If you are searching on the internet for information and find example code using any of these commands, ignore them and move on.
DBCC SHOWCONTIG | sys.dm_db_index_physical_stats |
DBCC DBREPAIR | DROP DATABASE |
DBCC CONCURRENCYVIOLATION | obsolete (removed in SQL Server 2008) |
DBCC UNPINTABLE
|
obsolete (removed in SQL Server 2005) |
|
obsolete (removed in SQL Server 2005) |
DBCC NEWALLOC |
DBCC CHECKALLOC
obsolete (removed in SQL Server 2005) |
DBCC ROWLOCK | obsolete (removed in SQL Server 2005) |
DBCC TEXTALL |
DBCC CHECKDB
obsolete (removed in SQL Server 2005) |
DBCC TEXTALLOC |
DBCC CHECKTABLE
obsolete (removed in SQL Server 2005) |
DBCC DBREINDEX | ALTER INDEX REBUILD |
DBCC INDEXDEFRAG | ALTER INDEX REORGANIZE |
With special thanks to Paul Randal , SQLskills.com for correcting technical errors. Paul wrote DBCC CHECKDB and the rest of DBCC.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.