目次


これだけはおさえたい DB2 の運用

障害回復のためのバックアップ・リカバリー

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: これだけはおさえたい DB2 の運用

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:これだけはおさえたい DB2 の運用

このシリーズの続きに乞うご期待。

バックアップ・リカバリーの概要

データベースにはビジネスに必要なデータが保管されており、万一データが失われてしまうと深刻な影響が生じます。

データが失われる原因には、ディスク障害などの物理障害や、人的ミスやアプリケーションのバグなどの論理障害があります。

さまざまな障害からデータをリカバリーするために、データベースやトランザクション・ログの定期的なバックアップが必要となります。

運用作業としては、バックアップを定期的に取得します。バックアップ取得は、シェルスクリプトなどを作成し、ジョブとして実行することで自動化している環境が多いです。

リカバリーは、障害発生時の運用作業となるため、自動化を通常行いません。その代わり、障害発生時のリカバリー手順として、コマンドレベルの詳細な手順書を作成し、有事の際に備えます。

DB2 では、以下の時点のデータに復元することができます。

  • トランザクション・ログの終わりまで (To end of logs)
  • バックアップ取得時点まで (To end of backup)
  • 任意のタイミング (Point in time)

    適切にバックアップとログが保管されていれば、障害発生の直前までデータベースをリカバリーすることができます。

この記事では、バックアップ運用のユースケースや、バックアップ・リカバリーの手順について説明することを主な目的とするため、バックアップ・リカバリーに関連する用語や仕組みなどの基礎知識については触れません。それらの情報が必要な場合には、developerWorks 記事「簡単! DB2 の運用: 第 5 回 ログと回復管理」を参照してください。

また、この記事はシングル・インスタンスの DB2 を対象としています。

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

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

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

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

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

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

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

バックアップの取得対象

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

図 2. DB2 BACKUP コマンドのバックアップ対象

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

表 1. DB2 BACKUP コマンドではバックアップされないもの
データの種別バックアップ対象 (配置場所)バックアップ取得方法
ポート番号、サービス名/etc/servicesOS コピー (ファイル・ディレクトリ単位) でバックアップ
ライセンス・ファイルインストール・ディレクトリー/license/nodelock同上
環境変数とインスタンス名ファイル/var/db2/global.reg設定値の保管
DBM 構成パラメーター~/sqllib/db2systm設定値の保管
ストアド・プロシージャー外部プロシージャーとして定義されたストアド・プロシージャーOS コピー (ファイル・ディレクトリ単位) でバックアップ
ユーザー定義関数ユーザーが定義した独自の外部関数同上
レジストリー変数~/sqllib/profile.env設定値の保管
(db2set の出力結果を保存)
プロファイルとノード情報
(AESE/AWSE/ESE エディションのみ該当)
db2nodes.cfg設定値の保管
(db2profile の出力結果を保存)
カタログ情報
(DB ディレクトリ情報・カタログ情報・ノード・ディレクトリ情報)
~/sqllib/sqldbdir (システム・データベース・ディレクトリー)
~/db2inst1/NODE0000/sqldbdir (ローカル・データベース・ディレクトリー)
LIST コマンドの出力結果を保存
db2cfexp によるエクスポート
プロファイル・レジストリー外の環境変数~/sqllib/db2profile
~/sqllib/db2cshrc
~/sqllib/.profile などの環境設定ファイル
OS コピー (ファイル・ディレクトリ単位) でバックアップ
インスタンスごとの環境設定ファイル~/sqllib/userprofile
~/sqllib/usercshrc
OS コピー (ファイル・ディレクトリ単位) でバックアップ
製品のインストール・ディレクトリー/opt/ibm/DB2製品の再インストール

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

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

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

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

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

想定するシナリオ

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

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

オンライン・バックアップ (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 <n> BUFFERS)、バッファーサイズ (BUFFER) などがあります。これらのパラメータを適宜調整することで、バックアップ処理時間を短縮することができます。デフォルトでは、DB2 により自動調整されます。

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

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

増分バックアップ

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

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

  • DB2 V9 運用管理ガイド:バックアップ・リカバリーの手順

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

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

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

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

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

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

バックアップの世代管理

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

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

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

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

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

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

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

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

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

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

DB2 機能による削除

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

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

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

図 4. 自動管理のイメージ図

バックアップの保管される世代数と保管期間は、下記の 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 バックアップ・リカバリーに関するポイントをご紹介します。

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

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

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

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

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

図 5. ストレージ装置による高速データコピー機能

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

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

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

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

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

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

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

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

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

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

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

ストレージ高速コピー機能によるバックアップ・リカバリーの詳細は、以下の資料にまとめられていますので、設計・手順について検討される際にはご一読ください。

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

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

TSM を使ったバックアップ取得

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

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

TSM を使ったバックアップの取得方法は、こちらをご参照ください。

developerWorks 記事「Use Tivoli Storage Manager to back up and recover a DB2 database

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

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

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

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

オフライン・バックアップ取得とリストアの方法は、こちらをご参照ください。

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

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

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

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

まとめ

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

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

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

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


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=992915
ArticleTitle=これだけはおさえたい DB2 の運用: 障害回復のためのバックアップ・リカバリー
publish-date=06132019