DBCC CheckDB会丢失哪些类型的损坏？

这个问题是由较早的帖子提示的，我将一个数据库归档以备将来调查，该数据库已恢复，具体操作如下：

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失败将发生什么类型的损坏？

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

首先，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，即使有一些不一致，也不要显示任何不一致之处。为此，我再次引用Paul Randal 关于腐败的误解：它们会消失吗？：

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

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