データの整合性を確保する
データベースを運用する上で最も壊れやすいコンポーネントはディスクサブシステムだ(注1)、という言葉を何度か見聞きしたことがあります。頻繁なバックアップを行ったり、局所的な復旧を可能にしたりと壊れても問題を小さくする対処はできたとしても、データ自体の破損や整合性が合わない状態というのは長い年月データベースを運用していると、どうしても避けられない問題だと思います。
しかも、データ整合性に何か問題が発生したとしても通常はデータ破損したタイミングで検知することはできず、そのデータを実際に使うタイミングで初めて問題があることが分かります。
たとえば、毎年3月31日にしか実行されない年次バッチでのみ参照されるテーブルが存在し、且つそのテーブルデータが破損したとします。テーブルデータの破損が4月1日に発生した場合、約１年間そのテーブルはアクセスされないためデータ破損が起こったことが検知されません。そして、翌年の3月31日に年次バッチを実行して初めてデータ破損が発生していることに気付く、という不幸な状態に陥るかもしれません。
上記はかなり極端な例ですが、もし定期的にデータの整合性をチェックしていたら、実際に年次バッチを実行する数か月も前から余裕を持って対処でき、業務処理が滞るのを避けられるかもしれません。そのため、「データ不整合を完全に発生させなくする」というのは現実的ではありませんが、「データ不整合が例え発生しても早期に発見し業務影響を最小限に抑える」というスタンスが重要であり、DBCC CHECKDBが大きな役割を果たします。
(注1) ここでのディスクサブシステムとはストレージ製品のことだけを指しているのではなく、デバイスドライバやネットワーク、OSのファイルシステムも含みます。
DBCC CHECKDBコマンドは何を行っているのか
DBCC CHECKDB はとても簡単なコマンドですが、内部ではデータベースの整合性を確保するためにとても多くのチェックを行っています。実行すると対象データベースに対する以下の処理が順に行われます。(注2)
- FILESTREAMに対するチェック
- DBCC CHECKALLOC 同等の処理
- 不整合の修復 (修復オプションが指定されている場合)
- システムテーブルに対するチェック
- 不整合の修復 (修復オプションが指定されている場合)
- テーブル、ビューに対する DBCC CHECKTABLE 同等の処理
- 不整合の修復 (修復オプションが指定されている場合)
- SQL Server Service Broker に対するチェック
- DBCC CHECKCATALOG 同等の処理
- インデックス付きビューやXMLインデックスに対するチェック
上記の通り、DBCC CHECKDBは実際にはDBCC CHECKALLOCや DBCC CHECKTABLEといった他の管理コマンドと同様のチェックを含んでいます。つまり、たくさんのコマンドを実行する替わりに１つのコマンドでマルッとデータベースの整合性を確保しようとするのがDBCC CHECKDBなのです。
DBCC CHECKDBの実行結果は全ての処理が完了したタイミングで出力されるため途中経過は分かりませんが、動的管理ビュー sys.dm_exec_requests の 『command 列』を参照することで内部のどの処理を実行しているかを確認できます。以下は command 列に表示される値とどのような状態にあるかをまとめたものです。
また、sys.dm_exec_requests ビューの『percent_complete列』を参照することで処理内での進行状況の目安にできます。例えば以下の場合、各テーブルの整合性チェックを行う処理(DBCC TABLE CHECK) が全体の約65% まで完了した状態であることが分かります。
(注2) DBCC CHECKDBは SQL Server のバージョンによってチェックの内容に違いがある場合があります。この内容は SQL Server 2012 RTM を基にしています。
