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検証をオフにすると、矛盾が検出されないことがあります。この投稿のポール・ランダルからの引用：

あなたが正しい-破れたページまたはチェックサムがオンになっていない場合、ページ保護オプションに関する限り、検出できるものはありません。CHECKDBは、実行するすべての整合性チェックを実行することで発見した破損を引き続き検出する場合がありますが、たとえば、データ値の途中で破損が発生することはありません。

ハ-それはページのチェックサムをオンにするのが面倒です-ページが読み込まれ、変更され、書き戻されるまで何も起こりません。ページにチェックサムを強制的に取得させる唯一の方法は、ページを変更することです。たとえば、すべてのインデックスを再構築するなど、口に合わない場合があります。「タッチ」ツールはまったくありません。

データベースをSQL Server 2000以前から2005年以降にアップグレードした場合、上記の状況が発生する可能性があります。次に、ALTER DATABASEを使用してページチェックサムを手動で有効にして、アクティブにします。ただし、上記の引用の2番目の段落が開始され、問題が生じる可能性があります。

BACKUP WITH CHECKSUMチェックサムの不整合を検出しますが、バックアップ中にページにすでにチェックサムが書き込まれている場合のみです。通常DBCC CHECKDB、これらのエラーも検出するため、BACKUP WITH CHECKSUMを使用してDBCC CHECKDBを置き換えることはお勧めできません。

現在はDBCC CHECKDB、たとえ矛盾があっても、矛盾を表示しないという2番目の可能性があります。このため、私は再び汚職に関する誤解の中でポール・ランダルを引用しています。：

では、腐敗の消滅についてはどうでしょうか？これにより、整合性チェックの仕組みがわかります。整合性チェックは、割り当てられたデータベース内のページでのみ実行されます。ページが何にも割り当てられていない場合、その8192バイトは無意味であり、解釈できません。予約済みと割り当て済みを混同しないでください。最初の誤解投稿で説明しています。ページが割り当てられている限り、DBCC CHECKDBによって一貫性がチェックされ、ページのチェックサムが存在する場合はテストされます。DBCC CHECKDBの実行時に破損したページが割り当てられた場合、破損は「消失」しているように見えますが、次のDBCC CHECKDBの実行時には割り当てが解除されます。最初は破損していると報告されますが、2回目は割り当てられていないため、整合性がチェックされず、破損しているとは報告されません。腐敗は神秘的に消えたように見えます。しかし、そうではありません。破損したページが割り当てられなくなっただけです。SQL Serverが破損したページの割り当てを解除するのを止めるものは何もありません-実際、これは多くのDBCC CHECKDB修復が行うことです-破損したものの割り当てを解除し、すべてのリンクを修正します。

あなたの質問に対する最終的な答えはありませんが、DBCC CHECKDB割り当てられたページをチェックするだけなので、割り当て解除されたページに矛盾は表示されません。私が今想像できる唯一の状況は、BACKUPによって、スキップされた潜在的なチェックサムエラーを示す割り当て解除されたページもバックアップすることですDBCC CHECKDB。