完全なDBCC CHECKDB操作を別のサーバー上の復元されたバックアップに安全にオフロードできますか？
現在、24時間年中無休の運用モデルに移行しています。そのため、メンテナンス戦略について調査しています。
私が理解できない問題の1つは、DBCC CHECKDBです。完全バックアップを実行し、別のSQLインスタンスでそのバックアップを復元し、その復元されたコピーでCHECKDBを実行することで、DBCCをオフロードできるという多数のリソースレポートを目にしました。また、エッジケースのシナリオのため、これは安全ではないと報告しているリソースもいくつか見つかりました。
CHECKDBを運用データベース自体で実行しない場合、安全に実行できますか？そうでない場合、復元されたコピーで実行しても安全なのはどの部分ですか？
SQL Serverエキスパート Paul Randal このオプションについては、彼の投稿で説明しています CHECKDB From Every Angle：Consistency Checking Options for a VLDB
別のシステムを使用してください
この方法は比較的簡単です。別のシステムでバックアップを復元し（定期的にバックアップを取得していますか？）、復元したデータベースで完全なDBCC CHECKDBを実行します。これにより、整合性チェックの負担が本番システムから解放され、バックアップが有効であることを確認することもできます。ただし、これにはいくつかの欠点があります。
バックアップを復元できるようにするには、スペアシステムに十分なディスク領域が必要です。本番データベースが数TBの場合、スペアボックスに同じ数個のTB=が必要です。これは、少なからずの金額に相当します–初期の設備投資と継続的なストレージ管理コストです。将来のリリースでこれが緩和されます-マイクロソフトでは、データベースを復元せずにバックアップ内のデータベースを一貫性チェックするメカニズムを発明し、特許を取得しました。）
整合性チェックでエラーが検出された場合、本番システムでデータベースが破損していることは確かではありません。破損の原因となったスペアボックスの問題である可能性があります。確実に知る唯一の方法は、本番システムで整合性チェックを実行することです。ただし、スペアシステムの整合性チェックはほとんどの場合問題ないため、バックアップを取得した時点で本番データベースはクリーンであることがわかります。
Paulが言及する欠点を除いて、整合性チェックを別のシステムにオフロードすることに問題があることは知りません。
私は質問への回答を提供しました- SQL Serverデータベースバックアップファイルの整合性テストを実行する方法？ ここで、私はショップで使用するプロセスについて説明しました。
私のショップには、「重要」と考えるデータベースの最新のFULL/DIFFの復元を自動化するために使用する「プレイ」サーバーがあります。 Windowsタスクスケジューラを使用して、いくつかのSQLCMDステップを含むbatファイルを開始します。復元が成功したら、完全なDBCC CHECKDB WITH ALL_ERRORMSGS、NO_INFOMSGSを実行し、結果をtxtファイルに出力します。次に、出力txtファイルを評価のためにデータベースグループにメールで送信します。
このプロセスは2つのことをテストします
- バックアップを復元できますか？
- バックアップ内のデータは構造的に完全な状態ですか（DBCC）
補足：破損が発生する可能性がありますanytime。良い直後DBCC CHECKDBまたは成功したバックアップなので、DBCC整合性チェックを頻繁に実行してみてください。