【TF】【IM】これだけはおさえたい Db2 の運用: 障害回復のためのバックアップ・リカバリー

バックアップの取得パターン

Db2 のバックアップ取得方法は、図のフローチャートに示す検討項目に基づいて決定していきます。

1. データの復元の必要性からバックアップ取得の必要性を判断する
2. バックアップ取得が必要な場合、バックアップ取得可能なオフライン時間が確保できるかどうか判断する
3. オフライン時間が確保できず、データベースのサイズがあまり大きくない場合には、オンライン・バックアップを取得する
4. オフライン時間が確保できず、データベースのサイズが大きい場合は、可能な環境であればストレージ装置による高速コピー機能を利用しバックアップ取得を行う
5. ストレージ機能が利用できない場合は、必要に応じて、表スペース単位のバックアップ取得や、差分バックアップを利用することによりバックアップ・イメージのサイズを抑えるなどの調整を検討する

典型的なバックアップ取得パターン

昨今では 24 時間 365日サービス継続を行うお客様が多く、そういったお客様環境では、データベース・サービスを止めずにオンラインでバックアップを取得する方法が選択肢となります。

具体的には、Db2 の BACKUP コマンドでオンライン・バックアップを取得するか、特にサイズが大きいデータベースである場合には、ストレージ装置の提供する機能 (たとえば、IBM の DS シリーズでは FlashCopy) によるオンライン・スプリット・ミラーの利用を検討します。オンライン・スプリット・ミラーについては、後続の章「オンライン・スプリット・ミラー」でも概要を説明します。

この記事では、データベース全体のオンライン・バックアップと、リカバリーの手順を解説します。次節の「オンライン・バックアップとリカバリーの手順」にて、具体的な手順とコマンド実行例とを紹介します。

バックアップの取得対象

Db2 の BACKUP コマンドにより取得されるものは図に示すとおりです。

BACKUP コマンドにより取得されないもの表 1 に示すとおりで、これらのオブジェクトについては別途、管理者がバックアップする必要があります。

表 1. Db2 BACKUP コマンドではバックアップされないもの

バックアップ・イメージにはインスタンスを復元するための情報は含まれません。ディスクが破損しインスタンス障害が発生した場合には、インスタンスの再作成にて復旧することができます。

データベースについてはバックアップ・イメージがあればリストアにより復旧することが出来ますが、バックアップ・イメージに含まれない DBM 構成パラメーター値などについては、db2support 出力や db2look 出力、個別にバックアップ保存されている構成ファイル、設計書などを参照し、再度設定を行います。

db2support、db2look コマンドの利用方法についてはこちらをご参照ください

[Db2 LUW] db2look コマンドの実行方法
[Db2 LUW] db2support の取得手順 (Linux/UNIX 版)

オンライン・バックアップとリカバリーの手順

フローチャートに示したうち、一般的に利用されることの多いオンライン・バックアップについて、具体的なバックアップの取得方法ならびにリカバリー方法を説明します。

想定するシナリオ

ここから示すバックアップ・リカバリーの手順は、以下のシナリオを想定します。

• DB データが格納されているディスクが破損したため、新しいディスクに入れ替えた
• トランザクション・ログが格納されているディスクと、バックアップ・イメージが配置されたディスクは問題なく利用できる状況である
• 障害が発生する直前の時点まで DB 全体のオンライン・バックアップを使用してデータベースを復旧する
  

オンライン・バックアップ (Db2 BACKUP コマンド) のポイント

バックアップ取得中に行われた更新処理のうち一部については、バックアップされる表のディスク領域には反映されず、トランザクション・ログには記録された状態となっています。バックアップ・イメージをリストアした後、バックアップ取得中の処理内容を含むログを適用することで、バックアップ取得完了時点のデータに復元することができます。

BACKUP コマンドの INCLUDE LOGS オプションを指定することで、データベースのバックアップ本体とトランザクション・ログを合わせた形でバックアップを取得することができます。シングル・インスタンスの Db2 では INCLUDE LOGS オプションはデフォルトで付与されるようになっているため、コマンド実行時に明示的に指定する必要はありませんが、以下のコマンド実行例では明示的に表記 しています。

また、トランザクション・ログの内容が必要とされることから、アーカイブ・ログ方式で運用されていることがオンライン・バックアップをおこなう前提となります。

バックアップ取得方法

1. データベースのバックアップを取得します。

   BACKUP DATABASE <db_name> ONLINE TO <target_directory> INCLUDE LOGS
   

戻し方

1. サービスを停止し、データベースに接続しているアプリケーションを切断します。

   FORCE APPLICATIONS ALL
   

2. データベースを非活動化します。

   DEACTIVATE DATABASE <db_name>
   

3. リストアしたいバックアップ・イメージが正しいディレクトリー上に配置されていることを確認します。

4. データベースをリストアします。

   RESTORE DATABASE <db_name> FROM <source_directory> TAKEN AT <yyyymmddhhmmss>
   

5. ロールフォワード (ログ適用) を行います。

   ROLLFORWARD DATABASE <db_name> TO END OF LOGS AND STOP
   

補足: DB サーバー上にロールフォワードに必要となるログが残存していない場合は、ログバックアップ・イメージからログ・ファイルを抽出します。

RESTORE DATABASE <db_name> LOGS FROM <source_directory> TAKEN AT <yyyymmddhhmmss> LOGTARGET <log_extract_directory>

※ロールフォワード処理には、トランザクション・ログが必要です。万一トランザクション・ログが破損している場合には、バックアップ・ファイルに含まれるトランザクション・ログを事前に抽出した上でロールフォワードを実行します。サーバー上のトランザクション・ログが利用可能な状態であれば、ログ抽出を行う必要はありません。

Db2 バックアップ取得を最適化するためのヒント

以下にご紹介するオプションにより、Db2 のバックアップ取得 (Db2 BACKUP コマンド) にかかる処理時間や、必要なディスク容量をより低減させることができます。

バックアップ取得を高速化するための Db2 BACKUP コマンド・オプション

Db2 バックアップ取得の処理速度に影響するオプションとして、並列度 (PARALLELISM)、バッファー数 (WITH BUFFERS)、バッファーサイズ (BUFFER) などがあります。これらのパラメータを適宜調整することで、バックアップ処理時間を短縮することができます。デフォルトでは、Db2 により自動調整されます。

また、ディスク I/O がボトルネックとなる場合には、バックアップ・イメージの出力先のディスクを分けることでバックアップ処理を高速化することもできます。

バックアップ処理の高速化については製品マニュアルに詳しく解説されていますので、バックアップ運用について計画される際にご参照ください。

• IBM Documentation: バックアップのパフォーマンスの最適化

増分バックアップ

大規模なデータベースの場合、データベース全体のバックアップを取得するために大容量のストレージが必要になります。大規模データベースであり、かつ、データの更新量があまり多くない場合では、毎回、データベース全体のバックアップを取得するのは効率的ではありません。増分バックアップを行うと、前回のバックアップ以降に更新されたページだけを含むバックアップ・イメージを取得することができます。

増分バックアップの取得ならびに復元の方法は、こちらをご参照ください。

• IBM Documentation: 増分バックアップおよびリカバリー

表スペース単位のバックアップ

表スペースのバックアップとは、データベース全体ではなく指定した表スペースのみバックアップ対象とするものです。処理時間は、データベース全体に対する操作よりも短くなります。また、リカバリーでは特定の表スペースを復旧すればよいため、他のデータ領域に対するユーザーアクセスに影響を与えることがありません。データベース全体を取る時間は取れないものの、一部はバックアップを取得したい場合に選択する方法です。たとえば、顧客データと受発注データを異なる表スペースに配置している環境で、受発注データの配置されたディスクに障害が起きたような場合に備えて、バックアップを取得したい場合などに便利ですが、障害発生時のリカバリーの手順が複雑になるデメリットもあります。

表スペース単位で行うバックアップ・リカバリーのヒント・考慮点などの情報につきましては、製品マニュアルもあわせてご確認ください。

• IBM Documentation: 表スペースにおける変更のロールフォワード

バックアップ・イメージの圧縮

データベースのバックアップ取得時に、COMPRESS オプションを指定することでバックアップ・イメージの圧縮を行うことができます。これにより、バックアップ・イメージの保管に必要なディスク容量を削減することができます。考慮点としては、バックアップ時の CPU 使用率が若干高くなることや、バックアップ取得時間も長くなることといった影響が生じるため、本番業務への適用にあたり差障りが無いことを事前にご確認ください。

データ圧縮についての詳細は、製品マニュアルをご参照ください。

• IBM Documentation: バックアップ圧縮

バックアップの世代管理

前節「オンライン・バックアップとリカバリーの手順」で説明した通り、万が一障害が発生しても、バックアップ・イメージとトランザクション・ログがあれば、データベースを復元することができます。裏を返すと、バックアップ・イメージやトランザクション・ログが失われてしまうと、データベースを復元することができません。よって、Db2 のバックアップ・イメージとログを配置するストレージ装置を二重化する等の手段により、万一の障害発生時にもこれらのファイルが失われることが無いよう配慮する必要があります。さらに災害対策まで考慮する場合には、バックアップ・イメージとログとを遠隔地で保管することもあります。

1. バックアップイメージとログの管理

リカバリーの際には、バックアップ・イメージと、トランザクション・ログの両方が必要となります。そのため、バックアップ・イメージとログは、セットで保管しておきます。

高可用性や、災害対策を目的としてバックアップ・イメージを別ロケーション/別ストレージ装置に退避する場合には、バックアップ取得後のタイミングで、バックアップ・イメージのコピーを実施します。トランザクション・ログ (アーカイブ・ログ) についても、バックアップ・イメージと同じタイミングで別ディスクへコピーすることが一般的ですが、更新処理量が多く、出力されるログがディスクに収まらないような場合などでは、ログをより頻繁に別ディスクに退避しておきます。

2. バックアップの世代管理方法

時間経過とともに、バックアップ・イメージやアーカイブ・ログは増え続けるため、世代管理として、保存世代数を過ぎたバックアップ・イメージの削除を行います。

削除するバックアップ・イメージより古いアーカイブ・ログについても、バックアップ・イメージとあわせて削除します。

バックアップの世代管理の方法としては、Db2 の自動削除機能を用いるか、手動での削除を行います。

Db2 BACKUP コマンドの出力先に作成されたバックアップ・イメージや、Db2 パラメータで指定された場所に出力されたアーカイブ・ログについては、Db2 自動削除機能による世代管理を行うことができます。

しかし、Db2 自動削除機能では、管理者により別ロケーションに退避されたファイルなどについては削除できないため、手動での削除の仕組みが必要です。一般的には、シェルスクリプトなどで、最も古い世代を判別し削除するよう実装します。

Db2 機能による削除

Db2 BACKUP コマンドを用いてバックアップ取得を行う場合、パラメーターにて事前に定義された保管世代数、期間を超えた分は自動削除を行う仕組みが提供されています。

世代管理のための作業を行うワークロードを低減できるメリットがあるため、Db2 BACKUP コマンドを利用する環境ではこちらの方法を選択することがおすすめです。

図は、バックアップとログを 3 世代保管し、かつ、保存期間を 3 週間としたケースのバックアップの自動世代管理のイメージ図です。

バックアップの保管される世代数と保管期間は、下記の DB 構成パラメーターの設定値の組み合わせで決まります。

• AUTO_DEL_REC_OBJ : データベース・ログ・ファイル、バックアップ・イメージ、およびロード・コピー・イメージを、それらに関連するリカバリー履歴ファイルの項目が整理されるときに、削除するかどうかを指定する DB 構成パラメーター
• NUM_DB_BACKUPS : バックアップ保持数
• REC_HIS_RETENTN : バックアップ保持期間

AUTO_DEL_REC_OBJ パラメーター値が ON の場合、NUM_DB_BACKUPS と REC_HIS_RETENTN の両方の設定値 (閾値) を超え、不要と判断されたバックアップ・イメージ、アーカイブ・ログが Db2 の自動世代管理機能により削除されます。

バックアップ・イメージ、ログ・ファイルの世代管理に関わる DB 構成パラメーターの設定については、リンク先の資料に詳しく解説されています。

[Db2 LUW] ログ・ファイルのメンテナンス方法

バックアップ・リカバリーに関するヒントと考慮点

この節では、Db2 バックアップ・リカバリーに関するポイントをご紹介します。

「パックアップの取得パターン」のフローチャートには書ききれなかった考慮点について、こちらの節で説明します。

• オンライン・スプリット・ミラー (ストレージ機能による高速バックアップ)
• クラスター環境におけるバックアップ・リカバリー
• ISP(旧TSM) を使ったバックアップ取得
• オフライン・バックアップ
• バックアップ・ペンディングの回復方法

オンライン・スプリット・ミラー (ストレージ機能による高速バックアップ)

オンライン・スプリット・ミラーとは

ストレージ装置には、大容量のデータを高速でコピーする機能が提供されています。(たとえば、IBM の DS シリーズであれば FlashCopy など)

仕組みとしては、図に示すように、① ポインター情報のみのコピー、② 実データのコピー の 2 段階に分けてコピーを行います。ユーザー (DB サーバー) が待たされるのは ① の間のみとなるため、瞬時にデータコピーが完了しているように見えます。なお、② の実データコピーはバックグラウンドで行われ、データ量に応じた処理時間がかかります。

Db2 では、ストレージ装置が提供する高速コピー機能を使用して、データベースのバックアップ・コピー (スプリット・ミラー) を作成することができます。

高速コピー機能を用いて、オンラインの状態でデータベースのバックアップを取得する際の考慮点として、更新処理が絶え間なく行われている状態でバックアップ取得を行うと、データの整合性が取れなくなる可能性があります。

そこで、Db2 では、SET WRITE SUSPEND (書込み中断) /SET WRITE RESUME (書込み再開) というコマンドにより、データベースからディスクへの I/O 処理を一時的に中断してディスクの書込みの静止点を取る仕組みを提供しています。

SET WRITE SUSPEND が実行された時点で Db2 はディスクへの書込みを中断しますので、この間にバックアップ取得を開始します。図の ① の処理が完了した時点で SET WRITE RESUME を実行すれば、その後は読取/書込いずれの処理も実施可能となるため、データベース・サービスを継続することができます (図における ② の状態)。

なお、SET WRITE SUSPEND 実行から SET WRITE RESUME が実行されるまでの間では、更新処理は出来ませんがデータの読取処理は可能であり、SELECT 文などの処理は実行可能です。

高速コピー機能によるバックアップ取得を行うと、データベースに書込みができない時間が短く済むため、バックアップのためにデータベース・サービスを長時間停止することができず、データベースのサイズが大きい場合 (1テラバイトを超えるなど) に、オンライン・スプリット・ミラーが選択肢となります。

必要な装置前提についての考慮点

ストレージの高速コピー機能の利用によって、大規模データベースのバックアップ運用時間を短縮できますが、その反面、必要なコストは増加します。理由は、高速コピー機能を利用するためのストレージ・オプションの購入、データサイズの2倍のディスク容量が必要なためです。

物理設計、バックアップ運用設計についての考慮点

Db2 により利用されるディレクトリーには、ストレージ機能によるバックアップ取得対象とできるディレクトリーと、対象とするべきでないディレクトリーが存在します。これらのディレクトリーは、予め異なるファイルシステムに配置しておくべきです。

その他にも、一時表スペースをバックアップ対象とする場合にはダイレクト I/O の表スペースとなるよう予めオプションを指定しておく必要があることなど、整合性の観点から諸々の考慮点があります。

クラスター環境におけるバックアップ・リカバリー

クラスター・ソフトウェアによる高可用性構成 (アクティブ・スタンバイ) や、災害対策環境のミラーリング構成を取っている環境でも、オンライン・バックアップ、オンライン・スプリット・ミラーを取得することができます。アクティブ・スタンバイ構成においては、通常アクティブ側のデータベースのバックアップを取得します。Db2 HADR 環境では、プライマリー・データベース側でバックアップを取得する必要があります。

ISP(旧TSM)を使ったバックアップ取得

Db2 BACKUP コマンドにより作成されるバックアップ・イメージの出力先として、テープ装置を指定することができます。

直接テープにバックアップを取得することができるため、ディスク容量に限りがある環境や、高価なストレージ装置を使っている環境においてバックアップ・イメージ配置先のコストを抑制できるといったメリットがあります。

オフライン・バックアップ

オフライン・バックアップは、アプリケーションからの接続をすべて切断してバックアップを取得する方法であり、データベース・サービスの停止時間枠を確保できる場合に選択肢となります。データベースのリストアを行うことにより、バックアップ取得時点のデータを復元することができます。オンライン・バックアップとは異なりロールフォワード (ログ適用) が不要であるため、手順としては最もシンプルであることが利点です。

定常運用としてはオンライン・バックアップを取得することが多いですが、以下のような場合は、オフライン・バックアップのみが取得可能です。

• 循環ログで運用されているデータベースのバックアップを取得する場合
• バックアップ・イメージを用いて Db2 をバージョンアップする場合

オフラインでのストレージの機能を使ったバックアップについては、こちらをご参照ください。

• [AIX] Offline database backup and restore using the ESS FlashCopy product on AIX platforms
• [Windows] Offline database backup/restore using Windows ntbackup

バックアップ・ペンディングの回復方法

バックアップ・ペンディング状態になると、データ・アクセスに制限がかかるため、ペンディング状態を解消する必要があります。

具体的なバックアップ・ペンディングの回復方法は、リンク先の情報をご参照ください。

• [Db2 LUW] バックアップ・ペンディングの回復方法

まとめ

この記事では、データベースに障害が発生した場合にデータを復元するために必要なバックアップ運用についてご紹介しました。

どういったケースでどのようなバックアップ取得運用が適するかを解説し、データベース単位のオンライン・バックアップ取得とリストアを行う手順やコマンドの使い方、世代管理の方法などについてご紹介しました。

この記事の内容から、作業の流れのイメージをつかんでいただき、バックアップ運用手順を検討される際などにご活用いただければと存じます。

本シリーズのその他の記事も合わせてご参照いただくことで、Db2 をうまく稼働させるために必要な運用作業について把握することができます。

著者 内海 加奈子

参考情報

• IBM Db2 11.5 for Linux, Unix and Windows documentation
• [Db2] パスポート・アドバンテージによく寄せられる質問
• [Db2] ログ・ファイルのメンテナンス方法
• [Db2] バックアップ・ペンディングの回復方法
• [Db2] db2look コマンドの実行方法
• [DB2 LUW] db2support の取得手順 (Linux/UNIX 版)

シリーズ一覧

・これだけはおさえたい Db2 の運⽤: Db2 運⽤管理の概要編
・これだけはおさえたい Db2 の運用: パフォーマンス維持のための運用 (REORG と RUNSTATS) 編
・これだけはおさえたい Db2 の運⽤: Db2 を「⾒える化」するためのモニタリング運⽤
・これだけはおさえたい Db2 の運⽤: 障害回復のためのバックアップ・リカバリー

お断り：