こんにちは、Kirkです。GSEチームの上級主席エンジニアです。このビデオでは、Microsoft SQL Server TSQL データベース ツールである DBCC CHECKDB について説明します。DBCC CHECKDB を実行する理由とタイミング、および関連するデータベース チェックのレベルと実行時間を決定するコマンド オプションについて説明します。
実際の使い方の前に、今回のポイントを上げておきます。DBCC CHECKDB は、特定の SQL Server データベース内のすべてのオブジェクトの論理的および物理的な整合性を調べる TSQL ツールです。いくつかの修復オプションも用意されており、オプションとして「TABLOCK」と呼ばれるものがあり、データベースのスナップショットの使用または不使用が含まれます。「ESTIMATEONLY」オプションと、それを使用する理由、およびCHECKDBプロセス中の「TEMPDB」の使用に関連するオプションを見ていきます。
また、「PHYSICAL_ONLY」について、このオプションを使用する理由とタイミングについても説明します。また、「MAXDOP」と呼ばれるものを使用して、CHECKDBプロセスに関与するプロセッサの数を制御する方法についても見ていきます。そこで、ここでは、DBCC CHECKDB を実行したときに表示される内容の例をいくつか見ていきます。したがって、最初のコマンド自体は、DBCC CHECKDB が特定のデータベース内で参照できるすべてのものを文字通りチェックします。
こちらが結果です。これを実行するときに最も関心があるのは、データベースで見つかった "割り当てエラー" と "整合性エラー" の数です。そのため、正常な "AdventureWorks2019" データベースがあるので、すべてエラーなしで返されます。サイズの小さいデータベースなので、実行も短時間で済みます。はるかに大きなデータベース、たとえばこのデータベースの100倍のサイズのデータベースがある場合、これを実行するのにはるかに長い時間がかかります。
また、DBCC CHECKDB をどのくらいの頻度で実行する必要があるか疑問に思われる方も多いと思いますが、通常、SQL マスタはできるだけ早く実行するように指示します。データベースに不整合や何らかのソフトウェアの損傷がある場合は、できるだけ早くそれを発見して対処する必要があります。次にご紹介するのは、「WITH PHYSICAL_ONLY」と呼ばれるオプションです。
これは同じコマンドですが、この場合は文字通り、物理的なエンティティまたはデータベース自体の構造のみをチェックします。通常、フル チェックよりもはるかに高速に実行されるため、メンテナンス時間に制限がある本番環境で実行する必要があります。また、"WITH TABLOCK" という別のオプションもあるので、DBCC CHECKDB について理解する必要があることの 1 つは、最初に "TEMPDB" データベースに含まれるスナップショット ファイルを作成することですが、CHECKDB プロセスでは "TEMPDB" を使用できない場合があります。
したがって、"WITH TABLOCK" と指定する場合でも、スナップショット ファイルを作成しないように DBCC CHECKDB に指示しているため、"TEMPDB" でその領域を占有することはなく、通常はその結果、実行速度が向上します。オプションとして実行できる他のものの1つは、「WITH ESTIMATEONLY」です。この特定のコマンドは、CHECKDBの実行時に「TEMPDB」データベース内で使用されると予想されるスペースの量を示します。
ここに出力の例を示します。キロバイトで返されるので、約230メガバイトです。もう1つ、「WITH MAXDOP」オプションがあります。これで、DBCC CHECKDB が実行する場合でも、並列実行に必要な数のプロセッサを使用しようとします。できるだけ早く実行するために、複数のスレッドを実行したいと考えています。そのため、このプロセスで実行を許可するプロセッサの数に制限がある場合があるため、"WITH MAXDOP" ステートメントで制限できます。
この場合、CHECKDB の実行に 1 つのプロセッサのみを使用するように SQL に指示します。これを行うと、これ専用のプロセッサは少なくなりますが、通常、DBCC CHECKDB の実行に時間がかかります。次に修復オプションを見てみましょう。いくつかの修復オプションがあります。徹底した修復を行うのが「REPAIR_ALLOW_DATA_LOSS」です。エラーが返ってきたデータベースを修復するためにこのオプションを使用するたびに、文字通りデータが失われる可能性があります。「REPAIR_REBUILD」も使用できます。
REPAIR_REBUILDはソフト修復オプションと見なされます。つまり、これを実行してもデータベース内の利用可能なデータが失われないことを保証するものです。そのため、このコマンドのレイアウトでは、「Master」データベースのコンテキストを使用します。このようなことを行うときはいつでも、修復操作を可能にするためにデータベースを「SINGLE_USER」モードにする必要があります。このとおり実行してみます。
ここでも [ESTIMATEONLY] というオプションがあります。ここでも [ESTIMATEONLY] を選択すると、これを行うために "TEMPDB" でどの程度の領域を解放するかがわかります。スナップショット ファイルは、ここで返すと約230メガバイトになります。これで修理を行った後、「MULTI_USER」モードに戻します。「ESTIMATEONLY」では、実際に修復を実行したのではなく、見積もりのみを行いました。それでは、「REPAIR_REBUILD」を使用してコマンドを実行する方法を見てみましょう。
もう一度、「実行」しましょう。「MULTI_USER」に戻します。もう一度、「Master」データベースのコンテキストで「SINGLE_USER」モードにします。この場合は、修復が行われます。軽い修復オプションです。通常のDBチェックで確認できる内容とほぼ同じです。ここでも、報告されたエラーを確認します。今回も、エラーは出ませんでした。
データベースに問題はありません。そして、この操作の最後の部分は、「MULTI_USER」モードに戻すことです。「REPAIR_ALLOW_DATA_LOSS」修復コマンドは、「REPAIR_ALLOW_DATA_LOSS」を使用する点が異なりますが、「REPAIR_REBUILD」とまったく同じです。通常、これは「REPAIR_REBUILD」を実行しようとしたときに実行し、「REPAIR_REBUILD」が戻ってきて、データベースの修復を完了できなかったことを通知します。
したがって、適切なバックアップがない最後の手段であり、「REPAIR_ALLOW_DATA_LOSS」を実行することを余儀なくされる前に、適切なバックアップを使用する必要があります。バックアップが存在しない場合、これがデータベースをオンラインに戻して使用できるようにする唯一のオプションです。これで、DBCC CHECKDB について説明し、CHECKDB をいつ使用するか、および使用可能な最も一般的なコマンド オプションのいくつかを検討するデモは終了です。このビデオが、一貫性のある安定した SQL Server データベース インストールを維持するときに DBCC CHECKDB を使用する価値を理解するのに役立つことを願っています。
ご視聴ありがとうございました。
