Db2 高可用性災害時リカバリー (HADR) において複製される操作

Db2 高可用性災害時リカバリー (HADR) は、データベース・ログを使用して、1 次データベースからスタンバイ・データベースにデータを複製します。 ログはスタンバイ・データベースで再生されるため、スタンバイ・データベースは一部のアクティビティーが原因で 1 次データベースに後れを取る場合があります。 アクティビティーによっては頻繁に記録されるものがあるため、大量のログ・ファイルが生成されることでストレージの問題が発生する場合もあります。 ログを使ってデータをスタンバイ・データベースに複製することは可用性の中核を成すストラテジーですが、ロギング自体はソリューションの可用性に負の影響を与える可能性があります。 保守ストラテジーは賢明に設計し、ロギングによる負の影響が最小限に抑えられるようにシステムを構成するとともに、ロギングによってトランザクション・データを保護することができるようにしてください。
高可用性災害時リカバリー (HADR) では、以下の操作が 1 次データベースからスタンバイ・データベースに複製されます。
  • データ定義言語 (DDL)
  • データ操作言語 (DML)
  • バッファー・プール操作
  • 表スペース操作
  • オンライン再編成
  • オフライン再編成
  • ストアード・プロシージャーおよびユーザー定義関数のメタデータ (ただし、関連するオブジェクト・ファイルまたはライブラリー・ファイルは除く)。 .jar ファイルとして保存される Java ストアード・プロシージャーは 1 つの例外です。詳しくは、以下を参照してください。

オンライン再編成操作中に行われたすべての変更は、詳細にログに記録されます。 そのため、HADR は、より標準的なデータベース更新の場合よりも、 スタンバイ・データベースを遅れさせることなく、操作を複製できます。 しかし、この動作では、大量のログ・レコードが生成されるため、 システムに大きな影響が出る可能性があります。

オフライン再編成は、オンライン再編成ほど詳細にログに記録されませんが、 通常は、再編成の影響を受けた数百か数千の行ごとに、操作がログに記録されます。 つまり、スタンバイ・データベースは、各ログ・レコードを待機してから、 多数の更新を一度に再生するため、後れを取る可能性があるということです。 オフライン再編成がクラスター化されていない場合、 再編成操作全体の完了後に、1 つのログ・レコードが生成されます。 この方法では、スタンバイ・データベースが 1 次データベースに後れを取らない役割を果たす上で、大変大きな影響を与えます。 スタンバイ・データベースは、1 次データベースからログ・レコードを受け取った後に再編成全体を実行します。

HADR は、ストアード・プロシージャー、UDF オブジェクト、およびライブラリー・ファイルを複製しません。 1 次データベースとスタンバイ・データベースの両方で、同じパスにファイルを作成する必要があります。 スタンバイ・データベースが、参照されているオブジェクトまたはライブラリー・ファイルを検出できない場合、 スタンバイ・データベースでのストアード・プロシージャーまたは UDF の呼び出しは失敗します。

重要: .jar ファイルとして保存されている Java ストアード・プロシージャーの複製操作中には、追加のステップが必要です。 フェイルオーバー後、新しい HADR 1 次データベース上のストアード・プロシージャーにアクセスすると、アプリケーションは SQL4304N メッセージを受け取ります。 このメッセージが表示されないようにするには、ストアード・プロシージャーを使用する前に sqlj.refresh_classes() または sqlj.recoverjar() を実行する必要があります。 この複雑さは、 .java ファイルとして保存される Java ストアード・プロシージャーには適用されないことに注意してください。