完全バックアップの前にDBCCcheckdbを実行する必要がありますか？またはその後？
SQL 2000、2005、および2008サーバーが混在しており、バックアップする前にDBが良好な状態であることを確認する必要があるという理論に基づいて、完全バックアップの直前に常にDBCCCHECKDBを毎晩実行しています。 。 （明らかに、バックアップの完全な検証はテスト復元を介してのみ実行できますが、それは少し異なるトピックです。）
DBCCをバックアップサーバーなどにオフロードできないと仮定すると（理想的です）、DBCCCHECKDBの後にFULLBACKUPを実行するのが最適なシーケンスですか？
これについて説明していることがわかった唯一の「ベストプラクティス」ドキュメントは SAPのSQL Serverメンテナンスのベストプラクティス 2006年からTechNetで見つけました。
理想的には、DBCC CHECKDBを使用した整合性チェックは、オンラインデータベースバックアップを実行する前に実行する必要があります。
このアドバイスは正しいですか？ SQLのすべてのバージョンで正しいですか？
（これが役立つ場合、これを尋ねる動機の一部は、DBCCランタイムが夜ごとにかなりの量で変化するように見えるため、バックアップがいつ完了するかを正確に信頼できないため、テープアーカイブのスケジュールが作成されます。また、メンテナンスに時間がかかり、何らかの理由でキャンセルする必要がある場合は、DBCCよりもバックアップを確実に完了することをお勧めします。）
あなたが考えるかもしれないもう一つのことは、バックアップファイルのテスト復元に使用できる別のサーバー（Devまたはその他）がある場合、そこでそれを実行したいかもしれません。したがって、RESTORE DATABASE、次にDBCCCHECKDBを復元します。そうすることで、バックアップファイルが適切であることを検証するだけでなく、本番環境に影響を与えることなくデータベースが適切であることを検証できます。
すべてのバックアップを毎週別のサーバーにテスト復元してから、それらのサーバーでCHECKDBを実行します。
これが私の見解です...
回復可能性に関しては、いつCHECKDBを実行するかは正確には重要ではありませんが、バックアップが適切かどうかについての自信を高めるのに役立つ可能性があります。
データベースが破損したとします。
バックアップ前のDBCCCHECKDBが失敗した場合、後続のバックアップはおそらく役に立たないことがわかります。
最初にバックアップを実行し、その後でCHECKDBを実行すると、バックアップが良好か不良かが少しわかりにくくなります（バックアップとCHECKDBの間で破損が発生した可能性があります）。これはあなたにとって重要ですか？
CHECKDBを定期的に実行している限り、いつかは問題ではありません。そして、あなたが言ったように、復元を定期的にテストするための代替手段はありません。
完全なDBCCCHECKDBをメンテナンスウィンドウに収めることができない場合は、バックアップルーチンに WITH CHECKSUM を追加し、別の時間（SQL 2005以降）で完全なCHECKDBを実行できます。
BACKUP [...] WITHCHECKSUMはDBCCCHECKDBを置き換えないことに注意してください。 Paul Randalに詳細があります ここ 。
また、データが破損していると判断した場合の回復戦略を理解することも役立ちます。障害点に復元する場合は、バックアップの前にcheckdbを実行すると、時間とデータの損失を節約できます。