DBCC CHECKALLOC 可使用内部数据库快照来提供执行这些检查所需的事务的一致性。如果无法创建快照，或指定了 TABLOCK，则 DBCC CHECKALLOC 将尝试获取排他 (X) 数据库锁，以获取所需的一致性。有关锁的详细信息，请参阅锁模式。

DBCC CHECKALLOC 命令完成后，会将一条消息写入 sql Server 错误日志。如果 DBCC 命令成功执行，则消息指示成功完成以及命令运行的时间。如果 DBCC 命令在完成检查之前由于错误而停止，则消息将指示命令已终止，并指示状态值和命令运行的时间。下表列出并说明了此消息中可包含的状态值。

一旦 DBCC CHECKALLOC 检测到损坏错误，就将在 sql Server LOG 目录中创建微型转储文件 (sqlDUMPnnnn.txt)。如果为 sql Server 实例启用了“功能使用情况数据收集”和“错误报告”功能，该文件将被自动转发给 Microsoft。收集的数据将用于改进 sql Server 功能。

转储文件包含 DBCC CHECKALLOC 命令的结果以及其他诊断输出数据。该文件拥有任意访问控制列表 (DACL)。只有 sql Server 服务帐户和 sysadmin 角色的成员有权进行访问。默认情况下，sysadmin 角色包含 Windows BUILTIN\Administrators 组和本地管理员组的所有成员。如果数据收集进程失败，DBCC 命令不会失败。

如果 DBCC CHECKALLOC 报告了任何错误，则建议您通过数据库备份来还原该数据库，而不是运行修复。如果备份不存在，则运行修复也可纠正报告的错误；但是，纠正这些错误时可能需要删除某些页，进而删除数据。

修复可在用户事务内执行。允许回滚所做的更改。如果回滚所做的更改，则数据库仍将包含错误，因此必须通过备份进行还原。修复完成后，备份该数据库。

对索引进行的逻辑一致性检查因数据库兼容级别而异，如下所示：

• 如果兼容级别为 100 (sql Server 2008) 或更高：

  • 除非指定 NOINDEX，否则 DBCC CHECKDB 对单个表及其所有非聚集索引同时执行物理和逻辑一致性检查。但是，在默认情况下，仅对 XML 索引、空间索引和索引视图执行物理一致性检查。

  • 如果指定了 WITH EXTENDED_LOGICAL_CHECKS，则将对索引视图、XML 索引和空间索引（如果存在）执行逻辑检查。默认情况下，先执行物理一致性检查，然后执行逻辑一致性检查。如果还指定了 NOINDEX，则仅执行逻辑检查。

    这些逻辑一致性检查可对索引对象的内部索引表及其引用的用户表进行交叉检查。为了查找外部行，将构造内部查询来对内部表和用户表的完整交集执行查询。运行此查询可能会对性能产生很大影响，并且无法跟踪其进度。因此，建议您仅在以下情况下才指定 WITH EXTENDED_LOGICAL_CHECKS：怀疑存在与物理损坏无关的索引问题，或者已关闭页级校验并且怀疑存在列级硬件损坏。

  • 如果索引为筛选索引，DBCC CHECKDB 将执行一致性检查以验证索引项是否满足筛选谓词的要求。

• 如果兼容级别为 90 或更低，则除非指定 NOINDEX，否则 DBCC CHECKDB 将对单个表或索引视图及其所有非聚集索引和 XML 索引同时执行物理和逻辑一致性检查。不支持空间索引。

了解数据库的兼容级别

• 如何查看或更改数据库的兼容级别 (SQL Server Management Studio)

对于执行这些检查所需要的事务一致性，DBCC CHECKDB 使用内部数据库快照。这样可以防止在执行这些命令时出现阻塞和并发问题。有关详细信息，请参阅了解数据库快照中的稀疏文件大小以及 DBCC (Transact-SQL) 中的“DBCC 内部数据库快照用法”部分。如果无法创建快照或指定了 TABLOCK，DBCC CHECKDB 将获取锁以获得所需一致性。在这种情况下，需要排他数据库锁才能执行分配检查，需要共享表锁才能执行表检查。

如果无法创建内部数据库快照，则对 master 运行 DBCC CHECKDB 时将失败。

对 tempdb 运行 DBCC CHECKDB 不会执行任何分配或目录检查，并且必须获取共享表锁才能执行表检查。这是因为，为了提高性能，不允许对 tempdb 使用数据库快照。这意味着无法获得所需的事务一致性。

对数据库和表启用 FILESTREAM 后，便可选择将 varbinary(max) 二进制大型对象 (BLOB) 存储在文件系统中。对在文件系统中存储 BLOB 的数据库使用 DBCC CHECKDB 时，DBCC 将检查文件系统和数据库之间的链接级一致性。

例如，如果表包含使用 FILESTREAM 属性的 varbinary(max) 列，则 DBCC CHECKDB 将检查文件系统目录和文件与表行、表列和列值之间是否存在一对一映射。如果指定 REPAIR_ALLOW_DATA_LOSS 选项，DBCC CHECKDB 便可修复损坏。为了修复 FILESTREAM 损坏，DBCC 将删除缺少文件系统数据的所有表行。

建议您使用 PHYSICAL_ONLY 选项，以便可以频繁检查生产系统。使用 PHYSICAL_ONLY 可以极大地缩短对大型数据库运行 DBCC CHECKDB 的运行时间。同时建议您定期运行没有选项的 DBCC CHECKDB。应当以什么频率执行这些运行任务将取决于各个企业及其生产环境。

默认情况下，DBCC CHECKDB 对对象执行并行检查。并行度由查询处理器自动确定。最大并行度的配置与配置并行查询相同。若要限制 DBCC 检查可使用的处理器的最大数目，请使用 sp_configure。有关详细信息，请参阅 max degree of parallelism 选项。通过使用跟踪标志 2528 可以禁用并行检查。有关详细信息，请参阅跟踪标志 (Transact-SQL)。

DBCC CHECKDB 命令结束之后，便会将一个消息写入 sql Server 错误日志。如果 DBCC 命令成功执行，则消息指示成功以及命令的运行时间。如果 DBCC 命令在完成检查之前由于错误而停止，则消息将指示命令已终止，并指示状态值和命令运行的时间。下表列出并说明了此消息中可包含的状态值。

一旦 DBCC CHECKDB 检测到一个损坏错误，便会在 sql Server LOG 目录中创建转储文件 (sqlDUMPnnnn.txt)。如果为 sql Server 实例启用了“功能使用情况数据收集”和“错误报告”功能，该文件将被自动转发给 Microsoft。收集的数据将用于改进 sql Server 功能。

转储文件包含 DBCC CHECKDB 命令的结果以及其他诊断输出数据。只有 sql Server 服务帐户和 sysadmin 角色的成员有权进行访问。默认情况下，sysadmin 角色包含 Windows BUILTIN\Administrators 组和本地管理员组的所有成员。如果数据收集进程失败，DBCC 命令不会失败。

如果 DBCC CHECKDB 报告了任何错误，建议从数据库备份还原数据库，而不运行具有一个 REPAIR 选项的 REPAIR。如果不存在备份，则运行修复将更正报告的错误。要使用的修复选项在报告的错误的末尾处指定。但是，通过使用 REPAIR_ALLOW_DATA_LOSS 选项来更正错误可能需要删除某些页，因此会删除某些数据。

在某些情况下，可能会在数据库中输入对列的数据类型而言无效或越界的值。在 sql Server 2000 中，DBCC CHECKDB 不对这些列值执行范围或完整性检查。但是，在 sql Server 2005 及更高版本中，DBCC CHECKDB 可以检测到对所有列数据类型均无效的列值。因此，对从 sql Server 的早期版本升级的数据库运行带 DATA_purity 选项的 DBCC CHECKDB 可能会显示预先存在的列值错误。因为 sql Server 不会自动修复这些错误，所以必须手动更新这些列值。如果 CHECKDB 检测到此类错误，CHECKDB 将返回一个警告、错误号 2570 以及标识受影响的行和手动更正错误的信息。

修复操作可以在用户事务下执行，以使用户回滚已做的更改。如果回滚修复，数据库仍会包含错误，因而必须通过备份进行还原。修复完成后，备份数据库。

如果已通过使用 ALTER DATABASE 语句将数据库设置为紧急模式，那么，假如指定了 REPAIR_ALLOW_DATA_LOSS 选项，则 DBCC CHECKDB 可以对数据库执行某些特殊修复。这些修复可能允许那些在普通情况下无法恢复的数据库在物理一致状态下重新联机。这些修复应当是最后手段，并且只有在无法从备份还原数据库时才采用。如果将数据库设置为紧急模式，则该数据库将标记为 READ_ONLY 并禁用日志记录，而且只有 sysadmin 固定服务器角色的成员才能访问它。

数据库处于紧急模式并且以 REPAIR_ALLOW_DATA_LOSS 子句运行 DBCC CHECKDB 时，将执行以下操作：

• DBCC CHECKDB 将使用由于 I/O 或校验和错误而标记为不可访问的页，就如同这些错误没有出现过一样。这样操作将增加从数据库恢复数据的机会。

• DBCC CHECKDB 将尝试使用常规的基于日志的恢复方法恢复数据库。

• 如果由于事务日志损坏而导致数据库恢复失败，则将重新生成事务日志。重新生成事务日志可能导致事务一致性丢失。

如果 DBCC CHECKDB 命令成功，则数据库将在物理上是一致的，并且数据库状态将设置为 ONLINE。但是，数据库可能包含一种或多种事务不一致的情况。我们建议运行 DBCC CHECKCONSTRAINTS 来发现任何业务逻辑缺陷，并立即备份数据库。

如果 DBCC CHECKDB 命令失败，则无法修复数据库。

运行具有 REPAIR_ALLOW_DATA_LOSS 选项的 DBCC CHECKDB 命令可能会影响用户数据库（发布数据库和订阅数据库）以及由复制使用的分发数据库。发布数据库和订阅数据库包括已发布的表和复制元数据表。请注意这些数据库中的下列潜在问题：

• 已发布的表。可能不会复制由 CHECKDB 进程为修复损坏的用户数据而执行的操作：

  • 合并复制使用触发器跟踪对已发布的表所做的更改。如果 CHECKDB 进程插入、更新或删除了行，则触发器不会激发；因此，更改将不会复制。

  • 事务复制使用事务日志跟踪对已发布的表所做的更改。然后，日志读取器代理将这些更改移动到分发数据库。某些 DBCC 修复即使记入日志，仍然无法由日志读取器代理复制。例如，如果数据页由 CHECKDB 进程释放，则日志读取器代理不会将它翻译为 DELETE 语句；因此，更改将不会复制。

• 复制元数据表。由 CHECKDB 进程为修复损坏的复制元数据表而执行的操作需要删除并重新配置复制。

如果必须对用户数据库或分发数据库运行具有 REPAIR_ALLOW_DATA_LOSS 选项的 DBCC CHECKDB 命令：

1. 停止系统：停止数据库和复制拓扑中所有其他数据库的活动，然后尝试同步所有节点。有关详细信息，请参阅如何停止复制拓扑（复制 Transact-SQL 编程）。

2. 执行 DBCC CHECKDB。

3. 如果 DBCC CHECKDB 报表包括分发数据库中任何表或用户数据库中任何复制元数据表的修复，则请删除并重新配置复制。有关详细信息，请参阅删除复制。

4. 如果 DBCC CHECKDB 报表包括任何已复制表的修复，则请执行数据验证以确定发布数据库和订阅数据库中的数据之间是否存在差异。有关详细信息，请参阅发布服务器和订阅服务器上的数据不匹配。

下面的示例将对当前数据库和 AdventureWorks2008R2 数据库执行 DBCC CHECKDB。

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2008R2 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2008R2,NOINDEX);
GO

以下示例检查当前数据库，并取消所有信息性消息。

DBCC CHECKDB WITH NO_INFOMSGS;
GO

检查组成表或索引视图的所有页和结构的完整性。

table_name |  view_name

要进行完整性检查的表或索引视图。表名或视图名必须符合有关标识符的规则。

NOINDEX

指定不应对用户表的非聚集索引执行会占用很大系统开销的检查。这将减少总执行时间。NOINDEX 不会影响系统表，因为完整性检查的执行对象始终是所有系统表索引。

index_id

要执行完整性检查的索引标识 (ID) 号。如果指定了 index_id，则 DBCC CHECKTABLE 只对该索引以及堆或聚集索引执行完整性检查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

指定 DBCC CHECKTABLE 修复发现的错误。若要使用修复选项，数据库必须处于单用户模式。

REPAIR_ALLOW_DATA_LOSS

尝试修复报告的所有错误。这些修复可能会导致一些数据丢失。

REPAIR_FAST

保留语法只是为了向后兼容。未执行修复操作。

REPAIR_REBUILD

执行不会丢失数据的修复。这包括快速修复（如修复非聚集索引中缺少的行）以及更耗时的修复（如重新生成索引）。

REPAIR_REBUILD 不修复涉及 FILESTREAM 数据的错误。

@H_301_110@

注意

仅将 REPAIR 选项作为最后手段使用。若要修复错误，建议您通过备份进行还原。修复操作不会考虑表本身或表之间可能存在的任何约束。如果指定的表与一个或多个约束有关，建议您在修复操作后运行 DBCC CHECKCONSTRAINTS。如果必须使用 REPAIR，请运行不带有修复选项的 DBCC CHECKTABLE 来查找要使用的修复级别。如果要使用 REPAIR_ALLOW_DATA_LOSS 级别，建议您在运行带有此选项的 DBCC CHECKTABLE 之前备份数据库。

ALL_ERRORMSGS

显示不受限制的错误数。默认情况下显示所有错误消息。指定或省略此选项都不起作用。

EXTENDED_LOGICAL_CHECKS

如果兼容级别为 100 (sql Server 2008) 或更高，则对索引视图、XML 索引和空间索引（如果存在）执行逻辑一致性检查。

有关详细信息，请参阅本主题后面“备注”部分中的“对索引执行逻辑一致性检查”。

NO_INFOMSGS

取消显示所有信息性消息。

TABLOCK

可使 DBCC CHECKTABLE 获得一个共享表锁，而不使用内部数据库快照。TABLOCK 可使 DBCC CHECKTABLE 在负荷较重的表上运行得更快，但 DBCC CHECKTABLE 运行时会减少表上可获得的并发性。

ESTIMATEONLY

显示运行 DBCC CHECKTABLE 和所有其他指定选项时，所需的 tempdb 空间的估计大小。

PHYSICAL_ONLY

限制为检查页、记录标头以及 B 树的物理结构的完整性。此选项旨在以较低的开销检查表的物理一致性，同时，此项检查还可以检测可能危及用户数据安全的残缺页和常见的硬件故障。DBCC CHECKTABLE 完全运行的时间可能比在早期版本中完全运行的时间长得多。导致此行为发生的原因如下：

• 逻辑检查更加全面。

• 要检查的某些基础结构更为复杂。

• 引入了许多新的检查以包含新增功能。

因此，使用 PHYSICAL_ONLY 选项可能会使 DBCC CHECKTABLE 在大型表上运行的时间短得多，所以对需要频繁检查的生产系统，建议使用 DBCC CHECKTABLE。我们仍然建议定期执行 DBCC CHECKTABLE 的完整运行。这些运行的执行频率取决于各业务和生产环境特定的因素。PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何一个修复选项一同使用。

@H_301_110@

注意

指定 PHYSICAL_ONLY 会导致 DBCC CHECKTABLE 跳过对 FILESTREAM 数据的所有检查。

DATA_purity

使 DBCC CHECKTABLE 检查表中是否存在无效或越界的列值。例如，DBCC CHECKTABLE 检测到日期和时间值大于或小于 datetime 数据类型的可接受范围的列，或者小数位数或精度值无效的 decimal 或近似 numeric 数据类型列。

对于在 sql Server 2005 及更高版本中创建的数据库，默认情况下将启用列值完整性检查，并且不需要使用 DATA_purity 选项。对于从 sql Server 的早期版本升级的数据库，您可以使用 DBCC CHECKTABLE WITH DATA_purity 查找和更正特定表中的错误；但是，默认情况下不会对该表启用列值检查，直到 DBCC CHECKDB WITH DATA_purity 在数据库中正确运行时为止。然后，DBCC CHECKDB 和 DBCC CHECKTABLE 将默认检查列值完整性。

无法使用 DBCC 修复选项来纠正该选项所报告的验证错误。有关手动更正这些错误的信息，请参阅知识库文章 923247：解决 SQL Server 2005 中的 DBCC 错误 2570。

如果指定了 PHYSICAL_ONLY，则不执行列完整性检查。

对于指定的表，DBCC CHECKTABLE 将检查以下内容：

• 是否已正确链接索引、行内、LOB 以及行溢出数据页。

• 索引是否按照正确的顺序排列。

• 各指针是否一致。

• 每页上的数据是否合理（包括计算列）。

• 页面偏移量是否合理。

• 基表的每一行是否在每个非聚集索引中具有匹配的行，以及非聚集索引的每一行是否在基表中具有匹配的行。

• 已分区表或索引的每一行是否都位于正确的分区中。

• 使用 FILESTREAM 将 varbinary(max) 数据存储在文件系统中时，文件系统与表之间是否保持链接级一致性。

对索引执行逻辑一致性检查

内部数据库快照

检查和修复 FILESTREAM 数据

并行检查对象

了解 DBCC 错误消息

错误报告

纠正错误

DBCC CHECKTABLE 返回以下结果集。如果您仅指定了表名或任意选项，则返回相同的结果集。

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages,contact your system administrator.

如果指定了 ESTIMATEONLY 选项，则 DBCC CHECKTABLE 将返回以下结果集：

Estimated TEMPDB space needed for CHECKTABLES (KB) 
-------------------------------------------------- 
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages,contact your system administrator.

用户必须是表的所有者，或者是 sysadmin 固定服务器角色的成员，或 db_owner 固定数据库角色或 db_ddladmin 固定数据库角色的成员。

A. 检查特定表

USE AdventureWorks2008R2;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

B. 以较低的开销检查表

USE AdventureWorks2008R2;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

C. 检查特定索引

USE AdventureWorks2008R2;
GO
DECLARE @indid int;
SET @indid = (SELECT index_id 
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ("Production.Product",@indid);

database_name|  database_id | 0

要清除的表所在的数据库。如果指定 0，则使用当前数据库。数据库名称必须符合标识符规则。

table_name|  table_id |  view_name|  view_id

要清除的表或索引视图。

batch_size

每个事务处理的行数。如果未指定，或指定为 0，则该语句将在一个事务中处理整个表。

WITH NO_INFOMSGS

取消显示所有信息性消息。