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

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「起動後に行っている、データベースの復旧処理の裏側」を解説します。

[内ヶ島暢之，ユニアデックス株式会社]

連載バックナンバー

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

SQL Serverは起動時にどのような動きをしているのか

1. 起動から、利用可能になるまでの流れをログから理解する
2. SQL Serverの動きが変わる、サービス起動アカウントに実行権限を付与する方法
3. SQL Serverが起動後に行っている、重要な処理「復旧処理」について
4. アプリケーションが、どのプロトコルで接続しているのかを確認する

【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（耐久性）」を確保するためです。

*1：ACID特性：「Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（耐久性）」の頭文字。リレーショナルデータベースに求められる4つの耐性を示す専門用語。

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

バックアップの対象	特徴
データ	データファイルを物理的に複製することでバックアップする。完全バックアップや差分バックアップといった種類がある
トランザクションログ	トランザクションログの複製をすることでバックアップする。データのバックアップに加えてトランザクションログも記録するので、データベースの停止寸前までのデータを保証できる

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

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

復旧モデルの種類	特徴
完全	データ変更中、及び変更後の記録とトランザクションログに記録する。トランザクションのバックアップが行われるまで書き込んだ領域の再利用はできないが、障害発生の直前までデータを復旧できる
一括ログ	一括ログ操作（一部のBULK INSERTやSELECT INSERT処理）において、変更履歴を残さずに一括操作があったことだけをトランザクションログに書き込むもの。障害発生の直前までデータを復旧できる
単純	データ変更中はトランザクションログへ書き込みを行うが、COMMIT後は書き込んだ領域が再利用可能となる。上記とは違い、データの復旧は「バックアップの採取時点まで」となる。

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

→目次に戻る

本トラブルシューティングの対応バージョン：SQL Server 全バージョン

筆者紹介

内ヶ島 暢之（うちがしま のぶゆき）

ユニアデックス株式会社所属。Microsoft MVP Data Platform（2011〜 ）。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を行っていた。2016年4月よりIoTビジネス開発の担当となり、新しい仕事に奮闘中。ストレッチをして柔らかい身体を手に入れるのが当面の目標。

椎名 武史（しいな たけし）

ユニアデックス株式会社所属。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。