複数日にわたるDBCC CHECKDBの分割

Paul Randal がDBCC CHECKDBを手動で数日間に渡って分散する、非常に大規模なデータベースの実装に取り​​組んでいます。

• データベース内のテーブルを7つのバケット間でほぼ均等に分割する
• 週2回のDBCC CHECKALLOCの実行
• 週に1回、DBCC CHECKCATALOGを実行する
• 曜日ごとに1つのバケットでDBCC CHECKTABLEを実行する

誰かがこのテクニックを使用しましたか？既存のスクリプトはありますか？

これが実際にCHECKDBが行うすべてをカバーしていないのではないかと心配しています。CHECKDBのBooks Onlineドキュメントでは、CHECKALLOC、CHECKCATALOG、およびCHECKTABLEに加えて、次のことも述べられています。

• データベース内のすべてのインデックス付きビューの内容を検証します。
• FILESTREAMを使用してファイルシステムにvarbinary（max）データを格納するときに、テーブルメタデータとファイルシステムディレクトリおよびファイルの間のリンクレベルの整合性を検証します。（SQL 2008のみ）
• データベース内のService Brokerデータを検証します。

だからここに私の質問があります：

1. これらの追加のチェックは必要ですか/重要ですか？（インデックス付きビューは、おそらく私にとっては少し心配です。まだService BrokerやFILESTREAMを使用しているとは思いません。）

2. もしそうなら、これらの追加のチェックを個別に実行する方法はありますか？

3. CHECKALLOCとCHECKCATALOGは、大きなdbでも非常に高速に実行されるようです。これらを毎日実行しない理由はありますか？

（注：これは、数百のサーバーにわたる数千の既存のデータベース、または少なくとも特定のサイズを超えるすべてのデータベースの標準ルーチンになります。つまり、CHECKFILEGROUPを使用するようにすべてのデータベースを再構築するようなオプションは、実際には実用的ではありません。）

これらの追加のチェックは必要ですか/重要ですか？（インデックス付きビューは、おそらく私にとっては少し心配です。まだService BrokerやFILESTREAMを使用しているとは思いません。）

DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS インデックス付きビューで直接実行できます。インデックス付きビューのチェックは特定の状況で問題となる可能性があるため、結果として発生する誤検知を調査する準備をしてください。（Paul Randalは、参照記事へのコメントで、偽陰性も可能であると述べていますが、それを直接経験したことはありません。）

もしそうなら、これらの追加のチェックを個別に実行する方法はありますか？

Service Brokerの実行やFILESTREAM個別のチェックはサポートされていません。

CHECKALLOCそして、CHECKCATALOGさえ大きなDBSに、非常に迅速に実行するように見えます。これらを毎日実行しない理由はありますか？

私が知っていることではありません。

SQL Serverデータベースが破損していないことを100％確実にするには、DBCC CHECKDBが不可欠です。ただし、データベースのサイズが非常に大きくなるため、24時間365日稼働していると主張するときにメンテナンスウィンドウを見つけるのは非常に困難です。長年にわたって、SQL Serverチームは、特にハードウェアによって引き起こされる物理的な破損に関連する最も一般的な形式の破損を検出するさまざまなメカニズムを実装してきました。

SQL Server 2005以降にはPAGE_VERIFY = CHECKSUMがあり、データベースページの物理的な破損を予防的に検出できるため、I / Oシステムに書き込まれるときに各ページにチェックサムを追加し、ディスクから読み取られるときにチェックサムを検証します。

また、CHECKSUMを使用したバックアップ（完全または差分）では、ハードウェアによるI / O破損の検出が保証されます。

したがって、破損のハードウェア側から見ると、SQL Serverはそれを検出して報告するのに優れています。（重要な破損関連のアラートも設定してください）。

そうは言っても、依然として論理的な破損であり、scribblerはエラーを引き起こしました -インメモリページは、SQL Serverプロセス内で実行されているサードパーティのコード、またはWindowsカーネルモードやSQL Serverで実行する十分な権限を持つドライバーまたはその他のソフトウェアによって破損しています。バグなどは上記の方法では検出できないため、CHECKDBが登場します。

DBCC CHECKDBは、他の方法では検出できない破損の可能性がないかページヘッダーをチェックするなど、より徹底的なチェックを実行します。

既存のスクリプトはありますか？

車輪を再発明する代わりに、OlaのSQL Server Integrity Checkソリューションを確認することを強くお勧めします

DBCC CHECKDBを効率的に実行する：

CHECKDBを実行するための巨大なデータベースまたは多数のデータベースがあるメンテナンスウィンドウが厳しい場合は、創造的である必要があります。

SQLSkillsトレーニングに参加した後、私が環境に実装したものは次のとおりです。

• チェックする必要があるテーブルを優先します。
• テーブルを優先度の異なるグループに分け、DBCC CHECKTABLE実行DBCC CHECKALLOCおよびDBCC CHECKCATALOG
• 優先順位付きのテーブル名を格納するワーカーテーブルを作成します。優先度の高いすべてのテーブル（非常に大きい）が1つのグループに含まれていないことを確認してください。そうしないと、CHECKDBがまったく完了しません。
• ワーカーウィンドウに、メンテナンスウィンドウを通過したときにCHECKDBが強制終了されるときに調整するタイムアウト列を設定することもできます。
• それが実行するために、テーブルごとにかかった時間の追加DBCC CHECKTABLE、 DBCC CHECKALLOCおよびDBCC CHECKCATALOG。チェックの実行に通常どのくらい時間がかかるかを感じ取れるようにするためです。
• NOINDEXオプションで実行することもできます。ユーザーテーブルの非クラスター化インデックスをチェックしないため、操作が高速化されます。データが失われることはなく、必要に応じてインデックスを削除して再作成できるため、データの破損ほど重大ではないため、これにはいくつかの利点があります。

明らかに、EnterpriseエディションはDBCCステートメントの並列実行を利用できますが、MAXDOP設定に注意してください。これは、最終的にすべてのCPUを占有する可能性があるためです。これは、リソースガバナーによって厳しく制限される場合があります。

注：あなたがSPARSE列を持っている場合は説明するように、そしてあなたのCHECKDBが遅く死んでいるだろうここに。

最後に、利用可能なすべてのツールセットとデータベースサーバーハードウェアシステムへの信念、そして最も重要なのはデータの価値を活用して、データベースの破損を防ぐ方法です。

いくつかの優れた参考文献：

• CHECKDBは必要ですか？
• DBCCチェックとテラバイト規模のデータベース
• SQLU VLDBウィーク–整合性チェック
• DBCC CHECKDBコマンドの改善により、PHYSICAL_ONLYオプションを使用するとパフォーマンスが向上する可能性があります
• SQL Server 2008データベースチェック