DBCC 数据库错误检查与修复

 

http://msdn.microsoft.com/zh-cn/library/ms176064.aspx

 

通过执行下列操作检查指定数据库中所有对象的逻辑和物理完整性：

• 对数据库运行 DBCC CHECKALLOC。
• 对数据库中的每个表和视图运行 DBCC CHECKTABLE。
• 对数据库运行 DBCC CHECKCATALOG。
• 验证数据库中每个索引视图的内容。
• 使用 FILESTREAM 在文件系统中存储 varbinary(max) 数据时，验证表元数据和文件系统目录和文件之间的链接级一致性。
• 验证数据库中的 Service Broker 数据。

这意味着不必从 DBCC CHECKDB 单独运行 DBCC CHECKALLOC、DBCC CHECKTABLE 或 DBCC CHECKCATALOG 命令。有关这些命令执行的检查的详细信息，请参阅这些命令的说明。

Transact-SQL 语法约定

语法

---

复制

DBCC CHECKDB 

[     [ ( database_name | database_id | 0         [ , NOINDEX         | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]         ) ]     [ WITH         {             [ ALL_ERRORMSGS ]             [ , EXTENDED_LOGICAL_CHECKS ]             [ , NO_INFOMSGS ]             [ , TABLOCK ]             [ , ESTIMATEONLY ]             [ , { PHYSICAL_ONLY | DATA_PURITY } ]         }     ]

]

参数

---

database_name | database_id | 0

要为其运行完整性检查的数据库的名称或 ID。如果未指定，或者指定为 0，则使用当前数据库。数据库名称必须符合有关标识符的规则。

NOINDEX

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

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

指定 DBCC CHECKDB 修复发现的错误。指定的数据库必须处于单用户模式，才能使用以下修复选项之一。

REPAIR_ALLOW_DATA_LOSS

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

REPAIR_FAST

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

REPAIR_REBUILD

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

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

重要提示：

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

ALL_ERRORMSGS

显示针对每个对象报告的所有错误。在 SQL Server 2008 Service Pack 1 (SP1) 中，默认情况下显示所有错误消息。指定或省略此选项都不起作用。在 SQL Server 的早期版本（SQL Server 2005 SP3 除外）中，如果未指定 ALL_ERRORMSGS，则只为每个对象显示前 200 条错误消息。按对象 ID 对错误消息排序，从 tempdb 数据库生成的那些消息除外。

在 SQL Server Management Studio 中，返回的最大错误消息数为 1000。使用 Management Studio 时，如果指定了 ALL_ERRORMSGS，则可能需要多次执行 DBCC CHECKDB 才能得到完整的错误列表。当您指定 ALL_ERRORMSGS 时，我们建议您使用 sqlcmd 实用工具来执行 DBCC 命令，或计划 SQL Server 代理作业来执行该命令并将输出定向到文件。这两种方法中的任一种都可以确保执行该命令一次即可报告所有错误消息。

EXTENDED_LOGICAL_CHECKS

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

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

NO_INFOMSGS

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

TABLOCK

使 DBCC CHECKDB 获取锁，而不使用内部数据库快照。这包括一个短期数据库排他 (X) 锁。TABLOCK 可使 DBCC CHECKDB 在负荷较重的数据库上运行得更快，但 DBCC CHECKDB 运行时会减少数据库上可获得的并发性。有关锁的详细信息，请参阅锁模式。

TABLOCK 限制执行的检查；DBCC CHECKCATALOG 未对数据库运行并且 Service Broker 数据未进行验证。

ESTIMATEONLY

显示运行包含所有其他指定选项的 DBCC CHECKDB 时所需的 tempdb 空间估计数量。不执行实际数据库检查。

PHYSICAL_ONLY

将检查限制为页和记录标头的物理结构完整性、B 树的物理结构以及数据库的分配一致性。设计该检查是为了以较小的开销检查数据库的物理一致性，但它还可以检测会危及用户数据安全的残缺页、校验和错误以及常见的硬件故障。

DBCC CHECKDB 完成运行所需的时间可能比早期版本要长得多。出现此现象的原因是：

• 逻辑检查更加全面。
• 要检查的某些基础结构更为复杂。
• 引入了许多新的检查以包含新增功能。

因此，使用 PHYSICAL_ONLY 选项可能会大幅减少对较大数据库运行 DBCC CHECKDB 所需的时间，所以对需要频繁检查的生产系统，建议使用此选项。我们仍然建议完整地定期执行 DBCC CHECKDB。这些运行的执行频率取决于各业务和生产环境特定的因素。

PHYSICAL_ONLY 始终表示 NO_INFOMSGS，不能与任何一个修复选项一同使用。

注意：

指定 PHYSICAL_ONLY 会使 DBCC CHECKDB 跳过对 FILESTREAM 数据的所有检查。

DATA_PURITY

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

对于在 SQL Server 2005 及更高版本中创建的数据库，默认情况下将启用列值完整性检查，并且不需要使用 DATA_PURITY 选项。对于从 SQL Server 的早期版本升级的数据库，默认情况下不启用列值检查，直到 DBCC CHECKDB WITH DATA_PURITY 已在数据库中正确运行为止。然后，DBCC CHECKDB 将默认检查列值完整性。有关从 SQL Server 的早期版本升级数据库会对 CHECKDB 有何影响的详细信息，请参阅本主题的“备注”部分。

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

无法使用 DBCC 修复选项来纠正该选项所报告的验证错误。

http://msdn.microsoft.com/zh-cn/library/ms176064.aspx