Comments
Description
Transcript
簡単シリーズ バックアップ リカバリー編 2004/03
簡単シリーズ バックアップ リカバリー編 2004/03 目次 第1章 バックアップとロギング 1-1 1-2 1-3 1-4 1-5 1-6 バックアップの種類 リストアの種類 DB2のログ ログ運用のモード インクリメンタル・バックアップ コントロール・センター 第2章 運用上の考慮点 2-1 ログに関するヒント 2-2 バックアップ種類選択のための考慮点 第3章 バックアップとリカバリー例 3-1 3-2 3-3 3-4 3-5 バックアップとリカバリー例１ （バージョン回復） バックアップとリカバリー例２ （表スペース単位の回復） バックアップとリカバリー例３ （特定時点までの回復） バックアップとリカバリー よく見られるパターン バックアップとリカバリー例４ （インクリメンタル・バックアップの利用） 第4章 その他 4-1 Online Split Mirror 4-2 リダイレクト・リストア 第1章 バックアップとロギング １−１． バックアップの種類 ■ BACKUP DATABASEコマンドによるバックアップ ● バックアップの単位 ➨ データベース ➨ 表スペース ● 取得モード ➨ オンライン ➨ オフライン ● 取得先 ➨ ディスク ➨ テープ ● 取得範囲 ➨ フル・バックアップ ➨ インクリメンタル（増分）バックアップ ● 特長 ➨ データ・ファイル（コンテナー）は意識する必要なし ■ EXPORTによる外部ファイル形式の利用によるバックアップ ● DEL（区切りつきASCII） ● WSF（ワークシート形式） ● IXF（統合交換形式） １−１． バックアップの種類 ■ BACKUP DATABASEコマンドによるバックアップ ● BACKUP DATABASEコマンドは、DB2が提供するユーティリティーです。 ● バックアップは、データベース単位、表スペース単位のどちらでも取得可能です。 ● また、データベースに誰も接続していない状態でバックアップを取得するオフライン・バックアップと、データ ベースに接続しているアプリケーションが存在する状態で、バックアップを取得できるオンライン・バックアップ が選択できます。 ● 増加分だけ（差分だけ）のバックアップも可能です。 ■ EXPORTによる外部ファイル形式の利用によるバックアップ ● EXPORTユーティリティーはデータベース間でのデータの移動だけでなく、他のアプリケーションとのデータの 受け渡しにも使用可能です。サポートしているファイルのタイプは下記の３タイプになります。 ➨ 区切りつきASCII （区切りなしASCIIはIMPORT/LOADでは使用できますが、EXPORTでは使用できません） ➨ WSF（ワークシート形式） ➨ IXF（統合交換形式） ● EXPORTユーティリティーはBACKUPコマンドに比べ低速であるため、大容量データベースのバックアップの 目的のためにのみ使用するのは不向きです。 ● EXPORTコマンド例 ➨ export to d:¥db2backup¥tst1exp of ixf messages d:¥db2backup¥expmsg select * from admin.employee ; １−２． リストアの種類 ■ RESTORE DATABASEコマンドによるリストア ● 復元の単位 ➨ データベース単位（フルと増分） ➨ 表スペース単位（フルと増分） – ■ データベース単位のバックアップ・イメージから表スペース単位の復元が可能 ROLLFORWARDコマンドによるロールフォワード回復 ● ログの最後、または、任意の時点まで回復することが可能 ■ IMPORT または LOADによる外部ファイル形式からのロード ● IMPORTユーティリティがサポートしているファイルのタイプは下記のタイプになります。 ➨ ➨ ➨ ➨ 区切り付きASCII 区切りなしASCII IXF（統合交換形式） WSF(ワークシート形式） LOADでは使用不可 １−２． リストアの種類 ■ RESTORE DATABASEコマンドによるリストア ● BACKUP DATABASEコマンドでバックアップを取得したものを、RESTORE DATABASEコマンドで戻します。 バージョン回復や、リストア・リカバリーと呼ばれるもので、バックアップを取得した時点までの回復を行いま す。 ● オンライン・バックアップで取得したバックアップ・ファイルをリストアした場合は、必ずロールフォワード回復が 必要になります。 ■ ROLLFORWARDコマンドによるロールフォワード回復 ● アーカイブ・ログを使用している場合、バックアップ・ファイルをリストアしてからロールフォワード回復を実行 することにより、ログを適用します。最新の状態までの回復と、時間指定による特定時点までの回復を選択 することができます。 ■ IMPORT または LOADによる外部ファイル形式からのロード ● IMPORTユーティリティーは、内部的にINSERT処理を行うことにより、データの表への挿入を行います。IXF形 式のIMPORTでは、表が定義されていない場合でも‘CREATE’オプションを使用することにより表の作成も同 時に可能です。 ● LOADユーティリティーを使用する場合は、あらかじめ表や索引を定義しておく必要があります。 ● IMPORTユーティリティーはすべての行をログに記録するため、LOADに比べて低速です。 ● IMPORTコマンド例 ➨ import from d:¥db2backup¥tst1exp of ixf messages d:¥db2backup¥impmsg replace into admin.employee ; １−３． ＤＢ２のログ ■ 活動ログ（アクティブ・ログ） ● 現在使用中のログ ■ オンライン・アーカイブ・ログ ● アーカイブ・ロギング使用した場合に、完了したトランザクションについてのログが保存される ● アクティブ・ログと同じディスク上のログ・パス・ディレクトリーに保存される ■ オフライン・アーカイブ・ログ ● オンライン・アーカイブ・ログをテープやログ・パス・ディレクトリー以外に移動したもの アーカイブ・ロギング使用時にのみ有効 ・アクティブ・ログがクローズされた時点の自動的なアーカイブ処理 ・ARCHIVE LOGコマンドが発行された時点 アクティブ・ ログ ｵﾝﾗｲﾝ･ ｱｰｶｲﾌﾞ・ﾛｸﾞ ｵﾌﾗｲﾝ･ ｱｰｶｲﾌﾞ・ ﾛｸﾞ ｵﾌﾗｲﾝ･ ｱｰｶｲﾌﾞ・ﾛｸﾞ or ・ｵﾝﾗｲﾝ･ｱｰｶｲﾌﾞ・ﾛｸﾞを手動でﾛｸﾞ・ﾊﾟｽ・ﾃﾞｨﾚｸﾄﾘｰ以外にコピーした場合 ・USEREXIT使用時でアクティブ・ログがクローズ、またはARCHIVE LOGコマンドが発行された場合 １−３． ＤＢ２のログ ■ 活動ログ（アクティブ・ログ） ➨ 現在使用中の(ファイルがオープンされている)ログです。 ➨ クラッシュ・リカバリーおよびロールバックのために必要とされます。 ‒ クラッシュ・リカバリーで使用されるコミット・データのロールフォワードによるディスク反映 ‒ 未コミット・データのロールバック処理などに使用されます。 ➨ これが壊れるとデータベースは機能しなくなるため誤って削除などしないよう注意が必要です。 ➨ ログには、データベース中のレコードの変更前と変更後の状態が入ります。 ➨ コミットされていない状態、もしくは、コミットはされたが、まだ表に物理的に書き込まれていない状態のトランザクション が含まれています。 ■ オンライン・アーカイブ・ログ ➨ ➨ ➨ ➨ ■ アーカイブ・ログとは、クローズされ、通常の処理には必要なくなったログです。 ロールフォワード・リカバリーに必要です。 DB2 UDBでは、アーカイブ・ログをオンラインとオフラインの２つのタイプに分けています。 オンライン・アーカイブ・ログとは、アクティブ・ログと同じディレクリー（ログ・パス・ディレクトリー）に存在するアーカイ ブ・ログを指します。 オフライン・アーカイブ・ログ ➨ オフライン・アーカイブ・ログは、ログ・パス・ディレクトリー以外に置かれたアーカイブ・ログのことです。 ➨ オンライン・アーカイブ・ログをユーザー自身が移動させたり、USEREXITを定義することにより、アクティブ・ログから直 接ログ・パス・ディレクトリー以外の場所にアーカイブ処理（アクティブ・ログが新しいものに切り替り、古いアクティブ・ロ グがアーカイブ・ログとされる）を行ったりします。 ➨ 一般的な運用としては、アクティブ・ログがクローズされた時点で、 ‒ USEREXITプログラムによって十分な容量のあるディスクに直接書き出し、 ‒ その領域を定期的にテープに吸い上げるといった方法があります。 １−４． ログ運用のモード 循環ロギング アクティブ １次ﾛｸﾞ１ アクティブ １次ﾛｸﾞ２ アクティブ ２次ﾛｸﾞ2 アクティブ ２次ﾛｸﾞ1 ２次ログファイルの数は、ＤＢ構成パラメーター（DB CFG)の LOGSECONDで指定する アクティブ １次ﾛｸﾞ３ ２次ログは１次ログが足りなくなったときに割り振られる １次ログファイルの数は、ＤＢ構成パラメーター（DB CFG)の LOGPRIMARYで指定する アーカイブ・ロギング ＤＢ構成パラメーター（DB CFG)の LOGPRIMARYで指定した数 アクティブ １次ﾛｸﾞ 使用中 ｵﾝﾗｲﾝ･ｱｰｶ ｲﾌﾞ･ﾛｸﾞ ｵﾝﾗｲﾝ･ｱｰｶ ｲﾌﾞ･ﾛｸﾞ ｵﾌﾗｲﾝ･ｱｰｶ ｲﾌﾞ･ﾛｸﾞ ｵﾌﾗｲﾝ･ｱｰｶ ｲﾌﾞ･ﾛｸﾞ アクティブ １次ﾛｸﾞ アクティブ １次ﾛｸﾞ アクティブ ２次ﾛｸﾞ アクティブ ２次ﾛｸﾞ １次ログが足りなくなった ときに割り振られる １−４． ログ運用のモード ■ 循環ロギング ➨ アクティブ・ログのみで構成されるモードです。クラッシュ・リカバリーのためにログを使用することを目的にしています。 ログに書き出される処理がコミットかロールバックされれば、その処理をそれ以後保管する必要がないため、ログは再 使用可能な状態になります。 ➨ 通常は１次ログが使用されますが、コミットなしで多量のINSERTなどが発生する処理が行われたために、１次ログの みでは不足を生じた場合には、２次ログが割り振られます。 ただし、２次ログの割り振りには負荷がかかりますので、出来る限り１次ログで収まるようにログ・ファイル・サイズおよ びファイル数を決定します。ログの数は、ＤＢ構成パラメーターのLOGPRIMARYおよびLOGSECONDで定義されます。 ■ アーカイブ・ロギング ➨ バックアップ・ファイルをリストアした後に、ロールフォワード処理するためにログを保存しておくモードです。DB2 UDB では、オンライン・バックアップ、表スペース単位のバックアップを使用する場合は、アーカイブ・ロギングを選択する必 要があります。 ➨ アーカイブ・ロギングでは、オンライン・アーカイブ・ログとオフライン・アーカイブ・ログの２つのアーカイブ・ログが使用 可能な状態になります。 ➨ アクティブ・ログについては循環ロギングと同様で、１次ログと２次ログが存在し、割り振られるログの数はＤＢ構成パ ラメーターのLOGPRIMARYおよびLOGSECONDで定義されます。 ➨ V8.1では無限ロギングがサポートされました。LOGSECONDに-1を設定した場合、２次ログは無制限にアロケーション されます。これにより、アクティブ・ログ・ファイルの数は無制限に使用できます。 ● アーカイブ・ロギングの設定方法 ➨ ＤＢ構成パラメーター（DB CFG)の LOGRETAIN = RECOVERY ➨ ＤＢ構成パラメーター（DB CFG)の USEREXIT = ON ‒ 上記のどちらかを設定します（LOGRETAINがOFFでもUSEREXIT=ONならばアーカイブ・ロギング・モードになる） ➨ コマンド例 ‒ 設定: UPDATE DB CFG FOR DB名 USING LOGRETAIN ON ‒ 確認: GET DB CFG FOR DB名 １−５．インクリメンタル・バックアップ ■インクリメンタル・バックアップ ●効果 ➨バックアップするサイズが小さければ、それだけバックアップ中に読み込むデータ量は減る ➨フル・バックアップを頻繁に取ったり、長いログの処理を行うことなく回復させることが可能 ➨データベースと表スペースのインクリメンタル・バックアップが可能 ●サポートされるバックアップ・レベル ➨累積 : 最後のフル・バックアップから変更されたデータのバックアップ ➨デルタ（非累積） : 最後のフル・バックアップまたはインクリメンタル・バックアップから変更されたデータのバックアップ 日曜日 月曜日 火曜日 水曜日 木曜日 金曜日 土曜日 日曜日 フル フル 累積バックアップ フル デルタ バックアツプ フル １−５．インクリメンタル・バックアップ ■インクリメンタル・バックアップのためのパラメーター ● データベース構成ファイル（DB CFG）のトラック変更ページ（TRACKMOD）パラメーターをONにする。 ➨ コマンド例 : update db cfg for sample using TRACKMOD yes ● TRACKMOD=yesを有効にした後、最初はフル・バックアップを取得する必要がある。 ■累積バックアップとデルタ（差分）バックアップ ● 累積バックアップは、最新のフル・バックアップ後の変更データを保存する。 ● デルタ・バックアップは、最新の任意のバックアップ（フル・バックアップ、累積バックアップ、またはデルタ・バック アップ）後の変更データを保存する。 ➨ コマンド例 backup database sample incremental to d:¥db2backup （累積） backup database sample incremental delta to d:¥db2backup （デルタ） ■サポートされるモード ● オンラインとオフラインの両方のモードをサポート ■サポートされるバックアップ可能単位 ● データベースと表スペースのどちらの単位でも取得可能 １−５．インクリメンタル・バックアップ ■インクリメンタル・バックアップでのリストア ●リストア対象（例） ➨フル・バックアップ ➨最新の累積バックアップ ➨デルタ・バックアップ ➨障害発生前のログ・ファイル ●AUTOMATICオプションにより、リストアが自動的に必要なバックアップ・イメージを要求 ➨コマンド例 : restore database sample incremental automatic taken at <timestamp> 日曜日 月曜日 火曜日 水曜日 木曜日 金曜日 フル デルタ デルタ 累積 デルタ デルタ 土曜日 フル 回復 + フル + 累積 + デルタ 日曜日 ログ １−５．インクリメンタル・バックアップ ■RESTOREコマンド ● RESTOREコマンドにINCREMENTALを指定した場合、各バックアップ・イメージごとにRESTOREコマンドを手 動で実行する必要があります。 ● RESTOREコマンドにINCREMENTAL AUTOMATICを指定すると、自動的に必要なバックアップ・イメージが 選択されてリストアされます。 ➨ コマンド例 : restore database sample incremental automatic from d:¥db2backup taken at 20040221020048 ■リストア後のロールフォワード ● アーカイブ・ロギングの場合、リストア後、データベースはロールフォワード・ペンディング状態になるので、 ロールフォワードを実施します。 ➨ コマンド例 : rollforward database sample to 2004-02-21-02.01.00.000000 and stop ■データベース・ヒストリーの照会 ● リストアに必要なバックアップ・イメージを調べるには、db2ckrstコマンドを使用します。 ➨ コマンド例 : db2ckrst –d sample –t 20040221020048 １−６．コントロール・センター ■コントロール・センターを使用したバックアップ １−６．コントロール・センター ■ コントロールセンターを使用してバックアップ対象の定義、実行が可能です ■ 即時にバックアップを実行する以外に、スケジュールを設定することも可能です 時、日、週、月に１回の指定 曜日と時間指定 日と時間指定 ■ コントロール・センターからジャーナルを呼び出すことにより、スケジュール状況、実行状況、結果 の確認ができます １−６．コントロール・センター ■コントロール・センターを使用したリストア １−６．コントロール・センター ■ コントロールセンターを使用してリストア対象の定義、実行が可能です ■ リストア対象は、コントロールセンターで、リストより選択して指定することができます ■ ロールフォワード・リカバリーの指定も同時に行うことが可能です ■ 実行状況、結果の確認もコントロールセンターからジャーナルを呼び出すことにより可能です 第２章 運用上の考慮点 ２−１． ログに関するヒント ■ログは表スペース・コンテナーとは別のディスクに配置します ■アーカイブ・ロギングで運用する場合は、USEREXITプログラムを使用することを検討します ■アクティブ・ログはrawデバイスを使用することも検討します ■アクティブ・ログは２重化することを検討します ■その他 ● LOGBUFSZ ● SOFTMAX ● LOGFILSIZ ● LOGPRIMARY ● LOGSECOND ２−１． ログに関するヒント ■ログは表スペース・コンテナーとは別のディスクに配置します ● I/Oの競合をさけるために、ログと表スペースのコンテナーを別のディスクに配置することを検討します。 ■アーカイブ・ロギングで運用する場合は、USEREXITプログラムを使用することを検討します ● 手動でのオフライン・アーカイブへの移動を行うのではなく、USEREXITの使用を検討します。 ● USEREXITは、サンプル・プログラムが提供されており、環境に合わせた簡単な修正にてすぐに使用可能です。 ➨ sqllib/samples/c 以下に、db2uext2.cdisk等のC言語のサンプル・プログラムが用意されています。 ■アクティブ・ログはrawデバイスを使用することも検討します ● ログの書き込みが高速です。 ● HA(高可用性）構成時に切り替え処理が速い。 ● ただし、rawデバイス・ログでは、２次ログが使用できません。 ■アクティブ・ログは２重化することを検討します ● ログの障害対応として２重化を検討します。２重化は下記の２つの方法で実現できます。 ➨ H/WやOSによるディスクのミラーリング機能 ➨ DB2の重複ロギング機能の利用（ログ・パスとミラー・ログ・パスの両方にアクティブ・ログを作成します） ２−１． ログに関するヒント ■その他 ● LOGBUFSZ ➨ ログ・レコードをディスクに書き込む前に使用するメモリーの大きさを指定します。 ➨ この値を大きくすればログ・レコードをディスクに書き込む頻度を減らすことができます。デフォルトは、８ページ （8×4KB)と小さいため、より大きな値を設定してください。（512程度の値を目安としてください） ● SOFTMAX ➨ 破損回復に必要なログ・ファイルの量が、ログ・ファイル・サイズ（LOGFILSIZ）に対してこのパラメーターで設定した パーセンテージ以上になると、バッファー・プール上の変更された古いページがディスクに書き込まれます。 LOGFILSIZが大きい場合にはこの値を小さくすることを検討してください。 ● LOGFILSIZ ➨ １次、２次ログ・ファイルのサイズ（単位は4KB)。デフォルトは非常に小さな値のため大きくする必要があります。 ● LOGPRIMARY ➨ 作成する１次ログ・ファイルの数、１次ログの容量は、LOGPRIMARY×LOGFILSIZになります。 ● LOGSECOND ➨ １次ログが一杯なった場合に割り振られる２次ログの数。基本は、１次ログで収まるように１次ログを定義します。 ➨ logsecond を -1 に設定した場合は、データベースは、アクティブ・ログ・スペースが無限として構成されます。 ➨ rawデバイスにログを取った場合には２次ログは使用できません。 ただし、overflowlogpath 構成パラメーターを構成することにより、 logsecond を -1 に設定することは可能です。 この場合、overflowlogpath はディレクトリーでなければならず、ロー・デバイスではありません。 ２−２．バックアップ種類選択のための考慮点 夜間等に十分なDB2の停止時間が確保できるか （ｵﾝﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ or ｵﾌﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟの判断） YES ｵﾌﾗｲﾝ NO ｵﾝﾗｲﾝ 最新の状態あるいは、ある特 定の業務途中までに戻す必要 があるか（ﾛｰﾙﾌｫﾜｰﾄﾞ・ﾘｶﾊﾞﾘｰ の必要性判断） NO ﾛｰﾙﾌｫﾜｰﾄﾞ不要 ﾊﾞｯｸｱｯﾌﾟ時間を少しでも 短縮したい。 NO ｲﾝｸﾘﾒﾝﾀﾙなし ｵﾌﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ + 循環ﾛｷﾞﾝｸﾞ YES ｲﾝｸﾘﾒﾝﾀﾙ使用 ｵﾌﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ + ｲﾝｸﾘﾒﾝﾀﾙ・ ﾊﾞｯｸｱｯﾌﾟ + 循環ﾛｷﾞﾝｸﾞ YES ﾛｰﾙﾌｫﾜｰﾄﾞ必要 ﾊﾞｯｸｱｯﾌﾟ時間を少しでも短 縮したい。 （ﾛｰﾙﾌｫﾜｰﾄ・ﾞﾘｶﾊﾞﾘｰは使 用可能） ﾊﾞｯｸｱｯﾌﾟ時間を少しでも 短縮したい。 NO ｲﾝｸﾘﾒﾝﾀﾙなし ｵﾌﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ + ｱｰｶｲﾌﾞ･ﾛｷﾞﾝｸﾞ YES NO ｲﾝｸﾘﾒﾝﾀﾙ使用 ｲﾝｸﾘﾒﾝﾀﾙなし ｵﾌﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ + ｲﾝｸﾘﾒﾝﾀﾙ・ ﾊﾞｯｸｱｯﾌﾟ + ｱｰｶｲﾌﾞ･ﾛｷﾞﾝｸﾞ ｵﾝﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ + ｱｰｶｲﾌﾞ･ﾛｷﾞﾝｸﾞ YES ｲﾝｸﾘﾒﾝﾀﾙ使用 ｵﾝﾗｲﾝ・ﾊﾞｯｸｱｯﾌﾟ + ｲﾝｸﾘﾒﾝﾀﾙ・ ﾊﾞｯｸｱﾂﾌﾟ + ｱｰｶｲﾌﾞ･ﾛｷﾞﾝｸﾞ ２−２．バックアップ種類選択のための考慮点 ■バックアップの取得方法 ● 種類選択のための考慮点 ➨ バックアップ方法を選択するにあたり、バックアップが取得される時間帯の制約を考慮する場合と、リカバリー要件（ど の時点までリカバリーするか、どれくらいリカバリーに時間をかけられるか）を考慮する場合があります。 ➨ 連続運転をする必要がなく、夜間等に十分な停止時間が得られる場合には、オフライン・バックアップを第一に候補と して考えることができます。 ➨ 逆に、十分な停止時間が得られない場合には、オンライン・バックアップを検討します。 ➨ なお、後述するIBM ESS等のディスク装置の高速コピー機能を使用したバックアップは、データベースのミラー・イメー ジを別のディスク上に取得することができるため、３６５日２４時間運転に限りなく近い運用が求められている大規模な データベースに適用することが可能です。 ➨ インクリメンタル・バックアップは、前回のバックアップ以降に更新されたページだけをバックアップ対象とするものです。 このため、バックアップに必要な時間はフル・バックアップよりも短時間で済みます。 ２−２．バックアップ種類選択のための考慮点 ■バックアップの種類とロギング・モード ➨ 取得するバックアップの種類と単位に応じた、適切なロギング・モードで運用されている必要があります オフライン・バックアップ オンライン・バックアップ データベース単位 表スペース単位 データベース単位 表スペース単位 循環 ロギング ○ × × × アーカイブ・ ロギング ○ ○ ○ ○ ２−２．バックアップ種類選択のための考慮点 ■バックアップの種類とロギング・モード ➨ オフライン・バックアップは、データベースに誰も接続していない状態でバックアップを取得します。 ➨ オフラインかつ、データベース単位のバックアップが、循環ロギングで使用できる唯一のバックアップ形態になります。 循環ロギングで運用している場合は、リストアは、データベース単位のバックアップ・ファイルを戻すバージョン回復の みが可能になります。 ➨ オフライン・バックアップであってもアーカイブ・ロギング運用をしている場合は、バージョン回復の後に、ロールフォ ワード・リカバリーを行い、最新あるいは、特定時点までの状態に戻すことが可能になります。 ➨ 表スペース単位のバックアップ、リカバリーには、アーカイブ・ロギングでの運用が必要です。アーカイブ・ロギング運 用であれば、データベース単位でバックアップしていても、リストアは表スペース単位で行うことが可能です。 ➨ オンライン・バックアップにはアーカイブ・ロギングでの運用が必要です。バックアップの単位は、データベース単位、表 スペース単位の両方が利用できます。オンライン・バックアップをリストアした場合は、必ずロールフォワード処理が必 要です。（WITHOUT ROLLING FORWARDを指定すると、「SQL2537 リストア後のロールフォワードが必要です」のメッ セージが出力されます） ➨ 障害時回復のためにはデータベースのフル・バックアップが必須です。表スペース単位のバックアップを寄せ集めても リカバリーすることはできません。 第３章 バックアップとリカバリー例 ３−１．バックアップとリカバリー 例１（バージョン回復） 時間 １日 ３日 ２日 業務稼動 業務稼動 ﾛｸﾞ1にﾛｷﾞﾝｸﾞされた範囲 業務稼動 ﾛｸﾞ２にﾛｷﾞﾝｸﾞされた範囲 障 害 ﾛｸﾞ2 活動 ﾛｸﾞ1 ｱｰｶｲﾌﾞ ｵﾌﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 1 ｵﾌﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 2 要件：オフライン・バックアップ２の 状態に戻したい リカバリー要件 夜間にＤＢ２のオフライン・バックアップを毎日取得しています。ログはアーカイブ・ロギングで運用していますが、 変更があまり発生しない準マスター・ファイルに障害が発生したため、２日の業務終了後に取得したオフライン・ バックアップからのバージョン回復（ＤＢ単位）を実施する必要が生じました。 ３−１．バックアップとリカバリー 例１（バージョン回復） ■毎日のオフライン・バックアップの取得 ● 夜間の停止時間帯にオフライン・バックアップを取得します ➨ コマンド例 : backup database sample to d:¥db2backup ■障害時の回復処理 ● 障害が発生すると、まず２日目のオフライン・バックアップをリストアしてバージョン回復を行います。このリス トア対象のタイムスタンプは、20040212224116としています。（バックアップ時の終了ログやコントロール・セン ターでもタイムスタンプを確認できます） ➨ コマンド例 : restore database sample from d:¥db2backup taken at 20040212224116 without rolling forward ● without rolling forward を指定しているため、RESTORE後にロールフォワード・ペンディングにはなりません。 確認は、GET DB CFG FOR SAMPLE で可能です。 ３−２．バックアップとリカバリー 例２（表スペース単位の回復） ２日 １日 業務稼動 ３日 業務稼動 ﾛｸﾞ1にﾛｷﾞﾝｸﾞされた範囲 業務稼動 ﾛｸﾞ２にﾛｷﾞﾝｸﾞされた範囲 障 害 ﾛｸﾞ2 活動 ﾛｸﾞ1 ｱｰｶｲﾌﾞ ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 1 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 2 要件：特定の表スペースのみ障害 直前の状態に戻したい リカバリー要件 業務は２時から翌日１時４５分までの２３時間４５分連続稼動であるため、業務稼動時間内に、ＤＢ２のオンライ ン・バックアップ(DB単位）を取得しています。３日の夕方に障害が発生したため、障害対象の表スペースの バックアップをリストアーした後に、ロールフォワード・リカバリーを行い、障害発生の直前の状態まで戻す必要が 生じました。 ３−２．バックアップとリカバリー 例２（表スペース単位の回復） ■毎日のオンライン・バックアップの取得 ● 夜間にオンライン・バックアップを取得します ➨ コマンド例 : backup database sample online to d:¥db2backup ■障害時の回復処理 ● 障害が発生すると、まず２日目のオンライン・バックアップをリストアします。 リストア対象のタイムスタンプは、バックアップ時の終了ログやコントロール・センターなどで確認できます。 ➨ コマンド例 : restore database sample tablespace (userspace1) from d:¥db2backup taken at 2004021222411 ● RESTORE後、表スペースはロールフォワード・ペンディングになっています。 確認は、 GET DB CFG FOR SAMPLE で可能です。 リストア後 ロールフォワード 保留状態 ➨ この状態では、DBへのCONNECT（CONNECT TO SAMPLE）は可能ですが、ロールフォワード・ペンディング中である USERSPACE1を使おうとすると、“SQL0290N 表スペース・アクセスが許されていません。 SQLSTATE=55039”のエラーに なります。 ３−２．バックアップとリカバリー 例２（表スペース単位の回復） ● 次に最新の状態までログを使用してロールフォワード・リカバリーを実施します。 ➨ コマンド例 : rollforward database sample to end of logs and stop tablespace (userspace1） ● ロールフォワードが終了すると、ロールフォワード・ペンディングでなくなります。 ➨ GET DB CFGおよびLIST TABLESPACESコマンドにてﾛｰﾙﾌｫﾜｰﾄﾞ保留状態が解除されたのを確認します。 ロールフォワード後 ロールフォワード 保留解除 「状況」欄を 確認 ３−３．バックアップとリカバリー 例３（特定時点までの回復） 時間 １日 ３日 ２日 業務稼動 業務稼動 ﾛｸﾞ1にﾛｷﾞﾝｸﾞされた範囲 業務稼動 ﾛｸﾞ２にﾛｷﾞﾝｸﾞされた範囲 障 害 ﾛｸﾞ2 活動 ﾛｸﾞ1 ｱｰｶｲﾌﾞ ｵﾌﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 1 ｵﾌﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 2 要件：特定の表スペースのみ１１時の 状態に戻したい リカバリー要件 夜間にＤＢ２のＤＢ単位のオフライン・バックアップを毎日取得しています。ログはアーカイブ・ロギングで運用してい ます。特定の表スペースに障害が発生しました。該当の表スペースは、朝のバッチジョブでのみ更新されて いるため、３日朝１１時丁度の状態までリカバリーできれば良いという結論になりました。ＤＢ単位ではなく、障害の 発生した表スペース単位でのリカバリーの必要があります。 ３−３．バックアップとリカバリー 例３（特定時点までの回復） ■毎日のオフライン・バックアップの取得 ● 夜間の停止時間帯にオフライン・バックアップを取得します ➨ コマンド例 : backup database sample to d:¥db2backup ■障害時の回復処理 ● 障害が発生したため、まず２日目のオフライン・バックアップをリストアします。 このリストア対象のタイムスタンプは、20040213014958としています。 ➨ コマンド例 : restore database sample tablespace (userspace1) from db2backup taken at 20040213014958 ● RESTORE後、表スペースはロールフォワード・ペンディングになっています。 確認は、 GET DB CFG FOR SAMPLE で可能です。 リストア後 ロールフォワード 保留状態 ➨ この状態ではDBへのCONNECT（CONNECT TO SAMPLE)は可能ですが、ロールフォワード・ペンディング中である USERSPACE1を使おうとすると、“SQL0290N れます。 表スペース・アクセスが許されていません SQLSTATE=55039” が出力さ ３−３．バックアップとリカバリー 例３（特定時点までの回復） ● 次にログを使用して特定時点までのロールフォワード・リカバリーを実施します。 ➨ コマンド例 : rollforward database sample to 2004-02-13-11.00.00.000000 using local time and stop tablespace (userspace1) ロールフォワード後 ロールフォワード 保留解除 ３−３．バックアップとリカバリー 例３（特定時点までの回復） ➨ ここで対象表スペース中の表を使用すると、検索はできるものの、更新、削除、追加は、“SQL0290N アクセスが 許されていません”という結果になります。なぜなら、時間指定でロールフォワード・リカバリーした場合は、バック アップ・ペンディングになるためです。 ● バックアップ保留を解除するために、対象表スペースあるいは、その表スペースが定義されているデータ ベースのバックアップを取得します。 ● 表スペースの状態は、LIST TABLESPACESコマンドで確認できます。（コントロール・センターでも可） リストア後 ロールフォワード前 ロールフォワード 保留状態 時間指定の ロールフォワード後 バックアップ 保留状態 ３−４．バックアップとリカバリー よく見られるパターン 火 月 業務稼動 業務稼動 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 2 木 水 業務稼動 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 3 業務稼動 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 4 土 金 業務稼動 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 5 日 業務稼動 業務稼動 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 1 ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 6 ｵﾌﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 1 ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰｶｲﾌﾛｸﾞﾞ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ｵﾌﾗｲﾝ ｱｰ ｶｲﾌﾞﾛｸﾞの ｺﾋﾟｰ ３−４．バックアップとリカバリー よく見られるパターン ■平日はオンライン・バックアップ ● 平日の夜間は停止時間が短いため、オンライン・バックアップを取得します。 ➨ コマンド例 : backup database sample online to d:¥db2backup ● すべてオンライン・バックアップで行うことも可能ですが、途中のログの消失などの安全性を考慮し、週末など停 止時間が長く取れるときにロールフォワードが必要ないオフライン・バックアップを保険の意味で取得しておく場合 があります。 ■アーカイブ・ログの保管期間 ● 論理的には最新のオンライン・バックアップが始まる直前のアーカイブ・ログ以降を保存しておけば十分ですが、 これも保険の意味を込めて、最新のオフライン・バックアップ以降のアーカイブ・ログを保管する場合もあります。 ● ARCHIVE LOGコマンドにより、アクティブ・ログを明示的にクローズすることで、保管すべきアーカイブ・ログを容 易に特定することができます。 ➨ コマンド例 : archive log for database sample ■時間指定のロールフォワード処理の注意 ● 時間指定のロールフォワードの場合、データの整合性（UOWのコミットがどこで取られているか）維持はユーザー の責任になります。 ■リカバリー後の注意 ● 時間指定以外の場合はバックアップ・ペンディングにはなりませんが、これも保険の意味で、整合性をとるための 一連のバックアップを取得しておくことをお勧めします。時間に余裕があればオフラインを推奨します。 ３−５．バックアップとリカバリー 例４（インクリメンタル・バックアップの利用） ２日 １日 業務稼動 ３日 業務稼動 ﾛｸﾞ1にﾛｷﾞﾝｸﾞされた範囲 業務稼動 ﾛｸﾞ２にﾛｷﾞﾝｸﾞされた範囲 障 害 ﾛｸﾞ2 活動 ﾛｸﾞ1 ｱｰｶｲﾌﾞ ｵﾝﾗｲﾝ ﾊﾞｯｸｱｯﾌﾟ 1 ｲﾝｸﾘﾒﾝﾀﾙ ﾊﾞｯｸｱｯﾌﾟ 要件：特定の表スペースのみ障害 直前の状態に戻したい リカバリー要件 週始めにオンライン・バックアップ(DB単位）で取得、その後は日次でインクリメンタル・バックアップをオンラインで取 得している。３日目の夕方に障害が発生したため、対象表スペース（userspace1)のみを障害発生の直前の 状態に戻したい ３−５．バックアップとリカバリー 例４（インクリメンタル・バックアップの利用） ■週初めのオンライン・バックアップの取得 ● オンライン・バックアップを取得します ➨ コマンド例 : backup database sample online to d:¥db2backup ■以降、日次でインクリメンタル・バックアップをオンラインで取得 ● インクリメンタル・バックアップを取得します ➨ コマンド例 : backup database sample online incremental to d:¥db2backup ■リストア順序の確認（AUTOMATIC指定でリストアする場合には必要なし） ● db2ckrstコマンドで増分リストアに必要なバックアップ・イメージをリスト表示します ➨ コマンド例 : db2ckrst –d sample –r tablespace –n userspace1 –t 20040221024552 ■リストア ● 表スペースをAUTOMATIC指定で自動リストアします ➨ コマンド例 : restore database sample tablespace (userspace1) incremental automatic from d:¥db2backup taken at 20040221024552 ■ロールフォワードで最新状態までリカバリー ● ログを使用して最新状態までのロールフォワード・リカバリーを実施します ➨ コマンド例 : rollforward database sample to end of logs and stop tablespace (userspace1) 第４章 その他 ４−１．Online Split Mirror ■Online Split Mirror ● OSやハードウェアが提供するコピー機能を使用して、データベースをオンラインのまま他のディスクにコ ピーする技術をOnline Split Mirrorと呼びます。 ➨ DB2のBACKUPコマンドに比べ、高速なバックアップ処理が可能です。 ● 分割したデータベースを一貫性を保ちながらリカバリーすることが可能です。 ➨ ミラー・イメージからバックアップおよびシステム・コピーをとることができます。 Disk Mirror DB2 Tables DB2 Tables ４−１．Online Split Mirror cloneデータベース db2 set write suspend 本番 データベース db2inidb as snapshot バックアップ・コピー mirror (バックアップ復元 専用) db2inidb as standby db2 set write resume mirrorからの復元 db2start db2inidb as mirror db2 rollforawd 回復した本番 データベース 復元コピー rollforward専用 データベース ４−１．Online Split Mirror ■バックアップの実行手順 ● すべての表スペースとログに対するディスク書き込みを禁止します。 ➨ コマンド例 : set write suspend for database ● SET WRITE SUSPENDコマンドが発行されると、ログ・バッファー内のログは強制的にディスクに書き出され ます。 ➨ バッファープール内のページはディスクに書き出されません。 ● ディスクへの書き込みが発生しない限り、SELECT/INSERT/DELETE/UPDATEの実行は可能です。 ➨ バッファープール、ログ・バッファーには書き込めるので、空きがある限り、UPDATE/INSERT/DELETEは実行できます。 ➨ 更新トランザクションのCOMMITはログ・バッファーのディスク・フラッシュを伴うのでWAITになります。 ➨ 一時表スペースへの書き込みが必要なSELECTはWAITになります。 ● IBM ESSのFlash Copy等システムのコピー機能により、Split Mirrorイメージを取得します。 ➨ データベースを停止する必要はありません。 ● ディスク書き込み禁止状態を解除します。 ➨ コマンド例 : set write resume for database ■リカバリーの実行手順 ● Flash Copy等システムのコピー機能により、Split Mirrorイメージをコピー・バックします。 ● db2inidbコマンドでas mirrorと指定し、復元コピーは元のデータベースを置き換えることを宣言します ● DB2のrollforwardコマンドを実行します。 ➨ 適用されるログは、本番データベース上のものを使用します。 ４−１．Online Split Mirror ■Split Mirrorイメージの初期化 ● データベースのミラー・イメージを取得したときは、db2inidbコマンドにより、取得したSplit Mirrorイメージの用途 を指定する必要があります。 ➨ コマンド例 : db2inidb sample as _________ ● MIRROR ➨ Split Mirrorを、プライマリー・データベースのリストアに使用できるバックアップ・イメージとして使用することを指定します。 ➨ データベースはロールフォワード・ペンディングになり、最新のログをロールフォワード・コマンドにより適用し、指定した時刻 あるいは障害の直前のコミットした状態にリカバリすることが可能です。 ● SNAPSHOT ➨ 照会専用のcloneデータベースなどとして利用するときに指定します。 ➨ クラッシュ・リカバリーが実行され、書き込み禁止状態が解除されます。 ➨ Split Mirrorが取得された時点で未COMMITのトランザクションはロールバックされます。 ● STANDBY ➨ 災害対策などの用途で、本番データベースのログを継続してrollforwardし適用する場合などに指定します。 ➨ クラッシュ・リカバリーは実行されず、データベースをロールフォワード・ペンディングにしておきます。 ➨ データベースはロールフォワード・ペンディングのため、必要に応じてロールフォワードを実行し、プライマリー・データベース のログ・ファイルを適用します ➨ プライマリー・データベースが循環ロギングを用いている場合、STANDBYおよびMIRRORオプションは指定できません。 ➨ DB2 DPF(Database Partitioning Feature)構成においては、Split Mirrorイメージがアクセス可能になる前に、全パーティショ ン上でdb2inidbコマンドを実行する必要があります。 ➨ db2inidbで初期化する前にsplit Mirrorイメージに対してCONNECTしようとすると、SQL20153Nのエラーになります。 ４−２．リストアによる表スペース・コンテナーの変更 ■リダイレクト・リストア ● リストア時に表スペース・コンテナーの追加、変更、削除を行いたい場合、REDIRECTオプションを付けてリ ダイレクト・リストアを行います。 ➨ コマンド例 : restore database sample tablespace (userspace1) from d:¥db2backup taken at 20040211200235 redirect ● SMS表スペースでもコンテナーを増やすことができます。 ➨ 通常、SMS表スペースはDMS表スペースの場合とは異なり、コンテナーを追加することはできません。しかし、このリダ イレクト・リストアを行うことでコンテナーを増やすことができます。データが増えてSMS表スペース・コンテナーのサイズの 上限に達しそうな場合は、この方法によるコンテナー・パスの変更やコンテナーの追加で対応することが可能です。 ● DMS表スペース・コンテナーの場所を変更することができます。 ➨ DMS表スペース・コンテナをFILEからRAW DEVICE、DEVICEからFILEに変更することができます。 ■リダイレクト・リストアの手順 （コンテナー・パスの変更） ● バックアップ・ファイルを指定してリダイレクト・リストアを行います。 ➨ コマンド例 : restore database sample tablespace (userspace1) from d:¥db2backup taken at 20040222200010 redirect ● SET TABLESPACE CONTAINERSコマンドでコンテナー・パスを変更します。 ➨ コマンド例 : set tablespace containers for 2 using (path ‘d:¥db2data2') ● 変更したコンテナー・パスに対して、リストア処理を再開します。 ➨ コマンド例 : restore database sample continue ➨ リダイレクトが完了すると、表スペースはロールフォワード・ペンディングになるので、ロールフォワード処理が必要です。 （リダイレクト・リストアは、アーカイブ・ロギングで行う必要があります。）