SQL Serverが起動後に行っている重要な処理、「復旧処理」を理解する：SQL Serverトラブルシューティング（7）

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。今回は、「起動後に行っている、データベースの復旧処理の裏側」を解説します。

【3】SQL Serverが起動後に行っている重要な処理、「復旧処理」を理解する

　SQL Serverの起動後、システムとユーザデータベースはデータの整合性を保つために「復旧処理」と呼ばれる重要な処理を行っています。

　SQL Serverに限らず、RDBMSでは「WAL（Write Ahead Logging：ログ先行書き込み）」と呼ばれる動作で、障害時にデータの損失を防ぐリスクヘッジを行っています。

　つまり、「変更データをデータファイルに書き込む処理」は即時に行われるのではありません。障害が発生し、万が一稼働中のインスタンスが強制終了してしまった場合には、次回起動時にWALで記録したログレコードを基にして、COMMIT済みのデータをデータファイルに書き出す処理を行います。これが「復旧処理」です。この復旧処理によって、データの整合性を保つようにしています。

　SQL Serverがデータを保存する領域を「データファイル」、変更を記録する領域を「トランザクションログファイル」と呼びます。

　例えば、UPDATEステートメントでデータを変更したとします。変更処理そのものは、まずメモリ内で実行されます。その変更が確定（＝COMMIT）されると、変更履歴をトランザクションログファイルに記録します。この段階では、まだデータファイルには反映しません。ユーザーによる変更処理はしたが、データファイルにはまだ反映されていないデータを「ダーティページ」と呼びます。データファイルには、SQL Serverが定期的に実行している「CHECKPOINT」と呼ばれる“ダーティページを一括して書き込む処理”が動いたときにようやく反映されます（図1）。

図1　SQL Serverの「ログ先行書き込み動作」の流れ

　なぜ、このような回りくどい処理をするのでしょう。1つはパフォーマンス向上のため。もう1つは、RDBMSが持つACID特性（*1）の「Durability（耐久性）」を確保するためです。

　一方で、Durabilityを確保するためには、バックアップ処理を運用に組み込むことが肝心です。SQL Serverでは、大きく分けると「データのバックアップ」と「トランザクションログのバックアップ」の2種類があります。

データベースの「復旧モデル」を理解する

　データベースには「復旧モデル」と呼ばれる、3段階の設定があります。この設定ごとに、採取すべきバックアップの種類が変わります。

　ちなみに、復旧モデルはデータベースごとに設定できます。このため、データベースごとに復旧できるレベルも変わることに少し注意が必要です。ディスク障害などのトラブル時には、採取したバックアップを基に復旧作業を行うことになります。