Quais tipos de corrupção o DBCC CheckDB pode faltar?

Essa pergunta foi solicitada por essa postagem anterior e por eu ter um banco de dados arquivado para investigação futura restaurada a seguir:

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

Na pergunta vinculada e no backup que eu estou pronto para investigações de DBCC PAGE, o DBCC CHECKDB passou sem erros, mas a corrupção está evidentemente presente.

Que tipos de corrupção podem ocorrer pelos quais o CHECKDB passará, mas um BACKUP WITH CHECKSUM falhará?

A seguir, é apresentada uma compilação de resultados que eu li. Você encontrará muito mais informações nos blogs e documentos vinculados.

Primeiro, pode acontecer que DBCC CHECKDBnão detecte inconsistências se você desativar a verificação de soma de verificação ou página rasgada. Uma citação de Paul Randal neste post :

Você está certo - se a página rasgada ou a soma de verificação não estiver ativada, nada poderá ser detectado no que diz respeito às opções de proteção de página. O CHECKDB ainda pode detectar as corrupções que encontra ao fazer todas as verificações de consistência que realiza - mas não verá corrupções no meio dos valores dos dados, por exemplo.

Ha - essa é a chatice de ativar as somas de verificação da página - nada acontece até que uma página seja lida, alterada e gravada novamente. A única maneira de forçar as páginas a obter somas de verificação é fazê-las mudar - por exemplo, através da reconstrução de todos os seus índices, o que pode ser desagradável - não há nenhuma ferramenta de 'toque' lá fora.

A situação acima pode afetar você, se você atualizou um banco de dados do SQL Server 2000 ou anterior para 2005 ou posterior. Você precisa ativar manualmente as somas de verificação de página com o ALTER DATABASE para ativá-las. Mas o segundo parágrafo da citação acima entra em ação e pode incomodá-lo.

BACKUP WITH CHECKSUMdetectará inconsistências da soma de verificação, mas apenas se a página já tiver uma soma de verificação gravada, quando estiver sendo copiada. Normalmente, DBCC CHECKDBtambém detecta esses erros, portanto, não é uma boa ideia usar BACKUP WITH CHECKSUM para substituir o DBCC CHECKDB .

Agora há uma segunda possibilidade de DBCC CHECKDBnão mostrar inconsistências, mesmo que existam. Por isso, estou apenas citando novamente Paul Randal em Equívocos sobre corrupções: elas podem desaparecer? :

E as corrupções que desaparecem? Isso explica como as verificações de consistência funcionam. As verificações de consistência são executadas apenas nas páginas do banco de dados alocadas. Se uma página não estiver alocada para nada, os 8192 bytes dela não terão sentido e não poderão ser interpretados. Não fique confuso entre reservado e alocado - explico isso nos primeiros conceitos errados postados aqui. Enquanto uma página estiver alocada, ela será verificada consistentemente pelo DBCC CHECKDB, incluindo o teste da soma de verificação da página, se ela existir. Uma corrupção pode parecer 'desaparecer' se uma página corrompida for alocada no momento em que um DBCC CHECKDB for executado, mas será desalocada no momento em que o próximo DBCC CHECKDB for executado. Na primeira vez, ele será reportado como corrompido, mas na segunda vez não será alocado, portanto, não será verificado a consistência e não será relatado como corrompido. A corrupção parece ter desaparecido misteriosamente. Mas isso não aconteceu - apenas a página corrompida não está mais alocada. Não há nada que impeça o SQL Server de desalocar uma página corrompida - na verdade, é isso que muitos dos reparos do DBCC CHECKDB fazem - desalocam o que está quebrado e corrigem todos os links.

Não tenho uma resposta final para sua pergunta, mas como DBCC CHECKDBapenas verifica as páginas alocadas, ela não mostra inconsistências nas páginas desalocadas. A única situação que posso imaginar agora é que o BACKUP também faz backup das páginas desalocadas, mostrando possíveis erros de soma de verificação ignorados DBCC CHECKDB.