NEC

E ラーニング事業部

鈴木 智行

2002 年 5 月 8 日

目次

3.1 障害発生時点までのトランザクションログ取得
3.2 重要な復元オプション
3.3 特別な復元方法
3.4 バックアップヒストリテーブル
3.5 システムデータベースの復元
3.6 まとめ

3.1 障害発生時点までのトランザクションログ取得

データベースに障害が発生した場合、しっかりとしたバックアップ計画を用いて運用していれば最新のバックアップデータを用いてデータベースを復旧できます。しかし最新のバックアップを行った後に変更作業が行われていたとしたら、最新のバックアップを用いたとしてもバックアップ後の変更作業を適用することはできません（図 3-1-1 ）。

運がよければバックアップ後の変更作業（トランザクションログ）は壊れたデータベース中に格納されているはずです。したがってこのトランザクションログを利用して障害発生直前までデータベースを復旧することができます。

壊れたデータベース内のトランザクションログは no_truncate オプションを利用してバックアップ可能です。

簡単な例を用いて紹介しましょう。表 3-1-2 のようにデータベースを作成し、下記の作業を実行します。

表 3-1-2　データベースとテーブルの構成

作業

1. testdb データベースにデータ追加（例えば 5 件）

2. testdb データベースを testdbbak バックアップファイルにフルデ－タベースバックアップ

3. testdb データベースにさらにデータ追加（例えば 5 件）

4. testdb_Data 2 データベースファイル（testdb_Data 1 でも OK）の物理ファイル名を変更し、壊れたことをシミュレート

物理ファイル名を変更すると、 SQL Server ログにエラーが表示され、 . testdb データベースはデータベースとして使用できなくなります（画面 3-1-3 ）。

このケースでは no_truncate オプションを使用して最新のトランザクションログを取得可能です（画面 3-1-4 ）。

こうすれば、バックアップファイルにトランザクションログがバックアップできるため   （画面 3-1-5 ）、通常の作業でデータを復元することができます。

もちろん no_truncate オプションは、トランザクションログが壊れてしまい、それ自体にアクセスできない場合は使用できません（画面 3-1-6 ）。

ページのトップへ

3.2 重要な復元オプション

データを復元するときのオプションはさまざまありますが、ここでは一番重要だと思われるオプションについて紹介します。皆さんに最低限覚えていただきたいオプションは以下の 3 つです（画面 3-2-1 ）。

• Recovery （データベースは操作可能状態。別のトランザクションログの復元は不可）

• NoRecovery （データベースは操作不可状態。別のトランザクションログの復元は可能）

• Standby （データベースは読み取り専用。別のトランザクションログの復元は可能）

この 3 つの復元オプションでバックアップデータを復元したときの状態を決定します。

Recovery オプションはデータベースの整合性を保つように復元します。第 2 回で説明したとおり、バックアップデータにはバックアッププロセス中に実行されたトランザクション情報が含まれます。したがってバックアップを終了した時点でどのトランザクションが未完了かがわかるので、この未完了のトランザクションを自動的にロールバックします。したがって未完了のトランザクション情報がなくなるので、これ以上のトランザクションログバックアップは追加で復元できませんが、データベースは完全に使用可能となります。したがって Recovery オプションは最新のバックアップを復元するときに使用するオプションだと考えてください。

NoRecoveryオプションは上記の未完了トランザクションをロールバックしません。したがってデータベースは整合性が取れていない状態なので、ユーザーのデータベースへのアクセスが一切拒否されますが、追加のトランザクションログバックアップは復元することができます。したがって NoRecovery オプションは復元プロセスの途中段階で使用するオプションだと考えてください。

Standby オプションは上記 2 つの中間的なオプションです。未完了トランザクションをロールバックしますが、その情報を廃棄せず undo ファイルに保存し（画面 3-2-1 では元に戻すファイルと表示されています）、追加のトランザクションログに対応できるようにします。復元した時点でのデータ整合性はとれているのですが、追加のトランザクションログを適用した後にデータは変更される恐れがあるので、それを保護するためにデータベースは読み取り専用となります。したがって Standby オプションは復元途中のデータを確認する場合やスタンバイサーバーのような読取専用データベースをもったサーバーを構築する場合などに使用するオプションと考えた方が良いでしょう。

通常、図 3-1-1 の場合で障害が発生した場合には以下の方法でバックアップデータを復元します。

（ケース 1 ）   最新の障害発生時点までのトランザクションログが取得できた場合（図 3-2-2 ）

1. フルデータベースバックアップを NoRecovery オプションで復元

2. 差分バックアップを NoRecovery オプションで復元
   　　（それまでのトランザクションログバックアップの復元は不要）

3. トランザクションログバックアップを NoRecovery オプションで復元

4. no_truncate オプションで取得した最新のトランザクションログバックアップを Recovery オプションで復元

   

( ケース 2 ）   最新の障害発生時点までのトランザクションログが取得できなかった場合（図 3-2-3 ）

1. フルデータベースバックアップを NoRecovery オプションで復元

2. 差分バックアップを NoRecovery オプションで復元
   　　（それまでのトランザクションログバックアップの復元は不要）

3. トランザクションログバックアップを Recovery オプション で復元

4. 必要であれば、最新のトランザクションログバックアップ以降おこなったトランザクションを再適用

   

ページのトップへ

3.3 特別な復元方法

データベース復旧モデルがフルモデルの場合は以下の 2 つの復元が可能となります（ただし、一括ログの対象となる作業を行っていなければ一括ログ記録モデルでも可能となる場合があります）。

• 特定時点への復元

  通常の復元ではトランザクションログをバックアップした時点にしか戻りませんが、 Restore Log ステートメントの STOPAT オプションを使用すれば（ SQL Server Enterprise Manager でも可能）、トランザクションログバックアップの一部を使用してデータベースを指定された日付と時刻の状態に復元します（図 3-3-1 ）。

  

• 特定のトランザクションへの復元

  特定のトランザクションへの復元には、マーク付きトランザクションとしてトランザクションを定義しなければいけません。 Begin Transaction ステートメントでトランザクションを開始するときに、トランザクション名を指定し、 with Mark オプションを使ってマーキングします。すると msdb データベースの logmarkhistory システムテーブルに情報が登録されます（表 3-3-2 ）。

表3-3-2　logmarkhistory システムテーブル

復元の際には、 Restore Log ステートメントの STOPATMark オプションあるいは STOPBeforeMark オプションでマークをつけたトランザクション名を指定します。

STOPATMark オプションはマークの時点にロールフォワードし、マークの付いたトランザクションを実行します。すなわちマーク付きトランザクションが終わった時点に戻ります。

STOPBeforeMark オプションはマークの時点にロールフォワードし、マークの付いたトランザクションは実行しません。すなわちマーク付きトランザクションが始まる前の時点に戻ります。（図 3-3-3 ）。

ページのトップへ

3.4 バックアップヒストリテーブル

SQL Server Enterprise Manager を使用すれば復元作業は非常に簡単です。例えば 3.2 のケース 2 の場合、復元を実行しようとすると画面 3-4-1 のように表示されます。

このように SQL Server Enterprise Manager ではバックアップ履歴を利用し、バックアップを用いて最新のデータに正しい順序で復元するための情報を提示してくれます。したがって私達はその提示情報を確認し、必要であれば最終的なデータベースの状態（ Recovery or NoRecovery or Standby ）を選択し、最後に [OK] ボタンを押すだけで復元を実行することができます。

この簡単な復元作業を実現するためにはバックアップヒストリテーブルが重要な役割を担っています。バックアップヒストリテーブルは以下の 4 つのテーブルにバックアップの履歴を保存しています（表 3-4-2 ）。

表 3-4-2 バックアップヒストリテーブルの種類

この 4 つのテーブルはいずれも  msdb データベース中に格納されています。このため msdb データベースが壊れてしまうと復元作業でバックアップ履歴を使用できなくなるので注意してください。

ページのトップへ

3.5 システムデータベースの復元

ユーザーデータベースではなくシステムデータベースが壊れた場合には、どういう影響があるでしょうか？

model データベースはユーザーデータベースのテンプレートとなるデータベースです。このデータベースは頻繁に変更するようなデータベースではありません。変更の度合いにもよりますが、変更後のフルデータベースバックアップがあれば、それほど多大な影響を及ぼすものではないでしょう。

msdb データベースは 3.3 や 3.4 で説明したとおり、マーク付きトランザクションやバックアップ履歴、これ以外にもジョブスケジュールや DTS のパッケージの情報など SQL Agent サービスに関わる管理情報などを保持しています。業務にもよるでしょうが、この情報がなくなると多大な影響を及ぼす可能性があります。このデータベースのデフォルト復旧モデルはシンプルモデルになっており、モデルを変更する必要がない場合にはフルデータベースバックアップと差分データベースバックアップを組み合わせ、ユーザーデータベースと同様にしっかりとしたバックアップ計画を組んでください。

master データベースは環境設定オプションやログインなどの SQL Server 全体の管理情報を保持しており、以下のようなタスクを実行すると master データベース内のシステムテーブルが変更されます。

• データベースの作成／削除

• ログインアカウントの追加／削除

• リンクサーバーの追加／削除

• ユーザー定義エラーメッセージの追加／削除.....etc

変更した後にバックアップするのが理想ですが、運用上頻繁にバックアップできない場合もあるかもしれません。 msdb データベース同様、しっかりとしたバックアップ計画を組んでください。しかし最悪のケースを考えた場合、 master データベースが壊れてしまったら、SQL Server が起動しなくなってしまうことがあります。最低限 SQL Server が起動すればバックアップを用いて復元できますが、 SQL Server が起動できなければ、たとえバックアップがあったとしても復元操作自体ができません。したがって master データベースをバックアップするのはもちろんですが、 SQL Server が起動しなくなった場合の復元方法をしっかりおさえておく必要があります。

簡単な例を用いて紹介しましょう。表 3-5-1 のようにシステムデータベースに関わるような構成要素を作成して環境を設定します。ただし AfterDatabase データベースは他の構成要素を作成し、 master データベースと msdb データベースをフルバックアップした後に作成するものとします。

表 3-5-1 テスト環境

手順）

1. master 再構築ユーティリティ（Rebuildm コマンドプロンプトユーティリティ）を利用してシステムデータベースを再構築します（画面 3-5-2）。

   　→照合順序は元の master データベースと同じものを選択します。

   　 master 再構築ユーティリティを実行すると msdb 、 model データベースも同時に再構築されるため、表 3-5-1 の構成要素は全て認識されなくなります。

   

   画面 3-5-2 master 再構築ユーティティ

2. master データベースのバックアップをするために SQL Server をシングルユーザーモードで起動します（画面 3-5-3）。

   

   画面 3-5-3 SQL Server をシングルユーザーモードで起動

3. Restore ステートメントを使用して master データベースのバックアップから復元します。

   　→表 3-5-1 の構成要素のうち、 BeforeDatabase 、 NWtraders\carl 、 carl 、 masterbak 、 msdbbak が認識できるようになります。

4. （SQL Server を通常モードで起動し） msdbbak から msdb データベースを復元します。

   　→表 3-5-1 の構成要素のうち、 JobA 、 DTSPackA が認識できるようになります。

5. AfterDatabase データベースをアタッチします（画面 3-5-4）。

   　→表 3-5-1 の構成要素のうち、 AfterDatabase が認識できるようになります。

   

   画面 3-5-4 フルデータベースバックアップ後に作成されたデータベースをアタッチ
   ページのトップへ
   

3.6 まとめ

上記のように復元方法は様々で、どこまで復元すべきかという要件も状況によってかわってきます。また復元にはトランザクションログが重要であり、トランザクションログの採取方法は復旧モデルによって決定されます。すなわち第 1 回から第 3 回までご紹介した内容はそれぞれ単独で、また運用中などに考えるべきものではなく、事前に十分な運用計画をたてるべきものだと考えます。以上、ご紹介したポイントが皆さんの運用業務に少しでもお役に立てれば幸いです。

鈴木 智行: NEC E ラーニング事業部に所属。   入社以来、インストラクタとして教育業務に従事。汎用機、 UNIX を経て、 1994 年より   マイクロソフト認定トレーナー (MCT) として、管理者向け教育を担当。 SQL Server は 4.21a から携わっており、現在は主に SQL Server 2000 に関わるデータベース教育を中心に担当。 Windows 2000 および SQL Server 2000 での MCSA , MCSE , MCDBA を取得しており、情報処理技術者試験のテクニカルエンジニア   （データベース）   も取得済。最近は MCA の 3 科目   （データベース、 OS ／ネットワーク、アプリケーション構築）   全てに合格し、 C# を勉強中。

ページのトップへ