将DBCC CHECKDB分为多天进行

我正在研究实施Paul Randal的手动分散DBCC CHECKDB至数天方法,用于非常大的数据库,基本上包括:

  • 在数据库中将表大致均匀地分成7个桶
  • 每周运行两次DBCC CHECKALLOC
  • 每周运行一次DBCC CHECKCATALOG
  • 每天运行一个桶的DBCC CHECKTABLE

有人使用过这种技术吗?是否有现有的脚本可用?

我担心这可能实际上没有覆盖CHECKDB的所有内容;CHECKDB的Books Online文档还提到,除了CHECKALLOC、CHECKCATALOG和CHECKTABLE之外,它还包括:

验证数据库中每个索引视图的内容。 在使用FILESTREAM将varbinary(max)数据存储在文件系统中时,验证表元数据和文件系统目录和文件之间的链接级一致性。(仅适用于SQL 2008) 验证数据库中的服务代理数据。 所以这里是我的问题: 这些额外的检查是否必要/重要?(对我来说,索引视图可能更令人担忧,我认为我们还没有使用服务代理或FILESTREAM。) 如果是这样,有没有办法单独执行这些额外的检查? CHECKALLOC和CHECKCATALOG似乎在大型数据库上运行非常快。不运行这些检查的原因是什么? (注意:这将成为数千个现有数据库跨数百个服务器的标准例程,或者至少是每个特定大小的数据库。这意味着像重新构建所有数据库以使用CHECKFILEGROUP这样的选项对我们来说并不实际。)

Paul在他的博客评论中回答了这个问题的一个版本。他说:“不用担心索引视图验证。从2008年开始,默认情况下关闭了它,因为它没有发现问题。” - BradC
我正在努力做同样的事情,有什么建议或者你发现了哪些需要注意的地方吗?因为你很可能已经实施过这个。 - S3S
1@scsimon 我成功地解决了这个问题,可以参考相关问题中我使用的具体策略来划分表格。我最终创建了一个包含整个服务器上所有(大型)数据库中所有表格的主列表,将其划分为每日的“桶”,这比单独划分每个数据库的列表要均匀得多。对于较小的数据库,我每天只进行完整的DBCC操作,并不参与划分过程。 - BradC
2个回答

DBCC CHECKDB对于SQL Server数据库来说非常重要,可以百分之百确保没有损坏。然而,由于数据库规模不断增长,很难找到一个维护窗口,而你声称是24x7运行的。多年来,SQL Server团队已经实施了各种机制,可以检测最常见的损坏形式,特别是由硬件引起的物理损坏。

从SQL Server 2005及更高版本开始,PAGE_VERIFY = CHECKSUM 可以帮助您主动检测数据库页面中的物理损坏,通过在写入I/O系统时向每个页面添加校验和,并在从磁盘读取时验证校验和。

此外,备份(完全备份或差异备份)使用CHECKSUM将保证检测由硬件引起的任何I/O损坏。

因此,从硬件损坏的角度来看,SQL Server在检测和报告方面做得很好。(还要确保设置与损坏相关的重要警报)。

说到这一点,仍然有逻辑损坏由编写者引起的错误 - 在内存页面被第三方代码或具有足够特权在Windows内核模式下执行的驱动程序或其他软件破坏以及SQL Server Bugs等情况下,以上方法无法检测到,因此需要使用CHECKDB。 DBCC CHECKDB执行更彻底的检查,包括检查页头是否存在可能通过其他方式无法检测到的损坏。

是否有现成的脚本?

与其重新发明轮子,我强烈建议您看看Ola's SQL Server完整性检查解决方案。 高效运行DBCC CHECKDB: 当您在维护窗口时间紧张、数据库庞大或数据库数量众多时,您只需要发挥创造力来运行CHECKDB。 参加了SQLSkills培训后,我在我的环境中实施的是:
  • 优先考虑需要检查的关键表。
  • 将表分成不同优先级的组,并运行DBCC CHECKTABLE,同时运行DBCC CHECKALLOCDBCC CHECKCATALOG
  • 创建一个工作表,用于存储带有优先级的表名。只需确保所有高优先级的大型表不在同一组中,否则您的CHECKDB将无法完成。
  • 您甚至可以在工作表中添加一个超时列,以协调在维护窗口过后何时终止CHECKDB。
  • 记录每个表运行DBCC CHECKTABLEDBCC CHECKALLOCDBCC CHECKCATALOG所花费的时间。这样您就可以了解您的检查通常需要多长时间。
  • 您甚至可以使用NOINDEX选项运行,因为它会加快操作速度,不会检查用户表上的非聚集索引。这有一些优势,因为它与数据损坏不同,不会丢失数据,如果需要可以删除并重新创建索引。
显然,企业版可以利用并行执行DBCC语句的优势,但要注意MAXDOP设置,因为它可能会占用所有的CPU。这可以通过资源管理器进行硬限制。 注意:如果你有稀疏列,那么你的CHECKDB将会非常慢,如 这里所描述的。 最后,通过利用所有可用的工具集和对数据库服务器硬件系统以及数据价值的信任,来防止数据库损坏。 一些优秀的参考资料:
  • CHECKDB是必须的吗?
  • DBCC检查和TB级数据库
  • SQLU VLDB周-完整性检查
  • 使用PHYSICAL_ONLY选项时,DBCC CHECKDB命令的改进可能会导致更快的性能
  • SQL Server 2008数据库检查

  • 这些附加的检查是必要/重要的吗?(索引视图可能让我有点担心,我不认为我们正在使用Service Broker或者FILESTREAM。) 你可以直接在索引视图上运行`DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS`命令。在某些情况下,检查索引视图可能会有问题,因此需要准备好调查任何导致的错误结果(假阳性)。 (Paul Randal在引用文章的评论中还提到过假阴性的可能性,但我没有直接的经验。) 如果有必要进行这些附加的检查,是否有办法单独执行它们? 不支持单独运行Service Broker或者`FILESTREAM`检查。 `CHECKALLOC`和`CHECKCATALOG`似乎在大型数据库上运行得很快。每天运行这些检查是否有任何理由不推荐? 不是我知道的。
    你可能还要考虑运行DBCC CHECKCONSTRAINTS。无论你指定了什么选项,这个检查都不包含在DBCC CHECKDB中。你也可以考虑在适当的时候偶尔运行CHECKDB