%EF%BC%9F.png)
我正在我们的 OLTP 环境 (SQL 2005,2008) 中启用 DBCC CHECKDB。系统开销在我们的服务器上非常明显，因此我希望它们尽可能高效。因此 - 我想启用 NOINDEX 选项，这是我以前从未使用过的选项。我的想法是：如果在完整性检查之外检测到索引存在问题，我可以重建索引。此外，完整性检查的持续时间将大大减少，并且将检测到更严重的损坏。
我的计划有什么缺陷？
谢谢，Deb
答案1
DBCC CHECKDB 需要在非工作时间或使用率较低的时段执行。对于大型数据库，它会（按照设计）严重损坏服务器的磁盘子系统，使其几乎无法使用。它需要读取数据库中的每一页。使用 NOINDEX 选项对您没有太大帮助，因为您需要检查所有（可重建）索引是否均已损坏。如果其中一个索引已损坏，则可能会将错误返回到您的应用程序或内部过程/事务。如果您的应用程序代码或过程没有正确处理所有这些错误（即正确回滚嵌套事务），则最终可能会出现逻辑数据损坏（例如会计系统中的借方没有贷方）。
我们每周在周日凌晨对所有数据库进行一次 CHECKDB，因为那时使用率非常低。对于我们规模最大、使用最频繁的 24x7 操作，我们会运行 DBCC CHECKTABLE，而不是在表之间使用 WAITFOR，以最大限度地减少对最终用户的影响。如果您采用这种方式，您还需要定期在数据库上运行 DBCC CHECKALLOC 和 DBCC CHECKCATALOG（这些都包含在完整的 CHECKDB 中）。
最后，如果您遇到 SQL Server 数据库中任何形式的损坏，您需要立即查看存储硬件堆栈。自 1990 年代的 SQL 6.5 以来，我们商店中从未见过任何类型的数据库损坏，我们有数十台高容量 SQL 服务器。我唯一一次在 SQL 7 及更高版本中看到数据库损坏是因为客户站点的 RAID 控制器出现故障（Promise 真的很糟糕）。
答案2
没有什么缺陷，但是您面临着非聚集索引中的完整性失败可能影响最终用户或应用程序的风险，您不会丢失任何数据，但在重建索引时可能会产生影响。
如果性能是一个巨大的担忧，请每天运行完整备份，恢复到不同的服务器并根据副本运行检查。