将DBCC CHECKDB划分为多天

我正在实施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之类的选项对我们而言并不实际。）

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

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

如果是这样，是否有办法分别执行这些附加检查？

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

CHECKALLOC并且CHECKCATALOG即使在大型数据库上，其运行速度也非常快。有什么理由不每天运行这些？

不是我知道的。

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

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

同样，使用CHECKSUM进行的备份（完整或差异备份）将保证检测到由硬件引起的任何I / O损坏。

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

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

DBCC CHECKDB执行更彻底的检查，包括检查页面标题是否有其他任何方式都无法检测到的可能损坏。

有没有现有的脚本？

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

高效运行DBCC CHECKDB：

当您在维护窗口非常紧张的情况下，只要您有大量数据库或大量数据库来运行CHECKDB，您只需发挥创造力即可。

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

• 确定哪些表对检查至关重要。
• 将表分为不同优先级的组，然后DBCC CHECKTABLE与运行DBCC CHECKALLOC和DBCC CHECKCATALOG
• 创建一个工作表，该表将存储具有优先级的表名。只需确保所有高优先级表（非常大）不在一个组中，否则您的CHECKDB将根本无法完成。
• 您甚至可以在worker表中有一个timeout列，该列将安排CHECKDB通过维护窗口后何时被杀死
• 添加每个表运行所花的时间DBCC CHECKTABLE， DBCC CHECKALLOC然后DBCC CHECKCATALOG。这样您就可以了解运行支票通常需要多长时间。
• 您甚至可以使用NOINDEXoption运行，因为它不会检查用户表上的非聚集索引，因此可以加快操作速度。这具有一些优点，因为它没有数据损坏那么重要，因为没有数据丢失，并且您可以在必要时删除并重新创建索引。

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

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

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

一些出色的参考资料：

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