目次


DB2のインクリメンタルバックアップの使用

Comments

はじめに

DB2®バージョン7.2では多くの拡張機能が追加されましたが、特にデータベースの可用性と回復可能性が改善されています。

  • オンデマンドのログ・アーカイブ
  • 分割画像からのバックアップ
  • 二重化ロギング
  • Solaris上でのVeritasクラスターのサポート

この記事では、データ・ウェアハウスの最も強力なバックアップの改善、インクリメンタルバックアップについて取り上げます。インクリメンタルバックアップはフィックスパック3で追加されました。インクリメンタルバックアップとは、変更部分だけをバックアップすることを意味しますが、ある種のデータベース環境において、そのバックアップ方針を設計する際の融通性が大きくなるという利点があります。

なぜ変更部分だけをバックアップするのか?
ワープロを使用していて、作成した文書を保存した後、小さな変更を加え、再び文書全体を保存した、というような経験がおありでしょうか? なぜそうしたか考えてみてください。もちろん、最後に加えた変更をきちんと保存しておきたいからです。リレーショナル・データベースを使用するときには、データを管理するために購入するハードウェアや、マシンとソフトウェアの操作を担当する優秀な要員は重要ですが、それよりももっと貴重なものがあります。それは、究極の財産であるデータそのものです。そのデータの保護は最も重要であり、それ以外のものはすべてオマケみたいなものです。

DB2にはDB2エンジンに固有のバックアップおよびリストア・コマンドがあります。バックアップはオフライン(データベースにユーザが接続していないとき)でも実行できるし、データベースが変更されているときにはオンラインで実行することもできます。DB2のバックアップは、DBAによって一定の間隔、たとえば毎週、毎晩、毎時間ごとに実行されるようにスケジュールされる傾向があります。「いろいろ変更が多かったから、このへんで作業を保存しておこう」というような考え方は、DB2 には適用されません(ユーザーがデータをコミットする場合は別です。ただしその場合は別のコピーが作成されません)。DB2では、各バックアップ・イメージの間で加えられた変更が、DB2ログにキャプチャーされます。これら2つのピース(バックアップ・イメージと、そのバックアップ以降のすべての作業を表すログ)は、DB2の災害時回復計画の基本的なビルディング・ブロックです。バックアップ・イメージとログは、DB2トランザクションを処理するマシンとは別の場所に保管しておけば、DB2を実行するマシンが水浸しになり、ボートの錨として使用されたとしても、データをリストアすることができます。

航海日誌(Captain's log)
バックアップ・イメージとログという概念は、倉庫で使用される在庫管理システムのように、多数のトランザクションが発生する従来のデータベース・モデルのために考え出されたものです。リレーショナル・データベースが情報技術の世界に広く普及するにつれ、あまり変更されることのないデータも多くDB2に保存されるようになっています。自動車部品を保存する倉庫のデータベースは非常に頻繁に変更しますが(自動車はソフトウェアよりも故障しやすい)、固定資産税データベースの行の大半はほとんど変更しないはずです。住宅所有者はたいてい新しい家に引っ越すと、そこに長い間住み続けるからです。私たちが紙やマイクロフィルムに保存する必要のあるデータは膨大な量になり、それはリレーショナル・データベースに保存すればもっと利用価値が高くなるはずですが、たとえば米議会図書館のコンテンツなどは数週間ごとに変更があり、その1%だけでもバックアップするコストは、コンテンツをデジタル保存する利点が相殺されてしまうほどです。

マルチメディア・アプリケーションでは、データの大部分はラージ・オブジェクト(LOB)として保存されますが、それらはログされない傾向があり、バックアップとログの方針を使用することにも欠点があります。LOBをログすれば、データベースのトランザクション速度が低下するからです。このような理由から、DB2に取り入れられたのが、最後のバックアップ以降に加えられた変更だけを保存するための手段、インクリメンタルバックアップなのです。

インクリメンタルバックアップの利点

変更を追跡し、後でリストアできるように別の場所に保存しておくには、2つの方法があります。

  1. DB2では、INSERT、UPDATE、DELETE、CREATE、ALTER、DROP、GRANT、REVOKEの各ステートメントをログに書き込むことができます。最後に実行したデータベースのバックアップの時点から障害の発生時までの間にデータのリストアが必要になったときには、DB2はこのログを実行し、それらの変更を再作成することができます。いわばシャーロック・ホームズが、何人かの容疑者の残した痕跡を追求して犯罪を再現するようなものです。これはトランザクションの数が膨大である場合に非常に効率が高くなります。
  2. もう1つの方法は、DB2が各ページに変更があったときに、そのコピーを保存するというもので、これが増分バックアップの仕組みに相当します。

データベースが非常にアクティブである場合には、ページに変更があるたびに、そのページのコピーを保存するというのは不合理なやり方です。最後にはデータベースの全ページのコピーを保存するはめになってしまい、新しいバックアップ・イメージを保存するのと同じことになり、ページの変更を増分的に追跡するという本来の目的が台無しになり、おそらくSQLをログするほうが手っ取り早いということになるからです。それに対し、変更がどれもページのごく一部に限定されていたり、大部分のページが変更されないというような場合は、変更のあったページだけを増分バックアップ・イメージで保存すれば、バックアップ・イメージを作成するための時間と記憶域を大幅に節約することになります。ページに何も変更がなければ、インクリメンタルバックアップではそのページが飛ばされるからです。

インクリメンタルバックアップでは、トランザクション件数の少ないデータベースのバックアップとリストアが効率的になるのは、次のような理由からです。

  • バックアップの実行速度が速くなる(データベース中の全ページを保存するのではなく、最後に実行したバックアップ以後から変更のあったページだけを保存するため)
  • バックアップ・イメージが小さくなる(データベース中の全ページを保存するのではなく、最後に実行したバックアップ以後から変更のあったページだけを保存するため)

インクリメンタルバックアップでもログの必要性はなくなりません。ロールフォワード・リカバリーを有効にして(データベース構成で、LOGRETAIN=ONに設定)DB2を実行した場合は、ログを使用して過去の一定時点にまでロールフォワードすることができます。LOGRETAIN を有効にする方法は次のとおりです。

UPDATE DATABASE CONFIGURATION FOR SAMPLE USING LOGRETAIN ON

これで直ちにデータベースのバックアップが実行され、バックアップ・イメージに一貫性をもたせるための基準点が確立され、この時点から先はログを保存しなければなりません。ですから、ストレージ(バックアップ・イメージとログをアーカイブするためのディスク、テープ、IBM Tivoli® Storage Managerのようなストレージ・マネージャー、LegatoやVeritasのストレージ・マネージャーなど)を用意しておく必要があります。

インクリメンタルバックアップをオンに設定

データベースのインクリメンタルバックアップを有効にするには、データベース構成パラメーターのTRACKMOD=ON(変更のあったページの追跡)を使用します。このパラメーターは次のようにして有効にします。

UPDATE DATABASE CONFIGURATION FOR SAMPLE USING TRACKMOD ON

アプリケーションを使用してデータを変更する前に、TRACKMODを有効にした後でデータベースをバックアップしておかなければなりません。

バックアップ・データの範囲

インクリメンタルバックアップには2つの種類があります。

  1. フルインクリメンタルバックアップ。最後の完全なバックアップ以後に変更のあったすべてのページのイメージであり、それがフル・バックアップ・イメージであるか、テーブルスペースのバックアップ・イメージであるかには関係しません。フルインクリメンタルバックアップの例を示しておきます。
    db2 backup db sample online incremental use tsm
  2. デルタ。任意の種類のバックアップ(別のデルタ、インクリメンタルバックアップ・イメージ、バックアップ・イメージ)を最後に実行した以後に変更のあったすべてのページのコピーを作成します。デルタバックアップの例は次のとおりです。
    db2 backup db sample online incremental delta use tsm

ですから、破損のあったデータベースをリストアするために、次の4種類のバックアップ・データを利用できるわけです。

  1. フル・バックアップ・イメージ。これはどのようなリカバリー・ストラテジーにおいてもビルディング・ブロックとなるものです。フル・バックアップ・イメージがなければ、リストアを開始することはできません。バックアップをオンラインで取る場合は、バックアップが行われている間に発生したすべてのトランザクションのログが必要です。フル・バックアップをリストアし、バックアップを取り始めてからのトランザクションをすべて再現すれば、リカバリーは完了です。
  2. インクリメンタルバックアップ。これには、最後のフル・バックアップ以後にあった変更がすべて含まれています。フル・バックアップをリストアし、増分バックアップをリストアし、増分バックアップを取り始めてからのログをすべて再現すれば、リカバリーは完了です。
  3. デルタバックアップ。これには、バックアップの種類に関係なく、最後のバックアップ以後に発生したすべての変更が含まれています。最後のバックアップがフル・バックアップ・イメージである場合、そのイメージとデルタとが最も完全なバックアップになります。デルタの前のバックアップがインクリメンタルバックアップである場合は、デルタ、インクリメンタルバックアップ、そして増分が基になっているフル・バックアップ・イメージが必要です。デルタの前のバックアップが1つまたは複数のデルタである場合は、インクリメンタルバックアップまたはフル・バックアップ・イメージに到達するまでのすべてのデルタが必要です。
  4. ログ。ログには、リストアすることができた最後のバックアップ以後に発生したトランザクションがすべて含まれています。

このように種々の場合があるわけですが、もう1つ別の側面があります。DB2ではバックアップがデータベース全体と、個々の表スペースという2つのレベルで行えることです(後者はよりきめ細かいバックアップであり、バックアップまたはリストアを重要なテーブルスペースのみに限定することができます)。増分イメージと差分イメージのバックアップとリストアは、テーブルスペースにも適用できます。

リカバリー・ストラテジー

ここではまず、データベースのリカバリー・ストラテジーとして、日曜日ごとにフル・バックアップが取られ、毎日夜間に増分バックアップが取られるデータベースを考えます。これを図1に示しています(図ではログを省略していますが、ログは最後のリストアの後で必要です)。

  • たとえば月曜日にリストアを行う必要がある場合には、日曜日の夜のバックアップ・イメージを使用してリストアし、利用可能なすべてのログを適用します。
  • 火曜日から日曜日までのいずれかの日にリストアする必要がある場合は、前の日曜日のフル・バックアップ・イメージをリストアし、次に前夜のインクリメンタルバックアップ・イメージをリストアし、最後にリストアした増分イメージ以後のログを適用します。

どのようなリカバリーでも次のものが必要です。

  • フル・バックアップ・イメージが1つ
  • インクリメンタルバックアップが1つまたはゼロ
  • 1日分のログ

バックアップはどれも次のフル・バックアップが行われるまで大きくなっていきます。その理由は、バックアップが必要な変更されたページは月曜日よりも土曜日のほうが多い、つまり月曜日には1日分の作業であるのに対し、土曜日には6日分の作業に増えるからです。

図1:フル・バックアップ・イメージとインクリメンタルバックアップ・イメージ
図1:フル・バックアップ・イメージとインクリメンタルバックアップ・イメージ
図1:フル・バックアップ・イメージとインクリメンタルバックアップ・イメージ

図2に示すように、差分バックアップだけを取れば、毎晩のバックアップは少なくなります。

図2:フル・バックアップ・イメージとデルタバックアップ・イメージ
図2:フル・バックアップ・イメージとデルタバックアップ・イメージ
図2:フル・バックアップ・イメージとデルタバックアップ・イメージ

デルタバックアップを使用すれば、月曜日から土曜日までの毎晩のバックアップが必要なストレージは少なくなり、実行時間も短くなります。しかし図1のリカバリー・ストラテジーでは、フル・バックアップが1つ、増分バックアップが1つ、およびログが必要であるのに対し、毎晩のデルタバックアップを使用すれば、最後に行ったフル・バックアップまたはインクリメンタルバックアップ以後に取ったすべてのデルタが必要になります。

こうした種々のバックアップの管理を容易にするために、DB2の履歴ファイルにはデータベースのバックアップ履歴が記録されます。このデータベースのバックアップ履歴を照会するための構文については、「DB2 コマンド解説書」を参照してください。

LIST HISTORY BACKUP ALL FOR SAMPLE

DB2そのものは、この履歴ファイルを使用して、リカバリーのためには以前のイメージが必要であるかどうかを判断し、それに基づいて自動的にリストアを試みます。その結果として、図2に示すように一連のバックアップ・イメージが取り出されることがあります。

図3は、リカバリーにおいてフル・バックアップ・イメージ、最後のインクリメンタルバックアップ、最後のインクリメンタルバックアップ以後に取られたすべてのデルタバックアップ、ログがどのように使用されるかを示したものです。最後のインクリメンタルバックアップ(月曜日から水曜日まで)の前に取られた差分イメージは必要ありません。ただし、フル・バックアップ・イメージ後のすべてのログがあり、増分イメージの1つが破損している場合、リカバリーにはフル・イメージとログを使用できますが、それはインクリメンタルバックアップを使用しないデータベースの場合とまったく同じことになります。

図3:フル、インクリメンタル、デルタの各バックアップ・イメージ
図3:フル、インクリメンタル、デルタの各バックアップ・イメージ
図3:フル、インクリメンタル、デルタの各バックアップ・イメージ

DB2は履歴ファイルを使用して、インクリメンタルリカバリーにおいて次に何が来るのかを決定しますから、履歴ファイルのエントリーを削除するときは(この削除にはPRUNE HISTORYコマンドを使用する)細心の注意が必要です。履歴ファイルはメタデータであり、インクリメンタルバックアップにとってその重要性は、データベースに対するシステム・カタログの重要性に匹敵します。

自動リストア
リストアのためにINCREMENTAL AUTOMATICキーワードを使用すると、DB2が何をリストアするのかを決定してくれます。

RESTORE DB SAMPLE INCREMENTAL AUTOMATIC TAKEN AT (SAT)

この自動リストアはDB2バージョン7.2のフィックスパック4で追加された機能です。INCREMENTAL AUTOMATICを指定すると、DB2は以前のバックアップ・イメージが必要であるかどうかを決定し、必要ならばその自動リストアを試みます。必要なバックアップ・イメージの順序は履歴ファイルによって決まります。DB2はリストアを行うすべてのテーブルスペースの完全なコピーを含んでいる最後のバックアップ・イメージから開始し、次にそれ以後のインクリメンタルイメージを順番に適用します。この後続のバックアップ・イメージには、リストアを行うすべての表スペースが含まれている必要はありません。

DB2バージョン7.2には、履歴ファイルを構文解析し、リストアを開始する前に必要なバックアップ・イメージを記述するdb2ckrstコマンドも追加されています。

まとめ

インクリメンタルバックアップは、原則として読み取り専用ではあるが、多少のINSERT/UPDATE/DELETE アクティビティーが実行されているようなデータベースを保護する上で優れた手段です。また、発生する変更が表スペースの小さいサブセットに限定されているような場合にも有用な手段となります。インクリメンタルバックアップを使用するバックアップ・ストラテジーには、リカバリーする必要のある4種類のデータ(フル・イメージ、インクリメンタルイメージ、デルタ、ログ)が含まれている可能性がありますから、いつも何をしているのかを管理し、データベースのサポートを担当するDBA全員がストラテジーをよく理解し、DB2の履歴ファイルの読み方を知っていることが重要です。災害時回復に必要なアーカイブしたログが紛失してしまうような会社に勤めているのなら、インクリメンタルイメージとデルタイメージを取っても、置き場所のわからないものが増えるだけです。ログのテープを再利用していて、リカバリーが必要になったときにはどこから手をつけていいかわからない場合は、バックアップとリカバリーのストラテジーに関して、下記のような堅実な原則をいくつか決めておくことです。

  • マイグレーション、フィックスパックのインストール、大きなアプリケーションの変更などの重要な変更を行うときは、事前に必ずフル・バックアップを取ることです。
  • DB2のコマンドdb2ckbkpはバックアップ・イメージの保全性を検査するために使用します。このコマンドについては、「DB2 コマンド解説書」に説明があります。
  • DB2のコマンドdb2ckrstは履歴ファイルを照会し、インクリメンタルリストアがDB2のレコードと一致するために必要な要件をユーザーに確認するために使用します。
  • リストアについては、予行練習をして、どれくらい時間がかかるか、バックアップ・イメージやログなどの関連する要素がどこにあるかを知っておく必要があります。予行練習は複数の人間に参加してもらい、一人が休暇を取ったり、退職しても影響ないようにします。
  • 時刻指定ロールフォワード・リカバリー、または1度に1表スペースずつのリストア、あるいはこの両方を使用するつもりでいる場合は、データベース・スキーマを理解することです。特定の表スペースを最初にリストアしても、その中に他の表スペースの表に対する参照制約が含まれている場合には、その可用性は改善されません。
  • バックアップが最後まで完了しなかった場合の措置について判断を下します。
    • 実動の続行を許可する前にバックアップを完了すべきか?
    • 以前のバックアップ・イメージに戻れるほど十分なログがあるか?
    • バックアップが完了する前にユーザーがデータベースへのアクセスを要求してきた場合、バックアップ・ストラテジーではどうすべきか?
    • オンライン・バックアップを使用する場合は、DB2がデータベースをバックアップしている間に発生したすべてのトランザクションのログがなければバックアップ・イメージは役に立たないことを理解しておく。

障害が発生したときに、DBAが上記のようなルールを知らなければ、事態の悪化をまねくことがあります。DBAがこのようなルールに従えば、アポロ13号の司令官エド・ハリスのように、災害時こそ組織の活躍の見せ場ということになります。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=323398
ArticleTitle=DB2のインクリメンタルバックアップの使用
publish-date=052002