定期的なデータベースのメンテナンスは、データベース管理者の仕事の重要な部分であり、非常に重要なシステムが通常どおりに実行されていることを確認するのに役立ちます。これを実現する最も簡単な方法の1つは、DBCCCheckDBに関連するタスクを自動化することです。実行しているSQLServerのバージョンに関係なく、メンテナンスを必要としないデータベースはありません。特に実際の災害シナリオ時に背中を覆うことができるように、定期的にメンテナンスを行うように計画する必要があります。
DBAは常に犯人です
データベースの問題があるときはいつでも、すべての目がDBAにあります。問題の原因が雨によるものであろうと、開発者が厄介なコードを記述してデータベースの速度を低下させたものであろうと、DBAは常に混乱を修正することが期待されています。また、利用可能な最後のバックアップを使用してデータベースを迅速に復元するように求められた場合に対処する必要のある種類のプレッシャーを想像できます。このバックアップは、プロセスで判明したように無効であり、データベースの整合性がすでに数か月間損なわれています。前。ここに、プロアクティブDBAとリアクティブDBAの違いがあります。実際には、リカバリ戦略はバックアップ戦略と比較してはるかに重要です。復元時に役に立たない場合、毎日のデータベースバックアップはどのような目的に役立ちますか?
メンテナンスが重要な理由
データベーステクノロジーの前例のない成長とすべてのリリースで登場する新機能により、DBAとして他の人よりも先を行き、業界のベストプラクティスに従っていることを確認することが不可欠です。データベースのメンテナンス。
DBCCCheckDBとその実行方法
DBCC CheckDB –この名前は機能を非常によく表しています。簡単に言えば、データベースをチェックします。これは、データベースが期待どおりに機能していることを確認するために重要です。基本的に、DBCC CheckDBは、データベース内のすべてのオブジェクトの論理的および物理的な整合性をチェックします。これは、公式によると、DBCCCheckDBが内部で行うことです。 Microsoftのドキュメント:
-
データベースでDBCCCHECKALLOCを実行します–ディスクスペース割り当ての一貫性
-
データベース内のすべてのテーブルとビューでDBCCCHECKTABLEを実行します。これにより、テーブルまたはインデックス付きビューを構成するすべてのページと構造の整合性が保たれます。
-
データベースでDBCCCHECKCATALOGを実行します。これにより、指定されたデータベース内のカタログの整合性がチェックされます。
-
データベース内のすべてのインデックス付きビューの内容を検証します。
-
FILESTREAMを使用してvarbinary(max)データをファイルシステムに保存するときに、テーブルメタデータとファイルシステムディレクトリ/ファイル間のリンクレベルの整合性を検証します。
-
データベース内のServiceBrokerデータを検証します。
DBCC CheckDBコマンドを明示的に、またはジョブを介して実行すると、基本的に上記のすべてが実行されます。
データベースでDBCCCheckDBを直接実行する
DBCC CheckDBコマンドをデータベースで直接実行して、結果を確認できます。以下のスクリーンショットに示すように、コマンドの出力を確認してください。出力には、テーブル内の行と、これらの行で使用されるページ数に関する詳細が表示されます。
よく見ると、データベースオブジェクトに固有の詳細が表示されます。たとえば、「VLDB」データベースでは、次の出力を確認できます。
“Object ID 1179151246 (object 'Warehouse.ColdRoomTemperatures'): The operation is not supported with memory optimized tables. This object has been skipped and will not be processed.”
この出力が示すように、DBCCCheckDBはメモリ最適化テーブルではサポートされていません。メモリ最適化テーブルは、SQLServer2014でエンタープライズ専用機能として最初に導入されました。ただし、何年にもわたって、SQLServerで広く普及している機能になっています。
また、DBCCチェックが以下に示すようにデータベース内のサービスブローカーデータを検証したことにも気付くでしょう。
“DBCC results for 'VLDB'. Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.”
最後に、DBCC CheckDBコマンドが正常に完了すると、次の出力が表示されます。
DBCC CheckDBの実行後にエラーが報告された場合はどうなりますか?
上記の例では、DBCCCheckDBがエラーなしで完了したことがわかります。ただし、運が悪ければ、整合性エラーが発生する可能性があります。その場合は、重要な決定を行う必要があります。本番データベースで問題が発生した場合は、ビジネスオーナーまたは運用マネージャーにカードをテーブルに置くように通知するのが最善です。最後に使用可能なバックアップからデータベースを復元するオプションを提供するか、追加のオプションを使用してDBCCCheckDBコマンドを実行してみることができます。
DBCCエラーメッセージは次のようになります。
Table error: Object ID 36, index ID 1, partition ID, alloc unit ID (type In-row data). Keys out of order on page (1:107), slots 6 and 9. CHECKDB found 0 allocation errors and 1 consistency errors in table 'sys.syk' (object ID 36). CHECKDB found 0 allocation errors and 1 consistency errors in database 'VLDB'. repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (VLDB).
エラーメッセージには、慎重に表現されたエラーメッセージが表示されます–「repair_rebuildは 最小 DBCCCHECKDBによって検出されたエラーの修復レベル 」–repair_rebuildオプションを指定してDBCCCheckDBを実行することをお勧めします。強調表示されている単語「最小」を見てください。これは、repair_rebuildオプションを使用すると、データが失われる可能性が実際にはなく、SQLServerが内部でいくつかの迅速な修正を行うことを意味します。以下のコマンドを参照して、repair_rebuildオプションを指定してDBCCCheckDBを実行してください。データベースを必ずシングルユーザーモードにしてください。
Microsoftのドキュメントによると、データが失われることはないため、REPAIR_REBUILDオプションが最も無害なバージョンです。ただし、それでもREPAIR_REBUILDで整合性エラーが修正されない場合は、もう1つのオプションがあります。REPAIR_ALLOW_DATA_LOSSを有効にすることです。名前を見ると、このオプションをオンにすると、データが失われる可能性があることがわかります。このため、Microsoftは、REPAIR_ALLOW_DATA_LOSSを指定してDBCC CheckDBを実行すると予期しない結果が生じる可能性があるため、これを使用する場合は細心の注意を払って警告します。この場合のDBCCCheckDBコマンドは、次のようになります。
DBCCCheckDBで修復オプションを使用する前に考慮すべき点
-
問題のデータベースはどの程度重要ですか? -
データベースは本番環境にありますか、それともテスト環境にありますか?
-
データベースのサイズはどれくらいですか? -
問題が発生した場合に備えて、適切な復旧戦略がありますか?
-
データベースのバックアップを検証しましたか?
上記の質問に対する状況と回答に基づいて、クライアントの最善の利益を念頭に置いて決定を下すようにしてください。
そうですね、サーバー上でこれらのコマンドをすべて手動で実行する必要はありません。そのため、メンテナンス計画を立てています。データベース保守計画を使用して、すべてのデータベースの定期的な保守サイクルを必ずスケジュールしてください。これはかなり単純で簡単な作業です。 「保守計画タスク」の下で、「データベース整合性タスクの確認」を選択します。
これにより、データベースの整合性チェックをスケジュールするためのサブタスクがメンテナンスプランに追加されます。図のように、必ず必要なデータベースを選択してください。
すべてのデータベースチェックは、オフピーク時に必ず実行してください。通常、メンテナンスウィンドウは、サーバーが他の曜日に比べてビジー状態が少ない週末にあります。ただし、これはサーバーごとに異なり、アプリケーションによって異なります。重要なデータベースシステムでは、通常、DBCCCheckDBまたは整合性チェックが欠落している場合は常にアラートが表示されます。このようにして、DBAは事前にチェックし、整合性チェックが完了していることを確認して、後で予期しない事態を回避できます。
SQL Serverインスタンスでメンテナンスタスクを実行するために、SQLServerメンテナンスプランを常に使用する必要はありません。使用できる他の利用可能なカスタマイズされたスクリプトがあります。人気のある無料のメンテナンスツールの1つは、OlaHallengrenのメンテナンスソリューションです。バックアップや最適化などのタスクを含むメンテナンスソリューション全体をインストールすることも、整合性チェックに関連する関連スクリプトのみをダウンロードすることもできます。このデモでは、データベースの整合性チェックに固有のスクリプトをインストールしようとします。
示されているようにDatabaseIntegrityCheck.sqlオプションをクリックして、データベースの整合性をチェックするストアドプロシージャをダウンロードします。マスターデータベースでこれらのストアドプロシージャを実行した後、次の警告メッセージが表示されました。
“The module 'DatabaseIntegrityCheck' depends on the missing object 'dbo.CommandExecute'. The module will still be created; however, it cannot run successfully until the object exists.”
整合性チェックを実行するためにストアドプロシージャを実行すると、次のエラーが発生します:
エラーの状態として、不足しているコードをここからダウンロードできます。これが完了すると、データベースの整合性チェックの試行を開始できます。
追加のDBCCコマンドパラメータを使用して、さまざまなオプションを調整できます。詳細と例については、こちらをご覧ください。
ただし、このデモでは、いくつかの例をチェックして、これらのスクリプトが実際にどれほど簡単でユーザーフレンドリーかを確認します。
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'USER_DATABASES', @CheckCommands = 'CHECKDB'
実行されたコマンドと、DBCCCheckDBが正常に完了したことを確認する結果ステータスを確認できます。
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'SYSTEM_DATABASES', @CheckCommands = 'CHECKDB'
スクリーンショットでは、システムデータベースのDBCCCheckDBが正常に完了したことがわかります。
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'VLDB', -- your specific DB Name @CheckCommands = 'CHECKDB'
上記の例では、パラメータを使用するいくつかの方法を見てきました。ただし、好みに基づいて選択できるフィルターは他にもたくさんあります。また、すでに述べたように、このリンクを参照できます。 OlaHallengrenのスクリプトをさらに理解するため。繰り返しになりますが、私は管理しているサーバーでOla Hallengrenのスクリプトを使用しています。これは、SQLServerコミュニティ内で強く推奨および認識されています。好みのパラメータに基づいてストアドプロシージャをスケジュールし、オフピーク時にSQLジョブとして実行できます。このように、これらのスクリプトを手動で実行する必要がないため、他の重要なタスクに集中できます。
結論
- この記事から、DBCCCheckDBとその使用方法について学習しました
- また、すべての重要なデータベースでDBCCCheckDBを定期的に実行することの重要性を理解しました
- バックアップ戦略をテストすることの重要性についても学びました。DBCC修復オプションを使用して整合性エラーを解決するのではなく、適切なバックアップを使用してデータベースを復元することをお勧めします
- SQL Serverのメンテナンスプランまたはカスタマイズされたスクリプト(Ola Hallengrenのスクリプトなど)を使用して、スクリプトを構成および自動化するのがいかに簡単かについても説明しました。
- サポートされているインフラストラクチャでDBCCCheckDBをスケジュールしないことのリスクについても学びました
- また、使用しているサーバーや実行しているインフラストラクチャに関係なく、メンテナンスを必要としないデータベースはあり得ないことも学びました。
- 最後に、データベースを正常に保つようにしてください。いずれの場合も、管理できない可能性のあるオフの日に備えてください。