Comments
Description
Transcript
3-3. 増分バックアップ （ Incremental Backup ）
DB2 UDB運用管理 3. 回復の手順 3-3. 増分バックアップ （ Incremental Backup ） お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第１．００版＞２００１年６月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 3-3. 増分バックアップ（Incremental Backup） （内容） 3-3-1. 増分バックアップ（Incremental Backup）とは 3-3-2. 増分バックアップの前提とサポートされるレベル 3-3-3. 増分バックアップからの復元手順 3-3-4. 増分復元イメージ順序の検査 3-3-5. 増分バックアップの仕組み 3-3-6. 増分バックアップの注意点 3-3-7. 増分バックアップからの復元 データベース全体の回復シナリオ 表スペース単位の回復シナリオ 増分バックアップイメージの消失からの回復シナリオ 回復活動記録ファイルの消失からの回復シナリオ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 1-2 インクリ メンタ ル? DB2 UDB運用管理 3. 回復の手順 3-3-1. 増分バックアップ（Incremental backup）とは 効果 バックアップするサイズが小さければ、それだけバックアップ中に読み込むデータ量が減る。 フルバックアップを頻繁に取ったり、長いログの処理を行うことなく回復させることが可能。 データベースとテーブルスペースのインクリメンタルバックアップをサポートします。 サポートされるバックアップレベル 累積タイプ：最後のフルバックアップから変更されたデータのバックアップ デルタタイプ（非累積）：最後のフルバックアップまたはインクリメンタルバックアップから変更さ れたデータのバックアップ Sunday Mon Tue Wed Thu Full Full Fri Sat Sunday Full 累積 バックアップ (Incremental) デルタ バックアップ(DELTA) Full (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップ（Incremental backup）とは Incremental Backup データベース (特にウェアハウス) のサイズがテラバイトからペタバイトの 範囲に拡張するにつれて、これらのデータベースの バックアップおよびリカバリに 必要な時間とハードウェア・リソースも大幅に増加します。 大規模なデータベースを扱っている 場合、データベースおよび表スペースの 全バックアップを実行することは、データベースの複数コピーのストレージ要件が 巨 大になるため、最適なアプローチとはいえません。 以下の点に注意してください。 * ウェアハウス内で変更されたデータのパーセンテージが小さい場合、 データベース全体をバックアップする必要はあ りません。 * 表スペースを既存のデータベースに追加して、その表スペースのみをバックアップするのは危険です。 これは、バック アップされた表スペース以外のデータも変更されている可能性があるためです。 DB2 は現在、V7.2 Fixpak3で増分バックアップおよびリカバリをサポートしました (ただし、 大きなフィールド(LONG)およびラー ジ・オブジェクト・データ(LOB)は増分バックアップをサポートしません)。 増分バックアップは、直前のバックアップが取られた後 で 更新されたページのみを含むバックアップ・イメージです。 増分バックアップ・イメージそれぞれには、更新されたデータと索 引ページに加え、 通常、全バックアップ・イメージに保管される初期データベース・メタデータ (データベース構成、 表スペース 定義、データベース・ヒストリーなど) も含まれます。以下の 2 つのタイプの増分バックアップがサポートされています。 * 増分。 増分バックアップ・イメージは、最新の全バックアップ処理が正常に完了した後で 変更されたすべてのデータ ベース・データのコピーです。 時間の経過とともに取られた一連の増分バックアップに、以前の増分バックアップ・イメージ の内容が 含まれるため、これは累積バックアップ・イメージとも呼ばれます。 前の増分バックアップ・イメージは常に、正 常に実行された同じオブジェクトの最後の全バックアップです。 * デルタ。 デルタ (つまり増分デルタ) バックアップ・イメージは、最後に正常に実行された 該当する表スペースの (全、 増分、またはデルタ) バックアップ後に変更されたすべての データベース・データのコピーです。 これは、差分または非累 積バックアップ・イメージとも呼ばれます。 前のデルタ・バックアップ・イメージは、最後に正常に実行された、デルタ・バック アップ・イメージ内の 各表スペースのコピーを含むバックアップです。 増分バックアップ・イメージとデルタ・バックアップ・イメージとの主な相違点は、 時間の経過とともに変化するオブジェクトの連 続バックアップを取るときの動作です。 連続増分イメージそれぞれには、以前の増分イメージの内容全体に加え、直前の バックアップが作成された後で変更されたデータや追加されたデータも含まれます。 デルタ・バックアップ・イメージには、直前 のイメージが作成された後で変更されたページのみが含まれます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 3-4 DB2 UDB運用管理 3. 回復の手順 3-3-2. 増分バックアップの前提とサポートされるレベル 新しいデータベース構成パラメーターTRACKMOD データベース更新のトラッキングを可能にするため、DB2 は、 以下の 2 つの値を設定できる 新しいデータベース構成パラメーター TRACKMOD をサポートしています。 NO この構成で増分バックアップは許可されません。 データベース・ページの更新はトラッキングまたは記録されません。 YES この構成で増分バックアップが許可されます。 更新のトラッキングが可能になると、インスタンス内のデータベースへの 最初の接続が 完了した時点で、変更が有効になります。 増分バックアップを取るには、データベースの全バックアップを実行する必要があります。 サポートされるモード、レベル、コマンド オンラインとオフラインのモードをサポート データベースとテーブルスペーレベルのサポート Backup/RestoreコマンドにIncremental指定可能 db2ckrstコマンド (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップの前提とサポートされるレベル デフォルト TRACKMOD 設定は、既存のデータベースであれば NO、 新しいデータベースであれば YES です。トラッキングの 細分度は、SMS および DMS 表スペースの両方の表スペース・レベルです。データベースへの更新のトラッキングは、データ を更新または挿入するトランザクションの 実行時パフォーマンスに、わずかながら影響を与えることがあります。 Track modified pages Log file size (4KB) Number of primary log files Number of secondary log files Changed path to log files Path to log files First active log file (TRACKMOD) = OFF (LOGFILSIZ) (LOGPRIMARY) (LOGSECOND) (NEWLOGPATH) Group commit count (MINCOMMIT) Percent log file reclaimed before soft chckpt (SOFTMAX) Log retain for recovery enabled (LOGRETAIN) User exit for logging enabled (USEREXIT) = = = = = = 250 3 2 = = = = 1 100 CAPTURE OFF F:\DB2\NODE0000\SQL00004\SQLOGDIR\ S0000032.LOG データベースおよび表スペース増分バックアップの組み合わせは、 オンライン・モードとオフライン・モードの両方で許可され ています。 バックアップについて計画する場合、データベースおよび表スペース増分バックアップを 組み合わせると、前の データベース・バックアップは必ずしも 1 つのイメージではなく、 別の機会に取られた以前のデータベースおよび表スペース・ バックアップの 固有セットになる場合があるため、注意してください。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 5-6 DB2 UDB運用管理 3. 回復の手順 3-3-3. 増分バックアップからの復元手順 RestoreコマンドにてIncremental指定 最新の増分Backupは2回Restoreされる必要がある リストア操作中に作成されるデータベースの正しいヒストリー、データベース構成、 および表スペース定義でデータ ベースが確実に構成されるようにするため、 増分リストア操作のターゲット・イメージは 2 回アクセスされなければな りません。 データベースの全バックアップ・イメージが最初に取られれた後で、表スペースが ドロップされている場 合、そのイメージの表スペース・データはバックアップ・イメージから 読み取られますが、増分リストア操作中には無 視されます。増分バックアップ・イメージのセットを復元するには、 RESTORE DATABASE コマンドに TAKEN AT timestamp オプションを指定します。 復元する最終イメージのタイム・スタンプを指定してください。 Full1 Delta1 Delta３ Delta２ Insert1 (手順) 表作成 Insert2 1. db2 restore database Delta3 incremental from ... taken at <ts> 2. db2 restore database Full incremental from ... taken at <ts> 3. db2 restore database Delta1 incremental from ... taken at <ts> 4. db2 restore database Delta2 incremental from ... taken at <ts> 5. db2 restore database Delta3 incremental from ... taken at <ts> 6. db2 follforward db sample to ................ Insert3 Insert4 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからの復元手順 増分バックアップ・イメージからのリストア操作は常に、以下のステップで構成されています。 1. 増分ターゲット・イメージを識別します。 DBA は、まず復元される最終イメージを決定し、DB2 リストア・ユーティリ ティーからの 増分リストア処理を要求します。 このイメージは、復元される最終イメージとなるため、増分リストアのター ゲット・イメージとも呼ばれます。 このイメージに対して増分リストア・コマンドを実行すると、 このターゲット・イメージから の構成および表スペース定義で、新しい データベースを作成することができます。 増分ターゲット・イメージは、RESTORE DATABASE コマンドに TAKEN AT パラメーターを 使用することによって指定されます。 2. 最新の全データベースまたは表スペース・イメージを復元し、適用可能な 連続増分バックアップ・イメージのベースラ インを確立します。 3. 要求された全データベースまたは表スペース増分バックアップ・イメージを、ステップ 2 で復元されたベースライン・イ メージの上に、作成された順にそれぞれ復元します。 4. ステップ 1 によるターゲット・イメージが 2 回読み取られるまで、ステップ3 を繰り返します。 ターゲット・イメージは、増 分リストア処理が完了するまでに 2 回アクセスされます。 最初のアクセスでは、イメージから初期データのみが読み取ら れます。ユーザー・データは読み取られません。 2 回目のアクセスでは、完了イメージのみが読み取られて処理されま す。 RESTOREコマンドのAUTOMATIC指定 RESTORE時、AUTOMATICを指定すると自動的に関連する増分Backup Image,Full Backup Imageを読み込みロール フォーワード保留状態にする Fixpak3のRelease.txtには明記されていない。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 7-8 DB2 UDB運用管理 3. 回復の手順 3-3-3. 増分バックアップからの復元手順 オンラインで取得したバックアップのリストアに必要なログファイル リストアのターゲットとなる増分Backup取得中のログファイルが最低限必要 それ以前の一連のBackup取得中のログファイルは使用されない ターゲット増分Backupイメージ取得後のログファイルを使用して、ロールフォワードを実行 リストアのターゲット 増分バックアップ・イメージ ONLINE Full1 ONLINE Delta1 Delta1 Insert1 表作成 ONLINE Backup 取得中のログ ONLINE Delta３ ONLINE Delta２ Insert3 Insert2 ONLINE Backup 取得中のログ ONLINE Backup 取得中のログ ONLINE Delta3 のリストア後の ロールフォワードに使用されない Insert4 ONLINE Backup 取得中のログ ONLINE Delta3 のリストア後の ロールフォワードに必要 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからの復元手順 オンライン・バックアップを取得した場合、バックアップ・イメージをリストアした後、バックアップ取得中のログを使用して、最低 限バックアップ終了時点までのロールフォワードが必要です。つまり、オンライン・バックアップをリストアするためには、オンラ イン・バックアップ取得中のログファイルが必ず必要です。 しかし、増分バックアップをオンラインで取得した場合、そのバックアップをリストアするために最低限必要なログファイルは、 増分ターゲット・イメージを取得中のログファイルのみです。 それ以前の一連の増分バックアップ取得中のログファイルは、回復時に使用されません。 ただし、いずれかの増分バックアップが破損する可能性があるため、ログファイルはフル・データベース・バックアップ取得後 のログは削除せず保管しておくことをおすすめします。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 9-10 DB2 UDB運用管理 3. 回復の手順 3-3-4. 増分復元イメージ順序の検査 db2ckrst - 増分復元イメージ順序の検査 データベース履歴を照会して、増分復元に必要なバックアップ・イメージの タイム・スタンプの リストを生成します。 手作業の増分復元の単純な restore 構文も生成されます。 コマンド構文 >>-db2ckrst----d--database name----t--timestamp-----------------> >-----+---------------------+---+-----------------------------+-> | .-database---. | | .--------------------. | '--r--+-tablespace-+--' | V | | '--n-----tablespace name---+--' >-----+----+--------------------------------------------------->< +--h-+ +--u-+ '--?-' コマンド・パラメーター -d database namefile-name 復元するデータベースの別名を指定します。 -t timestamp 増分を復元するバックアップ・イメージのタイム・スタンプを指定します。 -r 実行する復元のタイプを指定します。 デフォルトはデータベースです。 -n tablespace name 復元する 1 つ以上の表スペースの名前を指定します。 -h/-u/-? Displays help information. このオプションを指定すると、他のすべての オプションは無視され、ヘルプ情報のみが表示さ れます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分復元イメージ順序の検査 例 db2ckrst -d mr -t 20001015193455 -r database db2ckrst -d mr -t 20001015193455 -r tablespace db2ckrst -d mr -t 20001015193455 -r tablespace -n tbsp1 tbsp2 > db2 backup db mr バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20001016001426 です。 > db2 backup db mr incremental バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20001016001445 です。 > db2ckrst -d mr -t 20001016001445 データベース mr のタイム・スタンプ 20001016001445 を使用した、推奨されるイメージの復元順序。 =================================================================== db2 restore db mr incremental taken at 20001016001445 db2 restore db mr incremental taken at 20001016001426 db2 restore db mr incremental taken at 20001016001445 =================================================================== > db2ckrst -d mr -t 20001016001445 -r tablespace -n userspace1 データベース mr のタイム・スタンプ 20001016001445 を使用した、推奨されるイメージの復元順序。 =================================================================== db2 restore db mr tablespace ( USERSPACE1 ) incremental taken at 20001016001445 db2 restore db mr tablespace ( USERSPACE1 ) incremental taken at 20001016001426 db2 restore db mr tablespace ( USERSPACE1 ) incremental taken at 20001016001445 =================================================================== 使用上の注意 このユーティリティーを使用するには、データベース履歴が存在していなければなりません。 データベース履歴が存在しない 場合は、このユーティリティーを使用する前に、 RESTORE コマンドで HISTORY FILE オプションを指定してください。PRUNE HISTORY コマンドの FORCE オプションを使用した場合は、 最新の完全なデータベース・バックアップ・イメージから、復元に 必要となる 項目が削除されるおそれがあります。 PRUNE HISTORY コマンドのデフォルト操作は、必要な項目が削除される のを防ぎます。 PRUNE HISTORY コマンドの FORCE オプションは使用しないことをお勧めします。バックアップには有用なレ コードを収め、ガイドとしてこのユーティリティーを 使用することをお勧めします。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 11-12 DB2 UDB運用管理 3. 回復の手順 3-3-5. 増分バックアップの仕組み トラッキング細分度 バックアップ時の高速化の為、に”クリーン”なページは読まず、”ダーティー”なページのみ読 み込む。 テーブルスペース エクステント(DMSのみ） TABLE SPACE V7.2ではまだトラッキング対象外、将来のリリースで ページ Clean or Dirty ? TABLE SPACE BACKUP Incremental... I am "Dirty" Extent Clean Page1 Extent I am "Dirty" Clean or Dirty ? Clean Page2 ALL Pages Dirty Page3 Dirty Page3 増分バッアアップ・イメージ・ファイル (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップの仕組み 増分バックアップ時の判断基準 データ挿入後、初期値(LSN=100,110,120) ページ内のBPSにアプライされた最新のトランザクションの情報LSNが格納される LSN log sequence number(log recordの先頭からのoffset)が格納されている テーブルスペース（SMS or DMS) BPS header LSN=100 DMS header BPS header LSN=110 DMS header BPS header LSN=120 DMS header Data Data Data Page1 Page2 Page3 LSN_MA X LSN_Full LSN_Last - - 120 全体バックアップ取得(LSN=150) 増分バックアップ取得(LSN=160) テーブルスペース（SMS or DMS) BPS header LSN=100 DMS header ３つのLSN LSN_MAX そのPAGEグループ内で最高位のLSN LSN_FULL FULLバックアップのLSN LSN_LAST いずれかのバックアップのLSN BPS header LSN=110 DMS header BPS header LSN=120 DMS header Data Data Data Page1 Page2 Page3 LSN_MA X 120 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 13-14 LSN_Full LSN_Last 150 160 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップの仕組み データ更新(LSN=200) 対象PAGE LSNとLSN_MAXが更新される テーブルスペース（SMS or DMS) BPS header LSN=100 DMS header BPS header LSN=200 DMS header BPS header LSN=120 DMS header Data Data Data Page1 Page2 Page3 データ更新 LSN_MA X 200 LSN_Full LSN_Last 150 160 その後のLSNの比較を行い"CLEAN"と"DIRTY"の判断をしている INCREMENTAL バックアップの条件 LSN_MAX > LSN_FULLの場合ページ毎のLSN比較を行ない、バックアップ対象のページをスキャンする 上記の場合 200 > 150 なのですべてのページを読み、LSN=150よりも大きいPageを増分バッアアップ・イメージ・ ファイルへ書き出す INCREMENTAL DELTAバックアップの条件 LSN_MAX > LSN_LASTの場合ページ毎のLSN比較を行ない、バックアップ対象のページをスキャンする 上記の場合 200 > 160 なのですべてのページを読み、LSN=160よりも大きいPageを増分バッアアップ・イメージ・ ファイルへ書き出す LSN_LASTにINCREMENTAL DELTAのLSNにする (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 15-16 DB2 UDB運用管理 3. 回復の手順 3-3-6. 増分バックアップの注意点(1/2) LF/LOBが含まれる場合はページ単位の増分Backupは行なわれない そのテーブルスペース内のLF/LOBを含む表があり、LF/LOBを含まない表に更新があった場 合でも、そのTablespaceにDirtyマーカーが記録されそのTablespace内のすべての表の LF/LOBデータはすべてBackupされる そのテーブルスペース内のLF/LOBを含む表があり、その表に更新があった場合でも、その TablespaceにDirtyマーカーが記録されそのTablespace内のすべての表のLF/LOBデータは すべてBackupされる LOB Space (User data) LB Object slots Data Record LF Descriptor LOB Descriptor Data Page Allocati on Page Buddy Space Buddy Space ... Allocati on Page Buddy Space Buddy Space ... LF Object 構造上、各ページ内にはLong Varchar,Long Vargraphic, Blob,Clob,DBclobのデーターは含まれ ず、それらの列の記述子のみ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 表スペースにLF/LOBが含まれ、更新が起きた場合(1/2) SMSのテーブルスペース内に２つの表が存在する。 表TESTS内にLong列を含み、そこに更新があります 更新がないその表内のすべてのLF/LOBデータが増分バックアップファイルには含まれます 表スペース: SMS1 long varchar TESTS表 表スペース: SMS1 long varchar UPDATE TESTS表 増分バッアアップ・イメ ージ・ファイル (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 17-18 DB2 UDB運用管理 3. 回復の手順 解説： 表スペースにLF/LOBが含まれ、更新が起きた場合(1/2) SMSのテーブルスペース内に２つの表が存在する。 表TESTS内にLong列を含み、LF/LOBを含まない表TESTS1に更新があります。 更新があった対象ページが増分バックアップファイルには含まれます 更新がないその表内のすべてのLF/LOBデータが増分バックアップファイルには含まれます 表スペース: SMS1 long varchar TESTS表 int TESTS1表 表スペース: SMS1 long varchar INSERT TESTS表 TESTS1表 増分バッアアップ・イメ ージ・ファイル (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 19-20 DB2 UDB運用管理 3. 回復の手順 3-3-6. 増分バックアップの注意点(2/2) REORGを行なうとその表内すべてのページのが増分バックアップの対 象（Dirty)と判断されてしまう 全体バックアップを適用すべき LOADはそのような事にはならないが、既存のデータ量と比較し大量LOADするのであれば表 スペース増分でなく、表スペース全体バックアップを検討すべき 更新トランザクションがロールバックしてもそのページは増分バックアッ プの対象（Dirty)と判断されてしまう 各ページのLSNはコミット時の番号でなく、最新のトランザクションになるため 増分バックアップファイルを紛失し、Incremental Restoreの操作を既に 開始してしまった場合, Restore Incremental Abortで初期状態にもどす Restoreを開始し、もう一度Full,Incremental Deltaを取得して再度Restoreしようとしても...... SQL2574N A backup image restored as part of an incremental RESTORE operation cannot be newer than the target image. (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップの注意点 下記の手順でバックアップイメージを取得 (SQL2474Nのケース） Full2 Full1 Delta2 Delta1 表作成 Insert1 Insert2 Insert3 Insert4 (手順) 1. db2 restore database sample incremental from Delta1 taken at <ts> 2. db2 restore database sample incremental from Full1 taken at <ts> 3. db2 restore database sample incremental from Delta2 taken at <ts> SQL2574N 増分 RESTORE 操作の一部として復元されるバックアップ・イメージに、 ターゲット・イメージより新しいものを指定することはできません。 4. db2 "restore db v7db tablespace(sms1) incremental abort" SQL2001N ユーティリティーへの割り込みが発生しました。 出力データが不完全の可能性があります。 5. db2 restore database sample incremental from Delta2 taken at <ts> 6. db2 restore database sample incremental from Full2 taken at <ts> 7. db2 restore database sample incremental from Delta2 taken at <ts> 8. db2 rollforward db v7db to end of logs and stop (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 21-22 DB2 UDB運用管理 3. 回復の手順 3-3-7. 増分バックアップからの復元 データベース全体の回復シナリオ 回復シナリオ 障害 通常運用 T0 T2 T1 更新 更新 回復処理 通常運用 T3 ④ 時間 T4 ロールフォ ワード保留 データベース ① ★ データベース全体の オフライン・バックアッ プ取得 ② アーカイブ・ログ、アクティブ・ログ を保存 ★ End of Logs または Point in Time まで ③ データベース増分の オフライン・バックアッ プ取得 ⑤ ⑧ ⑥ ⑦ アーカイブ・ログ＋アクティブ・ログを使用して ロールフォワード データベース全体のリストア (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのデータベース全体の回復のシナリオ(1/6) 基本的な回復処理のシナリオは以下の通りです。 Manualリストアーの手順 シナリオ ① データベース全体のオフライン・バックアップを取得します。 データベースに対して更新処理を行います。アーカイブ・ログは削除しないように保存します。 ② データベース増分のオフライン・バックアップ取得します ③ データベースに対して更新処理を行います。アーカイブ・ログは削除しないように保存します。 ④データベースに障害が発生し使用不能になったとします 時刻 T0 T0-T1 T1 T1-T2 T2 ⑤ ②で保管してあった増分のオフライン・バックアップをリストアします T2-T3 ⑥ ①で保管してあったデータベース全体のオフライン・バックアップをリストアします T2-T3 ⑦ ②で保管してあった増分のオフライン・バックアップをもう一度リストアします -->Rollforward Pending T3 ⑧ ③で保管してあったアーカイブ・ログおよびアクティブ・ログを使用してログの最後までロールフォワードを 行い停止します。データベースはログに書き出されている最後のトランザクションがコミットした状態に回復し ます。（時刻指定でロールフォワードを停止することも可能です。） T4 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 23-24 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのデータベース全体の回復のシナリオ(2/6) データベース全体のオフライン・バックアップを取得します。（① ①） backup db v7db to /dbland2 buffer 8 バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010523092916 です。 データベースの更新処理を行います データベース増分のオフライン・バックアップを取得します。この時点のデータベースを★で表します。（② ②） backup db v7db incremental delta to /dbland2 buffer 8 バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010523092922 です。 データベースの更新処理を行います（③ ③） Backup Imageファイルの確認 Buffer Sizeを指定していないとDefault Buffer Sizeが4MBの為、その倍数になってしまうので要注意 [db2v7@yumiko(Ja_JP)/dbland2] ==> ls -l V7DB.* -rw-r----- 1 db2v7 sys -rw-r----- 1 db2v7 sys 7733248 May 23 09:29 V7DB.0.db2v7.NODE0000.CATN0000.20010523092916.001 1048576 May 23 09:29 V7DB.0.db2v7.NODE0000.CATN0000.20010523092922.001 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのデータベース全体の回復のシナリオ(3/6) データベース増分を復元します。（⑤ ⑤） 警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。 db2 "restore db v7db incremental from /dbland2 taken at 20010523092922 without prompting SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。 データベース全体を復元します。（⑥ ⑥） ==>db2 "restore db v7db incremental from /dbland2 taken at 20010523092916 without prompting DB20000I RESTORE DATABASE コマンドが正常に終了しました。 もう一度、データベース増分を復元します。（⑦ ⑦） ==>db2 "restore db v7db incremental from /dbland2 taken at 20010523092922 without prompting DB20000I RESTORE DATABASE コマンドが正常に終了しました。 上記⑤ ⑤､⑥ ⑥､⑦ ⑦を一度に復元することも可能（AUTOMATIC指定） ==> db2 "restore db v7db incremental automatic from /dbland2 taken at 20010523092922 without prompting SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。 ==> db2 connect SQL1117N ロールフォワード保留中のために、データベース "V7DB"の接続または活動化を行なうことはできません。 SQLSTATE=57019 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 25-26 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのデータベース全体の回復のシナリオ(4/6) リストアが終了すると、データベースはオフライン・バックアップを取得した時点（★）と同じになります。ただし、データベースはロー ルフォワード保留状態になります。 この状態では、データベースに接続しようとしても、SQL1117N（ロールフォワード保留中）のエラーで接続できません。 ==> db2 connect to v7db SQL1117N ロールフォワード保留中のために、データベース "V7DB"の接続または活動化を行なうことはできません。 SQLSTATE=57019 ロールフォワード保留中であることは、データベースの構成情報を表示させることによっても確認できます。 db2 "get db cfg for V7DB" V7DB データベースのデータベース構成 （略） バックアップ保留状態 = NO 整合状態のデータベース ロールフォワード保留状態 復元保留中 （略） = YES = DATABASE = NO (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのデータベース全体の回復のシナリオ(5/6) ロールフォワード保留を解除するために、データベース全体のロールフォワードを行う必要があります。（Point in Time 指定また はログの最後（End of Logs）まで。） （⑧ ⑧） ==> db2 "rollforward db v7db to end of logs and stop" ロールフォワード状況 入力データベース別名 状況を返したノードの数 ノード番号 ロールフォワード状況 次に読み込むログ・ファイル 処理したログ・ファイル 最後にコミットしたトランザクション = v7db = 1 = = = = = 0 not pending S0000005.LOG - S0000005.LOG 2001-05-22-23.29.24.000000 DB20000I ROLLFORWARD コマンドが正常に終了しました。 ロールフォワードが終了すると、データベースに接続することができます。 ==> db2 connect to v7db データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = V7DB (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 27-28 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのデータベース全体の回復のシナリオ(6/6) ロールフォワード保留が解除されていることは、データベースの構成情報を表示することで確認できます。 db2 "get db cfg for V7DB" V7DB データベースのデータベース構成 （略） バックアップ保留状態 = NO 整合状態のデータベース ロールフォワード保留状態 復元保留中 （略） = YES = NO = NO (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 29-30 DB2 UDB運用管理 3. 回復の手順 3-3-7. 増分バックアップからの復元 表スペース単位の回復シナリオ 回復シナリオ 通常運用 T0 更新 回復処理 障害 T1 T2 T3 通常運用 T5 T6 時間 DDL 更新 更新 T4 ロールフォ ワード保留 ④ 表スペース ★ ① ② ★ アーカイブ・ログ、アク ティブ・ログを保存 ③ End of Logs または Point in Time (T3)まで データベース全 表スペース増分 表スペース増分 体のオフライン・ のオフライン・バッ のオフライン・バッ バックアップ取得 クアップ取得 クアップ取得 ⑤ ⑥ ⑦ ⑧ ⑨ アーカイブ・ログ＋アクティブ・ログを使用して ロールフォワード 表スペース全体のリストア (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(1/12) 基本的なテーブルスペースの回復処理のシナリオは以下の通りです。 Manualリストアーの手順 シナリオ ①データベース全体のオフライン・バックアップを取得します。 表スペースに対して更新処理を行います。アーカイブ・ログは削除しないように保存します。 時刻 T0 T0-T1 ② 表スペース増分のオフライン・バックアップ取得します T1 表スペースに対して更新処理を行います。アーカイブ・ログは削除しないように保存します。 T1-T2 ③表スペース増分のオフライン・バックアップ取得します T2 表スペーススに対して更新処理を行います。アーカイブ・ログは削除しないように保存します。 T2-T3 新規に表スペースを作成します T3 ④ データベースに障害が発生し使用不能になったとします T4 ⑤ ③で保管してあった増分のオフライン・バックアップをリストアします T4-T5 ⑥ ①で保管してあった全体（表スペース）のオフライン・バックアップをリストアします T4-T5 ⑦ ②で保管してあった増分のオフライン・バックアップをリストアします T4-T5 ⑧ ③で保管してあった増分のオフライン・バックアップをもう一度リストアします -->Rollforward Pending T4-T5 ⑨ ③で保管してあったアーカイブ・ログおよびアクティブ・ログを使用してT3までPITでロールフォワード (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 31-32 T5 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(2/12) シナリオの準備として、DMSのテーブルスペースを作成し表 TESTDを作成します。 connect to v7db データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = V7DB drop tablespace dms1 DB20000I SQL コマンドが正常に終了しました。 create tablespace dms1 managed by database using (file '/dbland2/dms1' 1000) DB20000I SQL コマンドが正常に終了しました。 create table testd (c1 int , c2 char(250), c3 char(250), c4 char(250), c5 char(250)) in dms1 DB20000I SQL コマンドが正常に終了しました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(3/12) 表へinsertするSQL Procedure (WHILED) を作成しておきます C1はユニークになるようになっています コールされる時のパラメーターがINSERTする回数になっています WHILED(10) -->10行インサート CREATE PROCEDURE WHILED(IN n1 INT) SPECIFIC WHILED LANGUAGE SQL BEGIN ATOMIC DECLARE count INT; DECLARE while_count INT default 0; DECLARE max_count INT default 0; SELECT MAX(c1) into max_count from testd; if max_count is null then set max_count=0; end if; SET count = n1; WHILE (count > 0) DO SET while_count = while_count + 1; INSERT INTO TESTD VALUES (max_count+while_count,'Data1','data2','data3' ,'data4'); set count = count -1; END WHILE ; END DB20000I SQL コマンドが正常に終了しました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 33-34 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(4/12) データベース全体のオフライン・バックアップを取得します。（① ①） backup db v7db to /dbland2 buffer 8 バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010524101851 です。 データベースヘ接続し更新処理(10行インサート）を行います connect to v7db データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = V7DB CALL WHILED(10) "WHILED" 戻り状況 : "0" データベース増分のオフライン・バックアップを取得します。（② ②） backup db v7db tablespace(dms1) incremental delta to /dbland2 buffer 8 バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010524101903 です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(5/12) db2diag.log 上に増分バックアップが完了したと記録される 2001-05-24-10.19.03.343681 Instance:db2v7 Node:000 PID:53406(db2agent (V7DB)) Appid:*LOCAL.db2v7.010524001843 database_utilities sqlubcka Probe:0 Database:V7DB Starting an incremental delta tablespace backup. 2001-05-24-10.19.03.612647 Instance:db2v7 PID:19092(db2bm.53406.0) Appid:none database_utilities sqlubbmcont Probe:10 Backing up tablespace DMS1 0000 128e 000b 2001-05-24-10.19.03.876358 Instance:db2v7 PID:19092(db2bm.53406.0) Appid:none database_utilities sqlubbmcont Probe:6 Node:000 ...... Node:000 Finished tablespaces (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 35-36 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(6/12) データベースヘ接続し更新処理(10行インサート）を行います connect to v7db データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = V7DB CALL WHILED(10) "WHILED" 戻り状況 : "0" テーブルスペース増分のオフライン・バックアップを取得します。（③ ③） backup db v7db tablespace(dms1) incremental delta to /dbland2 buffer 8 バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010524101907 です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(7/12) データベースヘ接続し更新処理(100行インサート）を行います connect to v7db データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = V7DB CALL WHILED(100) "WHILED" 戻り状況 : "0" 後述のRollforward時のPITを記録するためDROP/CREATE Tablespaceを実行 表の内容をすべて削除(30行）これを障害とする（④ ④） drop tablespace dms2 DB20000I SQL コマンドが正常に終了しました。 create tablespace dms2 managed by database using (file '/dbland2/dms2' 1000) DB20000I SQL コマンドが正常に終了しました。 delete from testd DB20000I SQL コマンドが正常に終了しました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 37-38 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(8/12) Backup Image Fileの確認 [db2v7@yumiko(Ja_JP)/dbland2] ==> ls -l V7DB* -rw-r----- 1 db2v7 sys -rw-r----- 1 db2v7 sys -rw-r----- 1 db2v7 sys 9797632 May 24 10:18 V7DB.0.db2v7.NODE0000.CATN0000.20010524101851.001 1310720 May 24 10:19 V7DB.3.db2v7.NODE0000.CATN0000.20010524101903.001 1310720 May 24 10:19 V7DB.3.db2v7.NODE0000.CATN0000.20010524101907.001 テーブルスペース増分を復元します。（⑤ ⑤） db2 "restore db v7db tablespace(dms1) incremental from /dbland2 taken at 20010524101907" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 表スペース DMS1が復元保留、進行中であることは、LIST TABLESPACESの構成情報を表示させることによっても確認できます。 db2 "list tablespaces" 現在のデータベースの表スペース （略） 表スペース ID 名前 タイプ 内容 状況 詳しい説明: 復元保留中 復元進行中 = = = = = 3 DMS1 データベース管理スペース 任意のデータ 0x2100 この表スペース DMS1が復元保留、進行中である場合、照会も失敗します。 SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(9/12) db2diag.log 上に増分Restoreが完了したと記録される 2001-05-24-10.30.02.040535 Instance:db2v7 Node:000 PID:31590(db2agent (V7DB)) Appid:*LOCAL.db2v7.010524001843 database_utilities sqludautController Probe:874 Database:V7DB Non-automatic restore. 2001-05-24-10.30.02.171718 Instance:db2v7 Node:000 PID:31590(db2agent (V7DB)) Appid:*LOCAL.db2v7.010524001843 database_utilities sqludrsa Probe:0 Database:V7DB Starting a tablespace restore. 2001-05-24-10.30.03.015109 Instance:db2v7 Node:000 PID:31590(db2agent (V7DB)) Appid:*LOCAL.db2v7.010524001843 database_utilities sqludrsa Probe:0 Database:V7DB Restore Complete. (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 39-40 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(10/12) データベース全体を復元します。（⑥ ⑥） db2 "restore v7db tablespace(dms1) incremental from /dbland2 taken at 20010524101851" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 テーブルスペース増分を復元します。（⑦ ⑦） db2 "restore v7db tablespace(dms1) incremental from /dbland2 taken at 20010524101903" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 テーブルスペース増分を復元します。（⑧ ⑧） db2 "restore v7db tablespace(dms1) incremental from /dbland2 taken at 20010524101907" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 表スペース DMS1が復元保留、進行中からロールフォワード保留中へ変更される。 表スペース ID 名前 タイプ 内容 状況 詳しい説明: ロールフォワード保留中 = = = = = 3 DMS1 データベース管理スペース 任意のデータ 0x0080 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(11/12) 表スペースDMS2の最小回復時刻を調べる ロールフォワード保留を解除するために、表スペースDMS1のロールフォワード（Point in Time 指定またはログの最後（End of Logs）まで） および停止を行う必要があります。ここでは、T3時刻（例では2001-05-24-00.19.11.00000 CUT）を指定してPoint in Time までロールフォワードして停止します。（⑨ ⑨） 表スペース ID 名前 タイプ 内容 状況 詳しい説明: (略） プリフェッチ・サイズ (バイト) コンテナー数 Minimum recovery time = = = = = 5 DMS2 データベース管理スペース 任意のデータ 0x0000 = 32 = 1 = 2001-05-24-00.19.11.000000 ==>db2 rollforward db v7db to 2001-05-24-00.19.11.00000 and stop tablespace(dms1) SQL1278W ロールフォワード処理が正常に完了しました。 活動状態あるいは未確定のトランザクションがノード "0" で必要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 41-42 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップからのテーブルスペースの回復のシナリオ(12/12) 表スペースをPITを指定してロールフォワードを実行すると表スペースはバックアップ保留状態になります。 バックアップ保留状態では、その表スペース上の表の照会は可能ですが、更新はできません。 ==> db2 "select count(*) from testd" 1 ----------120 1 レコードが選択されました。 表スペース ID 名前 タイプ 内容 状況 詳しい説明: バックアップ保留中 = = = = = 3 DMS1 データベース管理スペース 任意のデータ 0x0020 表スペースDMS1がバックアップ保留になる理由は、以下の通りです。 この後にログを使用してデータベースのロールフォワードを行った場合に、表スペースDMS1にもそのログファイルに記録されてい るトランザクションが適用されてしまい、表スペースの内容が正しくない状態になってしまいます。 しかし、この表スペース DMS1のバックアップがあれば、それを復元することにより表スペース DMS1の状態を時刻T3の状態にす ることができます。このバックアップを必ずとるために、表スペースはバックアップ保留となります。 この後、バックアップ保留はFull またはIncremental Backupを取得すると解除されます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 43-44 DB2 UDB運用管理 3. 回復の手順 3-3-7. 増分バックアップからの復元 オンライン・インクリメンタル・バックアップの回復シナリオ 最後のオンライン・バックアップ中のログが最低限必要 通常運用 T0 T1 障害 T2 T3 T4 T5 T6 ① 更新処理 回復 T7 ⑪ 通常運用 T8 T9 時間 ロールフォ ワード保留 データベース ③ ⑥ オンライン・ オンライン・ バックアップ バックアップ ⑦ 中の更新ログ ④ 更新ログ 中の更新ログ 更新ログ ⑨ オンライン・ バックアップ ⑩ 中の更新ログ 更新ログ ⑬ オンライン・インクリメンタル・ ② データベース全体 のオンライン・ フル・バックアップ フル デルタ・バックアップ中の 更新ログをロールフォワード ⑧ ⑤ オンライン・ インクリメンタル バックアップ オンライン・ インクリメンタル・ デルタ・バックアップ デルタ ⑭ End of Logs までロールフォワード ⑫ インクリメンタル・バックアップをリストア (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： オンライン・インクリメンタル・バックアップの回復シナリオ (1/6) オンライン・インクリメンタル・バックアップの回復シナリオは以下の通りです。 シナリオ 時刻 ① データベースを定常的にアプリケーションが更新している状況を考えます。 ② データベースのオンライン・データベース・フル・バックアップを取得開始します。 T0 ③ データベースのオンライン・データベース・フル・バックアップの取得が終了します。バックアップ取得中の 更新については、ログに記録されます。 T1 ④ アプリケーションによる更新はログに書き出されます。 T1-T2 ⑤ データベースのオンライン・データベース・インクリメンタル・バックアップを取得開始します。 T2 ⑥ データベースのオンライン・データベース・インクリメンタル・デルタ・バックアップの取得が終了します。バッ クアップ取得中の更新については、ログに記録されます。 T3 ⑦ アプリケーションによる更新はログに書き出されます。 T3-T4 ⑧ データベースのオンライン・データベース・インクリメンタル・デルタ・バックアップを取得開始します。 T4 ⑨ データベースのオンライン・データベース・インクリメンタル・デルタ・バックアップの取得が終了します。バッ クアップ取得中の更新については、ログに記録されます。 T5 ⑩ アプリケーションによる更新はログに書き出されます。 T5-T6 ⑪ データベースに障害が発生したとします。 T6 ⑫ ⑨で取得完了したオンライン・データベース・インクリメンタル・デルタ・バックアップを指定し、AUTOMATIC リストアします。 T7 ⑬ ⑨のログをロールフォワードします。（オンライン・バックアップのリストア完了） T7-T8 ⑭ ⑩のログをEnd of Logs までロールフォワードします。（⑬と⑭のロールフォワードは一度に実行可能） T8-T9 このシナリオでは、⑨のログが最低限必要で、回復する時点によって⑩のログも必要です。（⑬および⑭のロールフォワード時） ③、④、⑥、⑦のログは、このシナリオでは必要ありません。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 45-46 DB2 UDB運用管理 3. 回復の手順 解説： オンライン・インクリメンタル・バックアップの回復シナリオ (2/6) あるプロセスがデータベースを定常的に更新している状況を考えます。ここでは、TIMESTAMP データタイプの列をCURRENT TIMESTAMP で繰り返し更新しています。（① ①） db2 "update t1 set c2 = CURRENT TIMESTAMP" データベースのオンライン・フル・バックアップを取得します。 （② ②） db2 "backup db SAMPLE online to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010528153438 です。 このオンライン・フル・バックアップ取得中のログは、LIST HISTORY コマンドで調べることができます。以下の場合、 S0000001.LOG から S0000005.LOG のログがオンライン・フル・バックアップ取得中のログです。（S0000006.LOG はバックアップ が終了し次に書き込まれるログファイルであるため。）（③ ③） db2 "list history backup since 20010528153438 for SAMPLE" Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ -------------B D 20010528153438001 N D S0000001.LOG S0000006.LOG ---------------------------------------------------------------------------2 個の表スペースを含みます : 00001 SYSCATSPACE 00002 USERSPACE1 ---------------------------------------------------------------------------コメント: DB2 BACKUP SAMPLE ONLINE 開始時刻: 20010528153438 終了時刻: 20010528153507 ---------------------------------------------------------------------------00001 ロケーション: /backup (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： オンライン・インクリメンタル・バックアップの回復シナリオ (3/6) しばらくデータベースを更新した後（④ ④）、データベースのオンライン・インクリメンタル・バックアップを取得します。 （⑤ ⑤） db2 "backup db SAMPLE online incremental to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010528153520 です。 このオンライン・インクリメンタル・バックアップ取得中のログは、LIST HISTORY コマンドで調べることができます。以下の場合、 S0000007.LOG から S0000009.LOG のログがオンライン・インクリメンタル・バックアップ取得中のログです。 db2 "list history backup since 20010528153520 for SAMPLE" Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ -------------B D 20010528153520001 O D S0000007.LOG S0000010.LOG ---------------------------------------------------------------------------2 個の表スペースを含みます : 00001 SYSCATSPACE 00002 USERSPACE1 ---------------------------------------------------------------------------コメント: DB2 BACKUP SAMPLE ONLINE 開始時刻: 20010528153520 終了時刻: 20010528153532 ---------------------------------------------------------------------------00002 ロケーション: /backup (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 47-48 DB2 UDB運用管理 3. 回復の手順 解説： オンライン・インクリメンタル・バックアップの回復シナリオ (4/6) しばらくデータベースを更新した後（⑦ ⑦）、データベースのオンライン・インクリメンタル・デルタ・バックアップを取得します。 （⑧ ⑧） db2 "backup db SAMPLE online incremental delta to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010528153546 です。 このオンライン・インクリメンタル・デルタ・バックアップ取得中のログは、LIST HISTORY コマンドで調べることができます。以下の 場合、S0000011.LOG から S0000014.LOG のログがオンライン・インクリメンタル・デルタ・バックアップ取得中のログです。 db2 "list history backup since 20010528153546 for SAMPLE" Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ -------------B D 20010528153546001 E D S0000011.LOG S0000015.LOG ---------------------------------------------------------------------------2 個の表スペースを含みます : 00001 SYSCATSPACE 00002 USERSPACE1 ---------------------------------------------------------------------------コメント: DB2 BACKUP SAMPLE ONLINE 開始時刻: 20010528153546 終了時刻: 20010528153607 ---------------------------------------------------------------------------00003 ロケーション: /backup (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： オンライン・インクリメンタル・バックアップの回復シナリオ (5/6) しばらくデータベースを更新します。（⑩ ⑩） その後、データベースが障害により使用不能となったとします。取得した一連のインクリ メンタル・バックアップからリストアします。ここでは、最後に取ったインクリメンタル・デルタ・バックアップを指定して AUTOMATIC 指定でリストアを行います。 警告2539 は既存のデータベースを上書きするという警告です。 db2 "restore db SAMPLE incremental automatic from /backup taken at 20010528153546 without prompting" SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを 復元中に、警告 "2539" が出されました。 データベースはロールフォワード保留であるため、ログの最後（End of Logs）までロールフォワードを実行します。（⑬ ⑬、⑭ ⑭） db2 "rollforward db SAMPLE to end of logs and stop" ロールフォワード状況 入力データベース別名 状況を返したノードの数 ノード番号 ロールフォワード状況 次に読み込むログ・ファイル 処理したログ・ファイル 最後にコミットしたトランザクション = SAMPLE = 1 = = = = = 0 not pending S0000011.LOG - S0000019.LOG 2001-05-28-06.36.37.000000 DB20000I ROLLFORWARD コマンドが正常に終了しました。 ロールフォワードの出力結果より、S0000011.LOG - S0000019.LOG がロールフォワードに使用されたことがわかります。 これは、一番最後のオンライン・インクリメンタル・デルタ・バックアップ取得中（⑨ ⑨）のログと、取得後のログ（⑩ ⑩）です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 49-50 DB2 UDB運用管理 3. 回復の手順 解説： オンライン・インクリメンタル・バックアップの回復シナリオ (6/6) 以上より、オンライン・インクリメンタル・バックアップをリストアする場合には、リストアするバックアップ・イメージの中で最も新しい オンライン・バックアップ・イメージ（＝ターゲット・イメージ）取得中のログが最低限必要であり、それ以前のオンライン・バックアッ プ・イメージの取得中のログファイルは、この回復には必要がないことがわかります。 必要に応じて、最後のオンライン・アックアップ取得後のログを使用して、ロールフォワードをすることにより、ログの最後まで（End of Logs）または指定時刻まで（Point in Time）回復が可能です。 （シナリオでは、ロールフォワードを一度にログの最後まで実行しています。） (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 51-52 DB2 UDB運用管理 3. 回復の手順 3-3-7. 増分バックアップからの復元 インクリメンタル・バックアップ・イメージを消失した際の考慮点 障害 通常運用 回復 通常運用 時間 ⑧ データベース 更新処理 ⑩ リストア ABORT ⑤ ③ ① データベース全体 ⑥ ④ 更新処理 ② 更新処理 インクリメンタル バックアップ のフル・バックアップ インクリメンタル・ デルタ・ バックアップ ⑦ 消失 インクリメンタル・バックアップからの ⑨リストアは不可 ⑪ フル・バックアップ・イメージのリストア＋ロールフォワード (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップイメージの消失からの回復シナリオ(1/8) インクリメンタル・バックアップを行う際に、その中の1つのバックアップ・イメージを消失してしまった場合の回復に関するシナリオ は以下の通りです。 シナリオ ① データベース全体のオフライン・フル・バックアップを取得します。 ② データベースの更新操作を行います。 ③ データベース全体のオフライン・インクリメンタル・バックアップを取得します。 ④ データベースの更新操作を行います。 ⑤ データベース全体のオフライン・インクリメンタル・デルタ・バックアップを取得します。 ⑥ データベースの更新操作を行います。 ⑦ ③で取得したインクリメンタル・バックアップ・イメージを消失したとします。 ⑧ データベース全体に障害が発生したとします。 ⑨ ⑤のインクリメンタル・デルタ・バックアップを使用してリストアを行うことは、⑦で途中のインクリメンタル・バックアップイ メージを消失してしまったため、不可能です。 ⑩ リストアをARORTし、インクリメンタル・リストアの処理中に作成されたリソースをクリーンアップします。 ① で取得したフル・バックアップをリストアし、ロールフォワードすることでデータベースを回復することは可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 53-54 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップイメージの消失からの回復シナリオ(2/8) データベース全体のフルバックアップを取得します。（① ①） db2 "backup db SAMPLE to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010525153512 です。 データベースに接続し、t1表に10行Insert （② ②）した後、Incremental バックアップを取得します。（③ ③） db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------10 1 レコードが選択されました。 db2 "terminate" DB20000I TERMINATE コマンドが正常に終了しました。 db2 "backup db SAMPLE incremental to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010525153540 です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップイメージの消失からの回復シナリオ(3/8) さらに、t1表に10行Insert （④ ④）した後、Incremental Delta バックアップを取得します。（⑤ ⑤） db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------20 1 レコードが選択されました。 db2 "terminate" DB20000I TERMINATE コマンドが正常に終了しました。 db2 "backup db SAMPLE incremental delta to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010525153612 です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 55-56 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップイメージの消失からの回復シナリオ(4/8) さらに、t1表に10行Insert します。（⑥ ⑥） db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------30 1 レコードが選択されました。 db2 "terminate" DB20000I TERMINATE コマンドが正常に終了しました。 t1表には30行データが存在します。 ここで、Incremental バックアップ・イメージ（タイムスタンプ 20010525153540 のもの）を削除してしまったとします。（⑦ ⑦） rm /backup/SAMPLE.0.db2v7.NODE0000.CATN0000.20010525153540.001 ls /backup/ SAMPLE.0.db2v7.NODE0000.CATN0000.20010525153512.001 SAMPLE.0.db2v7.NODE0000.CATN0000.20010525153612.001 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップイメージの消失からの回復シナリオ(5/8) Incremental Delta バックアップ・イメージを使用して、リストアを行います。（⑨ ⑨） db2 "restore db SAMPLE incremental from /backup taken at 20010525153612 without rolling forward without prompting" SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを 復元中に、警告 "2539" が出されました。 db2 "restore db SAMPLE incremental from /backup taken at 20010525153512" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 しかし、先ほど Incremental バックアップ・イメージを削除してしまったため、タイムスタンプ20010525153540 のIncremental バック アップ・イメージを指定した リストア操作はエラーとなってしまいます。 db2 "restore db SAMPLE incremental from /backup taken at 20010525153540" SQL2542N 指定されたソース・データベースの別名 "SAMPLE" と タイム・スタンプ "2001052" に一致する、データ ベース・イメージ・ファイルが ありません。 このエラーを無視してリストア操作を続けようとしても、以下のようなエラーが示されます。 db2 "restore db SAMPLE incremental from /backup taken at 20010525153612" SQL2572N 順序に従わないイメージの増分復元を行おうとしました。 タイム・スタンプ "20010525153540" を指定したバックアップ・イメージは、バックアップを行う直前に復元される 必要があるため、表スペース "USERSPACE1" の復元でエラーが起きました。 このようになってしまった場合、これ以上 Incremental バックアップのリストア操作を継続することはできません。 最初のフル・バックアップ取得時点からのログファイルが適切に保管してあれば、フル・バックアップのリストア→ロールフォワード という手順で回復することが可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 57-58 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップイメージの消失からの回復シナリオ(6/8) フル・バックアップからのリストアを行う際の注意点としては、Incremental バックアップからのリストア処理が途中の場合、そのま まではフル・バックアップからのリストア操作をしようとしても、以下のようなエラーとなるということが挙げられます。 db2 "restore db SAMPLE from /backup taken at 20010525153512 without prompting" SQL2576N 表スペース "SYSCATSPACE" を増分 RESTORE 操作の一部として復元しようとしましたが、RESTORE コマン ドに INCREMENTAL 文節が指定しませんでした。 したがって、まず RESTORE コマンドに INCREMENTAL ABORT オプションを指定して、Incremental バックアップからのリストア処 理を終了する必要があります。 これにより、Incremental リストア処理の途中で作成されたリソースをクリーンアップすることができ ます。 db2 "restore db SAMPLE incremental abort" SQL2001N ユーティリティーへの割り込みが発生しました。 出力データが不完全の可能性があります。 この状態では、またデータベースは使用可能な状態ではありません。接続しようとしても以下のようなエラーとなります。 db2 "connect to SAMPLE" SQL0276N 保留状態を復元しているため、データベース "SAMPLE" への接続を作成できません。 SQLSTATE=08004 リストア操作は行うことが可能です。ここでは、最初に取ったフル・バックアップ・イメージをリストアします。 db2 "restore db SAMPLE from /backup taken at 20010525153512 without prompting" SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 増分バックアップイメージの消失からの回復シナリオ(7/8) データベース全体をログの最後までロールフォワードします。 db2 "rollforward db SAMPLE to end of logs and stop" ロールフォワード状況 入力データベース別名 状況を返したノードの数 ノード番号 ロールフォワード状況 次に読み込むログ・ファイル 処理したログ・ファイル 最後にコミットしたトランザクション = SAMPLE = 1 = = = = = 0 not pending S0000000.LOG - S0000002.LOG 2001-05-25-06.36.29.000000 DB20000I ROLLFORWARD コマンドが正常に終了しました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 59-60 DB2 UDB運用管理 3. 回復の手順 解説： 増分バックアップイメージの消失からの回復シナリオ(8/8) データベースに接続し、表t1の内容を表示し正しく回復されていることを確認します。 db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------30 1 レコードが選択されました。 db2 "terminate" DB20000I TERMINATE コマンドが正常に終了しました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 61-62 DB2 UDB運用管理 3. 回復の手順 3-3-7. 増分バックアップからの復元 回復活動記録ファイルがPruneされた場合のリストアのシナリオ 障害 通常運用 回復 時間 ⑥ データベース ② 更新処理 ④ 更新処理 ③ ⑤ インクリメンタル バックアップ インクリメンタル・ デルタ・バックアップ ① データベース全体 のフルバックアップ ③’ ⑨ RESTORE ⑧ ABORT AUTOMATIC リストア/ db2ckrst コマンドはエラー （順番にそれぞれの バックアップの リストアは可能） ⑤’ バックアップの バックアップの ①’ バックアップの 記録を追記 記録を追記 記録を追記 ⑪ AUTOMATIC リストア可能 ⑩ 回復活動記録 ファイルを復元 （参照） ⑦ エントリーを削除 回復活動記録ファイル 回復活動記録ファイル (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 回復活動記録ファイルの消失からの回復シナリオ(1/6) 回復活動記録ファイルの内容を削除（Prune）してしまった場合の回復手順に関するシナリオは以下のとおりです。 シナリオ ① データベース全体のオフライン・フル・バックアップを取得します。 ①’バックアップ操作の記録が回復活動記録ファイルに追記されます。 ② データベースの更新操作を行います。 ③ データベース全体のオフライン・インクリメンタル・バックアップを取得します。 ③’インクリメンタル・バックアップ操作の記録が回復活動記録ファイルに追記されます。 ④ データベースの更新操作を行います。 ⑤ データベース全体のオフライン・インクリメンタル・デルタ・バックアップを取得します。 ⑤’インクリメンタル・バックアップ操作の記録が回復活動記録ファイルに追記されます。 ⑥ データベース全体に障害が発生したとします。 ⑦ PRUNE HISTORY コマンドをWITH FORCE OPTION をつけて実行し、記録を削除します。 ⑧ インクリメンタル・バックアップをリストアします。AUTOMATIC オプションの使用および db2ckrst コマンドはエラーとなり ます。 順番を確認しながらそれぞれのイメージに対して RESTORE コマンドを実行することは可能です。 ⑨ リストアをARORTし、インクリメンタル・リストアの処理中に作成されたリソースをクリーンアップします。 ⑩ ⑤のバックアップイメージに対して RESTORE コマンドを HISTORY FILE オプションを指定して実行することで、回復活 動記録ファイルを復元することができます。 ⑪ 回復活動記録ファイルが復元されていれば、AUTOMATIC オプションを指定してリストアが可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 63-64 DB2 UDB運用管理 3. 回復の手順 解説： 回復活動記録ファイルの消失からの回復シナリオ(2/6) データベース全体のフルバックアップを取得します。（① ①） db2 "backup db SAMPLE to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010525135630 です。 データベースに接続し、t1表に10行Insert （② ②）した後、Incremental バックアップを取得します。（③ ③） db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------10 1 レコードが選択されました。 db2 "terminate" DB20000I TERMINATE コマンドが正常に終了しました。 db2 "backup db SAMPLE incremental to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010525135703 です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 回復活動記録ファイルの消失からの回復シナリオ(3/6) さらに、t1表に10行 Insert した後、Delta バックアップを取得します。 db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------20 1 レコードが選択されました。 db2 "terminate" DB20000I TERMINATE コマンドが正常に終了しました。 db2 "backup db SAMPLE incremental delta to /backup" バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010525135724 です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 65-66 DB2 UDB運用管理 3. 回復の手順 解説： 回復活動記録ファイルの消失からの回復シナリオ(4/6) ここで、最後に取得したDelta バックアップを指定して、db2ckrst ユーティリティーを実行すると、どのバックアップ・イメージを、どの 順番でリストアすればよいかを知ることができます。 db2ckrst -d SAMPLE -t 20010525135724 -r database Suggested restore order of images using timestamp 20010525135724 for database SAMPLE. ==================================================================== restore db SAMPLE incremental taken at 20010525135724 restore db SAMPLE incremental taken at 20010525135630 restore db SAMPLE incremental taken at 20010525135703 restore db SAMPLE incremental taken at 20010525135724 ==================================================================== db2ckrst ユーティリティーは回復活動記録ファイルを参照しています。したがって、ここで回復活動記録ファイルの内容を削除して しまうと、db2ckrst ユーティリティーはエラーとなってしまいます。 db2 "prune history 20010525135724 with force option" DB20000I PRUNE コマンドが正常に終了しました。 db2 "list history all for db SAMPLE" SAMPLE の履歴ファイルのリスト 突き合わせファイル項目数 = 0 db2ckrst -d SAMPLE -t 20010525135724 -r database Error: db2ckrst - Memory allocation Return code of -6 seen at line 1020 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： 回復活動記録ファイルの消失からの回復シナリオ(5/6) また、RESTORE コマンドの INCREMENTAL AUTOMATIC オプションは、db2ckrst ユーティリティーと同様に、回復活動記録ファイ ルが削除されていると、以下のようにエラーとなってしまいます。 db2 "restore db SAMPLE incremental automatic from /backup taken at 20010525135724 without rolling forward without prompting" SQL2571N 自動増分復元を続行できません。 理由コード: "3"。 すなわち、インクリメンタル・バックアップを使用して回復を行う場合、回復活動記録ファイルが正しく保管されていないと、リストア 操作に影響があります。 このような場合は、RESTORE コマンドに HISTORY FILE オプションを指定することで、回復活動記録ファイルのみを復元すること が可能です。（「3-2. 回復活動記録ファイル」参照） まず、リストアをABORT します。 db2 "restore db SAMPLE incremental abort" SQL2001N ユーティリティーへの割り込みが発生しました。 出力データが不完全の可能性があります。 DELTA バックアップ・イメージに含まれる回復活動記録ファイルを復元します。 db2 "restore db SAMPLE history file from /backup taken at 20010525135724" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 回復活動記録ファイルが正常であれば、INCREMENTAL AUTOMATIC オプションを指定したリストアは正常に終了します。 db2 "restore db SAMPLE incremental automatic from /backup taken at 20010525135724 without rolling forward without prompting" SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを 復元中に、警告 "2539" が出されました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 (3-3) 67-68 DB2 UDB運用管理 3. 回復の手順 解説： 回復活動記録ファイルの消失からの回復シナリオ(6/6) また、このように回復活動記録ファイルの内容が削除されてしまった場合には、回復活動記録ファイルを復元しなくても、インクリ メンタル・バックアップのリストアの順番がわかっている場合には、それぞれのイメージを指定して順番にリストアすることは可能で す。 db2 "restore db SAMPLE incremental from /backup taken at 20010525135724 without rolling forward without prompting" SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを 復元中に、警告 "2539" が出されました。 db2 "restore db SAMPLE incremental from /backup taken at 20010525135630" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 db2 "restore db SAMPLE incremental from /backup taken at 20010525135703" DB20000I RESTORE DATABASE コマンドが正常に終了しました。 db2 "restore db SAMPLE incremental from /backup taken at 20010525135724 " DB20000I RESTORE DATABASE コマンドが正常に終了しました。 db2 "connect to SAMPLE" データベース接続情報 データベース・サーバー = DB2/6000 7.2.0 SQL 権限 ID = DB2V7 ローカル・データベース別名 = SAMPLE db2 "select count(*) from t1" 1 ----------20 1 レコードが選択されました。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです (3-3) 69-70 DB2 UDB運用管理 3. 回復の手順 ブランク・ページです ブランク・ページです (3-3) 71-72