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は失敗する、どのような種類の破損が発生する可能性がありますか？
以下は私が読んだ結果のまとめです。リンクされたブログやドキュメントには、はるかに多くの情報が含まれています。
まず、チェックサムまたはtorn_page検証をオフにすると、DBCC CHECKDBが不整合を検出しないことがあります。Paul Randalからの引用- この投稿 ：
そうです-引き裂かれたページまたはチェックサムがオンになっていない場合、ページ保護オプションに関する限り、何も検出できません。 CHECKDBは、実行するすべての整合性チェックを実行して検出された破損を引き続き検出する場合がありますが、たとえば、データ値の途中で破損が発生することはありません。
ハ-それはページのチェックサムをオンにするのは面倒です-ページが読み込まれ、変更され、書き戻されるまで何も起こりません。ページにチェックサムを強制的に取得させる唯一の方法は、ページを変更することです。すべてのインデックスを再構築することにより、不快なものになる可能性があります-「タッチ」ツールはまったくありません。
データベースをSQL Server 2000以前から2005以降にアップグレードした場合、上記の状況が発生する可能性があります。次に、ALTER DATABASEを使用してページチェックサムを手動で有効にし、それらをアクティブにする必要があります。しかし、その後、上記の引用の2番目の段落が始まり、問題が発生する可能性があります。
BACKUP WITH CHECKSUMは、チェックサムの不整合を検出しますが、バックアップ時にページに既にチェックサムが書き込まれている場合のみです。通常、DBCC CHECKDBもこれらのエラーを検出するため、 DBCC CHECKDBをBACKUP WITH CHECKSUMで置き換えることはお勧めできません です。
これで、たとえDBCC CHECKDBが不整合を示さない2番目の可能性があります。このため、もう一度引用しますポール・ランダル 腐敗に関する誤解：彼らは消えることができますか？ ：
では、消える腐敗についてはどうでしょうか？これは、整合性チェックがどのように機能するかを説明します。整合性チェックは、割り当てられたデータベースのページでのみ実行されます。ページが何にも割り当てられていない場合、その8192バイトは意味がなく、解釈できません。予約済みと割り当て済みを混同しないでください。ここにある最初の誤解の投稿で説明しています。ページが割り当てられている限り、存在する場合、ページチェックサムのテストを含め、DBCC CHECKDBによって整合性チェックが行われます。破損したページがDBCC CHECKDBの実行時に割り当てられていても、次のDBCC CHECKDBが実行されるときに割り当てが解除されると、破損が「消えた」ように見えることがあります。 1回目は破損として報告されますが、2回目は割り当てられないため、整合性チェックは行われず、破損として報告されません。腐敗は不思議なことに消えたようです。しかし、そうではありません。破損したページが割り当てられなくなっただけです。 SQL Serverが破損したページの割り当てを解除するのを止めるものは何もありません。実際、これは多くのDBCC CHECKDB修復が行うことです。壊れたものの割り当てを解除し、すべてのリンクを修正します。
質問への最終的な回答はありませんが、DBCC CHECKDBは割り当てられたページのみをチェックするため、割り当て解除されたページの不整合は表示されません。現在想像できる唯一の状況は、BACKUPが割り当て解除されたページもバックアップし、DBCC CHECKDBによってスキップされた潜在的なチェックサムエラーを示していることです。