我正在努力实现 Paul Randal 的优秀文章中提出的在几天内手动传播 DBCC CHECKDB 的方法从各个角度看 CHECKDB：VLDB 的一致性检查选项简而言之，该策略包括：
- 将数据库中的表平均划分为 7 个存储桶（使用页数）
- 每周运行两次 DBCC CHECKALLOC
- 每周运行一次 DBCC CHECKCATALOG
- 每周每天对一个存储桶运行 DBCC CHECKTABLE
我有一个单独的 StackOverflow 问题关于将表划分为存储桶的良好算法（如果您有一个有效的 TSQL 脚本，请在那里留言），但这个问题是为了确保我检查正确的东西。CHECKDB 的联机丛书文档表示除了执行 CHECKALLOC、CHECKCATALOG 和 CHECKTABLE 之外，它还：
- 验证数据库中每个索引视图的内容。
- 使用 FILESTREAM 将 varbinary(max) 数据存储在文件系统中时，验证表元数据与文件系统目录和文件之间的链接级一致性。（仅限 SQL 2008）
- 验证数据库中的 Service Broker 数据。
我的问题是：
有没有办法单独执行这些额外的检查？我应该担心吗？（索引视图可能比其他两个视图更让我担心）
如果我想在 SQL2000、2005 和 2008 数据库中实现这一点，我需要对我的策略做哪些重大修改？
CHECKALLOC 和 CHECKCATALOG 似乎运行得相当快。有什么理由不每天运行这 2 个检查？
谢谢！
答案1
不确定您将如何进行 1) 中的检查，也许在 Profiler 中查看 CHECKDB 以查看这些检查在幕后运行的内容，并查看该代码是否可以重复？
关于 2)，虽然我倾向于根据时间（每月）进行分区，例如对于总帐应用程序，但根据关键性（从更关键到不太关键、从更频繁使用到不太频繁使用等）将表放入文件组是否对您更有意义？这假定本月流量大的表组下个月也会如此。也许 DMV sys.dm_db_partition_stats 中的 used_page_count 有助于确认初始表到文件组的放置。
3) 如果时间不会导致生产可用窗口的蔓延，为什么不呢？
答案2
您说这是一个全屋范围的实施 - 除非您真的没有窗口，并且所有数据库都是 VLDB（10TB+），否则在我看来，这太复杂了。如果您的大多数实例都足够小，请使用标准 checkDB 作业运行 - 并且只需为真正大型的数据库准备一个特殊作业。它们应该是例外。
您是否考虑过针对还原到预生产阶段执行 checkDB？或者大多数情况下只针对 physical_only？或者使用第三方工具（例如 Redgate 的 SQL Virtual Restore）针对备份文件执行 checkDB。