web-dev-qa-db-ja.com

複数日にわたる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を使用するようにすべてのデータベースを再構築するようなオプションは、実際には実用的ではありません。）

sql-serverdbcc-checkdbvldb
10
BradC

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

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

また、backup（フルまたは差分）とCHECKSUMを使用すると、検出が保証されますハードウェアによるI/O破損。

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

そうは言っても、それでも論理的破損、 スクリブラーがエラーを誘発した -インメモリページが、SQL Serverプロセス内で実行されているサードパーティのコード、またはWindowsカーネルモードで実行されている十分な権限を持つドライバまたはその他のソフトウェア、またはによって破損している場合SQL Serverのバグなどは上記の方法では検出できないため、[〜＃〜] checkdb [〜＃〜]画像になります。

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

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

車輪を再発明する代わりに、 OlaのSQL Server整合性チェックソリューション を確認することを強くお勧めします

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は、説明されているように非常に遅くなります こちら 。

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

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

6
Kin Shah