web-dev-qa-db-ja.com

BACKUP WITH CHECKSUMは機能するが、DBCC CHECKDBが問題を検出する

最近管理しているサーバーで停電が発生し、SSRS ReportServerTempDBで問題が発生しました。停止後、OlaのDatabaseIntegriyCheckを実行する夜間のジョブは問題を報告し始めました：

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d Master 
  -Q "EXECUTE [dbo].[DatabaseIntegrityCheck] 
      @Databases = 'USER_DATABASES,SYSTEM_DATABASES', 
      @LogToTable = 'Y'" -b

コマンド：DBCC CHECKDB（[ReportServerTempDB]）WITH NO_INFOMSGS、ALL_ERRORMSGS、DATA_PURITY
メッセージ8979、レベル16、状態1、サーバーXXXXXXX、行1
テーブルエラー：オブジェクトID 133575514、インデックスID 1、パーティションID 72057594040156160、割り当てユニットID 72057594041466880（タイプ行内データ）。ページ（1：130168）には、親（不明）および前の（ページ（1：123239））ノードからの参照がありません。システムカタログの不良ルートエントリの可能性があります。
メッセージ8979、レベル16、状態1、サーバーXXXXXXX、行1
テーブルエラー：オブジェクトID 133575514、インデックスID 1、パーティションID 72057594040156160、割り当てユニットID 72057594041466880（タイプ行内データ）。ページ（1：130169）には、親（不明）および前の（ページ（1：123239））ノードからの参照がありません。システムカタログの不良ルートエントリの可能性があります。
メッセージ8979、レベル16、状態1、サーバーXXXXXXX、行1
テーブルエラー：オブジェクトID 133575514、インデックスID 1、パーティションID 72057594040156160、割り当てユニットID 72057594041466880（タイプ行内データ）。ページ（1：130170）には親（不明）からの参照がありません...
プロセス終了コード1.ステップは失敗しました。

ただし、夜間のバックアップジョブは、実行するたびに成功を報告し続けました。 SSRSにも問題がないようです。バックアップジョブには、複数のバックアップコマンドが1つのステップにまとめられています。

BACKUP DATABASE [ReportServer] TO  DISK = N'C:\Backup-SQLServer\ReportServer.bak' WITH NOFORMAT, COMPRESSION, CHECKSUM, INIT,  NAME = N'ReportServer-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
BACKUP DATABASE [ReportServerTempDB] TO  DISK = N'C:\Backup-SQLServer\ReportServerTempDB.bak' WITH NOFORMAT, COMPRESSION, CHECKSUM, INIT,  NAME = N'ReportServerTempDB-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
BACKUP DATABASE [TEST-PH] TO  DISK = N'C:\Backup-SQLServer\TEST-PH.bak' WITH NOFORMAT, COMPRESSION, CHECKSUM, INIT,  NAME = N'TEST-PH-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

バックアップジョブのステップ2では、ファイルをチェックします。それは毎晩実行され、毎回成功を報告しました：

RESTORE VERIFYONLY FROM DISK= N'C:\Backup-SQLServer\ReportServer.bak'
GO
RESTORE VERIFYONLY FROM DISK= N'C:\Backup-SQLServer\ReportServerTempDB.bak'
GO
RESTORE VERIFYONLY FROM DISK= N'C:\Backup-SQLServer\TEST-PH.bak'
GO

これは、都合のよいダウンタイムまで数日間続きました。停止前の夜間のバックアップでReportServerTempDBを復元/上書きすることで問題を解決しました。

私たちのデータベースPAGE_VERIFY_OPTIONはCHECKSUMに設定されます。

この動作を説明するシナリオは何ですか？

sql-serversql-server-2014dbcc-checkdbola-hallengren
4
poke

sp_BlitzErik コメントに書き込んだ（削除されたため）：

...このため[PAGE_VERIFY_OPTION]について質問しています： Blitz結果：ページ検証が最適ではありません 。バックアップのCHECKSUMオプションは、正しいページ検証オプションを使用している場合にのみエラーをスローします。データベースが古いバージョンのSQL Serverからのものである場合、最適とはいえない場合があります。

また、ページ検証オプションにCHECKSUMオプションを使用していても、ページが破損した場合afterに書き込んだ場合にのみエラーがスローされます。ディスクに。そして、私は彼らがその投稿のために必ずしも質問をしているとは思いません-私の推測では、彼らはすでにCHECKSUMにオプションを設定しています。

質問で説明されているシナリオは、メモリでページの破損が発生し（不良メモリ、メモリスクリブラー、またはSQL Serverの破損のバグのいずれかが原因）、その後、破損したページが有効なチェックサムでディスクに書き込まれた場合に発生します。

ページのチェックサムのテストを含む、その後のページの読み取りは成功します。ただし、DBCC CHECKDB（または不幸なクエリ）を実行すると、破損が明らかになります。この場合、BACKUPおよびRESTOREステートメントがCHECKSUMを使用するかどうかは関係ありません。それらはその破損を検出しません。

これが、どこでもCHECKSUMの使用に依存して整合性チェックを実行できない理由です。

これがあなたが見たものを説明するのに役立つことを願っています。

投稿したエラーから、そのクラスター化インデックスのルートページがどういうわけか破壊されたようです。

4
Paul S. Randal