DBCC CHECKDBの影響を最小限に抑える：すべきこととすべきでないこと

DBA（または<ここに役割を挿入>）としてのあなたの責任には、おそらくパフォーマンスの調整、容量計画、災害復旧などが含まれます。多くの人が忘れたり延期したりする傾向があるのは、データベースの構造（論理的および物理的の両方）の整合性を確保することです。最も重要なステップはDBCC CHECKDB 。 「データベースの整合性の確認タスク」を使用して簡単な保守計画を作成することで、途中まで進むことができますが、私の考えでは、これはチェックボックスをオンにするだけです。

よく見ると、タスクの動作を制御するためにできることはほとんどありません。非常に拡張性の高い[プロパティ]パネルでさえ、メンテナンスサブプランの多くの設定が表示されますが、DBCCについては事実上何も表示されません。 実行するコマンド。個人的には、CHECKDBの実行方法について、より積極的かつ制御されたアプローチを取る必要があると思います。 独自のジョブを作成し、DBCCを手動で作成することにより、本番環境での操作 コマンド。スケジュールやコマンド自体をさまざまなデータベースに合わせて調整することもできます。たとえば、ASP.NETメンバーシップデータベースは、販売データベースほど重要ではなく、チェックの頻度や徹底度の低下に耐えることができます。

しかし、あなたの重要なデータベースについては、混乱を最小限に抑えるために調査することのいくつかを詳しく説明する投稿をまとめると思いましたDBCC コマンドが引き起こす可能性があります–そしてあなたが警戒すべき神話やマーケティングフープラ。そして、この特定の投稿だけでなく、彼のブログ#sqlhelpやSQLskillsイマージョントレーニングで提供する無限のアドバイスにも貴重な情報を提供してくれたPaul "Mr. DBCC" Randal（@PaulRandal）に感謝します。

これらのアイデアのすべてを一粒の塩で取り入れ、環境で適切なテストを実行するために最善を尽くしてください。これらの提案のすべてがすべての環境でより良いパフォーマンスをもたらすわけではありません。ただし、少なくともCHECKDBの影響を考慮するのは、自分自身、ユーザー、および利害関係者のおかげです。 オペレーションは、適切なことをチェックしないことで不必要なリスクをもたらすことなく、実行可能な場合にそれらの影響を軽減するための措置を講じる可能性があります。

ノイズを減らし、すべてのエラーを消費します

CHECKDBを実行している場所に関係なく 、常にWITH NO_INFOMSGSを使用してください オプション。これは、各テーブルにいくつの行があるかを示すだけの無関係な出力をすべて抑制するだけです。その情報に興味がある場合は、DBCCではなく、DMVに対する単純なクエリから取得できます。 が走っています。出力を抑制すると、すべての幸せな出力に埋め込まれた重要なメッセージを見逃す可能性がはるかに低くなります。

同様に、常にWITH ALL_ERRORMSGSを使用する必要があります オプションですが、特にSQL Server2008RTMまたはSQLServer2005を実行している場合（これらの場合、オブジェクトごとのエラーのリストが200に切り捨てられて表示される場合があります）。 CHECKDBの場合 クイックアドホックチェック以外の操作では、出力をファイルに転送することを検討する必要があります。 Management Studioは、DBCC CHECKDBからの出力が1000行に制限されています 、したがって、この数値を超えると、いくつかのエラーを見逃す可能性があります。

厳密にはパフォーマンスの問題ではありませんが、これらのオプションを使用すると、プロセスを再度実行する必要がなくなります。これは、災害復旧の最中の場合に特に重要です。

可能な場合は論理チェックをオフロードします

ほとんどの場合、CHECKDB その時間の大部分をデータの論理チェックの実行に費やしています。 真のコピーに対してこれらのチェックを実行する機能がある場合 データのうち、本番システムの物理構造に注力し、セカンダリサーバーを使用してすべての論理チェックを処理し、プライマリからの負荷を軽減することができます。 セカンダリサーバーによる 、私は次のことだけを意味します：

• 完全な復元をテストする場所–復元をテストするからですよね？

他の人々（特にMicrosoftである巨大なマーケティング力）は、他の形式のセカンダリサーバーがDBCCに適しているとあなたに確信させたかもしれません。 チェックします。例：

• AlwaysOn可用性グループで読み取り可能なセカンダリ。
• ミラーリングされたデータベースのスナップショット。
• ログはセカンダリで出荷されました。
• SANミラーリング;
• またはその他のバリエーション…

残念ながら、これは当てはまりません。これらのセカンダリはいずれも、プライマリの代わりにチェックを実行するための有効で信頼できる場所ではありません。真のコピーとして機能できるのは、1対1のバックアップのみです。一貫性のある状態に到達するためにログバックアップの適用などに依存する他のものは、プライマリの整合性の問題を確実に反映することはありません。

したがって、論理チェックをセカンダリにオフロードしてプライマリで実行しないようにするのではなく、次のことをお勧めします。

1. 完全バックアップの復元を頻繁にテストしていることを確認してください。いいえ、これにはCOPY_ONLYは含まれません 上記と同じ理由で、AGセカンダリからのバックアップ–これは、完全復元でセカンダリを開始したばかりの場合にのみ有効です。
2. DBCC CHECKDBを実行します 多くの場合、フルに対して 何かをする前に、復元します。繰り返しますが、この時点でログレコードを再生すると、このデータベースは真のコピーとして無効になります。 ソースの。
3. DBCC CHECKDBを実行します あなたのプライマリーに対して、おそらくポール・ランダルが提案する方法で、および/または頻度の低いスケジュールで、および/またはPHYSICAL_ONLYを使用して分割されます 多くの場合。これは、実行する頻度と信頼性によって異なります（2）。
4. セカンダリに対するチェックで十分だと思い込まないでください。プライマリデータベースの正確なレプリカを使用している場合でも、プライマリのI / Oサブシステムで発生する可能性のある物理的な問題があり、セカンダリに伝播することはありません。
5. 常にDBCCを分析します 出力。それを実行して無視し、リストからチェックすることは、バックアップを実行し、必要なときに実際にそのバックアップを復元できることをテストせずに成功を主張するのと同じくらい役に立ちます。

トレースフラグ2549、2562、および2566を使用した実験

2つのトレースフラグ（2549と2562）を徹底的にテストしたところ、パフォーマンスが大幅に向上することがわかりましたが、Lonnyは、これらのフラグは不要または有用ではなくなったと報告しています。 2016年以降の場合は、このセクション全体をスキップ 。古いバージョンを使用している場合、これら2つのトレースフラグについては、KB＃2634571で詳しく説明されていますが、基本的には次のとおりです。

• トレースフラグ2549
  • これにより、個々のデータベースファイルが一意の基になるディスク上にあるものとして扱われるため、checkdbプロセスが最適化されます。これは、データベースに単一のデータファイルがある場合、または各データベースファイルが実際には別々のドライブにあることがわかっている場合に使用できます。データベースに複数のファイルがあり、それらが単一の直接接続されたスピンドルを共有している場合は、このトレースフラグに注意する必要があります。これは、害を及ぼす可能性があるためです。

    重要 ：sql.sasquatchは、SQLServer2014でのこのトレースフラグの動作のリグレッションを報告します。
    

• トレースフラグ2562
  • このフラグは、checkdbプロセス全体を単一のバッチとして扱いますが、tempdbの使用率が高くなります（データベースサイズの最大5％）。
  • より優れたアルゴリズムを使用してデータベースからページを読み取る方法を決定し、ラッチの競合を減らします（特にDBCC_MULTIOBJECT_SCANNERの場合） ）。この特定の改善はSQLServer2012のコードパスにあるため、トレースフラグがなくてもメリットが得られることに注意してください。これにより、次のようなエラーを回避できます。
    ラッチの待機中にタイムアウトが発生しました：クラス'DBCC_MULTIOBJECT_SCANNER'。
• 上記の2つのトレースフラグは、次のバージョンで使用できます。

  SQL Server 2008 ServicePack2累積更新プログラム9+
  （10.00.4330-> 10.00.5499）

  SQL Server 2008 ServicePack3累積更新プログラム4+
  （10.00.5775+）

  SQL Server 2008R2RTM累積更新プログラム11+
  （10.50.1809-> 10.50.2424）

  SQL Server 2008 R2 ServicePack1の累積的な更新プログラム4+
  （10.50.2796-> 10.50.3999）

  SQL Server 2008 R2 Service Pack 2
  （10.50.4000+）

  SQL Server 2012、すべてのバージョン
  （11.00.2100+）

• トレースフラグ2566
  • SQL Server 2005をまだ使用している場合、2005 SP2 CU＃9（9.00.3282）で導入されたこのトレースフラグ（累積的な更新プログラムのナレッジベースの記事、KB＃953752には記載されていません）は、パフォーマンスの低下を修正しようとします。 DATA_PURITYの x64ベースのシステムをチェックします。ある時点で、KB＃945770で詳細を確認できましたが、記事はMicrosoftのサポートサイトとWayBackマシンの両方から削除されたようです。クエリプロセッサの問題が修正されたため、このトレースフラグはSQLServerの最新バージョンでは必要ありません。

これらのトレースフラグのいずれかを使用する場合は、DBCC TRACEONを使用してセッションレベルで設定することを強くお勧めします。 起動トレースフラグとしてではなく。 SQL Serverを循環させずにそれらをオフにできるだけでなく、特定のCHECKDBを実行する場合にのみそれらを実装することもできます。 あらゆるタイプの修復を使用する操作とは対照的に、コマンド。

I / Oの影響を減らす：tempdbを最適化する

DBCC CHECKDB tempdbを多用する可能性があるため、そこでリソースの使用を計画するようにしてください。これは通常、どのような場合でも行うのが良いことです。 CHECKDBの場合 tempdbにスペースを適切に割り当てる必要があります。最後に必要なのはCHECKDBです 自動成長を待つ必要がある進行状況（およびその他の同時操作）。 WITH ESTIMATEONLYを使用して、要件のアイデアを得ることができます 、ポールがここで説明しているように。 SQL Server 2008 R2のバグが原因で、見積もりが非常に低くなる可能性があることに注意してください。また、トレースフラグ2562を使用している場合は、追加のスペース要件に必ず対応してください。

そしてもちろん、ほぼすべてのシステムでtempdbを最適化するための一般的なアドバイスはすべて、ここでも適切です。tempdbが独自の高速セットにあることを確認してください。 スピンドル、成長することなく他のすべての同時アクティビティに対応できるサイズであることを確認し、最適な数のデータファイルを使用していることを確認します。検討する可能性のある他のいくつかのリソース：

• tempdbパフォーマンス（MSDN）の最適化
• tempdb（MSDN）のキャパシティプランニング
• 1日のSQLServerDBAの神話：（12/30）tempdbには、プロセッサコアごとに常に1つのデータファイルが必要です

I / Oの影響を減らす：スナップショットを制御する

CHECKDBを実行するには 、SQL Serverの最新バージョンは、同じドライブ（または、データファイルが複数のドライブにまたがっている場合はすべてのドライブ）にデータベースの非表示のスナップショットを作成しようとします。このメカニズムを制御することはできませんが、CHECKDBの場所を制御したい場合 動作し、最初に独自のスナップショットを作成し（Enterprise Editionが必要）、任意のドライブでDBCCを実行します。 スナップショットに対するコマンド。いずれの場合も、スナップショットを通過するコピーオンライトアクティビティを最小限に抑えるために、相対的なダウンタイム中にこの操作を実行することをお勧めします。また、このスケジュールが、インデックスのメンテナンスやETLなどの大量の書き込み操作と競合することは望ましくありません。

CHECKDBを強制する提案を見たことがあるかもしれません WITH TABLOCKを使用してオフラインモードで実行するには オプション。このアプローチには反対することを強くお勧めします。データベースが積極的に使用されている場合、このオプションを選択すると、ユーザーはイライラするだけです。また、データベースがアクティブに使用されていない場合は、スナップショットを回避してディスクスペースを節約することはできません。これは、保存するコピーオンライトアクティビティがないためです。

I / Oの影響を減らす：665/1450/1452エラーを回避する

場合によっては、次のいずれかのエラーが表示されることがあります。

オペレーティングシステムは、ファイル'[file]'

CHECKDB中にこれらのエラーのリスクを減らすためのヒントがいくつかあります。 オペレーティングシステムとSQLServerのバージョンに応じて、いくつかの修正が利用可能になります。

• スパースファイルエラー：ファイルの断片化による1450または665：修正と回避策
• SQL Serverはオペレーティングシステムエラー1450または1452または665（再試行）を報告します

CPUへの影響を減らす

DBCC CHECKDB デフォルトではマルチスレッドです（ただし、Enterprise Editionのみ）。システムがCPUにバインドされている場合、またはCHECKDBが必要な場合 より長い実行を犠牲にしてより少ないCPUを使用するには、いくつかの異なる方法で並列処理を減らすことを検討できます。

1. Enterprise Editionを実行している限り、2008以降でResourceGovernorを使用します。特定のリソースプールまたはワークロードグループのDBCCコマンドのみを対象にするには、この作業を実行するセッション（特定のログインやjob_idなど）を識別できる分類関数を作成する必要があります。
2. トレースフラグ2528を使用して、DBCC CHECKDBの並列処理をオフにします。 （およびCHECKFILEGROUP およびCHECKTABLE ）。ここでは、トレースフラグ2528について説明します。もちろん、これはEnterprise Editionでのみ有効です。これは、Books Onlineが現在言っていることにもかかわらず、真実はCHECKDBであるためです。 StandardEditionでは並列になりません。
3. DBCC コマンド自体はMAXDOPをサポートしていません （少なくともSQL Server 2014 SP2より前は）、グローバル設定のmax degree of parallelismを尊重します。 。他に選択肢がない限り、おそらく本番環境で行うことではないでしょうが、これは特定のDBCCを制御するための包括的な方法の1つです。 より明示的にターゲットにできない場合はコマンド。

DBCC CHECKDBを実行するCPUの数をより適切に制御することを求めてきました。 を使用しますが、SQL Server2014SP2まで繰り返し拒否されていました。これで、WITH MAXDOP = nを追加できます。 コマンドに。

私の調査結果

私は、自分が制御できる環境でこれらのテクニックのいくつかを示したかったのです。私はAdventureWorks2012をインストールし、Jonathan Kehayias（ブログ| @SQLPoolBoy）によって作成されたAW引伸機スクリプトを使用して拡張しました。これにより、データベースが約7GBに拡張されました。次に、一連のCHECKDBを実行しました それに対するコマンド、およびそれらのタイミング。プレーンバニラDBCC CHECKDBを使用しました それ自体で、他のすべてのコマンドはWITH NO_INFOMSGS, ALL_ERRORMSGSを使用しました 。次に、（a）トレースフラグなし、（b）2549、（c）2562、および（d）2549と2562の両方を使用した4つのテスト。次に、これら4つのテストを繰り返しましたが、PHYSICAL_ONLYを追加しました。 オプション。すべての論理チェックをバイパスします。結果（10回のテスト実行の平均）は次のようになっています：

7​​GBデータベースに対するCHECKDBの結果

次に、データベースをさらに拡張して、2つの拡大されたテーブルのコピーを多数作成し、データベースのサイズが70 GBのすぐ北になり、テストを再実行しました。結果は、10回のテスト実行で平均化されました：

7​​0GBデータベースに対するCHECKDBの結果

これらの2つのシナリオで、私は次のことを学びました（ここでも、マイレージは異なる可能性があり、意味のある結論を引き出すには独自のテストを実行する必要があることに注意してください）：

1. 論理チェックを実行する必要がある場合：
   • データベースサイズが小さい場合、NO_INFOMSGS オプションを使用すると、SSMSでチェックを実行するときに処理時間を大幅に短縮できます。ただし、大規模なデータベースでは、情報の中継に費やされる時間と作業が全体の期間の非常に重要でない部分になるため、この利点は減少します。 2分のうち21秒はかなりの量です。 35分のうち88秒、それほど多くはありません。
   • テストした2つのトレースフラグは、パフォーマンスに大きな影響を与えました。両方を一緒に使用した場合、実行時間は40〜60％削減されました。
     
2. 論理チェックをセカンダリサーバーにプッシュできる場合（ここでも、真のコピーに対して他の場所で論理チェックを実行していると仮定します。 ）：
   • 標準のCHECKDBと比較して、プライマリインスタンスの処理時間を70〜90％短縮できます。 オプションなしで呼び出します。
   • 私のシナリオでは、トレースフラグはPHYSICAL_ONLYを実行するときに期間にほとんど影響を与えませんでした チェック。

もちろん、これを十分に強調することはできませんが、これらは比較的小さなデータベースであり、妥当な時間内に繰り返し測定されたテストを実行できるようにするためにのみ使用されます。このサーバーには80個の論理CPUと128GBのRAMがあり、私が唯一のユーザーでした。期間とシステム上の他のワークロードとの相互作用により、これらの結果がかなり歪む可能性があります。 CHECKDBの1つで、SQLSentryを使用した一般的なCPU使用率を簡単に確認できます。 操作（およびどのオプションもCPUへの全体的な影響を実際に変更することはなく、期間のみ）：

CHECKDB中のCPUへの影響–サンプルモード

そして、これは別のビューで、3つの異なるサンプルCHECKDBの同様のCPUプロファイルを示しています。 履歴モードでの操作（この範囲でサンプリングされた3つのテストの説明をオーバーレイしました）：

CHECKDB中のCPUへの影響–履歴モード

ビジーなサーバーでホストされているさらに大規模なデータベースでは、さまざまな効果が見られる場合があり、マイレージは大きく異なる可能性があります。したがって、CHECKDBにどのようにアプローチするかを決定する前に、通常の同時ワークロード中にデューデリジェンスを実行し、これらのオプションとトレースフラグをテストしてください。 。

結論

DBCC CHECKDB これは非常に重要ですが、DBAまたはアーキテクトとしての責任の一部として過小評価されることが多く、会社のデータを保護するために不可欠です。この責任を軽視せず、本番インスタンスへの影響を減らすために何も犠牲にしないように最善を尽くしてください。最も重要なことは、マーケティングデータシートを超えて、それらの約束がどれほど有効であるか、そして会社のデータをそれらに賭ける意思があるかどうかを完全に理解していることを確認することです。一部の小切手をスキップしたり、無効な二次的な場所に小切手をオフロードしたりすると、災害が発生するのを待っている可能性があります。

これらのPSS記事も読むことを検討する必要があります：

• より高速なCHECKDB–パートI
• より高速なCHECKDB–パートII
• より高速なCHECKDB–パートIII
• より高速なCHECKDB–パートIV（SQL CLR UDT）

そして、ブレントオザルからのこの投稿：

• DBCCCHECKDBをより高速に実行する3つの方法

最後に、DBCC CHECKDBについて未解決の質問がある場合 、Twitterの#sqlhelpハッシュタグに投稿してください。 Paulはそのタグを頻繁にチェックし、彼の写真はBooks Onlineのメイン記事に表示されるはずなので、誰かがそれに答えることができれば、彼は答えることができるでしょう。 140文字に対して複雑すぎる場合は、ここで質問するか（Paulがいつかそれを確認できるようにします）、Database AdministratorsStackExchangeなどのフォーラムサイトに投稿してください。