GOTCHA-DBCC CHECKDB（ 'DBNAME'、NOINDEX）はありますか？
OLTP環境（SQL 2005,2008）でDBCC CHECKDBをオンにしています。システムのオーバーヘッドはサーバー上で非常に目立つものなので、サーバーが理解できる限り効率的になるようにしますbe。HENCE-これまで使用したことのないオプションであるNOINDEXオプションをオンにしたい。整合性チェック以外で検出されたインデックスに問題がある場合は、インデックスを再構築するだけでよいと考えています。 。また、整合性チェックの期間が大幅に短縮され、厄介な破損が検出されます。
私の計画の欠陥は何ですか？
ありがとう、デブ
DBCC CHECKDBは、営業時間外または使用率の低い時間帯に実行する必要があります。巨大なデータベースでは、（設計上）サーバーのディスクサブシステムをひどく叩き、ほとんど使用できなくなります。データベース内のすべてのページを読み取る必要があります。 NOINDEXオプションを使用しても、（再構築可能な）インデックスが破損していないことを確認する必要があるため、あまり役に立ちません。それらの1つが破損している場合、エラーがアプリケーションまたは内部のプロシージャ/トランザクションに返される可能性があります。これらのエラーのすべてがアプリケーションコードまたはプロシージャによって適切に処理されない場合（つまり、ネストされたトランザクションを適切にロールバックする場合）、論理データの破損（クレジットのない借方など）が発生する可能性があります。会計システム）。
使用量が非常に少ないため、日曜日の朝の未明にすべてのデータベースのCHECKDBを毎週実行します。最大かつ最も頻繁に使用される24時間年中無休の操作では、代わりにテーブル間にWAITFORを指定してDBCC CHECKTABLEを実行し、エンドユーザーへの影響を最小限に抑えます。このルートを使用する場合は、データベースでDBCCCHECKALLOCおよびDBCCCHECKCATALOGを定期的に実行する必要もあります（これらは完全なCHECKDBに含まれています）。
最後に、SQL Serverデータベースで何らかの形の破損が発生している場合は、ストレージハードウェアスタックをすぐに確認する必要があります。当店では、1990年代のSQL 6.5以降、DBの破損は見られず、大量のSQLサーバーが数十台あります。 SQL 7以降でDBの破損が発生したのは、顧客サイトのRAIDコントローラーの障害が原因でした（Promiseは本当にひどいです）。
欠陥はありませんが、非クラスター化インデックスの整合性障害がエンドユーザーまたはアプリケーションに影響を与えるリスクがあります。データは失われませんが、インデックスの再構築中に影響が生じる可能性があります。
パフォーマンスが大きな懸念事項である場合は、毎日完全バックアップを実行し、別のサーバーに復元して、コピーに対してチェックを実行します。