DBCC CheckDB 会错过哪些类型的损坏？

Question

这个问题是由这篇较早的帖子提示的，我有一个数据库归档以备将来调查，该数据库在以下情况下恢复：

BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'.
Error: 3043, Severity: 16, State: 1.

在链接的问题和备份中，我已准备好进行 DBCC PAGE 调查，DBCC CHECKDB 无错误通过，但显然存在损坏。

哪些类型的损坏会导致 CHECKDB 通过但 BACKUP WITH CHECKSUM 会失败？

Answer 1

以下是我阅读的结果汇编。您将在链接的博客和文档中找到更多信息。

首先，DBCC CHECKDB如果您关闭校验和或 torn_page 验证，则可能无法检测到不一致。引用 Paul Randal 的话：

您是对的 - 如果未打开页面损坏或校验和，则就页面保护选项而言，无法检测到任何内容。CHECKDB 可能仍然会发现它通过执行它所做的所有一致性检查而发现的损坏 - 但它不会看到数据值中间的损坏，例如。

哈 - 这是关于打开页面校验和的无赖 - 在页面被读入、更改和写回之前不会发生任何事情。强制页面获取校验和的唯一方法是使它们更改 - 例如，通过重建所有索引，这可能令人不快 - 根本没有“触摸”工具。

如果您将数据库从 SQL Server 2000 或之前升级到 2005 或更高版本，则上述情况可能会打击您。然后，您需要使用 ALTER DATABASE 手动启用页面校验和以使它们处于活动状态。但是上面引用的第二段开始了，可能会给你带来麻烦。

BACKUP WITH CHECKSUM将检测校验和不一致，但仅当页面已写入校验和时，才可进行备份。通常DBCC CHECKDB也会检测到这些错误，因此“使用 BACKUP WITH CHECKSUM 替换 DBCC CHECKDB”不是一个好主意。

现在还有第二种可能性是DBCC CHECKDB不显示任何不一致，即使存在一些不一致。为此，我只是在“关于腐败的误解：它们会消失吗？”中再次引用保罗兰德尔：

那么消失的腐败呢？这涉及一致性检查的工作方式。一致性检查仅在数据库中分配的页面上运行。如果一个页面没有分配给任何东西，那么它的 8192 字节是没有意义的，无法解释。不要在保留和分配之间混淆 - 我在此处的第一个误解帖子中解释了这一点。只要分配了一个页面，DBCC CHECKDB 就会对其进行一致性检查，包括测试页面校验和（如果存在）。如果在 DBCC CHECKDB 运行时分配了损坏的页面，但在下一次 DBCC CHECKDB 运行时解除分配，则损坏似乎“消失”了。第一次它会被报告为损坏，但第二次它没有分配，所以它没有进行一致性检查，也不会被报告为损坏。腐败似乎神秘地消失了。但它没有 - 只是损坏的页面不再分配。没有什么可以阻止 SQL Server 解除分配损坏的页面 - 事实上，这就是许多 DBCC CHECKDB 修复所做的 - 解除分配损坏的页面，并修复所有链接。

我没有对您的问题的最终答案，但由于DBCC CHECKDB只检查分配的页面，因此不会在已释放的页面中显示不一致。我现在能想象的唯一情况是 BACKUP 还备份那些显示潜在校验和错误的已解除分配的页面，这些页面被DBCC CHECKDB.