将DBCC CHECKDB划分为多天

Question

我正在为非常大的数据库实现Paul的几天内手动扩展DBCC的方法，它主要包括：

• 将数据库中的表大致平分到7个桶之间
• 每周运行两次DBCC CHECKALLOC
• 每周运行一次DBCC CHECKCATALOG
• 每天在一个桶上运行

有人用过这种技术吗？有任何现存的脚本吗？

我担心这可能并不包括CHECKDB所做的所有事情；CHECKDB的联机图书文档说，除了CHECKCATALOG和CHECKTABLE之外，它还：

• 验证数据库中每个索引视图的内容。
• 当使用FILESTREAM在文件系统中存储var二进制(Max)数据时，验证表元数据与文件系统目录和文件之间的链接级一致性。(只有SQL 2008 )
• 验证数据库中的Service数据。

以下是我的问题：

1. 这些额外的检查是否必要/重要？(对我来说，索引视图可能更多一些，我认为我们还没有使用Service或FILESTREAM。)
2. 如果是，是否有方法单独执行这些附加检查？
3. CHECKALLOC和CHECKCATALOG似乎运行得非常快，甚至在大型dbs上也是如此。有理由不每天做这些吗？

(注意:这将是一个标准例程，用于跨越数百个服务器的数千个现有数据库，或者至少是一个特定大小的每个数据库。这意味着，像调整所有数据库以使用CHECKFILEGROUP这样的选项对我们来说并不实际。)

Answer 1

这些额外的检查是否必要/重要？(对我来说，索引视图可能更多一些，我认为我们还没有使用Service或FILESTREAM。)

您可以直接在索引视图上运行DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS。检查索引视图可以是在某些情况下有问题，因此准备调查任何错误的结果。(Paul也在提到的文章的评论中提到，虚假否定也是可能的，但我没有直接的经验。)

如果是，是否有方法单独执行这些附加检查？

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

CHECKALLOC和CHECKCATALOG的运行速度似乎非常快，甚至在大型星展上也是如此。有理由不每天做这些吗？

据我所知没有。

您还可以考虑运行DBCC CHECKCONSTRAINTS。此检查是不是包含 in DBCC CHECKDB，而不管您可以指定什么选项。您可能还想考虑在情况允许时偶尔运行CHECKDB。

Answer 2

DBCC对于Server数据库100%确保没有损坏至关重要。然而，由于数据库的规模越来越大，当您声称是24x7的时候，很难找到一个维护窗口。多年来，Server团队已经实现了各种机制，这些机制将检测大多数常见的损坏形式，特别是与硬件造成的物理损坏相关的损坏。

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

此外，使用校验和进行备份(完全备份或差异备份)将保证检测硬件造成的任何I/O损坏。

因此，从损坏的硬件方面看，Server在检测和报告它方面做得很好。(确保设置与腐败有关的重要警报 )。

话虽如此，但仍然存在逻辑损坏，使用上述方法无法检测到内存中的划线器诱导错误页面被运行在Server进程中的第三方代码、驱动程序或具有在Windows内核模式和/或Server中执行的足够权限的其他软件破坏，因此出现了CHECKDB。

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

有任何现存的脚本吗？

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

高效运行DBCC：

当您在维护窗口中有大量的数据库或大量的数据库来运行CHECKDB时，您只需要保持创造性。

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

• 优先考虑哪些表对检查至关重要。
• 将表划分为具有不同优先级的组，然后运行DBCC CHECKTABLE以及运行DBCC CHECKALLOC和DBCC CHECKCATALOG
• 创建一个将存储具有优先级的表名的worker表。只需确保所有高优先级表(这些表都很大)不在一个组中，否则您的CHECKDB根本就不会完成。
• 您甚至可以在worker表中有一个timeout列，该列将在CHECKDB通过维护窗口后被终止时进行编排。
• 添加每个表运行DBCC CHECKTABLE、DBCC CHECKALLOC和DBCC CHECKCATALOG所需的时间。这样你就能感觉到你的支票通常需要多长时间才能运行。
• 您甚至可以使用NOINDEX选项运行，因为它将加速操作，因为它不检查用户表上的非群集索引。这有一些优点，因为它并不像数据损坏那么关键，因为没有数据丢失，如果有必要，您可以删除并重新创建索引。

显然，Enterprise可以利用DBCC语句的并行执行，但是注意MAXDOP设置，因为它最终可能占用所有CPU。这可能会受到资源总督的严格限制。

注意:如果您有稀疏列，那么您的CHECKDB将像描述的这里那样非常慢。

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

一些优秀的参考资料：

• CHECKDB是必需的吗？
• DBCC检查和和级数据库
• 周-完整性检查
• 当使用物理时，命令的改进可能会提高性能._唯一选择
• 服务器2008数据库检查