几天内划分DBCC CHECKDB

Question

我正在实现Paul在几天内手动传播DBCC的方法，该方法来自于他的优秀文章CHECKDB从各个角度: VLDB的一致性检查选项。简言之，该战略包括：

• 将数据库中的表平均划分为7个桶(使用页数)
• 每周运行两次DBCC CHECKALLOC
• 每周运行一次DBCC CHECKCATALOG
• 每天在一个桶上运行

我有一个关于将表划分为桶的好算法的单独的StackOverflow问题 (如果您有一个工作的TSQL脚本，请加入其中)，但是这个问题是关于确保我检查的是正确的东西。CHECKDB的联机图书文档说，除了做CHECKALLOC、CHECKCATALOG和CHECKTABLE之外，它还：

• 验证数据库中每个索引视图的内容。
• 当使用FILESTREAM在文件系统中存储var二进制(Max)数据时，验证表元数据与文件系统目录和文件之间的链接级一致性。(只有SQL 2008 )
• 验证数据库中的Service数据。

以下是我的问题：

1. 是否有方法单独执行这些附加检查？我该担心吗？(索引视图可能比其他两个更直接地关心我)
2. 如果我想在SQL2000、2005年和2008年的数据库中实现这一点，我需要对我的策略做任何重大的修改吗？
3. CHECKALLOC和CHECKCATALOG似乎运行得很快。有理由不每天做这两次检查吗？

谢谢!

Answer 1

不确定如何在1)中进行检查，也许可以查看Profiler中的CHECKDB，以查看隐藏的这些检查在运行什么，并查看该代码是否可以复制？

关于2)，虽然我倾向于根据时间(每月)进行分区，例如总分类账应用程序，但会根据关键度将表放入文件组(对不太重要的情况更重要，对不太积极地使用，等等)。对你来说更有意义？这意味着，下个月的大流量表组将是相同的。也许来自车管局sys.dm_db_partition_stats的used_page_count将有助于确认原始表到文件组的位置。

3)如果时间并没有使产品的可用窗口变得缓慢，为什么不呢？

Answer 2

你说这是一个产业范围的实现--除非你真的没有窗口，而且所有的数据库都是VLDB (10TB+)，在我看来，这似乎过于复杂了。如果大多数实例都足够小，那么运行一个标准的checkDB作业--并为真正的大型数据库提供一个特殊的任务。他们应该是例外。

你有没有想过要做一个检查数据库来防止恢复到预驱动？或者大部分时间都是physical_only？或者使用第三方工具(如Redgate的)对备份文件执行checkDB。