SQL Server Guide

What is DBCC CHECKDB? Complete Guide to SQL Server Database Checking

By Data Repair Pro Team  ·  June 2026  ·  8 min read

If you manage a SQL Server database, DBCC CHECKDB is one of the most important commands you will ever run. It is SQL Server's built-in database integrity checker — a diagnostic tool that examines every single page, row, and allocation structure in your database and reports any inconsistencies or corruption it finds.

In this guide, we will cover exactly what DBCC CHECKDB does, how to run it, how to interpret its output, and — most importantly — what to do when it finds errors.

What Does DBCC CHECKDB Do?

DBCC stands for Database Console Commands. CHECKDB specifically performs a comprehensive physical and logical consistency check of your entire database. Here is what it checks:

• Allocation structures — Verifies that all pages are correctly allocated and belong to the right objects.
• Page checksums — Confirms that each data page has not been modified outside of SQL Server (torn pages, bit rot).
• Row integrity — Validates that row data is internally consistent with defined data types and constraints.
• Index consistency — Checks that clustered and non-clustered indexes correctly reference their base table data.
• Referential integrity — Verifies foreign key relationships between tables.

How to Run DBCC CHECKDB

The basic syntax to run DBCC CHECKDB against a database named MyDatabase is:

The WITH NO_INFOMSGS option suppresses informational messages and shows only errors, making the output much easier to read. To check the current database, you can simply use:

Understanding the Output

DBCC CHECKDB output can look intimidating. Here is a quick guide to what the messages mean:

Clean Output (No Errors)

This is the result you want to see. Your database is healthy.

Error Output (Corruption Found)

Error messages include a message number (like 8946), a severity level, and a description of what is wrong. Severity level 16 indicates user-correctable errors.

Common DBCC CHECKDB Error Codes

• Error 823 — Hard I/O error. SQL Server couldn't read a page. Usually indicates hardware failure.
• Error 824 — Logical consistency I/O error. The page was read but its checksum doesn't match.
• Error 8946 — Invalid page header. The page header has been corrupted beyond recognition.
• Error 2570 — Column value out of range. A row contains a value that violates its data type constraints.
• Error 7986 — System catalog consistency error. System tables are corrupt.

Repair Options in DBCC CHECKDB

When DBCC CHECKDB finds errors, it recommends a repair level. There are three levels:

REPAIR_FAST

Performs minor, syntactic repairs only. Rarely useful in modern SQL Server versions.

REPAIR_REBUILD

Rebuilds indexes and performs repairs that don't involve data loss. This is the safest option and should be tried first.

REPAIR_ALLOW_DATA_LOSS

The most aggressive repair option. SQL Server will discard corrupted pages, which may result in lost rows. Use this only as a last resort when REPAIR_REBUILD fails.

The Easier Way: Use Data Repair Pro

Manually running these T-SQL sequences is error-prone. A single typo in the wrong command can make a bad situation worse. Data Repair Pro automates the entire DBCC CHECKDB scan and repair sequence through a point-and-click interface — no command-line knowledge required.

Best Practices for Running DBCC CHECKDB

• Run DBCC CHECKDB at least once per week on all production databases.
• Schedule it during low-traffic hours using SQL Server Agent jobs.
• Enable Page Verification (CHECKSUM) on all databases to catch corruption early.
• Always take a backup before running any repair operations.
• Monitor the Windows Event Log and SQL Server Error Log for error 823 and 824 messages — these are early warning signs of failing storage hardware.

Related articles: Fix SQL Error 823 · Fix SQL Error 824 · Recover SUSPECT Database