☰

将 DBCC CHECKDB 划分为几天

tag-icon • tag-icon sql-server dbcc checkdb
将 DBCC CHECKDB 划分为几天

我正在努力实现 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 数据。

我的问题是：

  1. 有没有办法单独执行这些额外的检查？我应该担心吗？（索引视图可能比其他两个视图更让我担心）

  2. 如果我想在 SQL2000、2005 和 2008 数据库中实现这一点，我需要对我的策略做哪些重大修改？

  3. CHECKALLOC 和 CHECKCATALOG 似乎运行得相当快。有什么理由不每天运行这 2 个检查？

谢谢！

答案1

不确定您将如何进行 1) 中的检查，也许在 Profiler 中查看 CHECKDB 以查看这些检查在幕后运行的内容，并查看该代码是否可以重复？

关于 2)，虽然我倾向于根据时间（每月）进行分区，例如对于总帐应用程序，但根据关键性（从更关键到不太关键、从更频繁使用到不太频繁使用等）将表放入文件组是否对您更有意义？这假定本月流量大的表组下个月也会如此。也许 DMV sys.dm_db_partition_stats 中的 used_pa​​ge_count 有助于确认初始表到文件组的放置。

3) 如果时间不会导致生产可用窗口的蔓延，为什么不呢？

答案2

您说这是一个全屋范围的实施 - 除非您真的没有窗口，并且所有数据库都是 VLDB（10TB+），否则在我看来，这太复杂了。如果您的大多数实例都足够小，请使用标准 checkDB 作业运行 - 并且只需为真正大型的数据库准备一个特殊作业。它们应该是例外。

您是否考虑过针对还原到预生产阶段执行 checkDB？或者大多数情况下只针对 physical_only？或者使用第三方工具（例如 Redgate 的 SQL Virtual Restore）针对备份文件执行 checkDB。

相关内容