SQL Serverに構築されたユーザデータベースのバックアップとリストア（復元）手順については、もうご理解頂けたと思います。連載最終回の今回は、見落としがちなシステムデータベースのバックアップと、データベースサーバーの再構築についてお話したいと思います。

SQL Serverのデータベースサーバーの中には、master,msdb,model,tempdb という名前のシステムデータベースがあります。

Enterprise Managerの登録プロパティで、図1のように、「システムデータベースとシステムオブジェクトの表示」のオプションをチェックしてください。システムデータベースが画面に表示されます。


図1：システムデータベースとシステムオブジェクトの表示

masterデータベースは、データベースサーバーシステム全体を統括管理します。非常に重要なデータを記憶するデータベースです。

masterデータベースが損傷を受けると、データベースサーバーの正常な運用ができません。

msdbデータベースは、SQL Server Agent によるジョブ管理のデータや、DTSパッケージを管理するデータなどが記憶されます。masterデータベースに次いで重要なシステムデータベースです。

modelデータベースは、新しいユーザデータベースを新規に作成するときの、雛形となるデータベースです。modelデータベースの中にデータベースユーザやテーブルやストアドプロシージャなどを作成すると、新しく作成されたデータベースにそれらがコピーされます。

tempdbデータベースは、システムの作業用データベースです。SQL文をシステムが実行するときに作業用テーブルが作成されたり、ローカルテーブルやローカルストアドプロシージャなどが記憶されます。但しtempdbデータベースは、データベースサービスが起動するたびに初期化されますので、永続的な記憶を行なうことはできません。

このほかに、サーバーをレプリケーション ディストリビュータとして設定したときは、distributionデータベースもシステムデータベースとして作成されます。

tempdbデータベースを除く、master,msdb,modelデータベースがバックアップ対象となるデータベースです（本稿では、レプリケーションを行なっていないので、distributionデータベースは除いております）。

masterデータベースだけは、全体バックアップ命令だけが許されます（差分バックアップやトランザクションログバックアップはできません）。

システムデータベースの内容を更新したらシステムデータベースのバックアップを実行するのが基本です。

しかしどのようなデータベースサーバー操作を実行するとシステムデータベースが更新されるのか、それを理解するのは大変なことです。もちろんSQL Server のデータベースサーバー管理者を目指す人は、システムデータベースの役目を詳細に理解することは大事なことです。しかし初心者の私達にとっては、それは難しいことになります。

そこでユーザデータベースのバックアップと同様に、システムデータベースも定期的にバックアップの対象に含めて、自動実行ジョブを作成しましょう。

中小規模のデータベースサーバーでは、システムデータベースが巨大な大きさになることはありません。そこでバックアップ手法は、全体バックアップで行ないます。

バックアップを行なうタイミングは、データベースサーバー管理者がEnterprise Managerでサーバー管理業務を終える頃が最適ですが、時間を定めることはできないと思います。

ですから適度に、

午前9時から午後9時までの3時間間隔

とか、あるいは6時間間隔とか、バックアップを実施します。

ユーザデータベースと違ってシステムデータベースは、データ更新頻度はあまり激しくありません。このため1日に1回から数回、場合によっては数日に1回とか、バックアップを行なう頻度を下げることも許されます。データベースサーバーの運用状況に合わせてバックアップ計画を考えてください。

またユーザデータベースをバックアップするついでにシステムデータベースのバックアップも一緒に実施することでもよいと思います。

backup database master

to disk='D:\BACKUP\master.bak' with init

backup database msdb

to disk='D:\BACKUP\msdb.bak' with init

backup database model

to disk='D:\BACKUP\model.bak' with init

上記のようなシステムデータベースをバックアップするSQL文を適度に実行してください。with initオプションで、バックアップファイルを上書き更新しておりますが、過去の履歴を保存したいときは、with initオプションを外します。

意外と盲点になるのが、システムデータベースの物理ファイルのコピーを忘れていることです。

SQL Server の運用上の注意点として、データベースサーバーが壊れたときのシステムデータベースの復旧は、物理ファイルから行なうことがあります。このため各システムデータベースのデータファイルとトランザクションログファイルはコピーして保存しましょう。

また、SQL Serverのサービスパックを当てた時は、システムデータベースの物理ファイルがサービスパックによって更新されます。更新された物理ファイルを忘れずにコピーしてください。

それでは、データベースサーバーの物理ファイルが破壊を受けたときの復元について、一番簡単な方法を説明します。

ユーザデータベースの復元は、Backup Database文でバックアップされたファイルから復元することができるので、特に問題はありません。

master,model,msdb,tempdbなどのシステムデータベースが壊れると、データベースサーバーの正常な起動ができません。データベースサービスが開始されずに、異常終了します。

このような場面に遭遇したら、一番簡単に対処する方法としては、システムデータベースの物理ファイル（データファイルとトランザクションログファイル）のコピーをまず元の場所に戻します。

本来であれば、どのシステムデータベースが壊れたのかを調べて、該当する物理ファイルを戻すのがよいのですが、それがわからないときは、すべてのシステムデータベースの物理ファイルを戻してもよいでしょう。

ここでシステムデータベースの物理ファイルを正しくコピーしていることが条件になります。SQL Server のサービスパックを当てた時は、当てた後のシステムデータベースの物理ファイルのコピーが必要です。

このようにシステムデータベースの物理ファイルをコピーしたら、SQL Server のデータベースサービスを開始させることができます。

システムデータベースの物理ファイルをコピーしてデータベースサービスが立ち上がったら、最新のシステムデータベースのバックアップファイルを復元します。

コピーした物理ファイルが直近のものであれば、何も作業をする必要はありません。しかし、何ヶ月も前の古いシステムデータベースの物理ファイルのコピーを使用したときは、システムデータベースの復元が必要です。

システムデータベースの復元は、masterデータベースとそれ以外のデータベースでは方法が異なります。

［masterデータベースの場合］

最新のmasterデータベースの内容を復元するときは、データベースサービスの開始をコマンドプロンプトから行なう必要があります。

図2のように、カレントディレクトリ位置を変更し、sqlservr.exeコマンドを入力します。-cと-mスイッチを付けて起動します。

図2：シングルユーザモードでデータベースサービスを開始する

-cスイッチは、コマンドプロンプトからデータベースサービスの起動を行なうことを表し、-mスイッチは、シングルユーザモードで起動します。

データベースサービスが起動したら、もう1つ別のコマンドプロンプトを起動します。

osqlコマンドを図3のように入力し、masterデータベースを復元します。データベースが復元されるとデータベースサービスは自動的に停止します。データベースサービスを再起動したときに、masterデータベースは新しく更新されます。

図3：masterデータベースの復元

［model,msdbシステムデータベースの場合］

その他のシステムデータベースの復元方法は、一般ユーザデータベースとまったく同じです。

C:\Program Files\Microsoft SQL Server\MSSQL\Binnの中に、rebuildmコマンドがあります。このコマンドはmasterデータベースの再構築と呼ばれます。

このコマンドは、masterデータベースが損傷を受けたときに、図4のデータベースファイルセットから初期データベースの環境を構築することができます。図4からわかるように、システムデータベースではmaster,model,msdbの物理ファイル、そしてデモ用データベースとして提供されたpubs,northwnd物理ファイルが必要となります。

図4：rebuildmコマンドで読み込まれるファイル一覧

これらデータベースの最新の物理ファイルをいつでも手元に持っておけば、たとえデータベースサーバーが壊れても、rebuildmコマンドを使ってデータベースサーバーの初期環境を構築することができます。

さらにrebuildmコマンドでは、図5のように、データベースサーバーの照合順序を変更することができます。ただSQL Server 2000 では、照合順序指定はサーバー環境を変更しなくても個別データベース内部で考慮できるようになりましたので、このrebuildmによる照合順序指定の変更を行なう必要性は薄れました。これはSQL Server 7の名残です。

図5：照合順序の指定

データベースサーバーの構築や、rebuildmコマンドの動作からもわかるように、システムデータベースでは、物理ファイルそのものをコピーして保存することが大事です。

本連載の学習のまとめ