レベル: 中級 Takashi Yamamura (TKSY@jp.ibm.com), IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
2009年 01月 30日 この記事では、DB2のログと回復管理についてご紹介いたします。この記事は、DB2 V9.5 for Linux, UNIX and Windowsを前提としています。
はじめに
データベース管理システム(DBMS)において、データの整合性と回復可能性を保証することは重要なことです。DB2では、ロギングを行なうことによって、これらの要件を満たしてみます。この記事では、ログの種類、ロギングの方式、ログの二重化、ログを使用する回復管理、ログのメンテナンスについて、ご紹介させていただきます。なお、バックアップ・リカバリー運用については、参考文献「DB2セルフスタディ・キット - データベース管理」もご参照ください。
ログとは
DB2では、アプリケーションが行なうデータの挿入、更新、あるいは削除など、データベースへの変更内容をログと呼ばれるファイルに記録します。ログは、変更されるデータよりも、必ず先にディスクに書き出されます。これにより、データベースがダウンした場合においても、データベースを一貫性のある状態に回復することができます。
ログを使用する回復には、2つのリカバリー形式があります。
- クラッシュ・リカバリー
何らかの障害が発生して、データベースが停止した際に、ログ・ファイルの内容を元に、データベースを整合性の取れた状態に回復する処理です。コミットされた変更はディスクに反映し、未コミットの変更データについては取り消し（ロールバック）を行います。破損回復とも呼ばれます。
- ロールフォワード・リカバリー
バックアップ・ファイルのリストア後に、ログ・ファイルに記録された変更を適用する処理です。バックアップ取得後の変更をログ・ファイルから読み取ることで、データベースを特定時点の状態、または障害が生じる直前の状態までリカバリーします。
ログには、大きく分けて、2つの種類があります。
- アクティブ・ログ
現在使用中のログ・ファイルで、クラッシュ・リカバリーに使用されます。メモリーからディスクへの書き込みがまだ行われていない処理内容で、COMMIT済みの処理、未COMMITの処理を含みます。ユーザー操作により、削除してはいけないファイルです。
アクティブ・ログには、1次ログと 2次ログがあります。1次ログは、データベースが活動化した時点で割り振られるログ・ファイルです。2次ログは、1次ログが使いきられた際に、一時的に追加で割り振られるログ・ファイルです。通常は、1次ログ内でアクティブ・ログ・ファイルをまかなえることが望ましいです。
アクティブ・ログ・ファイルが保管される場所は、ログ・パスです。デフォルトは、データベース・パス配下に存在します。
（例）/database_path/instance_name/NODE0000/SQL0001/SQLOGDIR
ログ・パスは、NEWLOGPATH（DB構成パラメーター）で変更可能です。
（例）db2 update db cfg using NEWLOGPATH /active_logpath
- アーカイブ・ログ
クラッシュ・リカバリーには使用されないログ・ファイルで、ファイルに含まれている処理内容がすべてCOMMIT済みになり、ディスクへの書き込みが完了したログ・ファイルです。このログ・ファイルは、ロールフォワード・リカバリーで使用されます。
アーカイブ・ログには、オンライン、オフラインの 2つがあります。オンライン・アーカイブ・ログ・ファイルは、ログ・パス上に存在するアーカイブ・ログです。オフライン・アーカイブ・ログ・ファイルは、ログ・パス以外の場所にコピーされたアーカイブ・ログ・ファイルです。
図1 ログ・ファイルの種類と保管場所
アーカイブ・ログ・ファイルが保管される場所は、アーカイブ設定によって決まります。ログのアーカイブについては、「ロギングの方式」をご参照ください。
ロギングの方式
DB2では、循環ロギングとアーカイブ・ロギングの2つのロギング方式がサポートされています。ロギングの方式は、LOGARCHMETH1、LOGARCHMETH2（DB構成パラメーター）で設定します。両者のデフォルト値は OFFで、ロギング方式は循環ロギングです。
- 循環ロギング
名前の通り、ログ・ファイルを循環して使用するロギング方式です。ログ・ファイルは、そのファイルに記録されているトランザクションが終了し、かつ、ディスクに反映された場合に、再使用可能となります。循環ロギングでは、バージョン・リカバリーのみが可能です。
図2 循環ロギングにおけるログ・ファイルの使用例1
通常時は、1次ログのみが使用され、アクティブ・ログの量が1次ログを上回った場合には、2次ログが追加で使用されます。
図3 循環ロギングにおけるログ・ファイルの使用例2
循環ロギングは、以下のように設定します。
（例）db2 update db cfg using LOGARCHMETHl OFF
db2 update db cfg using LOGARCHMETH2 OFF
- アーカイブ・ロギング
ログ・ファイルをすべて保存するロギング方式です。アーカイブ・ロギングでは、データベースへ行なわれた更新がすべて保存されるため、データベースや表スペースのリストア後に、ログ・ファイルを適用して、データベースを、ある時点、またはログ・パス上にある最後のログ・ファイルまでリカバリーするロールフォワード・リカバリーを行なうことが可能です。また、アーカイブ設定によっては、ログ・パスとは別のディスク領域に、アーカイブ・ログ・ファイルをコピーすることが可能です。
図4 アーカイブ・ロギングによるログのコピー
代表的なアーカイブ設定には、以下の 3つがあります。この他に、TSMやベンダー・ライブラリーを使用したログのアーカイブも可能です。
- DISK
ユーザーが指定したパスに、ログ・ファイルがコピーされて保管されます。
- LOGRETAIN
アーカイブ・ログ・ファイルは、ログ・パス上に保管されます。
この設定は、LOGARCHMETH1のみ可能です。
- USEREXIT
USEREXITプログラムにより、ログ・パスとは別のパスにコピーされて保管されます。コピー先となるパス名は、USEREXITプログラムのソースコードで指定します。
この設定は、LOGARCHMETH1のみ可能です。
アーカイブ・ロギングは、以下のように設定します。
（例）db2 update db cfg using LOGARCHMETH1 DISK:/arch_logpath
db2 update db cfg using LOGARCHMETH2 LOGRETAIN
アーカイブの設定をDISKとした場合には、以下のネーミング・ルールでログ・ファイルを保管するためのディレクトリが作成されます。
/指定パス名/インスタンス名/データベース名/ノード名/チェーン名/
※指定パス名：LOGARCHMETHx に「DISK:」の後に指定するパス名
（例）インスタンス名：db2inst1, データベース名:SAMPLE, 構成パラメーターの設定：
LOGARCHMETH1=DISK：/arclogの場合のアーカイブ先のパス名
＝/arclog/db2inst1/SAMPLE/NODE0000/C0000000
図5 ログ・チェーン
チェーン名は、ログ・シーケンスに関連したディレクトリ名です。同一チェーン名のディレクトリに保管されるログ・ファイルは、同一のログ・シーケンス上に存在するログの集合となります。最初に作成されるチェーン名は、C0000000です。ROLLFORWARDコマンドが完了する度に、番号が１つ増加したディレクトリが自動的に作成されます。（例: C0000001, C0000002, ...）
 |
ログの二重化
ログ・ファイルは、データベースの変更が記録される重要なファイルであるため、ログ・パスが配置されるディスクが障害により使用不可となり、ロギングが行えないと、DBMSは処理を継続できなくなります。
DB2では、ログ・パスに障害が発生した場合に備えて、アクティブ・ログおよびアーカイブ・ログのミラーリングを行なう機能が提供されています。また、アーカイブ・ログ・パスについては、パスが破損した場合の代替アーカイブ・ログ・パスを設定することができます。この代替パスは、フェイルオーバー・アーカイブ・ログ・パスとも呼ばれます。
- アクティブ・ログのミラーリング（MIRRORLOGPATH）
ログ・パスの二重化は、MIRRORLOGPATH（DB構成パラメーター）にパスを設定することで行なえます。ミラー・ログ・パスが設定されると、DB2は、ログ・パスとミラー・ログ・パスの両方にアクティブ・ログ・ファイルを作成します。ログ・データはすべて両方のパスに書き込まれます。ミラー・ログ・パスには、アクティブ・ログ・ファイルのセットの複製があるので、ディスク・エラーや人間によるエラーで一方のパスにあるアクティブ・ログ・ファイルが破棄された場合でも、データベースはそのまま機能し続けることができます。このパスは、ログ・パスとは別の装置に配置することが推奨されます。
アクティブ・ログのミラーリングは、以下のように設定します。
（例）db2 update db cfg using MIRRORLOGPATH /mirror_logpath
- アーカイブ・ログのミラーリング（LOGARCHMETH1, LOGARCHMETH2）
アーカイブ・ログ・パスの二重化は、LOGARCHMETH1、LOGARCHMETH2の両者にパスを設定することで行なえます。それぞれの構成パラメーターに設定されたアーカイブ設定で、アーカイブ・ログ・ファイルが保管されます。両者のパスは、別の装置に配置することが推奨されます。
アーカイブ・ログのミラーリングは、以下のように設定します。
（例）db2 update db cfg using LOGARCHMETH1 DISK:/arch_logpath1
db2 update db cfg using LOGARCHMETH2 DISK:/arch_logpath2
- 代替アーカイブ・ログ・パス（FAILARCHPATH）
代替アーカイブは、FAILARCHPATH（DB構成パラメーター）にパスを設定することで行なえます。指定可能な装置は、ディスクです。代替アーカイブ・ログ・パスが設定されると、DB2は、LOGARCHMETH1、LOGARCHMETH2で設定されるパスへのログ・アーカイブが一定回数分、失敗した場合に、このパスにログ・ファイルをコピーします。代替アーカイブ・ログ・パスは、アーカイブ・ログ・パスとは別のディスクに配置することが推奨されます。
代替アーカイブは、以下のように設定します。
（例）db2 update db cfg using FAILARCHPATH /fail_arch_logpath
|
ログの適用（ロールフォワード）
障害発生によって、データベースが破損した場合には、日々の運用で取得しておいたバックアップ・ファイルを使用してのリカバリーを行ないます（バックアップのリストア）。このリカバリーでは、バックアップを取得した時点までのデータベースの状態へのリカバリーは可能です。さらに、バックアップ取得後に行なわれた変更処理を反映するためには、ログを適用したリカバリーを行ないます（ロールフォワード・リカバリー）。これは、バックアップ取得後に発生した更新処理については、バックアップ・ファイルには含まれないためです。ログ・ファイルが存在すれば、データベースへの変更記録があるため、データベースを直近までリカバリーすることが可能となります。
ここでは、オンラインで取得したデータベースのバックアップからのリカバリーを考えてみましょう。想定する環境は、図6にあるように、アーカイブ・ロギング・モードでデータベースを運用しているシステムで、データベースのバックアップを週に１度、アーカイブ・ファイルのテープへの移動を日次で行なっている環境とします。
図6 データベースのバックアップ運用例
- 週に1度、日曜日に、データベースのオンライン・フル・バックアップを取得する。
- バックアップは、ディスク上に取得する。1世代をディスク保管して、2世代以降は、テープ移動して保管する。
- ログのアーカイブは、LOGARCHMETH1=DISKの形式で行なう。
- アーカイブ・ログ・ファイルは、1日分をディスク上に保管して、2日目以降はテープに移動して保管する。テープへの退避は、日次で行なう。
このデータベースで、水曜日のシステム稼働中に障害が発生して、データベースのリストアからリカバリーを行なうことになったとします。最新の状態まで戻すことがリカバリーの要件である際の手順は、以下の通りです。
- リカバリーに必要なログ・ファイルの確認
- ディスク上に存在するログ・ファイルの確認
- テープからのログ・ファイルのコピー・バック
- データベースのリストア
- ログの適用
図7 バックアップからのリカバリー
- リカバリーに必要なファイルの確認
リカバリーを行う際に必要となるファイルは、バックアップ･ファイル、ログ・ファイルです。必要となるログ・ファイルは、データベースをどこまでの時点に回復するかによって決定されます。今回は、最新の状態までのリカバリーが要件ですので、障害発生前までのログ・ファイル（日～水）が必要です。
オンライン・バックアップでは、リカバリーに最低限必要なログが存在します。これは、バックアップ取得中にデータベースへの更新が可能なためです。バックアップ取得中にデータベースに行なわれた更新内容を反映するため、RESTOREコマンド実行後に、ROLLFORWARDコマンドによるログの適用を必ず行ないます。この際、リカバリーに必要となるログ・ファイルの番号は、以下のコマンドで確認できます。
（例）db2 list history backup all for db <database-alias>
なお、オンライン・バックアップのリカバリーに必要なログ・ファイルは、バックアップ取得時にINCLUDE LOGSのオプションを指定することによって、バックアップ・ファイルに含めることができます。
（例）db2 backup database <database-alias> online to <backup-directory> include logs
- ディスク上に存在するログ・ファイルの確認
手順1で確認したログ・ファイルのうち、ログ・パス、またはアーカイブ・ログ・パスに存在するログ・ファイルを確認します。今回は、アーカイブ・ログ・ファイルは、日次でテープ保管しているため、ディスク上に存在するものは、水のみです。
- テープからのログ・ファイルのコピー・バック
手順1で確認したリカバリーに必要なログ・ファイルのうち、ディスクではなく、テープで保管されているファイルを、ディスク上のログ・パス、もしくは任意のディレクトリ（temp-directory）へコピー・バックします。一定期間経過後のアーカイブ・ログ・ファイルの保管をディスクとは別の媒体に移動して行なう運用では、リカバリーに必要なログ・ファイルがディスク上に存在しない状況も十分考えられます。今回は、アーカイブ・ログ・ファイルは、日次でテープ保管しているため、テープに存在する日～火のログ・ファイルを、ディスク上の任意のディレクトリ（temp-directory）にコピー・バックします。
図8 ログ・ファイルのコピー・バック
- データベースのリストア
リカバリーに必要なログ・ファイルをディスク上に配置されたことを確認しましたら、いよいよ実際のリカバリーを開始します。まず初めに、データベース・バックアップをRESTOREコマンドで復元します。
（例）db2 restore db <database-alias> from <backup-directory>
- ログの適用
次に、ログの適用を、ROLLFORWARDコマンドで行ないます。最後のログ・ファイルまでを適用する場合には、to end of logsオプションを使用します。overflow log pathオプションを使用することで、ROLLFORWARDコマンド実行時に任意のディレクトリから、ログ・ファイルを読み込ませることができます。
（例）db2 rollforward db sample to end of logs overflow log path (<temp-directory>)
db2 rollforward db <database-alias> stop
上記 2つのROLLFORWARDコマンドは、以下のように1つのコマンドで実行することも可能です。
（例）db2 rollforward db sample to end of logs and stop overflow log path (<temp-
directory>)
今回は、データベースを最新の状態までリカバリーしたため、最後のログまでの適用を行ないましたが、DB2では、他にも 2つの時点までリカバリーを行なうことができます。
- 指定時間までのリカバリー
（例）db2 rollforward db <database-alias> to <timestamp> using local time
<timestamp>の形式は、yyyy-mm-dd-hh.mm.ss (年、月、日、時、分、秒)です。時間を指定した場合、協定世界時(UTC :Coordinated Universal Time)の設定になっているため、using local timeのオプションを選択するか、ローカル時間との差分を修正して時刻を指定して下さい。バックアップ・ファイルのタイム・スタンプはローカル時間に基づいています。
- 最小回復時間までのリカバリー
（例）db2 rollforward db <database-alias> to end of backup
to end of backupオプションは、DB2 V9.5から使用可能なオプションで、最小回復時間（データベースが整合状態となる最も早い時間）へのロールフォワード・リカバリーを可能とします。オンライン・バックアップでは、バックアップ取得時点にリカバリーされます。
|
ログのメンテナンス
ロギングの方式を、アーカイブ・ロギングとした場合には、ログ・ファイルはすべて保存されます。しかしながら、リカバリーで使用されるのは、個々のケースに応じた一部のログ・ファイルで、リカバリーで使用されない古いログ・ファイルは必要ありません。また、多くのログ・ファイルを保管すれば、その分だけのディスク領域が使用されてしまいます。そのため、リカバリーに不要なログ・ファイルを定期的に削除する運用が必要です。
では、削除しても良いログ・ファイルとは、どのようなファイルなのでしょうか。想定されるリカバリー・ケースによって違いはありますが、単純に考えれば、保管されている最も古い世代のバックアップをリカバリーするために必要とされないログ・ファイルと言うことができます。具体的には、LIST HISTORYコマンドの出力で、最も古いバックアップに関する履歴情報にあるEarliest Logよりも古い番号のログ・ファイルです。
DB2 V9.5では、アーカイブ・ログ・ファイルの削除メンテナンスを、DB2で自動的に実行する機能も提供されています。この機能を使用すると、DB構成パラメーターの設定のみで、アーカイブ・ログを含む回復オブジェクトの削除メンテナンスの仕組みを構築することができます。ユーザーが設定したバックアップの保管世代数（NUM_DB_BACKUPS DB構成パラメーター）、回復履歴ファイルの保持期間（REC_HIS_RETENTN DB構成パラメーター）に応じて、バックアップに関連する回復オブジェクト（バックアップ・ファイル、アーカイブ・ログ・ファイル、ロード・コピー・ファイル）の削除、および回復履歴ファイルのメンテナンスが行なわれます。詳細については、参考文献「DB2 9.5 技術資料 導入と管理機能の強化 - 第2章 管理機能強化 - 回復オブジェクトの自動削除」をご参照ください。
ログの削除は、PRUNE HISTORYコマンドを使用して行なうことも可能です。このコマンドは、回復履歴ファイルの情報を削除するコマンドで、AND DELETEオプションを指定して実行されると、ログ・アーカイブの実行履歴が削除される際に、対応するアーカイブ・ログ・ファイルの削除が行なわれます。
（例）db2 prune history <timestamp> and delete
<timestamp>の形式は、yyyymmddhhmmss (年、月、日、時、分、秒)で、指定されたタイム・スタンプより、以前にアーカイブされたログ・ファイルが削除されます。
おわりに
この記事では、データベース管理システム(DBMS)において、データの整合性と回復可能性を保証する仕組みとして、ログと回復管理についてご紹介させていただきました。なお、DB2では、さらに豊富なバックアップ、リカバリーの機能も提供されておりますので、それらにつきましては、参考文献をぜひご参照ください。
参考文献
著者について | | | Takashi Yamamura, IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 |
記事の評価
| 
