Paul Randalの実装に取り組んでいます DBCC CHECKDBを手動で数日にわたって分散する方法 非常に大規模なデータベース用。
誰かがこのテクニックを使用しましたか?既存のスクリプトはありますか?
これが実際にCHECKDBが行うすべてをカバーしていないのではないかと心配しています。 CHECKDBに関するBooks Onlineのドキュメント は、CHECKALLOC、CHECKCATALOG、およびCHECKTABLEに加えて、次のことも述べています。
だからここに私の質問があります:
これらの追加のチェックは必要ですか/重要ですか? (インデックス付きビューの方がおそらく私には少し心配です。まだService BrokerやFILESTREAMを使用しているとは思いません。)
その場合、これらの追加のチェックを個別に実行する方法はありますか?
CHECKALLOCとCHECKCATALOGは、大きなdbでも非常に高速に実行されるようです。これらを毎日実行しない理由はありますか?
(注:これは、数百のサーバーにわたる数千の既存のデータベース、または少なくとも特定のサイズを超えるすべてのデータベースの標準ルーチンになります。つまり、CHECKFILEGROUPを使用するようにすべてのデータベースを再構築するようなオプションは、実際には実用的ではありません。)
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
DBCC CHECKTABLE
、DBCC CHECKALLOC
およびDBCC CHECKCATALOG
。チェックが実行されるまでに通常かかっている時間の感触をつかむことができます。NOINDEX
オプションを指定して実行することもできます。ユーザーテーブルの非クラスター化インデックスをチェックしないため、操作が高速化されます。データが失われることはなく、必要に応じてインデックスを削除して再作成できるため、データの破損ほど重大ではないため、これにはいくつかの利点があります。言うまでもなく、EnterpriseエディションはDBCCステートメントの並列実行を利用できますが、MAXDOP設定に注意してください。これは、すべてのCPUを占有することになるためです。これは、リソースガバナーによって厳しく制限できます。
注:SPARSE列がある場合、CHECKDBは、説明されているように非常に遅くなります こちら 。
最後に、利用可能なすべてのツールセットとデータベースサーバーハードウェアシステムへの信念、そして最も重要なのはデータの価値を利用して、データベースの破損を防ぐ方法です。
いくつかの優れた参考文献: