DB2 のバックアップ
データベース全体をバックアップするか、特定の表スペースをバックアップすることができます。これにより、テープや別のサーバなどの別のメディアに、データベースまたは表スペースのコピーが作成されます。使用する復元ログの種類によっては、データベースを実行中にバックアップすることができます。
DB2 for z/OS のジオデータベースをバックアップするときは、ジオデータベースを構成するデータベース サブシステム内のすべてのデータベースをバックアップする必要があります。これは、最低でもジオデータベース リポジトリを格納するデータベースおよびユーザ定義データを格納するデータベースの 2 つがあります。
DB2 バックアップ タイプの概要を以下に示します。詳細な情報については、DB2 向けのバックアップおよびリカバリに関するマニュアルをご参照ください。マニュアルは次のとおりです。
『データ・リカバリと高可用性ガイドおよびリファレンス』
DB2 バージョン 9.7 for Linux、UNIX、および Windows の英語マニュアル
-
オンライン バックアップ
データベース インスタンスの実行中に DB2 データベースをバックアップすることを、オンライン バックアップと呼びます。オンライン バックアップを実行する予定がある場合は、アーカイブ ログを使用する必要があります。そのためには、ロールフォワード(roll-forward)リカバリ オプションを有効にする必要があります。また、データベースでロールフォワード オプションを有効にした後、データベースを再起動する必要があります。さらに、ロールフォワード オプションを有効にした後、オンライン バックアップを実行する前に、オフライン バックアップを少なくとも 1 回実行する必要があります(次のセクションをご参照ください)。
データベースは実行中なので、バックアップを実行している間も、ユーザはデータベースに接続することができます。バックアップ中にデータベースに加えられた変更は、ログに記録されます。
ヒント:ArcSDE サービスを使用している場合、オンライン バックアップを実行する前に ArcSDE サーバ プロセス(giomgr)を終了する必要はありません。
オンライン バックアップの詳細については、使用している DB2 リリースのドキュメントをご参照ください。
-
オフライン バックアップ
データベース インスタンスを終了している間に DB2 データベースをバックアップすることを、オフライン バックアップと呼びます。バックアップ中にユーザがデータベースに接続することはなく、データベースが変更されることはないので、オフライン バックアップの管理はオンライン バックアップよりも単純で、エラーも少ない傾向にあります。
データベースをオフラインにする前に、ArcSDE サービスなど、データベースにアクセスするサービスをすべて停止する必要があります。
循環ログを使用する(データベースがリカバリ不能である)場合は、オフライン バックアップが唯一の選択肢となります。アーカイブ ログを使用する場合は、オフライン バックアップまたはオンライン バックアップを使用することができます。
DB2 データベースの完全バックアップは定期的に実行する必要があります。完全バックアップでは DB2 データベースをバックアップし、ArcSDE サービスを起動している場合は、giomgr.defs、dbinit.sde、services.sde ファイルもバックアップしてください。
-
増分バックアップ
データベースのサイズが増えるにつれ、データベースの完全バックアップにかかる時間も増えていきます。データベースの完全バックアップの実行回数を減らすために、1 つの完全バックアップ イメージと複数の増分バックアップを作成することができます。増分バックアップには、最後のバックアップ以降に更新されたページと、初期データベースのすべてのメタデータだけが含まれます。DB2 では、累積バックアップとデルタ バックアップの 2 種類の増分バックアップ イメージを使用します。累積バックアップ イメージは、最後に成功した完全バックアップ以降に変更されたすべてのデータベース データのコピーです。累積バックアップ イメージには、ある期間内に実行された一連の増分バックアップが含まれています。したがって、前の増分バックアップ イメージが含まれています。デルタ バックアップ イメージは、最後に成功した完全、累積、デルタ バックアップ以降に変更されたすべてのデータベース データのコピーです。デルタ バックアップ イメージは、差分バックアップ イメージまたは非累積バックアップ イメージとも呼ばれます。
バックアップ イメージを作成するには、BACKUP DATABASE コマンドを使用します。このコマンドは、実行されたデータベース パーティションにのみ適用されます。BACKUP DATABASE コマンドを実行するには、データベースの sysadm、sysctr、または sysmaint 権限が必要です。
BACKUP DATABASE コマンドを使用する際には、バックアップ イメージを保存するディレクトリを指定することができます。この保存先には、ディレクトリ、デバイス、または他のサーバを指定することができます。コマンドに保存先を指定しない場合、バックアップ イメージはコマンドを実行したディレクトリに保存されます。
バックアップを実行するデータベースは、ローカルのデータベースでも、リモート サーバ上のデータベースでもかまいません。サードパーティの格納管理アプリケーションを使用している場合を除き、バックアップ イメージはデータベースのサーバ上に保存されます。
BACKUP DATABASE コマンドの実行を開始すると、データベースに対してバックアップ操作のための接続が確立されます。すでにデータベースに接続している場合、その接続はバックアップ用の接続が確立される前に切断されます。バックアップが完了すると、バックアップ用の接続は切断されます。
バックアップが正常終了した場合は、バックアップ イメージのタイム スタンプを含んだメッセージが表示されます。このタイム スタンプにより、各バックアップ イメージが一意に識別されます。
DB2 データベースをバックアップするには、オフライン ディレクトリに以下のファイルをコピーする必要があります。
- データ ファイル
- services.sde ファイル(ArcSDE サービスを使用している場合)
- 復元ログ ファイルのアーカイブ
データ ファイルを古い状態から新しい状態に移行させるには、データベース復元ログ ファイルが不可欠です。推奨オプションであるロールフォワードを使用する場合、データベースのリカバリを成功させるには、復元ログにある期間の履歴がすべて記録されている必要があります。
データベースのリカバリが必要と思われる時点までのすべての復元ログのアーカイブを、少なくとも 2 つ保管しておくことが推奨されます。2 つのコピーは、物理的に分かれているメディア(2 つのディスク ドライブなど)か、ディスク ドライブとテープ ドライブに保存します。ログをミラー化することにより、復元ログのコピーを別に保管することもできます。
アーカイブされた復元ログ ファイルをディスク上から削除する予定である場合は、その前に、アーカイブされた復元ログ ファイルのバックアップ コピーをもう 1 つ作成してください。
アーカイブされた復元ログ ファイルのバックアップが複数あると、思いのほか頻発する複数のメディアの破損に対する備えも万全です。たとえば、テープ ドライブからビット エラーが検出された場合、ファイルをリカバリしようとしても手遅れでしょう。
バックアップごとに各データ ファイルを 1 つコピーしておくだけで済むのは、万一のために、アーカイブされた復元ログのコピーを複数保管している場合だけです。
DB2 コントロール センターの自動保守の構成ウィザードを使用して、バックアップなどの保守作業の種類と、それらをいつ実行するかを設定できます。ウィザードを使用して、保守作業の目的と、保守作業を実行できるタイミングを指定します。DB2 はこの情報に基づいて、保守作業が許可されている次の期間内に、保守作業が必要かどうかと、それらをいつ実行するかを判断します。
保守作業の種類と時間を設定することに加えて、エラー メッセージを特定の受信者に送信するための通知メールを設定することもできます。
データベースの保守作業が自動化されている場合でも、バックアップ操作を手動で行うことができます。
また、DB コントロール センターのバックアップ ウィザードを使用して、データベース オブジェクト、パーティション、またはデータベース全体のバックアップを作成することもできます。