Professional Documents
Culture Documents
1 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
Syntax
DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
10/5/2016 8:58 AM
2 of 13
| , {
) ]
[ WITH
{
[
[
[
[
[
[
[
}
]
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
ALL_ERRORMSGS ]
, EXTENDED_LOGICAL_CHECKS ]
, NO_INFOMSGS ]
, TABLOCK ]
, ESTIMATEONLY ]
, { PHYSICAL_ONLY | DATA_PURITY } ]
, MAXDOP = number_of_processors ]
Arguments
database_name | database_id | 0
Is the name or ID of the database for which to run integrity checks. If not specified, or if 0 is specified, the current database is
used. Database names must comply with the rules for identifiers.
NOINDEX
Specifies that intensive checks of nonclustered indexes for user tables should not be performed. This decreases the overall
execution time. NOINDEX does not affect system tables because integrity checks are always performed on system table
indexes.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Specifies that DBCC CHECKDB repair the found errors. Use the REPAIR options only as a last resort. The specified database
must be in single-user mode to use one of the following repair options.
REPAIR_ALLOW_DATA_LOSS
Tries to repair all reported errors. These repairs can cause some data loss.
WARNING!!!
The REPAIR_ALLOW_DATA_LOSS option is a supported feature but it may not always be the best option
for bringing a database to a physically consistent state. -If successful, the REPAIR_ALLOW_DATA_LOSS
option may result in some data loss. In fact, it may result in more data lost than if a user were to restore
the database from the last known good backup.
Microsoft always recommends a user restore from the last known good backup as the primary method
to recover from errors reported by DBCC CHECKDB. The REPAIR_ALLOW_DATA_LOSS option is not an
alternative for restoring from a known good backup. It is an emergency last resort option
recommended for use only if restoring from a backup is not possible.
Certain errors, that can only be repaired using the REPAIR_ALLOW_DATA_LOSS option, may involve
deallocating a row, page, or series of pages to clear the errors. Any deallocated data is no longer
accessible or recoverable for the user, and the exact contents of the deallocated data cannot be
10/5/2016 8:58 AM
3 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
determined. Therefore, referential integrity may not be accurate after any rows or pages are deallocated
because foreign key constraints are not checked or maintained as part of this repair operation. The user
must inspect the referential integrity of their database (using DBCC CHECKCONSTRAINTS) after using
the REPAIR_ALLOW_DATA_LOSS option.
Before performing the repair, create physical copies of the files that belong to this database. This
includes the primary data file (.mdf), any secondary data files (.ndf), all transaction log files (.ldf), and
other containers that form the database including full text catalogs, file stream folders, memory
optimized data, etc.
Before performing the repair, consider changing the state of the database to EMERGENCY mode and
trying to extract as much information possible from the critical tables and save that data.
REPAIR_FAST
Maintains syntax for backward compatibility only. No repair actions are performed.
REPAIR_REBUILD
Performs repairs that have no possibility of data loss. This can include quick repairs, such as repairing missing rows in
non-clustered indexes, and more time-consuming repairs, such as rebuilding an index.
REPAIR_REBUILD does not repair errors involving FILESTREAM data.
IMPORTANT! Since DBCC CHECKDB with any of the REPAIR options are completely logged and
recoverable, Microsoft always recommends a user use CHECKDB with any REPAIR options within
a transaction (execute BEGIN TRANSACTION before running the command) so that the user can
confirm he/she wants to accept the results of the operation. Then the user can execute COMMIT
TRANSACTION to commit all work done by the repair operation. If the user does not want to
accept the results of the operation, he/she can execute a ROLLBACK TRANSACTION to undo the
effects of the repair operations.
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.
ALL_ERRORMSGS
Displays all reported errors per object. All error messages are displayed by default. Specifying or omitting this option has no
effect. Error messages are sorted by object ID, except for those messages generated from tempdb database.
InSQL Server Management Studio, the maximum number of error messages returned is 1000. When you specify
ALL_ERRORMSGS, we recommend that you run the DBCC command by using the sqlcmd utility or by scheduling a SQL
Server Agent job to run the command and direct the output to a file. Either of these methods will ensure that running the
command once will report all error messages.
EXTENDED_LOGICAL_CHECKS
If the compatibility level is 100 (SQL Server 2008) or higher, performs logical consistency checks on an indexed view, XML
indexes, and spatial indexes, where present.
For more information, see "Performing Logical Consistency Checks on Indexes," in the "Remarks" section later in this topic.
10/5/2016 8:58 AM
4 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
NO_INFOMSGS
Suppresses all informational messages.
TABLOCK
Causes DBCC CHECKDB to obtain locks instead of using an internal database snapshot. This includes a short-term exclusive
(X) lock on the database. TABLOCK will cause DBCC CHECKDB to run faster on a database under heavy load, but decreases
the concurrency available on the database while DBCC CHECKDB is running.
TABLOCK limits the checks that are performed; DBCC CHECKCATALOG is not run on the database, and Service Broker data is
not validated.
ESTIMATEONLY
Displays the estimated amount of tempdb space that is required to run DBCC CHECKDB with all the other specified options.
The actual database check is not performed.
PHYSICAL_ONLY
Limits the checking to the integrity of the physical structure of the page and record headers and the allocation consistency
of the database. This check is designed to provide a small overhead check of the physical consistency of the database, but it
can also detect torn pages, checksum failures, and common hardware failures that can compromise a user's data.
A full run of DBCC CHECKDB may take considerably longer to complete than earlier versions. This behavior occurs because:
The logical checks are more comprehensive.
Some of the underlying structures to be checked are more complex.
Many new checks have been introduced to include the new features.
Therefore, using the PHYSICAL_ONLY option may cause a much shorter run-time for DBCC CHECKDB on large databases and
is recommended for frequent use on production systems. We still recommend that a full run of DBCC CHECKDB be
performed periodically. The frequency of these runs depends on factors specific to individual businesses and production
environments.
PHYSICAL_ONLY always implies NO_INFOMSGS and is not allowed with any one of the repair options.
NOTE: Specifying PHYSICAL_ONLY causes DBCC CHECKDB to skip all checks of FILESTREAM data.
DATA_PURITY
Causes DBCC CHECKDB to check the database for column values that are not valid or out-of-range. For example, DBCC
CHECKDB detects columns with date and time values that are larger than or less than the acceptable range for the datetime
data type; or decimal or approximate-numeric data type columns with scale or precision values that are not valid.
Column-value integrity checks are enabled by default and do not require the DATA_PURITY option. For databases upgraded
from earlier versions of SQL Server, column-value checks are not enabled by default until DBCC CHECKDB WITH
DATA_PURITY has been run error free on the database. After this, DBCC CHECKDB checks column-value integrity by default.
For more information about how CHECKDB might be affected by upgrading database from earlier versions of SQL Server,
see the Remarks section later in this topic.
If PHYSICAL_ONLY is specified, column-integrity checks are not performed.
Validation errors reported by this option cannot be fixed by using DBCC repair options. For information about manually
correcting these errors, see Knowledge Base article 923247: Troubleshooting DBCC error 2570 in SQL Server 2005 and later
10/5/2016 8:58 AM
5 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
versions.
MAXDOP
Remarks
DBCC CHECKDB does not examine disabled indexes. For more information about disabled indexes, see Disable Indexes and
Constraints.
If a user-defined type is marked as being byte ordered, there must only be one serialization of the user-defined type. Not
having a consistent serialization of byte-ordered user-defined types causes error 2537 when DBCC CHECKDB is run. For
more information, see User-Defined Type Requirements.
Because the Resource database is modifiable only in single-user mode, the DBCC CHECKDB command cannot be run on it
directly. However, when DBCC CHECKDB is executed against the master database, a second CHECKDB is also run internally
on the Resource database. This means that DBCC CHECKDB can return extra results. The command returns extra result sets
when no options are set, or when either the PHYSICAL_ONLY or ESTIMATEONLY option is set.
In versions of SQL Server 2005 before SP2, executing DBCC CHECKDB clears the plan cache for the instance of SQL Server.
Clearing the plan cache causes recompilation of all later execution plans and may cause a sudden, temporary decrease in
query performance. In SP2 and later, executing DBCC CHECKDB does not clear the plan cache.
10/5/2016 8:58 AM
6 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
logical consistency checks. If NOINDEX is also specified, only the logical checks are performed.
These logical consistency checks cross check the internal index table of the index object with the user table that
it is referencing. To find outlying rows, an internal query is constructed to perform a full intersection of the
internal and user tables. Running this query can have a very high effect on performance, and its progress
cannot be tracked. Therefore, we recommend that you specify WITH EXTENDED_LOGICAL_CHECKS only if you
suspect index issues that are unrelated to physical corruption, or if page-level checksums have been turned off
and you suspect column-level hardware corruption.
If the index is a filtered index, DBCC CHECKDB performs consistency checks to verify that the index entries
satisfy the filter predicate.
If the compatibility level is 90 or less, unless NOINDEX is specified, DBCC CHECKDB performs both physical and
logical consistency checks on a single table or indexed view and on all its nonclustered and XML indexes. Spatial
indexes are not supported.
Starting with SQL Server 2016, additional checks on persisted computed columns, UDT columns, and filtered indexes
will not run by default to avoid the expensive expression evaluations. This change greatly reduces the duration of
CHECKDB against databases containing these objects. However, the physical consistency checks of these objects is
always completed. Only when EXTENDED_LOGICAL_CHECKS option is specified will the expression evaluations be
performed in addition to already present logical checks (indexed view, XML indexes, and spatial indexes) as part of
the EXTENDED_LOGICAL_CHECKS option.
To learn the compatibility level of a database
View or Change the Compatibility Level of a Database
10/5/2016 8:58 AM
7 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
(BLOBs) in the file system. When using DBCC CHECKDB on a database that stores BLOBs in the file system, DBCC checks
link-level consistency between the file system and database.
For example, if a table contains a varbinary(max) column that uses the FILESTREAM attribute, DBCC CHECKDB will check
that there is a one-to-one mapping between file system directories and files and table rows, columns, and column values.
DBCC CHECKDB can repair corruption if you specify the REPAIR_ALLOW_DATA_LOSS option. To repair FILESTREAM
corruption, DBCC will delete any table rows that are missing file system data.
Best Practices
We recommend that you use the PHYSICAL_ONLY option for frequent use on production systems. Using PHYSICAL_ONLY
can greatly shorten run-time for DBCC CHECKDB on large databases. We also recommend that you periodically run DBCC
CHECKDB with no options. How frequently you should perform these runs depends on individual businesses and their
production environments.
State
Description
Error number 8930 was raised. This indicates a corruption in metadata that terminated the DBCC
command.
Error number 8967 was raised. There was an internal DBCC error.
10/5/2016 8:58 AM
8 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
State
Description
Error Reporting
A dump file (SQLDUMPnnnn.txt) is created in the SQL Server LOG directory whenever DBCC CHECKDB detects a corruption
error. When the Feature Usage data collection and Error Reporting features are enabled for the instance of SQL Server, the
file is automatically forwarded to Microsoft. The collected data is used to improve SQL Server functionality.
The dump file contains the results of the DBCC CHECKDB command and additional diagnostic output. Access is limited to
the SQL Server service account and members of the sysadmin role. By default, the sysadmin role contains all members of the
Windows BUILTIN\Administrators group and the local administrator's group. The DBCC command does not fail if the data
collection process fails.
Resolving Errors
If any errors are reported by DBCC CHECKDB, we recommend restoring the database from the database backup instead of
running REPAIR with one of the REPAIR options. If no backup exists, running repair corrects the errors reported. The repair
option to use is specified at the end of the list of reported errors. However, correcting the errors by using the
REPAIR_ALLOW_DATA_LOSS option might require deleting some pages, and therefore some data.
Under some circumstances, values might be entered into the database that are not valid or out-of-range based on the data
type of the column. DBCC CHECKDB can detect column values that are not valid for all column data types. Therefore,
running DBCC CHECKDB with the DATA_PURITY option on databases that have been upgraded from earlier versions of SQL
Server might reveal preexisting column-value errors. Because SQL Server cannot automatically repair these errors, the
column value must be manually updated. If CHECKDB detects such an error, CHECKDB returns a warning, the error number
2570, and information to identify the affected row and manually correct the error.
The repair can be performed under a user transaction to let the user roll back the changes that were made. If repairs are
rolled back, the database will still contain errors and must be restored from a backup. After repairs are completed, back up
the database.
10/5/2016 8:58 AM
9 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
NOTE: You cannot run the DBCC CHECKDB command in emergency mode inside a user transaction and roll
back the transaction after execution.
When the database is in emergency mode and DBCC CHECKDB with the REPAIR_ALLOW_DATA_LOSS clause is run, the
following actions are taken:
DBCC CHECKDB uses pages that have been marked inaccessible because of I/O or checksum errors, as if the errors
have not occurred. Doing this increases the chances for data recovery from the database.
DBCC CHECKDB attempts to recover the database using regular log-based recovery techniques.
If, because of transaction log corruption, database recovery is unsuccessful, the transaction log is rebuilt. Rebuilding
the transaction log may result in the loss of transactional consistency.
WARNING! The REPAIR_ALLOW_DATA_LOSS option is a supported feature of SQL Server. However, it
may not always be the best option for bringing a database to a physically consistent state. If successful,
the REPAIR_ALLOW_DATA_LOSS option may result in some data loss. In fact, it may result in more data
lost than if a user were to restore the database from the last known good backup. Microsoft always
recommends a user restore from the last known good backup as the primary method to recover from
errors reported by DBCC CHECKDB. The REPAIR_ALLOW_DATA_LOSS option is not an alternative for
restoring from a known good backup. It is an emergency last resort option recommended for use
only if restoring from a backup is not possible.
After rebuilding the log, there is no full ACID guarantee.
After rebuilding the log, DBCC CHECKDB will be automatically performed and will both report and
correct physical consistency issues.
Logical data consistency and business logic enforced constraints must be validated manually.
The transaction log size will be left to its default size and must be manually adjusted back to its recent
size.
If the DBCC CHECKDB command succeeds, the database is in a physically consistent state and the database status is set to
ONLINE. However, the database may contain one or more transactional inconsistencies. We recommend that you run DBCC
CHECKCONSTRAINTS to identify any business logic flaws and immediately back up the database.
If the DBCC CHECKDB command fails, the database cannot be repaired.
10/5/2016 8:58 AM
10 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
by the CHECKDB process, triggers do not fire; therefore, the change is not replicated.
Transactional replication uses the transaction log to track changes to published tables. The Log Reader Agent
then moves these changes to the distribution database. Some DBCC repairs, although logged, cannot be
replicated by the Log Reader Agent. For example, if a data page is deallocated by the CHECKDB process, the
Log Reader Agent does not translate this to a DELETE statement; therefore, the change is not replicated.
Replication metadata tables. Actions performed by the CHECKDB process to repair corrupt replication metadata
tables require removing and reconfiguring replication.
If you have to run the DBCC CHECKDB command with the REPAIR_ALLOW_DATA_LOSS option on a user database or
distribution database:
1. Quiesce the system: Stop activity on the database and at all other databases in the replication topology, and then try
to synchronize all nodes. For more information, see Quiesce a Replication Topology (Replication Transact-SQL
Programming).
2. Execute DBCC CHECKDB.
3. If the DBCC CHECKDB report includes repairs for any tables in the distribution database or any replication metadata
tables in a user database, remove and reconfigure replication. For more information, see Disable Publishing and
Distribution.
4. If the DBCC CHECKDB report includes repairs for any replicated tables, perform data validation to determine whether
there are differences between the data in the publication and subscription databases.
Result Sets
DBCC CHECKDB returns the following result set. The values might vary except when the ESTIMATEONLY, PHYSICAL_ONLY, or
NO_INFOMSGS options are specified:
DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
10/5/2016 8:58 AM
11 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
10/5/2016 8:58 AM
12 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
Permissions
Requires membership in the sysadmin fixed server role or the db_owner fixed database role.
Examples
A. Checking both the current and another database
The following example executes DBCC CHECKDB for the current database and for the AdventureWorks2012 database.
Transact-SQL
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2012 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2012, NOINDEX);
GO
See Also
DBCC (Transact-SQL)
View the Size of the Sparse File of a Database Snapshot (Transact-SQL)
10/5/2016 8:58 AM
13 of 13
https://msdn.microsoft.com/en-us/library/ms176064(d=printer).aspx
sp_helpdb (Transact-SQL)
System Tables (Transact-SQL)
Community Additions
2016 Microsoft
10/5/2016 8:58 AM