将 DBCC CHECKDB 划分为多天

Question

我正在为非常大的数据库实施 Paul Randal 的手动传播 DBCC CHECKDB的方法，该方法基本上包括：

• 将数据库中的表大致平均地划分为 7 个桶
• 每周运行两次 DBCC CHECKALLOC
• 每周运行一次 DBCC CHECKCATALOG
• 一周中的每一天在一个存储桶上运行 DBCC CHECKTABLE

有人用过这个技术吗？有没有现有的脚本？

我担心这实际上可能无法涵盖 CHECKDB 所做的一切；CHECKDB 的联机丛书文档说，除了 CHECKALLOC、CHECKCATALOG 和 CHECKTABLE，它还：

• 验证数据库中每个索引视图的内容。
• 使用 FILESTREAM 在文件系统中存储 varbinary(max) 数据时，验证表元数据与文件系统目录和文件之间的链接级一致性。（仅限 SQL 2008）
• 验证数据库中的 Service Broker 数据。

所以这里是我的问题：

1. 这些额外的检查是否必要/重要？（我可能更关心索引视图，我认为我们还没有使用 Service Broker 或 FILESTREAM。）

2. 如果是这样，是否有单独执行这些额外检查的方法？

3. CHECKALLOC 和 CHECKCATALOG 似乎运行得非常快，即使在大型数据库上也是如此。有什么理由不每天运行这些？

（注意：这将是数百台服务器上数千个现有数据库的标准例程，或者至少是特定大小的每个数据库的标准例程。这意味着像重组所有数据库以使用 CHECKFILEGROUP 这样的选项对我们来说并不实用。）

Answer 1

DBCC CHECKDB对于 SQL Server 数据库 100% 确保没有损坏至关重要。但是，由于数据库的规模越来越大，当您声称 24x7 时，很难找到维护窗口。多年来，SQL Server 团队实施了各种机制来检测最常见的损坏形式，尤其是与硬件引起的物理损坏相关的损坏形式。

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

此外，带有 CHECKSUM 的备份（完整或差异）将保证检测由硬件引起的任何 I/O 损坏。

因此，从损坏的硬件方面来看，SQL Server 在检测和报告方面做得很好。（确保也设置重要的腐败相关警报）。

话虽这么说，仍然是逻辑损坏，scribbler 引起的错误- 其中内存页面被 SQL Server 进程内运行的第三方代码损坏，或者被驱动程序或其他具有足够权限的软件损坏，在 Windows 内核模式和/或SQL Server 中执行使用上述方法无法检测到错误等，因此CHECKDB出现了。

DBCC CHECKDB 执行更彻底的检查，包括检查页头是否存在任何其他方式无法检测到的可能损坏。

有没有现有的脚本？

我强烈建议您查看Ola 的 SQL Server 完整性检查解决方案，而不是重新发明轮子

高效运行 DBCC CHECKDB ：

当您在拥有庞大数据库或大量数据库来运行 CHECKDB 的维护窗口紧张时，您只需要发挥创造力。

参加 SQLSkills 培训后，我在我的环境中实施的是：

• 优先检查哪些表至关重要。
• 将表分成具有不同优先级的组，然后DBCC CHECKTABLE一起运行DBCC CHECKALLOC和运行DBCC CHECKCATALOG
• 创建一个工作表，该表将存储具有优先级的表名。只要确保所有高优先级表（非常大）都不在一个组中，否则您的 CHECKDB 将根本无法完成。
• 你甚至可以在你的工作表中有一个超时列，它会在你的 CHECKDB 超过维护窗口后被杀死时进行协调
• 添加每个表运行所需的时间DBCC CHECKTABLE， DBCC CHECKALLOC以及DBCC CHECKCATALOG。这样您就可以了解运行检查通常需要多长时间。
• 您甚至可以使用NOINDEX选项运行，因为它不会检查用户表上的非聚集索引，从而加快操作速度。这有一些优势，因为它不像数据损坏那么严重，因为没有数据丢失，您可以在必要时删除并重新创建索引。

显然，企业版可以利用 DBCC 语句的并行执行，但要注意 MAXDOP 设置，因为它最终可能会占用您所有的 CPU。这可能会受到资源调控器的严格限制。

注意：如果你有稀疏列，然后根据你的描述将CHECKDB死慢这里。

最后，它是如何通过利用所有可用的工具集+您对数据库服务器硬件系统的信心以及最重要的数据价值来防止数据库损坏的。

一些优秀的参考资料：

• CHECKDB 是必需品吗？
• DBCC 检查和 TB 级数据库
• SQLU VLDB 周 – 完整性检查
• 当您使用 PHYSICAL_ONLY 选项时，DBCC CHECKDB 命令的改进可能会导致更快的性能
• SQL Server 2008 数据库检查

Answer 2

这些额外的检查是否必要/重要？（我可能更关心索引视图，我认为我们还没有使用 Service Broker 或 FILESTREAM。）

您可以DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS 直接在索引视图上运行。在某些情况下检查索引视图可能会出现问题，因此请准备好调查由此产生的任何误报。（Paul Randal 在参考文章的评论中也提到假阴性也是可能的，但我没有直接的经验。）

如果是这样，是否有单独执行这些额外检查的方法？

不支持FILESTREAM单独运行 Service Broker 或检查，不支持。

CHECKALLOC并且CHECKCATALOG似乎运行得非常快，即使在大型数据库上也是如此。有什么理由不每天运行这些？

不是我所知道的。

您也可以考虑运行DBCC CHECKCONSTRAINTS. 无论您指定任何选项，此检查都不包含在 中DBCC CHECKDB。您可能还想考虑在情况允许的情况下偶尔跑步CHECKDB。