DB2 のリカバリ モデル

DB2 のジオデータベースに使用できるリカバリのタイプは、循環ログを使用するバージョン リカバリ、アーカイブ ログを使用するロールフォワード リカバリ、または HADR（High Availability Diaster Recovery）です。

メモ:

ArcSDE for DB2 のジオデータベースをリストアするときは、ArcSDE ジオデータベースを構成しているすべてのデータベースをリカバリする必要があります。

• バージョン リカバリと循環ログ

  循環ログは、ログ ファイルの輪（リング）を使用して、データベースへの変更を記録します。リングの最後のログがいっぱいになると、最初のファイルが再利用されます。トランザクション情報が上書きされる可能性があるので、循環ログを使用する際には、ロールフォワード リカバリを使用することは不可能です。ただし一般に、データの読み込み時にリカバリが必要になることはありません。循環ログは、デフォルトのログ モデルです。

• ロールフォワード リカバリとアーカイブ ログ

  ロールフォワード リカバリを使用する場合、ArcSDE ジオデータベースに推奨されるリカバリ手法ではアーカイブ ログが使用されます。アーカイブ ログはログ ファイルを上書きせず、新しいログを作成して、最後のバックアップ以降のトランザクションをすべて記録します。循環ログのようにログが再利用されないので、アーカイブ ログを使用するには、さらにディスク領域が必要になることに注意してください。

• HADR

  HADR は、DB2 で利用可能なデータベース レプリケーション機能です。ソース データベース（プライマリ データベース）からデータ変更をターゲット データベース（スタンバイ データベース）に複製することにより、データを保護します。プライマリ データベースがダウンした場合は、プライマリ データベースをリカバリするまでの間、スタンバイ データベースに切り換えることができます。

  HADR では、同期モードとして、同期（synchronous）、近同期（near synchronous）、非同期（asynchronous）のいずれかを指定することができます。

  同期モードでは、プライマリ データベースへの変更は、関連ログがスタンバイ データベースのトランザクション ログに書き込まれるまで、プライマリ データベースにコミットされません。スタンバイ データベースのログ ファイルに保存されていない変更がプライマリ データベースに適用されることがないので（したがってリカバリ可能なので）、2 つのデータベースの同期が保たれます。このモードは、プライマリ データベースのパフォーマンスに最も大きな影響を与えます。

  近同期モードでは、プライマリ データベースへの変更は、関連ログがスタンバイ データベースのメモリに書き込まれるまで、プライマリ データベースにコミットされません。これは同期モードとほぼ同じくらい効果的で、プライマリ データベースへの影響も少なく抑えられます。ただし、データがプライマリ データベースにコミットされた後にスタンバイ データベースがダウンした場合、転送されたデータが失われて、2 つのデータベースが一貫性のない状態になる可能性があります。

  プライマリ データベースでのデータベース トランザクションのコミットは、スタンバイ データベースとのログ レコードのやり取りに影響されません。このモードでは、2 つのデータベースが一貫性のない状態になる可能性が高くなります。この他に DB2 で使用できるレプリケーション オプションには、SQL レプリケーションと Q レプリケーションがあります。詳細については、DB2 のドキュメントをご参照ください。

ジオデータベースのリカバリには、RECOVER DATABASE コマンドまたは DB2 コントロール センターのリストア ウィザードを使用することができます。ジオデータベースは、既存のデータベースまたは新しいデータベースにリカバリすることができます。次に、新しいデータベースにリカバリする場合の注意事項を示します。

• 新しいデータベースにリカバリする場合は、インスタンスに接続する必要があります。
• 別のサーバ上の新しいデータベースにリカバリしていて、リカバリ元のサーバとリカバリ先のサーバがデフォルトのコード ページを使用していない場合は、リカバリを実行する前に、リカバリ先のコンピュータに正しいコード ページでデータベースを作成する必要があります。移行先のコード ページが移行元のコード ページと異なる場合、リストア ユーティリティはコード ページがデフォルトであることを前提に動作します。その結果、SQL2548N エラーとなります。
• 新しいデータベースにリカバリする場合は、バックアップ イメージのリカバリ履歴ファイルが新しいデータベースのリカバリ履歴ファイルになります。

リカバリ可能なデータベースの完全リカバリを実行する場合、データベースへの接続は、データベースのリカバリ時に確立された接続だけでなければなりません。完全バックアップをリストアする際、DB2 はデータをリストアするデータベース（既存のデータベースまたは新しい空のデータベース）に、バックアップ イメージで参照されているすべての表領域が存在することを確認します。欠けている、またはアクセス不能な表スペースが検出された場合、リカバリ処理は失敗します。

これを回避するには、リダイレクト リストア処理を実行します。これにより、リカバリ先のデータベースに存在しない表スペースをバックアップ イメージからリストアするための、新しい表スペースを指定することができます。リダイレクト リストアを実行する方法については、DB2 のドキュメントをご参照ください。

リカバリ可能なデータベースの表スペースを個別にリストアする場合は、リストア先の表スペースにユーザが接続していない限り、データベースをオンラインのままにすることができます。

ヒント

• ログ ファイルのアーカイブと取得は、USEREXIT プログラムで自動化することができます。これを使用するには、logarchmeth1 コンフィグレーション パラメータを USEREXIT に設定する必要があります。

  USEREXIT プログラムを開発して使用する方法については、DB2 のマニュアルをご参照ください。

• データベースがパーティション分割されている場合は、RECOVER DATABASE コマンドをカタログ パーティションから実行する必要があります。パーティション分割されたデータベースを特定の時点までリカバリする場合、db2nodes.cfg ファイルに列挙されているすべてのパーティションがその対象となります。ログの最後までリカバリする場合は、リカバリの対象となるパーティションを指定することができます。特定のパーティションを指定しない場合は、db2nodes.cfg ファイルのすべてのパーティションが対象となります。