...

3. 回復の手順 DB2 UDB運用管理

by user

on
Category: Documents
481

views

Report

Comments

Transcript

3. 回復の手順 DB2 UDB運用管理
DB2 UDB運用管理
3. 回復の手順
3. 回復の手順
お断り:当資料は、DB2 UDB V7.1(UNIX,PC) をベースに作成されています。
(一部、Fixpackに含まれるV7.2の機能についてもふれています。)
<第1.00版>2001年6月
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
3. 回復の手順 (内容)
3-1. 回復手順のシナリオ
3-2. 回復活動記録ファイル
3-3. 増分バックアップ
3-4. コントロールセンターの使用
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 1-2
DB2 UDB運用管理
3. 回復の手順
ブランク・ページです
ブランク・ページです
(3-1) 3-4
DB2 UDB運用管理
3. 回復の手順
3-1. 回復手順のシナリオ
お断り:当資料は、DB2 UDB V7.1(UNIX,PC) をベースに作成されています。
(一部、Fixpackに含まれるV7.2の機能についてもふれています。)
<第1.00版>2001年6月
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
3-1. 回復手順のシナリオ(内容)
3-1-1. 基本的な回復手順
(参考)オフライン状態の作成方法
3-1-2. オンラインバックアップの回復手順
3-1-3. 表スペース単位の回復手順
(参考)効率的な表スペースの回復の方法
3-1-4. Load後の回復手順
3-1-5. UserExit を使用した回復手順
3-1-6. 削除された表の回復手順
3-1-7. システム時間を遅らせた場合の回復に関する考慮点
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 5-6
DB2 UDB運用管理
3. 回復の手順
3-1. 回復手順のシナリオ
本章の内容
「ロールフォワード回復」についての具体的な手順の紹介
ロールフォワード回復の目的
バックアップをリストア後、ログを適用し、データベースをある時点までの状態に戻す
前提
データベースが「回復可能」であること
データベース構成パラメータ logretain = RECOVERY または userexit = YES
必要なバックアップが取得されていること
データベース単位/表スペース単位
オフライン/オンライン
フル・バックアップ/
増分(インクリメンタル、デルタ)バックアップ
更新処理
X月X日
障害発生
アーカイブ・ロギング
BACKUP
RESTORE
X月X日
障害発生の直前の時点まで戻す
ROLLFORWARD
アーカイブ・ロギング
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
3-1. 回復手順のシナリオ
データベースの回復に関する運用計画
障害が起こった時、どの時点まで回復が必要か?
バックアップを実行する間隔はどれくらいか?
障害時にどのくらいの時間で回復しなくてはならないか?
回復時に考慮する要因
オフライン/オンライン
データベース単位/表スペース単位
回復に影響を与えるユーティリティ(LOAD/UserExit)
必要な許可
バックアップ - sysadm、sysctrl、sysmaint のいずれか
既存のデータベースにリストア - sysadm、sysctrl、sysmaint のいずれか
新規のデータベースにリストア - sysadm、sysctrl のいずれか
ロールフォワード - sysadm、syscrtl、sysmaint のいずれか
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 7-8
DB2 UDB運用管理
3. 回復の手順
3-1-1. 基本的なデータベース全体の回復手順
質問(1)
オフラインバックアップ取得後のログファイル削除について
<<< QUESTION >>>
01/02/16 1:47:15
使用環境
WinNT 4.0 / SP5
DB2 V6.1 / FP5
-----------------------------オフラインバックアップ取得後、ログファイルのパス以下にあるファイルは全て削除してしまっても
DBの動作、リカバリーには影響はないでしょうか。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 基本的なデータベース全体の回復手順
回復手順に関する質問(1)
Answer はP.13 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 9-10
DB2 UDB運用管理
3. 回復の手順
3-1-1. 基本的なデータベース全体の回復手順
ロールフォワード回復
バックアップ取得から障害直前までの間の任意時点の状態に回復
データベース全体のオフライン・バックアップ、およびアーカイブ・ログ、アクティブ・ログが必要
データベース全体のオフライン・バックアップの復元→データベース全体のロールフォワード
回復
前提
データベースが「回復可能」
データベース構成パラメータ logretain = RECOVERY または、userexit = YES
オフライン・データベース・バックアップの取得、およびログファイルの保管
リストア後、データベースはロールフォワード保留
ロールフォワードを停止することで、ロールフォワード保留状態は解除される
ただし、以下の場合には、ロールフォワード保留にはならない
データベース構成パラメータ LOGRETAIN および USEREXIT が両方とも NO の場合
RESTORE DATABASE コマンドで、WITHOUT ROLLING FORWARD のオプションを指定した場合
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 基本的なデータベース全体の回復手順
最も基本的な回復方法は、データベース全体のオフライン・バックアップのリストア後、データベース全体のロールフォワードを行
うことです。
これにより、データベースをバックアップ取得後から障害直前までの任意の時点に回復することができます。
データベース全体のオフライン・バックアップ、およびバックアップ取得後から回復したい時点までのログが必要です。
ロールフォワード回復を行うためには、データベースが回復可能である必要があります。すなわち、以下のいずれか、または両方
が必要です。
データベース構成パラメータ logretain = RECOVERY
データベース構成パラメータ userexit = YES
回復の途中で、データベース全体のリストア後にデータベースはロールフォワード保留状態になります。ロールフォワード保留中
はそのデータベースへはアクセスすることができません。ロールフォワード保留状態を解除するためには、(ロールフォワード処理
を行った後)ロールフォワードの停止が必要です。
ロールフォワードを停止するには、STOPまたはCOMPLETEをオプションに指定します。(どちらを指定しても同じ意味を持ちま
す。) 未完了のトランザクションをロールバックし、データベースのロールフォワード保留状態をオフにすることによって、ロール
フォワード回復処理を完了します。これにより、すでにロールフォワードされたデータベースまたは表スペースへのアクセスが認め
られます。
以下のいずれかの場合には、データベースをリストアしてもロールフォワード保留状態にはなりません。
データベース構成パラメータ logretain および userexit が両方とも NO である
リストア時に WITHOUT ROLLING FORWARD オプションを指定した
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 11-12
DB2 UDB運用管理
3. 回復の手順
3-1-1. 基本的なデータベース全体の回復手順
質問(1)の答え
<<< ANSWER >>>
2001/02/16 11:55:10
データベースのオフラインバックアップ後、最初にアプリケーションがDBに接続する前、という意味ですね。
それでしたら問題ありません。最初にアプリケーションがDBに接続した時点で新しくログファイルが作成されます。
ただし、このオペレーションをするに先立ち、ログパス上のログファイルがもう不要であることを確認して下さい。
例えば以下のようなケースでは現在ログパス上にあるログファイルが必要になります。
ユーザーエグジットプログラムを使わず、かつログを保持するような設定(USEREXIT= NO、LOGRETAIN=YES)の環境で、
今回取得した以前のバックアップからのRestore&Rollfowardを行いたい場合
この場合、Rollfowardコマンドの実行にログが必要ですが、ユーザーエグジットを使っていないとすると、その必要な
ログはログパス上に存在しています。ですからこのログを削除してしまったとすると過去のバックアップからの
Restoreを行った後、Rollfowardコマンドの実行ができなくなってしまいます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 基本的なデータベース全体の回復手順
質問(1)の答え。
Question は P.9 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 13-14
DB2 UDB運用管理
3. 回復の手順
3-1-1. 基本的なデータベース全体の回復手順
手順
[前提] データベース全体のオフライン・バックアップの取得
データベース全体のリストア
データベース全体のロールフォワード
データベース(通常運用時)
データベース(回復前)
リストア
オフライン・
バックアップ
バックアップ
ロールフォワード
更新
Application
ログ書き出し
ログ
Application
データベース(回復後)
回復の前提
オフライン=データベースに他のアプリケーションが接続していない状態
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 基本的なデータベース全体の回復手順
回復を行う手順は以下のとおりです。
データベース全体のオフライン・バックアップの取得+ログの保管(前提)
データベース全体のリストア
データベース全体のロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 15-16
DB2 UDB運用管理
3. 回復の手順
3-1-1. 基本的なデータベース全体の回復手順
データベースおよび表スペースの状態
操作
操作後のデータベースの状態
操作後の表スペースの状態
正常
-
ロールフォワード保留
(DATABASE)
-
正常
-
復元保留
-
データベース全体のオフライン・バックアップ取得
データベース全体のオフライン・バックアップのリストア
データベース全体を時刻指定(Point in Time)またはログの最後
(End of Logs)までロールフォワードして停止
データベース全体のロールフォワードをキャンセル
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: データベースおよび表スペースの状態
バックアップを取得するためには、データベースが使用可能な状態である必要があります。(復元保留状態をのぞく)
ロールフォワード回復を行う際には、データベース全体のリストア後にデータベースはロールフォワード保留状態となります。
データベースがロールフォワード保留状態であることは、データベース構成パラメータの「ロールフォワード保留状態 =
DATABASE」となっていることで確認できます。
この状態では、データベースに対するアクセスはできません。
データベース全体をロールフォワード、およびロールフォワードの停止を行うと、データベースのロールフォワード保留状態は解除
されます。
データベース全体のロールフォワードをキャンセルすると、データベースは復元保留状態になり、データベース全体のリストアが
必要となります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 17-18
DB2 UDB運用管理
3. 回復の手順
3-1-1. 基本的なデータベース全体の回復手順
基本的なデータベース全体の回復のシナリオ
障害
通常運用
T1
T0
③
T2
回復処理
通常運用
T3
時間
ロールフォ
ワード保留
データベース
①
★
★
②アーカイブ・ログを保存
End of Logs または
Point in Time まで
データベース全体の
オフライン・バックアップ取得
⑤ アーカイブ・ログ+アクティブ・ログを使用して
④ データベース全体のリストア
ロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 基本的なデータベース全体の回復のシナリオ (1/4)
基本的な回復処理のシナリオは以下の通りです。
シナリオ
① データベース全体のオフライン・バックアップを取得します。
時刻
T0
② データベースに対して更新処理を行います。アーカイブ・ログは削除しないように保存します。
③ データベースに障害が発生し、データベースが使用不能になったとします。
T1
④ ①で取得したオフライン・バックアップをリストアします。
T2
⑤ ②で保管してあったアーカイブ・ログおよびアクティブ・ログを使用してログの最後までロールフォワードを
行い停止します。データベースはログに書き出されている最後のトランザクションがコミットした状態に回復し
ます。(時刻指定でロールフォワードを停止することも可能です。)
T3
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 19-20
DB2 UDB運用管理
3. 回復の手順
解説: 基本的なデータベース全体の回復のシナリオ (2/4)
データベース全体のオフライン・バックアップを取得します。この時点のデータベースを★で表します。(①
①)
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010409170536 です。
データベースの更新処理を行います。(②
②)
データベース全体を復元します。(④
④)
警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。 ここではWITHOUT
PROMPTING オプション(ユーザーの介在を通常必要とするアクションでは代わりにエラー・メッセージを戻す)を指定している
ため、上書きリストアの確認をユーザーが入力する代わりに警告が表示されています。
db2 "restore db SAMPLE from /backup taken at 20010409170536 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
リストアが終了すると、データベースはオフライン・バックアップを取得した時点(★)と同じになります。ただし、データベースは
ロールフォワード保留状態になります。
この状態では、データベースに接続しようとしても、SQL1117N(ロールフォワード保留中)のエラーで接続できません。
db2 "connect to SAMPLE"
SQL1117N ロールフォワード保留中のために、データベース "SAMPLE" の接続または活動化を行なうことはできませ
ん。 SQLSTATE=57019
なお、次のいずれかの場合には、データベースはリストア終了後ロールフォワード保留にはなりません。
データベース構成パラメータ LOGRETAIN および USEREXIT が両方とも NO の場合
RESTORE DATABASE コマンドで、WITHOUT ROLLING FORWARD のオプションを指定した場合
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 基本的なデータベース全体の回復のシナリオ (3/4)
ロールフォワード保留中であることは、データベースの構成情報を表示させることによっても確認できます。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= DATABASE
= NO
ロールフォワード保留を解除するために、データベース全体のロールフォワードを行う必要があります。(Point in Time 指定また
はログの最後(End of Logs)まで。) (⑤
⑤)
db2 "rollforward db SAMPLE to end of logs and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000001.LOG - S0000001.LOG
2001-04-09-08.06.03.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 21-22
DB2 UDB運用管理
3. 回復の手順
解説: 基本的なデータベース全体の回復のシナリオ (4/4)
ロールフォワードが終了すると、データベースに接続することができます。
db2 "connect to SAMPLE"
データベース接続情報
データベース・サーバー
= DB2/6000 7.1.0
SQL 権限 ID
= DB2V7
ローカル・データベース別名 = SAMPLE
ロールフォワード保留が解除されていることは、データベースの構成情報を表示することで確認できます。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= NO
= NO
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
ブランク・ページです
(3-1) 23-24
DB2 UDB運用管理
3. 回復の手順
(参考)オフライン状態の作成方法
質問(2)
UDB7.1Win2000のオフラインバックアップ手順について
<<< QUESTION >>>
2001/04/11 13:10:53
以下の手順でデータベースのオフラインバックアップを取得しようとしていますが、バックアップされない
ケースがあります。
1.force application all
2.10分待つ
3.backup database dwebedi user xxx using xxx to c:\backup
失敗したときのメッセージは以下の通りです。
「SQL1035N データベースは現在使用中です。 SQLSTATE=57019」
これは手順1.と2.の間にアプリケーションから接続要求があったときデータベースがアクティブになって
しまうためだと思われます。
2.でウェイトするのは FORCE APPLICATION ALLコマンドが非同期であるためです。
今のやり方だとこの10分の間に接続要求が発生するとバックアップが取得されません。
データベースを非活動にし、オフラインバックアップを確実に取得できる方法をお教えください。当システムは
夜間停止するためオンラインバックアップは考えておりません。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)オフライン状態の作成方法
質問(2)。
Answer は P. 31 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 25-26
DB2 UDB運用管理
3. 回復の手順
(参考)オフライン状態の作成方法
オフライン=アプリケーションが接続していない状態
FORCE APPLICATION コマンドを実行し、トランザクションがロールバックするのを待つ間に、
他のアプリケーションの接続を防ぐ必要がある
方法
アプリケーションからの接続用とバックアップ取得用に、それぞれ異なるデータベースの別名
を使用する
アプリケーションからの接続ユーザーのCONNECT特権をREVOKEする
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)オフライン状態の作成方法
データベースのオフライン・バックアップを取得する場合には、データベースに対するすべてのアプリケーションの接続を切断する
必要があります。
しかし、FORCE APPLCATION コマンドを実行後、BACKUP DATABASE コマンドを実行するまでの間にアプリケーションが接続し
てしまい、オフライン・バックアップが失敗するという状況が考えられます。
このような場合は、次ページのように別名をアンカタログする方法でアプリケーションからの接続を制御することが可能です。
また、別の方法として、バックアップ前に、アプリケーションからのCONNECT 特権をREVOKEし、バックアップ終了後に GRANT す
るという方法も考えられます。
上記いずれの方法も、オフライン・バックアップ中に接続しようとして返されるエラーに対して、アプリケーション側で対応できるよう
にする必要があります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 27-28
DB2 UDB運用管理
3. 回復の手順
(参考)オフライン状態の作成方法
別名を使用する方法
通常運用時
データベー
ス
Application
Application
Application 用別名
バックアップ用別名
オフライン・バックアップ取得時
Application 用別名を Uncatalog → FORCE APPLICATION コマンドの実行
SQL1013N
データベー
ス
Application
Application 用別名
Application
SQL1013N
バックアップ用別名
オフライン・バックアップ取
得
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)オフライン状態の作成方法
1. データベースに対して、あらかじめアプリケーションの接続用の別名とバックアップ取得用の別名をそれぞれつけておきます。
例えば、SAMPLE という名前のデータベースに対して、アプリケーション接続用に SAMPLE_A という別名を、バックアップ取得用
に SAMPLE_B という別名を作成し、クライアント・アプリケーションからはSAMPLE_A に対して CONNECT させます。
db2 catalog db sample as sample_a
db2 catalog db sample as sample_b
2. オフライン・バックアップを取得する時には、アプリケーション接続用の別名を UNCATALOG します。
db2 uncatalog db sample_a
これにより、この後アプリケーションがデータベースに接続使用とすると、SQL1013Nのエラーとなります。
「SQL1013N データベース別名またはデータベース名 "SAMPLE_A" のログ制御が見つかりませんでした。 SQLSTATE=42705」
この時点では既に接続済みのアプリケーションの接続が切れることはありません。
3. 現在、既に接続済みのアプリケーションをFORCE APPLICATION コマンドにより強制終了します。
db2 force application all
または、db2 list applications on for database sample_a でアプリケーションIDを調べ、そのIDを指定してFORCE APPLICATION を
実行します。この後、必要であればトランザクションがロールバックする時間を取ります。
4. バックアップ取得用の別名を指定して、オフライン・バックアップを取得します。
db2 backup db sample_b to d:\backup
5. バックアップ取得終了後、データベースの別名を再度 CATALOG します。
db2 catalog db sample as sample_a
この方法で取得したバックアップをリストアする場合には、RESTORE コマンドにはバックアップ取得用の別名を指定することにご
注意ください。リストアの際に、元のデータベース名でリストアするには、RESTORE コマンドで INTO 文節を指定します。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 29-30
DB2 UDB運用管理
3. 回復の手順
(参考)オフライン状態の作成方法
質問(2)の答え
<<< ANSW ER >>>
FORCE APPLICATION実 行 後 か ら BACKUP開 始 ま で の 間 に ア ク セ ス の あ る ユ ー ザ を 制 御 す る 方 法 と し ま し て は
以下の様な例が挙げられます。
--例 1 (CATALOG DB で の 制 御 )
(略)
--例 2 (OSコ マ ン ド で の 制 御 )
Windows 環 境 の 場 合 、 OSコ マ ン ド に よ り ユ ー ザ の ア ク セ ス を 制 御 さ せ る 方 法 も あ り ま す 。
1 . OSコ マ ン ド NET USERに よ り 全 ユ ー ザ の ア ク セ ス を 無 効 と し ま す 。
=> NET USER user_id /ACTIVE:NO
2 . 接 続 済 み ユ ー ザ を FORCE APPLICATIONに て 強 制 終 了 さ せ ま す 。
3 . そ の 後 BACKUPを 実 行 さ せ ま す 。
4 . BACKUP終 了 後 OSコ マ ン ド NET USERに よ り ア ク セ ス 無 効 と な っ た 全 ユ ー ザ を 有 効 に し ま す 。
=> NET USER user_id /ACTIVE:YES
--例 3 (CONNECT特 権 で の 制 御 )
DBに ア ク セ ス し て 来 る ユ ー ザ が 管 理 者 権 限 を 持 っ て い な い 場 合 は 一 時 的 に DBへ の 接 続 特 権 を 取 消 す 事 に よ り 制
御する方法もあります。
1 . 管 理 者 ユ ー ザ に て 対 象 DBへ 接 続 後 REVOKEコ マ ン ド に よ り ユ ー ザ か ら CONNECT特 権 を 取 消 し COMMIT後 に DBか
ら切断します。
=> REVOKE CONNECT ON DATABASE FROM USER user_id
2 . 接 続 済 み ユ ー ザ を FORCE APPLICATIONに て 強 制 終 了 さ せ ま す 。
3 . そ の 後 BACKUPを 実 行 さ せ ま す 。
4 . BACKUP終 了 後 に 再 度 、 管 理 者 ユ ー ザ に て DB接 続 後 GRANTコ マ ン ド に よ り CONNECT特 権 を 取 消 し た ユ ー ザ へ 特
権 を 付 与 し COMMITを 行 い ま す 。
=> GRANT CONNECT ON DATABASE TO USER user_id
上 記 方 法 は い ず れ も DB2コ マ ン ド ま た は OSコ マ ン ド に よ り BACKUP終 了 ま で の 間 、 ユ ー ザ の ア ク セ ス 制 御 が 可 能
となります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)オフライン状態の作成方法
質問(2)の答え。
Question は P. 25 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 31-32
DB2 UDB運用管理
3. 回復の手順
3-1-2. オンラインバックアップの回復手順
バックアップをオンラインで取得可能
「オンライン」とは、バックアップ操作中に他のアプリケーションがそのデータベースに接続でき
るという意味
オフライン・バックアップより時間がかかる
BACKUP コマンドで ONLINE オプションを指定
前提
データベースが「回復可能」
データベース構成パラメータ logretain = RECOVERY または、userexit = YES
オンライン・バックアップの取得、およびオンライン・バックアップ開始以降のログの保管
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: オンラインバックアップの回復手順
バックアップ処理は、オンラインで行うことが可能です。ここで、オンラインとは、バックアップ操作中に他のアプリケーションがその
データベースに接続できるという意味です。
一般的に、オンライン・バックアップの方がオフライン・バックアップより時間がかかります。
データベースは回復可能である必要があります。回復可能であるためには、以下のいずれか、または両方が必要です。
データベース構成パラメータ logretain = RECOVERY
データベース構成パラメータ userexit = YES
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 33-34
DB2 UDB運用管理
3. 回復の手順
3-1-2. オンラインバックアップの回復手順
注意点
リストア、ロールフォワードはオフラインで行う必要がある
回復には、オンライン・バックアップ取得終了時点までのロールフォワードが必要(必須)
必要なログファイルは、LIST HISTORY コマンドで確認
リストア時にWITHOUT ROLLING FORWARD オプションは使用できない
オンライン・バックアップ取得時に、バッファープールのダーティーページがディスクにフラッ
シュされる
表スペース上のオブジェクトに対するDDLが未コミットの場合、オンライン・バックアップはロッ
ク待ちになる
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: オンラインバックアップの回復手順
オンライン・バックアップ操作では、バックアップ処理中に他のアプリケーションによってデータベースの更新が行われる可能性が
あります。したがって、オンライン・バックアップからのリストア時には、オンライン・バックアップ開始時点から終了時点までの更新
ログを使用してロールフォワードを行わなければなりません。
リストアに必要なログファイルは、LIST HISTORY コマンドを使用して確認することができます。(「3-2. 回復活動記録ファイル」参
照)
データベース全体のリストア、ロールフォワードはオフラインで行う必要があります。
オンライン・バックアップからのリストア後には、データベースは必ずロールフォワード保留となります。リストア時のWITHOUT
ROLLING FORWARD オプションを指定すると、「SQL2537N 復元後のロールフォワードが必要です。」というエラーになります。
オンライン・バックアップ取得時には、バッファープール上のダーティーページがディスクにフラッシュされます。したがって、大きな
サイズのバッファープールを使用して、大量のデータを更新中にオンライン・バックアップを取得すると、大きなオーバーヘッドを生
じる可能性があります。
オライン・バックアップは、表スペースにINロックを取得します。したがって、表スペースにINロックと互換性がないロックを取得する
DDL文を実行し、未コミットのままの場合は、オンライン・バックアップがロック待ちとなってしまいます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 35-36
DB2 UDB運用管理
3. 回復の手順
3-1-2. オンラインバックアップの回復手順
手順
データベース(回復前)
[前提]オンライン・バックアップの取得+ログの保管
バックアップのリストア
オンライン・バックアップ取得完了時点以降、任意の時点までの
ロールフォワード
データベース(通常運用時)
リストア+
ロールフォワード
更新
バックアップ
Application
オンライン・
バックアップ
Application
Application
ログ
ロールフォワード
更新
ログ書き出し
Application
ログ
データベース(回復後)
回復の前提
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: オンラインバックアップの回復手順
データベース全体のオンラインでの回復は、以下の手順で行います。
オンライン・バックアップの取得+ログの保管(前提)
バックアップよりデータベース全体のリストア(オフライン)
オンライン・バックアップ取得完了時点以降、任意の時点までのデータベース全体のロールフォワード(オフライン)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 37-38
DB2 UDB運用管理
3. 回復の手順
3-1-2. オンラインバックアップの回復手順
データベースおよび表スペースの状態
操作
操作後のデータベースの状態
操作後の表スペースの状態
正常
-
ロールフォワード保留
(DATABASE)
-
正常
-
データベース全体のオンライン・バックアップ取得
データベース全体のオンライン・バックアップのリストア
データベース全体をオンライン・バックアップ取得完了以降、時刻
指定(Point in Time)またはログの最後(End of Logs)までロール
フォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: データベースおよび表スペースの状態
バックアップを取得するためには、データベースが使用可能な状態である必要があります。
オンライン・バックアップからのリストアを行う際には、データベース全体のリストア後にデータベースは必ずロールフォワード保留
状態となります。
データベースがロールフォワード保留状態であることは、データベース構成パラメータの「ロールフォワード保留状態 =
DATABASE」となっていることで確認できます。
この状態では、データベースに対するアクセスはできません。
データベースは、オンライン・バックアップ取得完了時点までロールフォワードを行う必要があります。
データベース全体をロールフォワードを行い、オンライン・バックアップ取得完了時点以降の時点でロールフォワードの停止を行
と、データベースのロールフォワード保留状態は解除されます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 39-40
DB2 UDB運用管理
3. 回復の手順
3-1-2. オンラインバックアップの回復手順
オンラインバックアップの回復のシナリオ
障害
通常運用
T1
T0
①
データベース
②
★
通常運用
T4
T5
時間
⑤
データベース全体の
オンライン・バックアップ バックアップ
取得終了
取得開始
バックアップ取得中の
アーカイブ・ログを保存
回復処理
T3
T2
③
ロールフォ
ワード保留
アーカイブ・ログを保存
⑥ アーカイブ・ログを使用してデータベース全体を
★
End of Logs または
Point in Time まで
⑦ データベース全体をロールフォワード
ロールフォワード(必須)
④ データベース全体のリストア
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: オンラインバックアップの回復のシナリオ (1/5)
オンラインでのデータベース全体の回復のシナリオは以下の通りです。
シナリオ
時刻
① オンラインでデータベース全体のバックアップを取得開始します。
バックアップ取得中も他のアプリケーションがデータベースに対して更新操作を行います。
T0
② オンライン・バックアップの取得が完了します。
その後もアプリケーションがデータベースに対して更新操作を行います。
T1
③ データベースに障害が発生し、データベースが使用不能になったとします。
T2
④ ①で取得したデータベース全体のバックアップをリストアします。
T3
⑤ リストア終了後、データベースはロールフォワード保留状態になります。
⑥ オンライン・バックアップ取得中のログを使用して、データベース全体のロールフォワードを行います。
T4
⑦ ⑥に続いてバックアップ取得後のログを使用して、ログの最後までロールフォワードを行い、停止します。
(通常は⑥と⑦を区別せず一連のロールフォワード操作として行います。)
T5
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 41-42
DB2 UDB運用管理
3. 回復の手順
解説: オンラインバックアップの回復のシナリオ (2/5)
データベース全体のバックアップをオンラインで取得します。(①
①)オンラインでバックアップを取得しているため、バックアップ取得
中もデータベースの更新が可能です。バックアップ取得終了時点のデータベースの状態を★で表します。(②
②)
db2 "backup db SAMPLE online to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010410231757 です。
データベースの更新処理を行います。その後、データベースに障害が発生し、データベースが使用不能になったとします。(③
③)
データベース全体を復元します。(④
④)
警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010410231757 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
リストアが終了すると、データベースはロールフォワード保留状態になります。(⑤
⑤)
この状態では、データベースに接続しようとしても、SQL1117N(ロールフォワード保留中)のエラーで接続できません。
db2 "connect to SAMPLE"
SQL1117N ロールフォワード保留中のために、データベース "SAMPLE" の接続または活動化を行なうことはできませ
ん。 SQLSTATE=57019
なお、データベースのオンライン・バックアップを取得した場合には、WITHOUT ROLLING FORWARD オプションを指定した場合で
も、リストア終了後に必ずロールフォワード保留になります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: オンラインバックアップの回復のシナリオ (3/5)
ロールフォワード保留中であることは、データベースの構成情報を表示させることによっても確認できます。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= DATABASE
= NO
オンライン・バックアップを復元した場合には、少なくともオンライン・バックアップが終了した時点までデータベース全体のロール
⑥)
フォワードを行う必要があります。この終了時点でデータベースの状態は★となります。(⑥
当然、オンライン・バックアップが終了した時点以降、Point in Time または ログの最後まで(End of Logs)一度にロールフォワード
を行うことが可能です。
オンライン・バックアップが終了した時点以前を指定してロールフォワードを行おうとすると、SQL1275Nのエラーで失敗します。
db2 "rollforward db SAMPLE to 2001-4-10.14.18.14 and stop"
SQL1275N ノード "0" のデータベース "SAMPLE" が指定した時間より前の情報を含んでいるため、ロールフォワード
に渡される停止時刻は、"2001-04-10-14.18.22.000000" 以降 または同等でなければなりません。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 43-44
DB2 UDB運用管理
3. 回復の手順
解説: オンラインバックアップの回復のシナリオ (4/5)
このとき、データベースは、ロールフォワード保留 = DATABASE、復元保留中 = YES となります。すなわち、このときに可能な操
作は、以下のいずれかの操作のみです。
指定する停止時刻をエラーメッセージに表示された時刻以降にしてロールフォワードを再び行う。
再度バックアップからの復元を行う。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= DATABASE
= YES
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: オンラインバックアップの回復のシナリオ (5/5)
正しい停止時刻を指定してロールフォワードおよび停止を行うことにより、データベースのロールフォワード保留状態は解除されま
す。(⑦
⑦)
db2 "rollforward db SAMPLE to 2001-4-10.14.18.24 and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000010.LOG - S0000011.LOG
2001-04-10-14.18.23.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 45-46
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
質問(3) オンラインバックアップのリストア
<<< QUESTION >>>2000/01/12 20:09:16
DB2のオンライン・バックアップでユーザー表スペース全体のバックアップを毎日取得しています。
このバックアップをリストアする際、ROLLFORWARDをさせたくない(バックアップを取得した
時点に戻したい)のですが、可能でしょうか?
ちなみに、以下のコマンドでバックアップ/リストアしてみましたが、リストア後、データベースへ
アクセスできなくなり、ROLLFORWARDしたところ状況が回避されました。
backup db kyotu2 user kyotu2 using kyotu2 tablespace USERSPACE1 to /SDBDev/tmp/20000107
restore db kyotu2 user kyotu2 using kyotu2 tablespace(USERSPACE1) from /SDBDev/tmp/20000107
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復手順
質問(3)。
Answer は P. 53 を参照。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 47-48
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
表スペース単位で回復可能
個々の表スペースごとにバックアップ、リストア、ロールフォワードすることが可能
表スペースに対する回復操作はオンラインで実行可能
データベース全体のバックアップ・イメージから特定の表スペースのみを回復可能
前提
データベースが「回復可能」
データベース構成パラメータ logretain = RECOVERY または、userexit = YES
データベースのバックアップ取得、または表スペースのバックアップ取得、およびログの保管
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復手順
データベースの表スペース単位でバックアップ、リストア、ロールフォワードを行うことが可能です。
表スペースに対する回復操作(表スペース単位でのバックアップ、リストア、ロールフォワード)はオンラインで実行することが可能
です。ただし、リストア、およびロールフォワードでは、その処理中はその表スペースに対するアクセスはできません。他の表ス
ペースに対するアクセスは可能です。
データベース全体のバックアップ・イメージから、特定の表スペースのみをリストア・ロールフォワードすることが可能です。
リストアした表スペースを他の表スペースと整合を保つためには、ログの最後まで(または表スペースを最後に更新した時点ま
で)表スペースのロールフォワードを行う必要があります。
したがって、表スペースのバックアップ・リストアを行うためには、データベースが回復可能である必要があります。回復可能であ
るためには、以下のいずれか、または両方が必要です。
データベース構成パラメータ logretain = RECOVERY
データベース構成パラメータ userexit = YES
回復可能でない場合に、表スペースのバックアップを取得しようとすると、「SQL2421N ロールフォワード回復が使用できないため
に、表スペース・レベルのバックアップが許されません。」というエラーになります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 49-50
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
注意点
表スペースのバックアップをリストア後、その表スペースはロールフォワードが必須
表スペースのバックアップから新規のデータベースをリストアすることはできない
複数の表スペースにまたがる表がある場合は、それらの表スペースを同時に回復
一時表スペースを含めると表スペース・バックアップはエラー
少なくとも表スペースの最小回復時間まではロールフォワードが必要
最小回復時間とは、表スペースまたは表スペース内の表に対して、一番最近DDL ステートメント実行された時間
表スペースの名前を変更した場合
変更後の名前を指定してリストア、ロールフォワードが必要
その変更した時点までロールフォワードが必要
カタログ表スペースはPoint in Time でロールフォワード不可能
削除された表スペースは、その表スペースのバックアップからではリストアできない。
リストア前に同じ名前で表スペースを再作成してもリストアはできない。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復手順
表スペースのリストアを行った場合、その表スペースはロールフォワード保留状態になり、ロールフォワード処理を行うことが必須
となります。
新規のデータベースに表スペースのバックアップを復元することはできません。 バックアップ・イメージから新規にデータベースを
リストアするには、データベース全体のバックアップが必要です。
複数の表スペースにまたがる表が存在する場合、それらの表スペースは同時に回復を行う必要があります。例えば、REGULAR
データ、索引、LOB をそれぞれ別のDMS表スペースに保管している場合、それらの表スペースは同時に回復処理を行わなけれ
ばなりません。同時に回復されない場合、表スペースのロールフォワード処理で、「SQL4906N 指定された表スペース名のリスト
は、ロールフォワード操作の設定を完了していません。」というエラーになります。
データベース内の一時表スペースを明示的にバックアップの対象の表スペースに含めると、バックアップ・コマンドは、例えば、
「SQL2066N 指定された表スペース名 "TEMPSPACE1"がデータベースに存在しないか、またはユーティリティーの操作に使用で
きません。」というエラーとなります。
表スペースをリストアする場合、最小回復時間より新しい時間まではロールフォワード処理をする必要があります。最小回復時間
とは、もっとも最近の表スペースまたは表スペース内の表に対してDDLが実行された時間です。DDLが実行されるとシステム・カタ
ログ表が更新されるため、カタログ表と回復を行っている表スペースの整合性のために、この制限があります。
表スペースのバックアップを取得した後、表スペースの名前を変更(RENAME)した場合、表スペースのバックアップ・イメージから
リストアする際には、変更後の名前を指定する必要があります。
カタログ表スペース(SYSCATSPACE)をリストアした場合、ログの最後までロールフォワードを行わなくてはいけません。これはシ
ステム・カタログは常に他のすべての表スペースと整合性を保たなくてはならないためです。
カタログ表スペースに対して Point in Time を指定してロールフォワードを実行すると、「SQL1274N データベース "sample"に
ロールフォワード回復が必要であり、時刻はログの最後に設定する必要があります。」というエラーになります。
削除された表スペースを、削除前に取得した表スペースのバックアップ・イメージからリストア使用とすると「SQL2549」のエラーと
なります。これは、削除された表スペースを同じ名前で再作成してリストアしようとしても同様です。この場合は、データベースの
バックアップからリストアする必要があります。 (C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 51-52
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
質問(3)の答え
<<< ANSWER >>> 2000/01/13 (木) 9:32:57
表スペース単位のバックアップをリストアする場合には、リストア後に必ずROLLFOWARDを実行することが
必須です。DDLを最後に実行したタイミングを越えていれば、ROLLFORWARDを時間指定で行うことが可能で
す。
データベースにアクセスできなかったという現象は、リストアした表スペースが、ロールフォワード保留
という状態になっていたことが原因であると考えられます。
Copyright 2000, IBM Japan Systems Engineering Co.,Ltd.
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復手順
質問(3)の答え。
Question は P. 47 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 53-54
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
手順
[前提] データベース全体、または表スペース・バックアップの取得
(オンライン、またはオフライン)+ログの保管
データベース(回復前)
表スペースのリストア(オンライン、またはオフライン)
表スペースのロールフォワード(オンライン、またはオフライン)
データベース(通常運用時)
表スペース
表スペースリストア
表スペース
バックアップ
Application
バックアップ
表スペース
ロールフォワード
更新
Application
ログ書き出し
ログ
データベース(回復後)
回復の前提(表スペースのバックアップをオフラインで取る場合)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復手順
表スペース単位の回復手順は以下の通りです。
データベース全体、または表スペースのオフライン、またはオンラインバックアップの取得、およびログの保管が前提
回復したい表スペースを含むバックアップから、その表スペースのみをリストア
リストアした表スペースをロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 55-56
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
データベースおよび表スペースの状態
操作
操作後のデータベースの状態
操作後の表スペースの状態
正常
正常
(0x0000)
ロールフォワード保留
(TABLESPACE)
ロールフォワード保留中
(0x0080)
正常
正常
(0x0000)
表スペースのバックアップ取得
表スペースバックアップのリストア
表スペースをログの最後(End of Logs)までロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: データベースおよび表スペースの状態
バックアップを取得するためには、データベースが使用可能な状態である必要があります。
表スペース単位のバックアップ/リストアを行うためには、データベースが回復可能である必要があります。
バックアップからのリストアを行う際には、表スペースのリストア後にその表スペースは必ずロールフォワード保留状態となりま
す。
表スペースがロールフォワード保留状態であることは、データベース構成パラメータの「ロールフォワード保留状態 =
TABLESPACE」となっていること、およびLIST TABLESPACES コマンドで、状況が「0x0080(ロールフォワード保留中)」であること
から確認できます。
この状態では、その表スペースに対するアクセスはできません。他の表スペースにはアクセスが可能です。
表スペースをログの最後までロールフォワードし停止すると、表スペースのロールフォワード保留状態は解除されます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 57-58
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
表スペース単位の回復のシナリオ(1)
End of Logs までロールフォワードする場合
通常運用
T0
T1
データベース全体
表スペース1
①
データベース全体、または
表スペース1 の
オフライン・バックアップ取得
回復処理
障害
▲③
② アーカイブ・ログを保存
時間
T3
T2
▲
⑤
0x80
▲
★
通常運用
▲
★
End of Logs まで
④ 表スペース1 のみリストア
⑥ アーカイブ・ログ+アクティブ・ログを使用して
表スペース1のみロールフォワード
表スペースの状況
0x80 : ロールフォワード保留中
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(1) (1/5)
表スペースの回復で、ログの最後までロールフォワードする場合のシナリオを以下に示します。
シナリオ
① オフラインでデータベースまたは表スペースのバックアップを取得します。
時刻
T0
② データベースの更新操作を行います。更新はログに記録されます。
③ データベースに障害が発生し、1つの表スペースのみが使用不能になったとします。
T1
④ ①で取得したデータベースまたは表スペースのバックアップより表スペースのみをリストアします。
T2
⑤ 表スペースはロールフォワード保留状態になります。
⑥ ②のログを使用して、表スペースをログの最後までロールフォワードします。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 59-60
T3
DB2 UDB運用管理
3. 回復の手順
解説: 表スペース単位の回復のシナリオ(1) (2/5)
表スペース(tbsp1)のオフライン・バックアップを取得します。この時点のデータベースを★で表します。(①
①)
db2 "backup db SAMPLE tablespace(tbsp1) to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010412111238 です。
データベースの更新処理を行います。(②
②)
データベースに障害が発生し、表スペース tbsp1 のみ使用不能になったとします。(③
③)
表スペース tbsp1のみリストアします。(④
④)
db2 "restore db SAMPLE tablespace(tbsp1) from /backup taken at 20010412111238 without prompting"
DB20000I RESTORE DATABASE コマンドが正常に終了しました。
リストアが終了すると、表スペース tbsp1はオフライン・バックアップを取得した時点(★)と同じになります。ただし、この表スペー
ス tbsp1はロールフォワード保留状態になります。(⑤
⑤)
この状態では、データベースに接続は可能ですが、ロールフォワード保留状態の表スペースへのアクセスは、SQL0290 でエラー
となります。例えば、表スペース1(tbsp1)上に作成したTEST表に対して、SELECT 文を実行すると、次のようになります。
db2 "select * from test"
C1
C2
----------- ---------SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(1) (3/5)
表スペース tbsp1がロールフォワード保留中であることは、データベースの構成情報を表示させることによっても確認できます。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= TABLESPACE
= NO
LIST TABLESPACES コマンドで、どの表スペースがロールフォワード保留中かを確認することができます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
ロールフォワード保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0080
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 61-62
DB2 UDB運用管理
3. 回復の手順
解説: 表スペース単位の回復のシナリオ(1) (4/5)
ロールフォワード保留を解除するために、表スペース tbsp1のロールフォワード(Point in Time 指定またはログの最後(End of
Logs)まで) および停止を行う必要があります。(⑥
⑥)
db2 "rollforward db SAMPLE to end of logs and stop tablespace(tbsp1)"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
= SAMPLE
= 1
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
=
=
=
=
=
0
not pending
S0000025.LOG
2001-04-12-02.46.20.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(1) (5/5)
ロールフォワード保留の解除はデータベースの構成情報より確認できます。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= NO
= NO
また、LIST TABLESPACES コマンドでもロールフォワード保留が解除されたことを確認することができます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
正常
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0000
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 63-64
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
表スペースのPoint in Time でロールフォワードする際の注意点
ロールフォワード完了後に表スペースはバックアップ保留
表スペースをPoint in Timeでロールフォワード実行後の操作
Point in Time で表スペースをロールフォワード実行後、表スペースはバックアップ保留
→表スペースのバックアップ取得
その時刻を越して、再度ロールフォワードを実行すると、表スペースは復元保留
→表スペースのバックアップをリストア
リストア後、表スペースはロールフォワード保留
→表スペースのロールフォワード
データベースのリストア後、表スペースのリストアをデータベース全体
のロールフォワード前に実行することも可能
表スペースに対してロールフォワードを2度行う手間を防ぐ
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペースのPoint in Time でロールフォワードする際の注意点
Point in Time を指定してロールフォワードを行った表スペースを含むデータベース全体をリストア、およびログの最後までロール
フォワードする場合を考えます。
表スペースを Point in Time でロールフォワードを行って停止すると、ロールフォワードを停止した時点と現在の時点との間に表ス
ペースに対してなされた更新は失われます。ただし、ログファイルにはその更新情報は他の表スペースの更新情報とともに残って
います。
もし、そのログファイルを使用して、以前のPoint in Time の時間を超えてロールフォワードを行った場合、表スペースには失われ
たはずの更新が再度適用されてしまうことになります。この場合、表スペースの内容は正しくない状態となるため、使用不能(復元
保留)となってしまいます。
このような状態の時に表スペースを使用可能にするために、Point in Time で表スペースのロールフォワードを停止すると、その
表スペースはバックアップ保留状態となり、表スペースのバックアップを取得する必要があります。もし、上記のように内容が正しく
ない状態となった場合には、この表スペースのバックアップをリストアすることにより、最初にPoint in Time でロールフォワードを
停止した状態に戻すことができます。そこから新たにロールフォワードを行うことにより表スペースの整合性は保たれます。
ただし、この場合は、一度データベース全体をロールフォワードした後、表スペースをリストア・ロールフォワードすることになり、表
スペースはいわば、2度ロールフォワードが実行される状態です。これを防ぐために、データベース全体のロールフォワードを行う
前に、まず復元保留になる表スペースを先にリストアすることができます。この場合、データベース全体のロールフォワードプロセ
スは、先にリストアされた表スペースに対する処理は行わないため、表スペースが2度ロールフォワード処理されることはありませ
ん。(「(参考)効率的な表スペースの回復の方法」参照)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 65-66
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
データベースおよび表スペースの状態
操作
操作後のデータベースの状態
操作後の表スペースの状態
正常
正常
(0x0000)
ロールフォワード保留
(TABLESPACE)
ロールフォワード保留中
(0x0080)
表スペースを時刻指定(Point in Time)でロールフォワード
正常
バックアップ保留中
(0x0020)
表スペースのバックアップ取得
正常
正常
(0x0000)
ロールフォワード保留
(DATABASE)
-
正常
復元保留中
(0x0100)
ロールフォワード保留
(TABLESPACE)
ロールフォワード保留中
(0x0080)
正常
正常
(0x0000)
データベースのバックアップ取得
表スペースのリストア
データベース全体のリストア
データベース全体をログの最後までロールフォワード
表スペースバックアップのリストア
表スペースをログの最後までロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: データベースおよび表スペースの状態
表スペースをリストアすると、その表スペースはロールフォワード保留状態になります。これは、データベース構成パラメータおよ
びLIST TABLESPACES コマンドで確認できます。
表スペースをPoint in Time でロールフォワードおよび停止すると、その表スペースはバックアップ保留状態になります。
表スペースのバックアップ(またはデータベース全体のバックアップ)を取得することにより、表スペースのバックアップ保留状態は
解除されます。
その後、データベース全体のリストアをします。データベースはロールフォワード保留状態になります。
データベース全体をログの最後までロールフォワードします。すると、先ほどPoint in Time でロールフォワードを行った表スペース
は、そのPoint in Time で指定した時刻を越して再度ロールフォワードを行ったことになるため、復元保留状態になります。
表スペースのバックアップイメージからリストアします。表スペースはロールフォワード保留状態になります。
表スペースをログの最後までロールフォワードし、停止します。するとデータベース、表スペースともに正常な状態となります。
表スペースのロールフォワードをPoint in Time で行った場合には、上記の手順を繰り返すことになります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 67-68
DB2 UDB運用管理
3. 回復の手順
3-1-3. 表スペース単位の回復手順
表スペース単位の回復のシナリオ(2)
Point in Time 指定でロールフォワードした後の回復
通常運用
Ta
T0
通常運用 障害
回復処理
障害
T1
T3
T2
T4
T5
データベース全体
表スペース tbsp1
⑤
② アーカイブ・ログを保存
③
★
0x80
★
▲
★
⑭ 0x100 0x80 ⑯
0x20
☆
▲
End of logs まで
▲
End of Logs まで
Point in Time
(Ta) まで
表スペースのみ
☆
⑥ ロールフォワード
①
データベース全体の
オフライン・
バックアップ取得
⑦ ログを保存
⑨
▲
★
☆
時間
ロールフォ
ワード保留
⑩
★
通常運用
⑫ 回復処理
T6
④ 表スペース のみリストア
⑪ データベース全体のリストア
⑬ データベース全体のロールフォワード
表スペースの状況
0x80 : ロールフォワード保留中
0x20 : バックアップ保留中
0x100 : 復元保留中
⑬
⑧ 表スペース の
データベース全体の
ロールフォワード
バックアップ
取得(必須)
⑮ 表スペースのリストア
⑰
表スペースの
ロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(2) (1/9)
表スペースを Point in Time 指定でロールフォワード回復した後のデータベースの回復に関するシナリオは以下のとおりです。
シナリオ
① オフラインでデータベースのバックアップを取得します。
時刻
T0
② データベースの更新操作を行います。更新はログに記録されます。
③ データベースに障害が発生し、1つの表スペースのみが使用不能になったとします。
T1
④ ①で取得したデータベースのバックアップより表スペースのみをリストアします。
T2
⑤ 表スペースはロールフォワード保留状態になります。
⑥ ②のログを使用して、表スペースをPoint in Time (Ta) までロールフォワード・停止します。
T3
⑦ 表スペースはバックアップ保留状態になります。
⑧ 表スペースのバックアップを取得し、バックアップ保留状態を解除します。
⑨ データベースの更新操作を行います。更新はログに記録されます。
⑩ データベースに障害が発生し、データベース全体が使用不能になったとします。
T4
⑪ ①で取得したデータベースのバックアップよりデータベース全体をリストアします。
T5
⑫ データベースはロールフォワード保留状態になります。
⑬ データベース全体をログの最後までロールフォワード・停止します。
⑭ 表スペースが復元保留となります。
⑮ ⑧で取得した表スペースのバックアップより表スペースをリストアします。
⑯ 表スペースはロールフォワード保留となります。
⑰ ⑨のログを使用して表スペースをログの最後までロールフォワード・停止します。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 69-70
T6
DB2 UDB運用管理
3. 回復の手順
解説: 表スペース単位の回復のシナリオ(2) (2/9)
データベース全体のオフライン・バックアップを取得します。この時点のデータベースを★で表します。(①
①)
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010412211716 です。
データベースの更新処理を行います。その間のある時刻(Ta)でのデータベースの状態を☆で表します。(②
②)
表スペース tbsp1のみに障害が発生したと仮定し(③
③)、表スペース tbsp1のみ復元します。(④
④)
db2 "restore db SAMPLE tablespace(tbsp1) from /backup taken at 20010412211716 without prompting"
DB20000I RESTORE DATABASE コマンドが正常に終了しました。
リストアが終了すると、表スペース1はオフライン・バックアップを取得した時点(★)と同じになります。ただし、この表スペース
tbsp1はロールフォワード保留状態になります。(⑤
⑤)
この状態では、データベースに接続は可能ですが、ロールフォワード保留状態の表スペースへのアクセスは、SQL0290 でエラー
となります。例えば、表スペース tbsp1上に作成したTEST表に対して、SELECT 文を実行すると、次のようになります。
db2 "select * from test"
C1
C2
----------- ---------SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(2) (3/9)
表スペース tbsp1がロールフォワード保留中であることは、データベースの構成情報を表示させることによっても確認できます。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= TABLESPACE
= NO
LIST TABLESPACES コマンドで、ロールフォワード保留中の表スペースの情報を確認することができます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
ロールフォワード保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0080
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 71-72
DB2 UDB運用管理
3. 回復の手順
解説: 表スペース単位の回復のシナリオ(2) (4/9)
ロールフォワード保留を解除するために、表スペース tbsp1のロールフォワード(Point in Time 指定またはログの最後(End of
Logs)まで) および停止を行う必要があります。ここでは、Ta時刻(例では2001-4-12.12.17.46 CUT)を指定してPoint in Time まで
ロールフォワードして停止します。(⑥
⑥)
db2 "rollforward db SAMPLE to 2001-4-12.12.17.46 and stop tablespace(tbsp1)"
SQL1278W ロールフォワード処理が正常に完了しました。
活動状態あるいは未確定のトランザクションがノード "0" で必要です。
ロールフォワード停止後、表スペース tbsp1は時刻Taの状態(☆)となりますが、他の表スペースは時刻T1の状態です。このとき
表スペース間の整合性はユーザーの責任で保つ必要があります。
表スペースをPoint in Time を指定してロールフォワードを実行・停止すると、表スペースはバックアップ保留状態となります。(⑦
⑦)
表スペース tbsp1 がバックアップ保留状態であることは、LIST TABLESPACES コマンドで確認できます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
バックアップ保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0020
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(2) (5/9)
バックアップ保留状態では、その表スペース上の表の照会は可能ですが、更新はできません。
db2 "select * from test"
C1
----------2
3
C2
---------BBBB
CCCC
2 レコードが選択されました。
db2 "insert into test values (6,'FFFF')"
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQL
ステートメントとして処理されました。 SQL
処理中に、そのコマンドが返されました。
SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
表スペース tbsp1がバックアップ保留になる理由は、以下の通りです。
この後に時刻TaからT1のログを使用してデータベースのロールフォワードを行った場合に、表スペース tbsp1にもそのログファイ
ルに記録されているトランザクションが適用されてしまい、表スペースの内容が正しくない状態になってしまいます。
しかし、この表スペース tbsp1のバックアップがあれば、それを復元することにより表スペース tbsp1の状態を時刻Taの状態にす
ることができます。このバックアップを必ずとるために、表スペースはバックアップ保留となります。
このシナリオを次に示します。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 73-74
DB2 UDB運用管理
3. 回復の手順
解説: 表スペース単位の回復のシナリオ(2) (6/9)
表スペース tbsp1のバックアップ保留状態を解除するために、表スペースのバックアップを取得します。(⑧
⑧)
db2 "backup db SAMPLE tablespace(tbsp1) to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010412211841 です。
バックアップ保留が解除されると、表スペースに対してアクセスが可能です。(⑨
⑨)
ある時刻T4でデータベース全体に障害が発生し(⑩
⑩)、T0で取得したデータベース全体のバックアップからのリストア、ロールフォ
ワードを行うことになったとします。T4の障害直前のデータベースの状態を▲で表します。
まず、データベース全体をリストアします。(⑪
⑪)
警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010412211716 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
このとき、データベースはロールフォワード保留状態ですので(⑫
⑫)、データベース全体をログの最後までロールフォワードし、停
止します。(⑬
⑬)
db2 "rollforward db SAMPLE to end of logs and stop"
SQL1271W データベース "SAMPLE" は回復されましたが、1 つ以上の表スペースがノード "0" でオフラインです。
このときデータベースの表スペース1以外は▲の状態となります。
SQL1271Wのメッセージは、さきほど時刻Taを指定してPoint in Time でロールフォワードした表スペース tbsp1が、その時刻を越
して再びロールフォワードされたため、表スペースが復元保留状態となり、使用できない状態になっていることを意味しています。
(⑭
⑭)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(2) (7/9)
表スペース tbsp1 の状態はLIST TABLESPACES コマンドを実行して確認することができます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
復元保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0100
この状態では、表スペースに対するアクセスは許されません。
db2 "insert into test values (8, 'HHHH')"
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQLステートメントとして処理されま
した。 SQL処理中に、そのコマンドが返されました。
SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
db2 "select * from test"
C1
C2
----------- ---------SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 75-76
DB2 UDB運用管理
3. 回復の手順
解説: 表スペース単位の回復のシナリオ(2) (8/9)
表スペースの復元保留を解除するために、時刻T3で取得した表スペースのバックアップをリストアします。(⑮
⑮)
db2 "restore db SAMPLE tablespace(tbsp1) from /backup taken at 20010412211841 without prompting"
DB20000I RESTORE DATABASE コマンドが正常に終了しました。
リストアが終了すると、表スペース tbsp1は時刻T3の状態(=時刻Taの状態=☆)となり、ロールフォワード保留となります。(⑯
⑯)
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
ロールフォワード保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0080
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 表スペース単位の回復のシナリオ(2) (9/9)
表スペースのロールフォワード保留を解除するために、ログの最後までロールフォワードを行い、停止します。(⑰
⑰)
db2 "rollforward db SAMPLE to end of logs and stop tablespace (tbsp1)"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000039.LOG
2001-04-12-12.19.06.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
上の例のようにログの最後までロールフォワードを行い停止すると、表スペースは正常な状態となります。Point in Time を指定し
てロールフォワード停止した場合には、時刻T3のときと同様に表スペースはバックアップ保留状態となりますので、バックアップを
取得する必要があります。
以上の方法では、表スペース1に対して2度ロールフォワード操作を行っています。時刻T5にデータベース全体のリストアを行った
後に続けて表スペース1のりストアを行うことで、表スペース1のロールフォワード操作の重複を防ぐことができます。(「(参考)効率
的な表スペースの回復の方法」参照)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 77-78
DB2 UDB運用管理
3. 回復の手順
(参考)効率的な表スペースの回復の方法
データベース全体のロールフォワード前に表スペースをリストア
データベース全体のリストアの後、データベース全体をロールフォワードする前に、表スペー
スのリストアを行うことにより、効率的に回復が可能
表スペースA
先にデータベースを
ロールフォワード
データベース
ロールフォワード
データベース
表スペースA
ロールフォワード
表スペースA
リストア
データベース
リストア
先にリストアした表スペースAはデータベース・ロールフォワードの対象外
先に表スペースAを
リストア
データベース
ロールフォワード
データベース
リストア
表スペースA
ロールフォワード
表スペースA
リストア
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)効率的な表スペースの回復の方法
データベース全体をロールフォワード回復し、特定の表スペースAのみをデータベース全体と異なる時刻を指定して Point in Time
でロールフォワードの停止をする場合、通常の手順は次のようになります。
データベース全体のリストア
データベース全体のロールフォワード
表スペースAのリストア
表スペースAのロールフォワード
しかし、これでは表スペースAに対して、2度ロールフォワード処理を行っていることになります。
これを防ぐために、以下の手順で回復を行うことができます。
データベース全体のりストア
表スペースAのリストア
データベース全体のロールフォワード
表スペースAのロールフォワード
このように表スペースAをリストアしてからデータベース全体をロールフォワードすることにより、表スペースAに対して2度ロール
フォワード処理が行われることを防ぎ、効率よく回復を行うことができます。
また、以前Point in Time 指定でロールフォワードを行った表スペースを含むデータベース全体を、そのPoint in Time を越して
ロールフォワードする場合には、その表スペースは復元保留となり、Point in Time のロールフォワード停止後に取得した表スペー
スのバックアップをリストアし、再度表スペースのロールフォワードを行わなくてはなりません。
このような場合も上と同様に、まず表スペースのリストアを行うことにより、データベース全体のロールフォワード処理ではその表
スペースに対しては処理が行われません。したがって、より効率よく回復ができることになります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 79-80
DB2 UDB運用管理
3. 回復の手順
(参考)効率的な表スペースの回復の方法
以下のような場合の回復に有効
特定の表スペースのみデータベース全体と異なる時点でロールフォワードの停止をする場合
以前にPoint in Time 指定でロールフォワードの停止をした表スペース(復元保留になる表ス
ペース)を含むデータベース全体を、以前のPoint in Time の時点を越してロールフォワードす
る場合
手順
データベース全体のリストア
表スペースのリストア
データベース全体のロールフォワード
表スペースのロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)効率的な表スペースの回復の方法 (1/3)
次のような場合は、データベース全体のロールフォワードの前に表スペースをリストアすることにより、効率的に回復ができます。
特定の表スペースのみデータベース全体と異なる時点でロールフォワードの停止をする場合
以前に特定の表スペースのみ Point in Time 指定でロールフォワードを停止し、その時点を越してデータベース全体をロール
フォワードする場合
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 81-82
DB2 UDB運用管理
3. 回復の手順
解説: (参考)効率的な表スペースの回復の方法 (2/3)
表スペースをデータベース全体のロールフォワードの前にリストアすることにより、その表スペースにはデータベース全体のロー
ルフォワード処理が適用されないことを確認
Point in Time を指定してロールフォワードを行った表スペースに対して、「再リストア→そのPoint in Time を越す時間を指定して
ロールフォワード」を行った場合、Point in Time から再リストアまでのログが表スペースに再適用されることを確認
STEP
時間
操作
[1]
TESTDBにSMSで表スペースSMS1を作成後、SMS1上に表tab1を作成
[2] T1
TESTDB全体のオフライン・バックアップ取得
[3]
tab1に10行INSERT
左の操作後の表
tab1のサイズ※
4,096
8,192
[4] T2
[5]
tab1に5000行INSERT
[6]
STEP[2]で取得したバックアップからデータベース全体をリストア
2,936,832
4,096
[7]
STEP[2]で取得したバックアップからSMS1のみをリストア
4,096
[8]
TESTDB全体をログの最後までロールフォワード
4,096
[9]
SMS1をT2までロールフォワード
8,192
[10] T3
SMS1の表スペースのバックアップ取得 (SMS1がバックアップ保留のため)
[11]
tab1に10行INSERT
16,384
[12] T4
[13]
tab1をDROP
[14]
STEP[2]で取得したバックアップからデータベース全体をリストア
[15]
TESTDB全体をT4までロールフォワード (SMS1は復元保留)
[16]
STEP[10]で取得した表スペースバックアップをリストア
[17]
SMS1をT4までロールフォワード
4,096
2,936,832
8,192
16,384
(※ tab1 のサイズは、SMSのディレクトリ内に作成される表のデータファイルのサイズ(単位:
KB))
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: (参考)効率的な表スペースの回復の方法 (3/3)
まず、STEP[7] でデータベース全体のロールフォワードの前に、表スペースのみをリストアしています。
その後、STEP[8]でデータベース全体をロールフォワードしているにもかかわらず、表データのサイズが増加していないことより、
データベース全体のロールフォワード前にリストアされた表スペースに関しては、データベース全体のロールフォワードで処理を
行っていないことがわかります。
次に、STEP[9]で、表スペースはPoint in Time (T2) を指定してロールフォワードを停止しているため、この表スペースに関しては
T2からT3の間の更新は破棄されていなくてはなりません。
しかし、STEP [15]で、データベース全体のロールフォワードを行った際に、表データのサイズが4,096バイト(1ページ)から
2,936,832 バイト(717ページ)へと増加しています。
ことから、Point in Time (T2) より後に行って破棄されなくてはならない「STEP[5] 5000行のINSERT操作」が、STEP[15]のデータ
ベース全体のロールフォワード処理で再適用されていることがわかります。なお、この場合は STEP[10] で取得した表スペースの
バックアップをリストアすることで、この5000行のINSERT前の状態に戻り、さらに表スペースのロールフォワードを行うことでデータ
ベース全体が正しく回復されます。
以上より、まず復元回復になる表スペースをリストアしてからデータベース全体をリストアすることで、効率的にロールフォワード回
復を行うことができるということがわかります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 83-84
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
質問(4) バックアップ保留状態での障害に対しての回復について
<<< QUESTION >>>
<環境> AIX 4.3, UDB V6.1
お客様環境にて、下記のようなバックアップ・スケジュールにてDBを運用しております。
1. 月に一度(1日) Database全体のオフラインバックアップ
2. 毎日
SYSCATSPACEとUSER表ペース(4個)毎のオンラインバックアップ
3. 毎日
ArchiveLogのバックアップ
この運用にて、毎日オンラインバックアップの前に、ある1つのUSER表内のテーブルに対して"COPY NO"のオプションでLOAD
を実施しています。
このロード処理の実行中、あるいはロード後に表スペースがバックアップ保留状態となりなっている状態でシステム全障害が発
生し、バックアップからデータを回復する場合の、復元範囲について教えて下さい。
------------------------------------------------------------------------------------------>
△
・・・ △
▲
☆
△
DBのオプライン
各TableSpaceの
表スペース1中の
障害発生
各TableSpaceの
バックアップ
archive logの
表へのLOAD
archive logの
バックアップ
(COPY NO)
バックアップ
1) 障害発生後、システムを起動でき、ディスク上にある障害時までのarchive LogFileが使用できる場合、
・表スペース毎のオンラインバックアップ + アーカイブログによる回復
・オフラインバックアップ + アーカイブログによる回復
共に回復可能なデータの範囲は下の考え方で正しいでしょうか?
・ COPY NOのオプションでLOADを実施した表スペースに対しては、表スペースのLOAD直前までの回復が可能。
・ LOADを実施した以外の表スペースに対しては、最後にCOMMITされた状態までの回復が可能。
2) 1)の場合、回復後、表スペースのバックアップ保留状態は解除されているという理解で正しいでしょうか。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説:
質問(4)。
Answer は P. 89 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 85-86
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
COPY=NOでLOADを行った場合の注意点
回復可能なデータベースでは、COPY=NOでLOAD後、表スペースはバックアップ保留
LOADを行った時点を越してロールフォワードを行うと、表スペースは復元保留
手順
データベース全体をリストア
データベース全体をロールフォワード
LOAD後の表スペースのバックアップからリストア
表スペースをロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=NOでLOADを行った場合の注意点
LOADをCOPY=NOを指定して実行すると、その表を含む表スペースは、LOAD実行後にバックアップ保留となります。
LOADは更新ログをとらないため、COPY=NOでは表スペースはロールフォワード回復ができません。しかし、LOAD実行後に表ス
ペースがバックアップ保留になることで、表スペースのバックアップが取得されるので、後にロールフォワードを実行したときも、そ
の表スペースはLOAD実行後のバックアップをリストアすることで回復が可能となります。
実際に、LOAD実行時点を越してデータベースのロールフォワードを行うと、LOADを実行した表を含む表スペースは復元保留とな
り、LOAD直後に取得した表スペースのバックアップからのリストアが求められます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 87-88
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
質問(4)の答え
<<< ANSWER >>>
1)
ご指摘の通りです。
COPY NO を指定してLOADを行った表スペースに対しては、その表スペースのバックアップイメージを取得
した時点からLOADを行った時点の間の任意の時点のPoint in Time を指定してROLLFORWARDを行うことが
可能です。
LOADを行った時点以降を指定して、ROLLFORWARDを行うと、表スペースは「復元保留」状態となります。
その他の表スペースに対しては、その表スペースのバックアップイメージを取得した時点からログの最後
まで(END OF LOGS)の間の任意の時点にROLLFORWARDすることが可能です。
表スペースをPoint in Time指定でROLLFORWARDした場合には、ROLLFORWARD後にその表スペースはバック
アップ保留となり表スペースのバックアップを取得する必要があることにご注意ください。
2)
バックアップをリストアすることによりLOADコマンドによる表スペースのバックアップ保留状態は解除
されていますが、上記の通り、表スペースに対してPoint in Time を指定して表スペースのROLLFORWARD
を実行すると、その表スペースはバックアップ保留となります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: Load後の回復手順
質問(4)の答え。
Question は P. 85 をご覧下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 89-90
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
データベースおよび表スペースの状態
操作
操作後のデータベースの状態
操作後の表スペースの状態
データベースのバックアップ取得
正常
正常
(0x0000)
表にLOAD(COPY=NO)
正常
バックアップ保留中
(0x0020)
表スペースのバックアップ取得
正常
正常
(0x0000)
ロールフォワード保留
(DATABASE)
-
正常
復元保留中
(0x0100)
ロールフォワード保留
(TABLESPACE)
ロールフォワード保留中
(0x0080)
正常
正常
(0x0000)
データベース全体のリストア
データベース全体をログの最後までロールフォワード
表スペースバックアップのリストア
表スペースをログの最後までロールフォワード
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: データベースおよび表スペースの状態
COPY=NO で表にデータをLOADすると、LOAD実行後に表スペースがバックアップ保留となります。
表スペースのバックアップを取得することで、表スペースは正常な状態となります。
データベース全体をリストアすると、データベース全体がロールフォワード保留となります。
データベース全体をログの最後までロールフォワードします。
LOAD時点を越してロールフォワードを行ったため、表スペースは復元保留となります。
表スペースのバックアップをリストアします。表スペースはロールフォワード保留となります。
表スペースをログの最後までロールフォワードすることで、表スペースは正常な状態となります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 91-92
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
COPY=NOでLoad後のデータベースに対する回復のシナリオ
通常運用
障害
T1
T0
T2 ⑥
⑧
T3
回復処理
通常運用
T4
ロールフォ
ワード保留
T5
時間
データベース全体
★
★
▲
▲
② アーカイブ・ログを保存
End of Logs まで
①
データベース全体の
オフライン・バックアップ
取得
⑨ データベース全体のロールフォワード
④ 0x20
⑦ データベース全体のリストア
⑩ 0x100 0x80 ⑫
表スペース tbsp1
★
☆
③ COPY NOを指定してLOAD
⑤ 表スペース tbsp1 の
オフライン・バックアップ
取得(必須)
☆
▲
▲
End of Logs まで
⑬ 表スペースのロールフォワード
⑪ 表スペースのリストア
表スペースの状況
0x20 : バックアップ保留中
0x100 : 復元保留中
0x80 : ロールフォワード保留中
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (1/7)
COPY=NOでLoad後のデータベースに対する回復のシナリオは以下のとおりです。
シナリオ
① オフラインでデータベースのバックアップを取得します。
時刻
T0
② データベースの更新操作を行います。更新はログに記録されます。
③ COPY=NOを指定して表にデータをLOADします。
T1
④ 表スペースはバックアップ保留状態になります。
⑤ 表スペースのバックアップを取得します。
⑥ データベースに障害が発生し、データベース全体が使用不能になったとします。
T2
⑦ ①のバックアップより、データベース全体をリストアします。
T3
⑧ データベースはロールフォワード保留になります。
⑨ データベース全体をログの最後までロールフォワード・停止します。
⑩ 表スペースが復元保留となります。
T4
⑪ ⑤で取得した表スペースのバックアップより表スペースをリストアします。
⑫ 表スペースはロールフォワード保留状態になります。
⑬ 表スペースをログの最後までロールフォワード・停止します。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 93-94
T5
DB2 UDB運用管理
3. 回復の手順
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (2/7)
データベース全体のオフライン・バックアップを取得します。この時点のデータベースを★で表します。(①
①)
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010413180219 です。
ある時刻T1に表スペースtbsp1上の表TESTに、COPY=NO を指定してデータをLOADします。この直後の表スペースの状態を☆
で表します。(③
③)
LOAD後に、LOADを行った表を含む表スペースは、バックアップ保留状態となります。これは、LOAD実行時には更新ログを取ら
ないため、COPY=NO ではこの表に対してフォワードリカバリーができなくなってしまうためです。(④
④)
表スペースがバックアップ保留状態であることは、LIST TABLESPACES コマンドで確認することができます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
= 3
名前
= TBSP1
タイプ
= データベース管理スペース
内容
= 任意のデータ
状況
= 0x0020
詳しい説明:
バックアップ保留中
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (3/7)
表スペースに対してバックアップ保留のとき、この表スペース上の表に対して、照会は可能ですが更新はエラーになります。
db2 "select * from test"
C1
----------2
3
4
5
6
C2
---------BBBB
CCCC
DDDD
EEEE
FFFF
5 レコードが選択されました。
db2 "insert into test values (7, 'GGGG')"
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQLステートメントとして処理されま
した。 SQL処理中に、そのコマンドが返されました。
SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
表スペースのバックアップ保留状態を解除するためには、この表スペースのバックアップを取得します。(⑤
⑤)
db2 "backup db SAMPLE tablespace(tbsp1) to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは20010413180303 です。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 95-96
DB2 UDB運用管理
3. 回復の手順
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (4/7)
この後、データベース全体に障害が発生し(⑥
⑥)、最初に取得したデータベース全体のバックアップをリストアすることになったとし
ます。障害直前のデータベースの状態を▲で表します。(⑦
⑦)
警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010413180219 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを
復元中に、警告 "2539" が出されました。
リストア後、データベースはロールフォワード保留状態となります。これは、データベースの構成情報を表示させて確認するこがで
きます。(⑧
⑧)
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
= YES
= DATABASE
= NO
データベースのロールフォワード保留状態を解除するには、データベース全体のロールフォワードが必要です。ここでは、ログの
最後まで(End of logs)ロールフォワードを行い、停止します。(⑨
⑨)
db2 "rollforward db SAMPLE to end of logs and stop"
SQL1271W データベース "SAMPLE" は回復されましたが、1 つ以上の表スペースがノード "0" でオフラインです。
ここでデータベースの表スペースtbsp1以外の表スペースは▲の状態となります。(⑩
⑩)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (5/7)
データベース全体のロールフォワード後、データベースに接続し、TEST表にアクセスすると、表スペースがアクセスできないという
エラーになります。これは、表スペース tbsp1 が復元保留となっているためです。
db2 "select * from test"
C1
C2
----------- ---------SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
db2 "insert into test values (8,'HHHH')"
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQLステートメントとして処理されま
した。 SQL処理中に、そのコマンドが返されました。
SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039
LIST TABLESPACES コマンドにより表スペース tbsp1 が復元保留状態であることが確認できます。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
復元保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0100
これは、データベースのロールフォワード処理ではLOAD処理を再実行できず、その後の表が正しい状態になっていないため、
LOAD後に取得した表スペースのバックアップをリストアし、表スペースをLOAD直後の状態(☆)にする必要があることを示してい
ます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 97-98
DB2 UDB運用管理
3. 回復の手順
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (6/7)
LOAD直後に取得した表スペースのバックアップをリストアします。(⑪
⑪)
db2 "restore db SAMPLE from /backup taken at 20010413180303 without prompting"
DB20000I RESTORE DATABASE コマンドが正常に終了しました。
リストアが終了すると、データベースはLOAD直後の状態(☆)になり、ロールフォワード保留状態となります。(⑫
⑫)
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
= 3
名前
= TBSP1
タイプ
= データベース管理スペース
内容
= 任意のデータ
状況
= 0x0080
詳しい説明:
ロールフォワード保留中
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=NOでLoad後のデータベースに対する回復のシナリオ (7/7)
表スペースのロールフォワードおよび停止を行うことで、ロールフォワード保留状態は解除され、表スペースtbsp1 は▲の状態と
なります。(⑬
⑬)
db2 "rollforward db SAMPLE to end of logs and stop tablespace(tbsp1)"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000061.LOG
2001-04-13-09.03.27.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 99-100
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
COPY=YESでLOADを行った場合の回復に関する注意点
COPY=YES の場合はLOAD実行中にコピーファイルを作成
コピーファイルは、ロールフォワードで使用される
コピーファイルを使用したロールフォワード
コピーファイルが存在しない場合、ユーザーに対して継続または中止の入力を促される
コピーファイルを移動してしまうと、ロールフォワード不可能
コピーファイルを正しい位置に戻して継続すれば、ロールフォワードは正常に終了
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=YESでLOADを行った場合の注意点
LOADをCOPY=YESを指定して実行すると、指定した場所に、ロードのコピーファイルを作成します。
LOADは更新ログをとりませんが、このコピーファイルを使用してロールフォワードを行うことができます。
ただし、コピーファイルをLOAD時に指定した場所から移動してしまうと、ロールフォワードプロセスはコピーファイルを見つけること
ができず、ロールフォワードは成功しません。この時点では、表スペースは復元保留となります。
マニュアル「管理の手引き」または「データ移動ユーティリティー手引きおよび解説書」によると、ロードのコピーファイルは、ロケー
ションファイル内に場所を指定し、そのロケーションファイルの位置をDB2LOADREC レジストリ変数に設定することで、コピーファ
イルの場所を移動してもロールフォワードをすることができるはずですが、V7.2現在はこの機能は動きません。(APAR IX86940)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 101-102
DB2 UDB運用管理
3. 回復の手順
3-1-4. Load後の回復手順
COPY=YESでLoad後のデータベースに対する回復のシナリオ
通常運用
T0
T1
T2
障害
回復処理
T3
⑤
ロールフォ
ワード保留
データベース全体
★
② アーカイブ・ログを保存 ▲
★
▲
★
☆
通常運用
時間
⑦
▲
End of Logs まで
表スペース tbsp1
★
T4
▲
End of Logs まで
①
データベース全体の
オフライン・バックアップ
取得
⑥ データベース全体のリストア
⑧ データベース全体のロールフォワード
③ COPY YESを指定してLOAD
④ LOADのコピーファイル
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (1/7)
COPY=YESでLoad後のデータベースに対する回復のシナリオは以下のとおりです。
シナリオ
① オフラインでデータベースのバックアップを取得します。
時刻
T0
② データベースの更新操作を行います。更新はログに記録されます。
③ COPY=YESを指定して表にデータをLOADします。
T1
④ LOADはコピーファイルを作成します。
⑤ データベースに障害が発生し、データベース全体が使用不能になったとします。
T2
⑥ ①のバックアップより、データベース全体をリストアします。
⑦ データベースはロールフォワード保留になります。
T3
⑧ データベース全体をログの最後までロールフォワード・停止します。
T4
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 103-104
DB2 UDB運用管理
3. 回復の手順
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (2/7)
データベース全体のオフライン・バックアップを取得します。この時点のデータベースを★で表します。(①
①)
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010501154817 です。
ある時刻T1に表スペースtbsp1上の表TESTに、COPY=YES を指定してデータをLOADします。この直後の表スペースの状態を☆
で表します。(③
③)
db2 "load from test.ixf of ixf insert into test copy yes to /work/load "
COPY=YES でLOADを行った場合、指定した場所にコピーファイルが作成されます(④
④)。コピー先にディスクを指定した場合、ファ
イルの名前は次のようになります。
(データベース別名).4.(インスタンス名).(ノード番号).(カタログノード番号).(タイムスタンプ).(順序番号)
このシナリオでは、以下のようなファイル名になります。
ls -l /work/load
合計 1336
-rw-r----- 1 db2v7
sys
679960 May 01 15:49 SAMPLE.4.db2v7.NODE0000.CATN0000.20010501154903.001
引き続きデータベースに対する更新操作を行います。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (3/7)
この後、データベースに障害が発生し(⑤
⑤)、最初に取得したデータベース全体のバックアップをリストアすることになったとします。
障害直前のデータベースの状態を▲で表します。(⑥
⑥)
警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010501154817 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
リストア後、データベースはロールフォワード保留状態となります。これは、データベースの構成情報を表示させて確認するこがで
きます。(⑦
⑦)
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
= YES
= DATABASE
= NO
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 105-106
DB2 UDB運用管理
3. 回復の手順
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (4/7)
データベースのロールフォワード保留状態を解除するには、データベース全体のロールフォワードが必要です。ここでは、ログの
最後まで(End of logs)ロールフォワードを行い、停止します。(⑧
⑧)
db2 "rollforward db SAMPLE to end of logs and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
= SAMPLE
= 1
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
=
=
=
=
=
0
not pending
S0000000.LOG - S0000000.LOG
2001-05-01-06.49.09.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
ロードを行った表に関しては、コピーファイルを使用してロールフォワードを行っています。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (5/7)
続いて、LOADのコピーファイルをLOAD実行時に指定した場所から移動してしまった場合のシナリオを示します。
まず、データベースをリストアします。
db2 "restore db SAMPLE from /backup taken at 20010501154817 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを 復元中に、警告 "2539" が出されました。
ここで、LOADのコピーファイルを/work/load ディレクトリから /work/load2 ディレクトリに移動します。
mv /work/load/* /work/load2/
ls -l /work/load
合計 0
ls -l /work/load2
合計 1336
-rw-r----- 1 db2v7
sys
679960 May 01 15:49 SAMPLE.4.db2v7.NODE0000.CATN0000.20010501154903.001
データベースはロールフォワード保留中です。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= DATABASE
= NO
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 107-108
DB2 UDB運用管理
3. 回復の手順
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (6/7)
ログの最後までロールフォワードを行います。
すると、LOADのコピーファイルが見つからないためエラーとなり、続行・終了・中止のいずれかを選択するように求められます。
ここでは t (ユーティリティーの中止)を選びます。
db2 "rollforward db sample to end of logs and stop"
SQL3799W 追加情報 "/work/load/SA" をともなう警告 "-2036" のために、表 "DB2V7./db2v7/NODE0000/SQL000TEST"
のロード回復がノード "0" 時刻 "20010501154903" で保留しています。
(c) で続行、(d) でこの装置のみ終了、(t) でユーティリティーを中止します。(c/d/t)
t
SQL3799W 追加情報 "/work/load/SA" をともなう警告 "-2036" のために、表 "DB2V7./db2v7/NODE0000/SQL000TEST"
のロード回復がノード "0" 時刻 "20010501154903" で保留しています。
この時、表スペースは「復元保留状態」になっています。
db2 "list tablespaces"
現在のデータベースの表スペース
(略)
表スペース ID
名前
タイプ
内容
状況
詳しい説明:
復元保留中
=
=
=
=
=
3
TBSP1
データベース管理スペース
任意のデータ
0x0100
マニュアルによると、ロケーションファイルを記述し、DB2LOADRECレジストリ変数にそのファイル名を指定することで、ロードのコ
ピーファイルが移動してもロールフォワードが行えるはずですが、V7.2 現在、この機能は働きません。(APAR IX86940)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: COPY=YESでLoad後のデータベースに対する回復のシナリオ (7/7)
続行・終了・中止のいずれかを選択するように求められた際に、コピーファイルを正しい位置に戻して、継続をすることでロール
フォワードは正常に終了します。
cp /work/load2/SAMPLE* /work/load
ls -l /work/load
合計 1336
-rw-r----- 1 db2v7
sys
679960 May 01 15:49 SAMPLE.4.db2v7.NODE0000.CATN0000.20010501154903.001
db2 "rollforward db sample to end of logs and stop"
SQL3799W 追加情報 "/work/load/SA" をともなう警告 "-2036" のために、表 "DB2V7./db2v7/NODE0000/SQL000TEST"
のロード回復がノード "0" 時刻 "20010501154903" で保留しています。
(c) で続行、(d) でこの装置のみ終了、(t) でユーティリティーを中止します。(c/d/t)
c
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000000.LOG - S0000000.LOG
2001-05-01-06.49.09.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 109-110
DB2 UDB運用管理
3. 回復の手順
3-1-5. UserExit を使用した回復手順
UserExit によりログファイルはArchive/Retrieveされる
ロールフォワード時にもUserExit プログラムが使用される
Retrieve Path にログファイルが存在しない場合:
データベース全体のロールフォワード
表スペースのロールフォワード
・・・そのまま終了
・・・SQL1273Nエラー
考慮点
Retrieve Path がディスクの場合には、UserExitを使用してログファイルをRetrieveさせるより、
OVERFLOW LOG PATH オプションでROLLFORWARD コマンドを実行した方がオーバーヘッ
ドが少ない
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExit を使用した回復手順
UserExit プログラムを使用可能に設定している場合、ロールフォワード中にLOGPATH にログファイルが存在しないと、UserExit
プログラムが呼ばれて、ログファイルを自動的に Retrieve し、ロールフォワードを継続します。
したがって、ロールフォワードを行う前に、UserExit の RETRIEVE PATH に必要なログファイルが存在していることを確認する必
要があります。
もし、必要なログファイルが存在しない場合、ロールフォワードプロセスは以下のような振る舞いをします。
データベース全体のロールフォワードの場合: 存在しているログファイルのみを使用してロールフォワードを実行し、そのまま
終了
表スペースのロールフォワードの場合: ロールフォワード時に指定した分だけログファイルが存在しないと、SQL1273Nエラー
UserExit プログラム内に指定している RETRIEVE PATH がディスクである場合には、ロールフォワード時にUserExit プログラムを
呼び出してログファイルをコピーさせるより、OVERFLOW LOG PATH パラメータに RETRIEVE PATH を指定した方が高速にロー
ルフォワード処理が終了することが期待されます。
これは、ロールフォワードプロセスがログファイルを探す順番が次のようになっているためです。
1. OVERFLOW LOG PATH ディレクトリ (OVERFLOW LOG PATH が指定されている場合)
2. UserExit プログラムを呼び出してログファイルをRetrieve (UserExit プログラムを使用する設定になっている場合)
3. データベース構成パラメータの「ログ・ファイルのパス」で指定されているディレクトリ(LOGPATH)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 111-112
DB2 UDB運用管理
3. 回復の手順
3-1-5. UserExit を使用した回復手順
UserExitを使用した回復のシナリオ
データベース全体の回復の場合
通常運用
T1
T0
障害
③
回復処理
T2
ロールフォ
ワード保留
通常運用
T3
⑤
時間
データベース全体
★
アーカイブ・ログを保存
① データベース全体の
オフライン・
バックアップ取得
★
▲
▲
End of Logs まで
② UserExitプログラムにより
自動的にアーカイブ
④ データベース全体のリストア
⑥ アーカイブ・ログ+アクティブ・ログを使用して
データベース全体のロールフォワード
アーカイブ・ログファイルはUserExitプログラムにより
自動的にリトリーブされる
または、OVERFLOW LOG PATH により指定する
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(データベース全体) (1/8)
UserExitを使用して、データベース全体を回復する場合 のシナリオは以下のとおりです。
シナリオ
① オフラインでデータベースのバックアップを取得します。
時刻
T0
② データベースの更新操作を行います。ログはUserExit プログラムにより順次Archive されます。
③ データベースに障害が発生し、データベース全体が使用不能になったとします。
T1
④ ①のバックアップより、データベース全体をリストアします。
⑤ データベースはロールフォワード保留になります。
T2
⑥ データベース全体をログの最後までロールフォワード・停止します。必要なログは UserExitプログラムによ
り Retrieve されます。または可能であれば OVERFLOW LOG PATH オプションを指定します。
T3
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 113-114
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(データベース全体) (2/8)
UserExitプログラムで定義するARCHIVE PATH、RETRIEVE PATH、およびオンライン・アーカイブ・ログが存在する場所
(LOGPATH)を、本シナリオでは次のように設定します。
ARCHIVE PATH = RETRIEVE PATH
/work/archive/SAMPLE/NODE0000
LOGPATH
/home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/ まず、TEST表に2レコード存在することを確認します。
db2 "select * from test"
C1
----------2
3
C2
---------BBBB
CCCC
2 レコードが選択されました。
データベースのバックアップを取得します。(①
①)
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010418220104 です。
データベースを更新します。ここでは、TEST表に計8行INSERTします。オンライン・アーカイブ・ログファイルはUSEREXITプログラ
ムにより、ARCHIVE PATH にコピーされます。(②
②)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(データベース全体) (3/8)
TEST表に計10レコード存在することを確認します。
db2 "select * from test"
C1
----------2
3
4
5
6
7
8
9
10
11
C2
---------BBBB
CCCC
DDDD
EEEE
FFFF
GGGG
HHHH
IIII
JJJJ
KKKK
10 レコードが選択されました。
このとき、ARCHIVE PATH は次のようになっています。つまり、本シナリオでは UserExit によりアーカイブされたログファイルは、
S0000084.LOGからS0000087.LOG です。
ls -l /work/archive/SAMPLE/NODE0000/
合計 104
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
Apr
Apr
Apr
Apr
18
18
18
18
22:01
22:01
22:01
22:01
S0000084.LOG
S0000085.LOG
S0000086.LOG
S0000087.LOG
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 115-116
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(データベース全体) (4/8)
このとき、データベースに障害が発生したと仮定し(③
③)、データベース全体をリストアします。(④
④)
ここで、警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010418220104 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
データベース全体をログの最後まで(End of Logs)ロールフォワードします。ロールフォワードのプロセスは、まず OVERFLOW
LOG PATH の指定を検索します。ここでは OVERFLOW LOG PATH を指定していないため、次にUSEREXIT プログラムが呼ば
れ、RETRIEVE PATH を検索し、必要なログファイルを使用してロールフォワードを行います。(⑥
⑥)
db2 "rollforward db SAMPLE to end of logs and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000084.LOG - S0000087.LOG
2001-04-18-13.01.58.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
ロールフォワード状況のメッセージより、ロールフォワードでアーカイブされたS0000084.LOGからS0000087.LOG が使用されてい
ることがわかります。
RETRIEVE PATH がディスクである場合には、OVERFLOW LOG PATH を指定した方がロールフォワード処理の処理が早くなるこ
とが期待されます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(データベース全体) (5/8)
TEST表に10行存在することを確認します。
db2 "connect to SAMPLE"
データベース接続情報
データベース・サーバー
= DB2/6000 7.1.0
SQL 権限 ID
= DB2V7
ローカル・データベース別名 = SAMPLE
db2 "select * from test"
C1
----------2
3
4
5
6
7
8
9
10
11
C2
---------BBBB
CCCC
DDDD
EEEE
FFFF
GGGG
HHHH
IIII
JJJJ
KKKK
10 レコードが選択されました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 117-118
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(データベース全体) (6/8)
もし、RETRIEVE PATH に必要なログファイルがなかった場合は、ディスクにログをアーカイブするUSEREXITプログラムは、その
まま終了します。
このシナリオを以下に示します。
ロールフォワードを行う前に、RETRIEVE PATH にあるアーカイブされたログファイルを他の場所に移動します。ここでは、
RETRIEVE PATH の中のtmpディレクトリに移動しています。
ls -l /work/archive/SAMPLE/NODE0000/
合計 104
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
drwxrwsr-x 2 db2v7
sys
2048
Apr
Apr
Apr
Apr
Apr
18
18
18
18
18
22:01
22:01
22:01
22:01
21:22
S0000084.LOG
S0000085.LOG
S0000086.LOG
S0000087.LOG
tmp
mv /work/archive/SAMPLE/NODE0000/*.LOG /work/archive/SAMPLE/NODE0000/tmp
RETRIEVE PATH にはログファイルは存在しないことを確認します。
ls -l /work/archive/SAMPLE/NODE0000/
合計 8
drwxrwsr-x 2 db2v7
sys
2048 Apr 18 22:03 tmp
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(データベース全体) (7/8)
この状態で、データベース全体のロールフォワードをログの最後まで(End of Logs)実行します。ロールフォワード・プロセスはまず
OVERFLOW LOG PATH が指定されているかを調べ、指定されていればその場所を探します。ここではOVERFLOW LOG PATH
を指定していないため、次にUserExit プログラムが呼ばれ、ログファイルを RETRIEVE PATH からログファイルを探します。しかし
本シナリオでは必要なログファイル(S0000084.LOGからS0000087.LOG)を UserExit プログラムが Retrieve できません。ロール
フォワード・プロセスは最後に LOGPATH を調べますがここに適用すべきログファイルがないため、処理すべきログファイルにつ
いてはすべてロールフォワードを行ったと考えてロールフォワード処理を終了します。
db2 "rollforward db SAMPLE to end of logs and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
2001-04-18-13.01.00.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 119-120
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(データベース全体) (8/8)
表は更新を行う前の状態と同じです。これは、TEST表の照会によって確認することができます。
db2 "connect to SAMPLE"
データベース接続情報
データベース・サーバー
= DB2/6000 7.1.0
SQL 権限 ID
= DB2V7
ローカル・データベース別名 = SAMPLE
db2 "select * from test"
C1
----------2
3
C2
---------BBBB
CCCC
2 レコードが選択されました。
このようなことがおこるため、ロールフォワード・プロセスが正常終了しても、必要なロールフォワード処理をすべて行われている
かどうかは、ユーザーが確認する必要があります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
ブランク・ページです
(3-1) 121-122
DB2 UDB運用管理
3. 回復の手順
3-1-5. UserExit を使用した回復手順
UserExitを使用した回復のシナリオ
表スペースの回復の場合
T0
障害
③
通常運用
T1
回復処理
T2
⑤
通常運用
T3
時間
0x80
表スペース tbsp1
★
アーカイブ・ログを保存
▲
★
▲
End of Logs まで
① データベース全体または
表スペースのオフライン・
バックアップ取得
④ 表スペースのリストア
② UserExitプログラムにより
自動的にアーカイブ
⑥ アーカイブ・ログ+アクティブ・ログを使用して
表スペースの状況
0x80 : ロールフォワード保留
表スペースのロールフォワード
アーカイブ・ログファイルはUserExitプログラムにより
自動的にリトリーブされる
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(表スペース) (1/7)
UserExitを使用して、表スペースを回復する場合 のシナリオは以下のとおりです。
シナリオ
① オフラインで表スペースのバックアップを取得します。
時刻
T0
② データベースの更新操作を行います。ログはUserExit プログラムにより順次Archive されます。
③ データベースに障害が発生し、表スペースが使用不能になったとします。
T1
④ ①のバックアップより、表スペースをリストアします。
⑤ 表スペースはロールフォワード保留になります。
T2
⑥ 表スペースをログの最後までロールフォワード・停止します。必要なログは UserExitプログラムにより
Retrieve されます。または OVERFLOW LOG PATH オプションを指定することも可能です。
T3
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 123-124
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(表スペース) (2/7)
UserExitプログラムで定義するARCHIVE PATH、RETRIEVE PATH、およびオンライン・アーカイブ・ログが存在する場所
(LOGPATH)を、本シナリオでは次のように設定します。
ARCHIVE PATH = RETRIEVE PATH
/work/archive/SAMPLE/NODE0000
LOGPATH
/home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/ まず、表スペースtbsp1 上の TEST表に2レコード存在することを確認します。
db2 "select * from test"
C1
----------2
3
C2
---------BBBB
CCCC
2 レコードが選択されました。
表スペースのバックアップを取得します。(①
①)
db2 "backup db SAMPLE tablespace(tbsp1) to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010419160425 です。
データベースを更新します。ここでは、TEST表に計8行INSERTします。オンライン・アーカイブ・ログファイルはUserExitプログラム
により、ARCHIVE PATH にコピーされます。(②
②)
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(表スペース) (3/7)
TEST表に計10レコード存在することを確認します。
db2 "select * from test"
C1
----------2
3
4
5
6
7
8
9
10
11
C2
---------BBBB
CCCC
DDDD
EEEE
FFFF
GGGG
HHHH
IIII
JJJJ
KKKK
10 レコードが選択されました。
このとき、ARCHIVE PATH は次のようになっています。つまり、UserExit によりアーカイブされたログファイルは、S0000001.LOG
からS0000004.LOG です。
ls -l /work/archive/SAMPLE/NODE0000/
合計 104
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
-rw------- 1 db2v7
sys
12288
Apr
Apr
Apr
Apr
19
19
19
19
16:04
16:04
16:05
16:05
S0000001.LOG
S0000002.LOG
S0000003.LOG
S0000004.LOG
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 125-126
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(表スペース) (4/7)
このとき、表スペースに障害が発生したと仮定し(③
③)、表スペースをリストアします。(④
④)
db2 "restore db SAMPLE tablespace (tbsp1) from /backup taken at 20010419160425 without prompting"
DB20000I RESTORE DATABASE コマンドが正常に終了しました。
表スペースtbsp1ををログの最後まで(End of Logs)ロールフォワードします。ロールフォワードのプロセスは、まず OVERFLOW
LOG PATH で指定されたディレクトリを検索します。ここでは OVERFLOW LOG PATH を指定していないため、次に UserExit プ
ログラムが呼ばれ、RETRIEVE PATH を検索し、必要なログファイル使用してロールフォワードを行います。(⑥
⑥)
db2 "rollforward db SAMPLE to end of logs and stop tablespace (tbsp1)"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000005.LOG
2001-04-19-07.05.04.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(表スペース) (5/7)
TEST表に10行存在することを確認します。
db2 "connect to SAMPLE"
データベース接続情報
データベース・サーバー
= DB2/6000 7.1.0
SQL 権限 ID
= DB2V7
ローカル・データベース別名 = SAMPLE
db2 "select * from test"
C1
----------2
3
4
5
6
7
8
9
10
11
C2
---------BBBB
CCCC
DDDD
EEEE
FFFF
GGGG
HHHH
IIII
JJJJ
KKKK
10 レコードが選択されました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 127-128
DB2 UDB運用管理
3. 回復の手順
解説: UserExitを使用した回復のシナリオ(表スペース) (6/7)
もし、RETRIEVE PATH に必要なログファイルがなかった場合は、表スペースのロールフォワード処理はエラーとなります。
このシナリオを以下に示します。
ロールフォワードを行う前に、RETRIEVE PATH のログファイルを他の場所に移動します。ここでは、RETRIEVE PATH の中のtmp
ディレクトリに移動しています。
ls -l /work/archive/SAMPLE/NODE0000/
合計 128
-rw------- 1 db2v7
sys
12288 Apr 19 16:04 S0000001.LOG
-rw------- 1 db2v7
sys
12288 Apr 19 16:04 S0000002.LOG
-rw------- 1 db2v7
sys
12288 Apr 19 16:05 S0000003.LOG
-rw------- 1 db2v7
sys
12288 Apr 19 16:05 S0000004.LOG
-rw------- 1 db2v7
sys
12288 Apr 19 16:05 S0000005.LOG
drwxrwsr-x 2 db2v7
sys
2048 Apr 18 23:50 tmp
mv /work/archive/SAMPLE/NODE0000/*.LOG /work/archive/SAMPLE/NODE0000/tmp
RETRIEVE PATH にはログファイルは存在しません。
ls -l /work/archive/SAMPLE/NODE0000/
合計 8
drwxrwsr-x 2 db2v7
sys
2048 Apr 19 16:06 tmp
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: UserExitを使用した回復のシナリオ(表スペース) (7/7)
この状態で、データベース全体のロールフォワードをログの最後まで(End of Logs)実行します。表スペースのロールフォワードで
は、必要なログファイル(S0000001.LOGからS0000004.LOG)を UserExit プログラムが Retrieve できないため、ロールフォワード
処理が失敗します。
db2 "rollforward db SAMPLE to end of logs and stop tablespace (tbsp1) "
SQL1273N ノード "0" のログ・ファイル "S0000001.LOG" が無いため、データベース "SAMPLE" のロールフォワー
ド回復が指定した停止ポイント (ログ・ファイルの終わりまたは指定時刻) に達することができません
この状態で、表スペースはロールフォワード保留状態です。
db2 "get db cfg for SAMPLE"
SAMPLE データベースのデータベース構成
(略)
バックアップ保留状態
= NO
整合状態のデータベース
ロールフォワード保留状態
復元保留中
(略)
= YES
= TABLESPACE
= NO
ロールフォワード保留を解除するためには、必要なログ・ファイルをLOGPATHまたは、RETRIEVE PATH に移すか、可能な場合
は ROLLFORWARD DATABASE コマンドの OVERFLOW LOG PATH パラメータにログ・ファイルの場所を指定して
ROLLFORWARD DATABASE コマンドを再実行する必要があります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 129-130
DB2 UDB運用管理
3. 回復の手順
3-1-6. 削除された表の回復手順
削除(DROP)された表の回復が可能(V6.1より)
前提
表スペース作成時に dropped table recovery on を指定
バックアップの取得+ログの保管
データベースが「回復可能」
データベース構成パラメータ logretain = RECOVERY または、userexit = YES
手順
ロールフォワード時に recovery dropped table を指定
ロールフォワード処理中に削除された表のデータがファイルにEXPORTされる
削除された表を再作成
EXPORT されたデータを使用して、表に IMPORT または LOAD
考慮点
回復活動記録ファイルから削除された表のIDと、作成するためのDDLを取得
REGULAR表スペースのみサポート
LONGデータ、LOBデータは EXPORT されない
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復手順
V6.1 より削除された表の回復が可能になりました。
表を誤ってDROPしてしまった場合、コミットしてしまうとこのSQL文をロールバックすることはできません。表を回復するためには、
データベース全体のバックアップをリストアし、表が削除される直前までロールフォワードを行う必要があります。しかし、この方法
では、表が削除された後のデータベースに対する更新は失われます。また、表が削除された時刻が最小回復時間となるため、表
スペースのバックアップ・リストアでは表を回復することはできません。(表スペースは最小回復時間以降までロールフォワードしな
くてはならないため。)
削除された表の回復を行うためには、あらかじめ dropped table recovery on オプションを指定して表スペースを CREATE または
ALTER する必要があります。
表が削除された後、データベースをリストアし、recovery dropped table オプションを指定してロールフォワードを行います。ロール
フォワード処理のなかで、削除された表のデータを EXPORT し、DEL形式のファイルとして保管します。ロールフォワードコマンド
には、削除された表のIDと EXPORT ファイルを保管するディレクトリを指定しなくてはなりません。したがって、ロールフォワードコ
マンドの実行前に回復活動履歴ファイルから表のIDを取得しておく必要があります。
ロールフォワードを停止したら、回復活動履歴ファイルから得られるDDL文を実行して、削除された表を再作成します。
ロールフォワード処理中に EXPORT されたデータを IMPORT または LOAD し、表を回復します。
削除された表の回復は、REGULAR 表スペースのみサポートされます。
また、REGULAR 表スペース上に保管していても、LONGデータおよび LOB データはロールフォワード時に EXPORT されません。
したがって、LONG データおよびLOBデータの列は回復することができません。
その他詳細については、「回復管理の基本事項」-「2. 回復の種類」-「Dropped Table Recovery」をご参照ください。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 131-132
DB2 UDB運用管理
3. 回復の手順
3-1-6. 削除された表の回復手順
削除された表の回復のシナリオ
通常運用
T1
T0
T2
回復処理
T3
時間
表スペース tbsp1
★
③ アーカイブ・ログを保存
① dropped table
recovery on を
指定して表ス
ペースの作成/
表の作成
★
End of Logs
まで
④ 表のDROP
⑧ 削除された
表の再作成
② データベース全体
のオフライン・
バックアップ取得
⑤ データベースのリストア
⑥ revoery dropped table を指定して
データベースのロールフォワード
⑦ 削除された表のデータがファイルに
EXPORTされる
⑨ 表のデータの
IMPORT
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (1/13)
削除された表を回復する場合 のシナリオは以下のとおりです。
シナリオ
時刻
① dropped table recovery on を指定して表スペースを作成し、その表スペース上に表t1を作成します。
② データベース全体のオフライン・バックアップを取得します。
T0
③ データベースの更新操作を行います。
④ 表t1 をDROP します。
T1
⑤ ②のバックアップより、データベースをリストアします。
T2
⑥ revoery dropped table を指定してデータベースをログの最後までロールフォワードし停止します。このと
き、回復活動履歴ファイルより取得できる表のIDと、削除された表のデータをEXPORTするディレクトリを指定
します。
⑦ ロールフォワード処理中に、削除された表のデータが⑥で指定したディレクトリ下に保存されます。
⑧ データベースに接続し、削除された表を再作成します。再作成するためのDDLは回復活動記録ファイルよ
り取得します。
⑨ ロールフォワード処理中に EXPORT されたデータを再作成した表に IMPORT します。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 133-134
DB2 UDB運用管理
3. 回復の手順
解説: 削除された表の回復のシナリオ (2/13)
データベースに接続し、dropped table recovery on を指定して表スペース tbspace1 を作成します。
db2 "connect to SAMPLE"
データベース接続情報
データベース・サーバー
= DB2/6000 7.1.0
SQL 権限 ID
= DB2V7
ローカル・データベース別名 = SAMPLE
db2 "create tablespace TBSPACE1 managed by database using (file '/work/dms/tbsp1' 1000) dropped table
recovery on"
DB20000I SQL コマンドが正常に終了しました。
表スペース tbspace1 上に表 t1 を作成します。
db2 "create table t1 (c1 int, c2 char(10)) in TBSPACE1"
DB20000I SQL コマンドが正常に終了しました。
データベースのバックアップを取得します。
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010518201508 です。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (3/13)
表 t1 にアプリケーションがデータを挿入します。ここでは、10件挿入します。
db2 "insert into t1 values (0, 'AAAAAA')"
DB20000I SQL コマンドが正常に終了しました。
…
db2 "select count(*) from t1"
1
----------10
1 レコードが選択されました。
表 t1 を削除します。
db2 "drop table t1"
DB20000I SQL コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 135-136
DB2 UDB運用管理
3. 回復の手順
解説: 削除された表の回復のシナリオ (4/13)
回復活動記録ファイルを参照し、削除された表のIDと再作成するためのDDLを取得します。
db2 "list history dropped table since 20010518201601 for db SAMPLE"
SAMPLE の履歴ファイルのリスト
突き合わせファイル項目数 = 1
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ -------------D T 20010518201601
00000000000003fe00030004
---------------------------------------------------------------------------"DB2V7 "."T1" は 1 表スペースに常駐します :
00001 TBSPACE1
---------------------------------------------------------------------------コメント: DROP TABLE
開始時刻: 20010518201601
終了時刻: 20010518201601
---------------------------------------------------------------------------00001
DDL: CREATE TABLE "DB2V7
"."T1" ( "C1" INTEGER , "C2" CHAR(10) ) IN "TBSPACE1" ;
----------------------------------------------------------------------------
表のID(Backup ID)は 00000000000003fe00030004、
DDLは CREATE TABLE "DB2V7 "."T1" ( "C1" INTEGER , "C2" CHAR(10) ) IN "TBSPACE1" です。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (5/13)
データベース全体をリストアします。
ここで、警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010518201508 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
表のID、および削除された表のデータをEXPORTする際に、ファイルを保存する場所を指定してログの最後までロールフォワード
を行い停止します。
db2 "rollforward db SAMPLE to end of logs and stop recover dropped table 00000000000003fe00030004 to
/backup"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000093.LOG - S0000094.LOG
2001-05-18-11.16.01.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 137-138
DB2 UDB運用管理
3. 回復の手順
解説: 削除された表の回復のシナリオ (6/13)
EXPORT されたデータは、ロールフォワード時に指定したディレクトリの下のNODEnnnn/data というファイルにDEL形式で保存さ
れます。ここで nnnn はノード番号です。
ls -l /backup/NODE0000/data
-rw-r----- 1 db2v7
dbadmin1
150 May 18 20:16 /backup/NODE0000/data
DEL形式なので、ファイルの中身は以下のようになっています。
cat /backup/NODE0000/data
0,"AAAAAA
"
1,"AAAAAA
"
2,"AAAAAA
"
3,"AAAAAA
"
4,"AAAAAA
"
5,"AAAAAA
"
6,"AAAAAA
"
7,"AAAAAA
"
8,"AAAAAA
"
9,"AAAAAA
"
データベースに接続します。この時点では、削除された表はまだ回復されていません。回復活動記録ファイルから取得したDDLを
実行し、削除された表を再作成します。
db2 " CREATE TABLE "DB2V7
"."T2" ( "C1" INTEGER , "C2" CLOB(1000) LOGGED NOT COMPACT ) IN "TBSPACE1" "
DB20000I SQL コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (7/13)
EXPORT されたデータを表に IMPORT します。
db2 "import from /backup/NODE0000/data of del insert into t2"
SQL3109N ユーティリティーが、ファイル "/backup/NODE0000/data" からデータのロードを開始しています。
SQL3110N ユーティリティーが処理を完了しました。 "10"
行が、入力ファイルから読み取られました。
SQL3221W ...COMMIT WORK が開始されました。入力レコード数 = "10"。
SQL3222W ...すべてのデータベース変更のコミットが成功しました。
SQL3149N "10" 行が、入力ファイルから処理されました。 "10"
行が、正常に表に挿入されました。"0" 行が、拒否されました。
読み込まれた行数
スキップされた行数
挿入された行数
更新された行数
拒否された行数
コミットされた行数
=
=
=
=
=
=
10
0
10
0
0
10
これで削除された表の回復が終了します。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 139-140
DB2 UDB運用管理
3. 回復の手順
解説: 削除された表の回復のシナリオ (8/13)
次に、LOBデータタイプ列を含む表(Regular 表スペース)では、LOBデータは EXPORT されないことを確認します。
表スペース tbspace1 上にCLOB 列を含む表 t2 を作成します。
db2 "create table t2 (c1 int, c2 clob (1000)) in TBSPACE1"
DB20000I SQL コマンドが正常に終了しました。
表にデータを挿入します。ここでは、10行データを挿入します。
db2 "insert into t2 values (0, 'AAAAAA')"
DB20000I SQL コマンドが正常に終了しました。
…
db2 "select count(*) from t2"
1
----------10
1 レコードが選択されました。
表 t2 を DROP します。
db2 "drop table t2"
DB20000I SQL コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (9/13)
回復活動記録ファイルを参照し、削除された表のIDと再作成するためのDDLを取得します。
db2 "list history dropped table since 20010518214218 for db SAMPLE"
SAMPLE の履歴ファイルのリスト
突き合わせファイル項目数 = 1
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID
-- --- ------------------ ---- --- ------------ ------------ -------------D T 20010518214218
000000000000044500030005
---------------------------------------------------------------------------"DB2V7 "."T2" は 1 表スペースに常駐します :
00001 TBSPACE1
---------------------------------------------------------------------------コメント: DROP TABLE
開始時刻: 20010518214218
終了時刻: 20010518214218
---------------------------------------------------------------------------00001
DDL: CREATE TABLE "DB2V7
"."T2" ( "C1" INTEGER , "C2" CLOB(1000) LOGGED NOT COMPACT ) IN "TBSPACE1" ;
----------------------------------------------------------------------------
表のID(Backup ID)は 000000000000044500030005、
DDLは CREATE TABLE "DB2V7 "."T2" ( "C1" INTEGER , "C2" CLOB(1000) LOGGED NOT COMPACT ) IN "TBSPACE1"
です。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 141-142
DB2 UDB運用管理
3. 回復の手順
解説: 削除された表の回復のシナリオ (10/13)
データベース全体をリストアします。
ここで、警告"2539"のメッセージは、バックアップイメージが既存のデータベースを上書きするという警告です。
db2 "restore db SAMPLE from /backup taken at 20010518214040 without prompting"
SQL2540W 復元は成功しましたが、非割り込みモードでデータベースを復元中に、警告 "2539" が出されました。
表のID、および削除された表のデータをEXPORTする際に、ファイルを保存する場所を指定してログの最後までロールフォワード
を行い停止します。
db2 "rollforward db SAMPLE to end of logs and stop recover dropped table 000000000000044500030005 to
/backup"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
= SAMPLE
= 1
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
=
=
=
=
=
0
not pending
S0000098.LOG - S0000100.LOG
2001-05-18-12.42.19.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (11/13)
EXPORT されたデータは、指定したディレクトリの下のNODEnnnn/data というファイルにDEL形式で保存されます。ここで nnnn は
ノード番号です。
ls -l /backup/NODE0000/data
-rw-r----- 1 db2v7
dbadmin1
30 May 18 21:42 /backup/NODE0000/data
DEL形式なので、ファイルの中身は以下のようになっています。LOBデータタイプの
LOBデータタイプの C2 列の値は EXPORT されていません。
cat /backup/NODE0000/data
0,
1,
2,
3,
4,
5,
6,
7,
8,
9,
データベースに接続します。この時点では、削除された表はまだ回復されていません。回復活動記録ファイルから取得したDDLを
実行し、削除された表を再作成します。
db2 " CREATE TABLE "DB2V7
"."T2" ( "C1" INTEGER , "C2" CLOB(1000) LOGGED NOT COMPACT ) IN "TBSPACE1" "
DB20000I SQL コマンドが正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 143-144
DB2 UDB運用管理
3. 回復の手順
解説: 削除された表の回復のシナリオ (12/13)
EXPORT されたデータを表に IMPORT します。
db2 "import from /backup/NODE0000/data of del insert into t2"
SQL3109N ユーティリティーが、ファイル "/backup/NODE0000/data" からデータの
ロードを開始しています。
SQL3110N ユーティリティーが処理を完了しました。 "10"
行が、入力ファイルから読み取られました。
SQL3221W ...COMMIT WORK が開始されました。入力レコード数 = "10"。
SQL3222W ...すべてのデータベース変更のコミットが成功しました。
SQL3149N "10" 行が、入力ファイルから処理されました。 "10" 行が、正常に表に挿入されました。"0" 行が、拒否
されました。
読み込まれた行数
スキップされた行数
挿入された行数
更新された行数
拒否された行数
コミットされた行数
=
=
=
=
=
=
10
0
10
0
0
10
IMPORT コマンドは正常に終了しますが、LOBデータタイプである C2 列は EXPORT されなかったため、回復されません。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: 削除された表の回復のシナリオ (13/13)
表t2 の内容を確認します。LOBデータタイプの列C2は回復されません。
db2 "select * from t2"
C1
----------0
1
2
3
4
5
6
7
8
9
C2
---------------------------------------------------------------------------------------------
10 レコードが選択されました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 145-146
DB2 UDB運用管理
3. 回復の手順
3-1-7. システム時間を戻した場合の回復に関する考慮点
質問(5)
<<< QUESTION >>>
2000/08/09 16:52:29
AIX4.3.2でUDB5.2が導入済みです。
当機器の時刻をntpを利用し時刻同期させることを検討中です。
時刻同期処理を実行する際に、時刻を戻すことも考えられますが、UDBを起動した状態でシステム時間を戻した
場合、UDB自体(ログ等)に問題が発生するでしょうか?
一般的に以下のようになり、障害時に復旧できなくなる可能性があると思いますが正しいでしょうか。
・ログの時間が逆転することにより、障害時の復旧の際、ログに不整合が発生する。
・バックアップ/リストアで保持している時間に不整合が発生する。
正しい場合、運用時の考慮点等ありますでしょうか。
また、その他考慮点がありましたらご指摘ください。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
3-1-7. システム時間を戻した場合の回復に関する考慮点
質問(5)の答え
<<< ANSWER >>>
00/08/09 22:06:26
システム時間を戻したとしてもUDBのログには順序番号が入っているため不整合は発生しません。
ログのタイムスタンプは時間を戻す前の時間に追いつくまで同じタイムスタンプを使用します。
例えば9:00から8:55にシステム時間を戻したとしたら、システム時間が9:00を超えるまで9:00のタイム
スタンプを使用することになります。
従って、ポイント・イン・タイムのロールフォワードをする場合に、足踏みをしている間の時間を指定
できなくなるということになります。
この点以外に特に不都合な事はありません。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 147-148
DB2 UDB運用管理
3. 回復の手順
3-1-7. システム時間を戻した場合の回復に関する考慮点
システム時間を戻した場合のログに対する影響
ログには順序番号があるため、不整合は生じない
タイムスタンプは、時間を戻す前の時間に追いつくまで、同じタイムスタンプを使用
Point in Time 指定でロールフォワードを行う場合の注意
時間を戻す前の時間に追いつくまでに行われるトランザクションは、すべて同じタイムスタンプ
でログに記録
そのタイムスタンプを指定してロールフォワードを行うと、時間を戻す前の時間に追いつくまで
の間に行われるすべてのトランザクションが回復
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復に関する考慮点
運用上、Network Time Protocol などを使用して、ネットワーク上のマシンの時刻の同期を取ることがあります。その際、システム
(OS)の時間を進めるまたは戻すという操作が行われる可能性があります。
システムの時間を進めた場合には、UDBに対する影響はありません。
システムの時間を戻した場合にも、UDBのログの各レコードは順序番号(LSN)で管理されているため、不整合は生じません。
この場合、ログの各レコードのタイムスタンプは、システム時間を戻す前の時間に追いつくまで、同じタイムスタンプを使用します。
例えば、9:00 のタイムスタンプでログレコードが記録された後に、8:55 にシステム時間を戻したとしたら、システム時間が 9:00 を
超えるまで、その間のログの各レコードは 9:00 のタイムスタンプを使用します。
このことより、システム時間を戻す前の時間に追いつくまでの間に実行されたトランザクションは、その同じタイムスタンプを指定し
てPoint in Time 指定でロールフォワードを行うと、すべて同時に回復されてしまうことに注意してください。
上の例では、バックアップ/リストアを行ったあとに、9:00 を指定してPoint in Time 指定でロールフォワードを行うと、システム時間
を戻してからシステム時間が9:00 になるまでになされた更新はすべて実行されることになります。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 149-150
DB2 UDB運用管理
3. 回復の手順
3-1-7. システム時間を戻した場合の回復に関する考慮点
システム時間を戻した場合の回復のシナリオ(1)
システム時間
10:28:30
10:28:41
10:23:57
10:24:07
10:29:07
ログファイル内の
タイムスタンプ
10:28:30
10:28:41
10:28:41
10:28:41
10:29:07
10秒
10秒
(時:分:秒)
5分
データベース
システム時間
を5分戻す
backup
①
1行insert
②
1行insert
③
1行insert
④
1行insert
⑤
1行insert
rollforward to 10:28:30
①の1行回復
rollforward to 10:28:41
①~④の4行回復
rollforward to 10:29:07
①~⑤の5行回復
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(1) (1/7)
システム時間を戻した場合に、回復(ロールフォワード)がどのような影響を受けるかを確認するために、以下のようなシナリオを
考えます。
システム時間
シナリオ
ログファイル内の
タイムスタンプ
10:27:55
データベースのバックアップ
10:28:30
表に1行Insert (①)
10:28:30
10:28:41
表に1行Insert (②)
10:28:41
DB2の停止
10:28:51
システム時間を5分戻す
10:23:51
DB2の開始
10:23:57
表に1行Insert (③)
10:28:41
10:24:07
表に1行Insert (④)
10:28:41
10:29:07
表に1行Insert (⑤)
10:29:07
ここで、障害が発生したと仮定し、データベースのリストアを行います。
10:28:30 を指定してロールフォワードを行った場合は、①の1行が回復されます。
10:28:41 を指定してロールフォワードを行った場合は、①と②の行のみならず、③と④の行も回復されます。これは、システム時
間を戻したことにより、システム時間が戻す前の時間に追いつくまでの間、ログのレコードは同じタイムスタンプ(10:28:41)を使用
して記録されているためです。
したがって、①~②までだけ、または①~③ までだけを回復させることはできません。例えば、10:23:57 を指定してロールフォ
ワードを行っても①~③が回復されるわけではありません。
10:29:07 まで、またはログの最後まで指定してロールフォワードを行った場合は、①~⑤の行が回復されます。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 151-152
DB2 UDB運用管理
3. 回復の手順
解説: システム時間を戻した場合の回復のシナリオ(1) (2/7)
データベースのバックアップを取得します。
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010510102755 です。
データベースに接続し、10:28:30 (JST)、10:28:41 (JST) にそれぞれ1行ずつ Insert します。
date
Thu May 10 10:28:30 JST 2001
db2 "insert into test values (1, 'AAAA')"
DB20000I SQL コマンドが正常に終了しました。
date
Thu May 10 10:28:41 JST 2001
db2 "insert into test values (2, 'BBBB')"
DB20000I SQL コマンドが正常に終了しました。
DB2を停止し、システムの時間を5分戻した後、DB2を開始します。
db2 "terminate"
DB20000I TERMINATE コマンドが正常に終了しました。
db2stop
SQL1064N DB2STOP の処理が正常に終了しました。
su root "-c date 051010232001"
Thu May 10 10:23:51 JST 2001
db2start
SQL1063N DB2START の処理が正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(1) (3/7)
データベースに接続し、10:23:57(JST)、10:24:07(JST)、10:29:07(JST) にそれぞれ1行ずつ Insert します。
date
Thu May 10 10:23:57 JST 2001
db2 "insert into test values (3, 'CCCC')"
DB20000I SQL コマンドが正常に終了しました。
date
Thu May 10 10:24:07 JST 2001
db2 "insert into test values (4, 'DDDD')"
DB20000I SQL コマンドが正常に終了しました。
date
Thu May 10 10:29:07 JST 2001
db2 "insert into test values (5, 'EEEE')"
DB20000I SQL コマンドが正常に終了しました。
ここで、障害が発生したと仮定し、データベースのリストア、ロールフォワードを行うことにします。
ここではシナリオの都合上、ロールフォワードを複数回行うため、ログファイルを退避させておきます。
db2 "terminate"
DB20000I TERMINATE コマンドが正常に終了しました。
cp /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/*.LOG /backup
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 153-154
DB2 UDB運用管理
3. 回復の手順
解説: システム時間を戻した場合の回復のシナリオ(1) (4/7)
1行目の Insert の時間を指定してロールフォワードを行う場合: 1行回復
db2 "restore db SAMPLE from /backup taken at 20010510102755 without prompting"
cp /backup/*.LOG /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/
db2 "rollforward db SAMPLE to 2001-5-10.1.28.30 and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
= SAMPLE
= 1
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
=
=
=
=
=
0
not pending
S0000022.LOG - S0000022.LOG
2001-05-10-01.28.30.000000
DB20000I ROLLFORWARD コマンドが正常に終了しました。
db2 "connect to SAMPLE"
db2 "select * from test"
C1
C2
----------- ---------1 AAAA
1 レコードが選択されました。
ロールフォワードの Point in Time で指定する時刻は協定世界時(CUT) (日本の場合、ローカルタイム - 9 時間) であることに注
意して下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(1) (5/7)
2行目の Insert の時間を指定してロールフォワードを行う場合: 4行回復
db2 "restore db SAMPLE from /backup taken at 20010510102755 without prompting"
cp /backup/*.LOG /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/
db2 "rollforward db SAMPLE to 2001-5-10.1.28.41 and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000022.LOG - S0000023.LOG
2001-05-10-01.28.41.000000
db2 "connect to SAMPLE"
db2 "select * from test"
C1
----------1
2
3
4
C2
---------AAAA
BBBB
CCCC
DDDD
4 レコードが選択されました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 155-156
DB2 UDB運用管理
3. 回復の手順
解説: システム時間を戻した場合の回復のシナリオ(1) (6/7)
3行目の Insert の時間を指定してロールフォワードを行う場合: ロールフォワード失敗
db2 "restore db SAMPLE from /backup taken at 20010510102755 without prompting"
cp /backup/*.LOG /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/
db2 "rollforward db SAMPLE to 2001-5-10.1.23.57 and stop"
SQL1275N ノード "0" のデータベース "SAMPLE" が指定した時間より 前の情報を含んでいるため、ロールフォワー
ドに渡される停止時刻は、"2001-05-10-01.28.20.000000" 以降 または同等でなければなりません。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(1) (7/7)
5行目の Insert の時間を指定してロールフォワードを行う場合: 5行回復
db2 "restore db SAMPLE from /backup taken at 20010510102755 without prompting"
cp /backup/*.LOG /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/
db2 "rollforward db SAMPLE to 2001-5-10.1.29.7 and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000022.LOG - S0000023.LOG
2001-05-10-01.29.07.000000
db2 "connect to SAMPLE"
db2 "select * from test"
C1
----------1
2
3
4
5
C2
---------AAAA
BBBB
CCCC
DDDD
EEEE
5 レコードが選択されました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 157-158
DB2 UDB運用管理
3. 回復の手順
3-1-7. システム時間を戻した場合の回復に関する考慮点
システム時間を戻した場合の回復のシナリオ(2)
システム時間
14:21:33
14:21:44
14:16:56
14:17:06
14:17:16
ログファイル内の
タイムスタンプ
14:21:33
14:21:44
14:21:44
14:21:44
14:21:44
10秒
10秒
(時:分:秒)
10秒
データベース
システム時間
を5分戻す
backup
①
1行insert
③
1行insert
②
1行insert
④
1行insert
全件
delete
rollforward to 14:21:42
①のInsert回復
rollforward to 14:21:44
全件削除
②~④の Insert は回復できない
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(2) (1/5)
次のような誤って表のデータを全件削除してしまうというシナリオを考えます。
システム時間
シナリオ
ログファイル内の
タイムスタンプ
14:20:59
データベースのバックアップ
14:21:33
表に1行Insert (①)
14:21:33
14:21:44
表に1行Insert (②)
14:21:44
DB2の停止
14:21:50
システム時間を5分戻す
14:16:50
DB2の開始
14:16:56
表に1行Insert (③)
14:21:44
14:17:06
表に1行Insert (④)
14:21:44
14:17:16
表の全件 Delete
14:21:44
通常であれば、バックアップからのリストア、および全件 Delete の直前の Insert (④) と Delete の間の時間を指定してロール
フォワードを行うことで、Delete 前の表のデータを回復することができます。
しかし、このシナリオのようにシステム時間を戻してしまってまだ元の時間まで追いついていない場合には、全件Delete とその前
の Insert (②~④)が同じタイムスタンプでログに記録されています。つまり、④のInsertまで回復しようとして時刻を指定しロール
フォワードを行うと、Delete も実行されてしまいます。
したがって、この場合は同じタイムスタンプで記録されている②~④のInsertを回復することはできません。
②のInsert の直前(14:21:42)を指定してロールフォワード:①のInsert まで回復
②のInsert の時刻(14:21:44) を指定してロールフォワード:全件削除
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 159-160
DB2 UDB運用管理
3. 回復の手順
解説: システム時間を戻した場合の回復のシナリオ(2) (2/5)
データベースのバックアップを取得します。
db2 "backup db SAMPLE to /backup"
バックアップは成功しました。このバックアップ・イメージのタイム・スタンプは 20010510142059 です。
データベースに接続し、14:21:33 (JST)、14:21:44 (JST) にそれぞれ1行ずつ Insert します。
date
Thu May 10 14:21:33 JST 2001
db2 "insert into test values (1, 'AAAA')"
DB20000I SQL コマンドが正常に終了しました。
date
Thu May 10 14:21:44 JST 2001
db2 "insert into test values (2, 'BBBB')"
DB20000I SQL コマンドが正常に終了しました。
DB2を停止し、システムの時間を5分戻した後、DB2を開始します。
db2 "terminate"
DB20000I TERMINATE コマンドが正常に終了しました。
db2stop
SQL1064N DB2STOP の処理が正常に終了しました。
su root "-c date 051014162001"
Thu May 10 14:16:50 JST 2001
db2start
SQL1063N DB2START の処理が正常に終了しました。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(2) (3/5)
データベースに接続し、14:16:56(JST)、14:17:06(JST)にそれぞれ1行ずつ Insert します。14:17:16(JST) に誤って全件をDelete し
てしまったとします。
date
Thu May 10 14:16:56 JST 2001
db2 "insert into test values (3, 'CCCC')"
DB20000I SQL コマンドが正常に終了しました。
date
Thu May 10 14:17:06 JST 2001
db2 "insert into test values (4, 'DDDD')"
DB20000I SQL コマンドが正常に終了しました。
date
Thu May 10 14:17:16 JST 2001
db2 "delete from test"
DB20000I SQL コマンドが正常に終了しました。
データベースのリストア、ロールフォワードを行います。
ここではシナリオの都合上、ロールフォワードを複数回行うため、ログファイルを退避させておきます。
db2 "terminate"
DB20000I TERMINATE コマンドが正常に終了しました。
cp /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/*.LOG /backup
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 161-162
DB2 UDB運用管理
3. 回復の手順
解説: システム時間を戻した場合の回復のシナリオ(2) (4/5)
2行目の Insert の少し前を指定してロールフォワードを行う場合: 1行回復
db2 "restore db SAMPLE from /backup taken at 20010510142059 without prompting"
cp /backup/*.LOG /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/
db2 "rollforward db SAMPLE to 2001-5-10.5.21.42 and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
= SAMPLE
= 1
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
=
=
=
=
=
0
not pending
S0000024.LOG - S0000024.LOG
2001-05-10-05.21.33.000000
db2 "connect to SAMPLE"
db2 "select * from test"
C1
C2
----------- ---------1 AAAA
1 レコードが選択されました。
ロールフォワードの Point in Time で指定する時刻は協定世界時(CUT) (日本の場合、ローカルタイム(JST) - 9 時間) であるこ
とに注意して下さい。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
解説: システム時間を戻した場合の回復のシナリオ(2) (5/5)
2行目の Insert の時刻を指定してロールフォワードを行う場合: 全件削除
db2 "restore db SAMPLE from /backup taken at 20010510142059 without prompting"
cp /backup/*.LOG /home/db2v7/db2v7/NODE0000/SQL00005/SQLOGDIR/
db2 "rollforward db SAMPLE to 2001-5-10.5.21.44 and stop"
ロールフォワード状況
入力データベース別名
状況を返したノードの数
ノード番号
ロールフォワード状況
次に読み込むログ・ファイル
処理したログ・ファイル
最後にコミットしたトランザクション
= SAMPLE
= 1
=
=
=
=
=
0
not pending
S0000024.LOG - S0000025.LOG
2001-05-10-05.21.44.000000
db2 "connect to SAMPLE"
db2 "select * from test"
C1
C2
----------- ---------0 レコードが選択されました。
2行目~4行目のInsert と Delete が同じタイムスタンプで記録されているため、2行目~4行目のInsert を実行してDelete だけを実
行しないということはできません。
(C)日本IBMシステムズ・エンジニアリング(株) データシステム部
(3-1) 163-164
Fly UP