DBCC CHECKTABLE (Transact-SQL)

更新日期： 2008 年 11 月 17 日

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

Transact-SQL 语法约定

语法

DBCC CHECKTABLE 
(
        table_name | view_name
    [ , { NOINDEX | index_id }
     |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } 
    ] 
)
    [ WITH 
        { ALL_ERRORMSGS ]
          [ , NO_INFOMSGS ]
          [ , TABLOCK ] 
          [ , ESTIMATEONLY ] 
          [ , { PHYSICAL_ONLY | DATA_PURITY } ] 
        }
    ]

参数

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

• ALL_ERRORMSGS
  显示不受限制的错误数。在 SQL Server 2005 Service Pack 3 (SP3) 中，默认情况下显示所有错误消息。指定或省略此选项都不起作用。在 SQL Server 的早期版本中，如果未指定 ALL_ERRORMSGS，则只为每个对象显示前 200 条错误消息。

• NO_INFOMSGS
  禁止显示所有信息性消息。

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

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

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

  • 逻辑检查比较全面。
  • 要检查的某些基础结构更为复杂。
  • 在 SQL Server 2005 中引入了许多新的检查，以包含新增功能。

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

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

  对于在 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 返回以下结果集。如果您仅指定了表名或任意选项，则返回相同的结果集。

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.

备注

除非指定 NOINDEX 选项，否则，DBCC CHECKTABLE 将对单个表或索引视图及其所有非聚集索引以及 XML 索引执行一致性检查。若要对数据库中的每个表执行 DBCC CHECKTABLE，请使用 DBCC CHECKDB。

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

• 是否已正确链接索引、行内、LOB 以及行溢出数据页。
• 索引是否按照正确的顺序排列。
• 各指针是否一致。
• 每页上的数据是否合理（包括计算列）。
• 页面偏移量是否合理。
• 基表的每一行是否在每个非聚集索引中具有匹配的行，以及非聚集索引的每一行是否在基表中具有匹配的行。
• 已分区表或索引的每一行是否都位于正确的分区中。

内部数据库快照

DBCC CHECKTABLE 使用内部数据库快照提供其执行这些检查必需的事务一致性。有关详细信息，请参阅了解数据库快照中的稀疏文件大小和 DBCC (Transact-SQL) 中的“DBCC 内部数据库快照用法”部分。

如果无法创建快照，或指定了 TABLOCK，则 DBCC CHECKTABLE 将获取一个共享表锁来获得所需的一致性。

注意：
如果对 tempdb 运行 DBCC CHECKTABLE，则必须获取一个共享表锁。这是因为，为了提高性能，不允许对 tempdb 使用数据库快照。这意味着无法获得所需的事务一致性。

并行检查对象

默认情况下，DBCC CHECKTABLE 对对象执行并行检查。并行度由查询处理器自动确定。最大并行度的配置方式与并行查询相同。若要限制 DBCC 检查可使用的处理器的最大数目，请使用 sp_configure。有关详细信息，请参阅max degree of parallelism 选项。

通过使用跟踪标志 2528 可以禁用并行检查。有关详细信息，请参阅跟踪标志 (Transact-SQL)。

注意：
在运行 DBCC CHECKTABLE 期间时，以字节顺序排列的用户定义类型列中存储的字节必须与用户定义类型值的计算序列相等。否则，DBCC CHECKTABLE 例程将报告一致性错误。

了解 DBCC 错误消息

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

错误报告

在 SQL Server 2005 Service Pack 1 (SP1) 中，一旦 DBCC CHECKTABLE 检测到破坏错误，就将在 SQL Server LOG 目录中创建小型转储文件 (SQLDUMPnnnn.txt)。如果为 SQL Server 实例启用了“功能使用情况数据收集”和“错误报告”功能，该文件将被自动转发给 Microsoft。收集的数据将用于改进 SQL Server 功能。有关详细信息，请参阅错误和使用情况报告设置。

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

纠正错误

如果 DBCC CHECKTABLE 报告了任何错误，那么，我们建议从数据库备份中还原数据库，而不是使用某个 REPAIR 选项来运行 REPAIR。如果没有备份，则运行 REPAIR 也可以更正报告的错误。要使用的修复选项在报告的错误的末尾处指定。但是，使用 REPAIR_ALLOW_DATA_LOSS 选项更正错误可能需要删除一些页面（从而也删除了数据）。

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

权限

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

示例

A. 检查特定表

以下示例将检查 AdventureWorks 数据库中的 HumanResources.Employee 表的数据页完整性。

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

B. 以较低的开销检查表

以下示例将以较低的开销检查 AdventureWorks 数据库中的 Employee 表。

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

C. 检查特定索引

以下示例将检查通过访问 sys.indexes 获得的特定索引。

USE AdventureWorks;
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);

请参阅

参考

DBCC (Transact-SQL)

其他资源

表和索引体系结构
索引视图上的 DBCC 错误疑难解答

帮助和信息

获取 SQL Server 2005 帮助

更改历史记录