我在我们的OLTP环境中启用DBCC CHECKDB（SQL 2005,2008）。 系统开销在我们的服务器上是一个非常明显的东西，所以我希望它们能够有效率，因为它们是有意义的。 HENCE – 我想打开NOINDEX选项，这是我以前从未使用过的一个选项。 我的想法是这样的：如果在完整性检查之外检测到索引存在问题，那么我可以重build索引。 此外，完整性检查的持续时间将会大大减less，并且会发现更糟糕的腐败现象。
我的计划有什么缺陷？
谢谢，Deb
DBCC CHECKDB需要在非工作时间或低使用时间进行。 在一个巨大的数据库上，它将（devise）严重地摧毁服务器的磁盘子系统，使其几乎不可用。 它需要读取数据库中的每一页。 使用NOINDEX选项不会有太大的帮助，因为您需要检查（可重新构build的）索引都不会损坏。 如果其中一个是腐败的，错误可能会返回到您的应用程序或内部程序/交易。 如果您的应用程序代码或过程没有正确处理所有这些错误（即正确回滚嵌套事务），则可能导致逻辑数据损坏（例如记帐系统中没有贷记的借方）。
我们在周日早上的凌晨做每周的所有数据库CHECKDB，因为使用率非常低。 对于我们最大，最常用的24×7操作，我们运行DBCC CHECKTABLE，而不是在表之间使用WAITFOR，以最大限度地减less最终用户的影响。 如果你走这条路线，你还需要定期对数据库运行DBCC CHECKALLOC和DBCC CHECKCATALOG（这些都包含在一个完整的CHECKDB中）。
最后，如果您在SQL Server数据库中遇到任何forms的损坏，则需要立即查看您的存储硬件堆栈。 自从上世纪90年代的SQL 6.5在我们的商店中，我们还没有看到任何types的数据库损坏，而且我们有数十个大容量的SQL服务器。 在SQL 7和更高版本中，我唯一一次看到数据库损坏是因为客户端的RAID控制器出现故障（Promise真的很糟糕）。
没有任何缺陷，但是您冒着非聚集索引中的完整性失败可能影响最终用户或应用程序的风险，您不会丢失任何数据，但重build索引时可能会有影响。
如果性能是一个巨大的问题，请每天运行完整备份，恢复到不同的服务器，并针对副本运行检查。