外部リフレッシュの実行

このようなサード・パーティーのツールとしては、ソースでの表アンロードおよびターゲットでの表ロード、ソース表とターゲット表の両方に対して実行される表の内容を再生成するアプリケーション・プログラム、ソースとターゲットの両方における過去のある時点への表の内容のリカバリーがあり、データをミラーリングするもの以外のサブスクリプションを使用した表のリフレッシュも考えられます。 このような手段による表のリフレッシュまたは再構築を「外部リフレッシュ」と呼びます。

外部リフレッシュの動作をサブスクリプションのミラーリング動作に統合するため、製品に新たなコマンド機能が追加されました。 このコマンドの動作内容、有効なデータの提供方法、および誤用を避けるための実践を理解するには、 アクティブ処理中のリフレッシュの仕組みを理解することが必要である。

サブスクリプション内の表が「方式: ミラーリング」かつ「状況: リフレッシュ」に設定されているとき、その表はアクティブ時リフレッシュ が作動可能になっています。 外から見ると、サブスクリプションの開始時に、表はリフレッシュされ、サブスクリプション内の表のミラーリングが開始されます。 サブスクリプションは開始時に、リフレッシュが実行された時点より前の位置でログからの収集を開始しなければなりません。 ミラーリングの開始時にリフレッシュされた表については、リフレッシュを開始した位置に収集が到達するまで、ログから収集された変更内容は破棄されます。 到達した時点から、その表について収集された変更内容はターゲットに転送され、ターゲット表に適用されます。 ログ内のリフレッシュ開始位置とリフレッシュ終了位置の間では、ログから収集された変更は、表のその部分がリフレッシュされるときには、表に適用されている可能性も、まだ表に適用されていない可能性もあります。 そのため、変更内容はターゲットに転送されている場合も転送されていない場合もあり、リフレッシュ中にターゲット表に適用される場合も適用されない場合もあります。 したがって、リフレッシュが実行された位置の間でログから収集された変更内容は、操作エラー (例えば、既存行の挿入、存在しない行の更新や削除など) をログに記録しないエラー軽減フィルターを使用して、ターゲットで適用されます。 これらの変更内容を、「無期限にリフレッシュ済み」標識が設定された状態で送信される変更といいます。 収集がログ内のリフレッシュ終了位置を過ぎると、「無期限にリフレッシュ済み」標識は設定されなくなり、操作エラーはそれ以外のエラーのように厳密に扱われます。

リフレッシュ開始時のログ内の位置より前に記録された変更内容が、リフレッシュ開始時にまだコミットされていなかったという状態は起こりえます。 このような変更は、COMMIT の発行後に表に現れますが、変更はログ内のリフレッシュ開始位置より前に記録されたため、ログから収集されるときに破棄されます。 リフレッシュ時に表の内容を取り込む処理では、COMMIT の発行までにどのぐらい時間が経過したかによって、これらの変更が取り込まれない可能性があります。 この場合には、ソース表とターゲット表が同期されなくなります。 これを回避するために、 CDC Replication は、使用中の DBMS に基づくメソッドを使用して、 アクティブな間のリフレッシュ のリフレッシュの開始時に表の整合点を設定します。 例えば、z/OS プラットフォームでリフレッシュ開始前に、表のスコープを持つ共有ロックをリフレッシュ対象の表で取得します。 現在のログ書き込み位置が判別された後、ロックは解除されます。 これにより、ロック対象の表に対する変更を含むリカバリー単位がすべて強制的に完了 (つまり、COMMIT) します。 共有ロックが解放されるときにリフレッシュが開始されて、ロックの保持中にサンプリングしたログ書き込み位置がリフレッシュ開始位置として使用されます。 共有ロックが保持されるのは、最大でも数ミリ秒間であり、表に対する通常の適用処理が中断されることはありません。

外部リフレッシュの実行時には、ソース表の内容が取り込まれ、その内容がターゲット表に書き込まれます。 ソース表の内容が取り込まれている期間は、ソース表が読み取られているアクティブ時リフレッシュ 中の期間と同等です。 ソース表とターゲット表がサブスクリプション外でどのように再同期されるかに応じて、この期間は大幅に長くなる場合 (例えば、アンロードとロードが使用される) や、効果的に短縮される場合 (例えば、ソースとターゲットの両方でのポイント・イン・タイム・リカバリー) があります。

CDC Replication Engine for Db2® for z/OS®の場合、この期間は、DBMS ログ内のログ位置によって表される、ログの開始位置と終了位置に変換する必要があります。 その後、コマンド・インターフェースを使用して 2 つの (おそらく同一の) ログ位置が CDC Replication に提供され、 CDC Replication は、 アクティブな間のリフレッシュのリフレッシュの実行に由来するものとして、それらのログ位置を使用してメタデータを更新します。 サブスクリプションがミラーリングを開始するときに、これらの 2 つのログ位置は、表データの破棄を停止して変更に「無期限にリフレッシュ済み」開始のマークを付ける時点、および変更に「無期限にリフレッシュ済み」停止のマークを付ける時点として、収集点を示します。

サポートされる他のすべてのエンジンでは、アクティブ時リフレッシュ期間は、dmmarkexternalunloadstart および dmmarkexternalunloadend コマンドが発行された時点のログの現在位置によって決まります。

これらの考慮事項に加えて、外部リフレッシュのためにソース表の取り込みを開始する時点で整合点を設定するという問題もあります。 アクティブ時リフレッシュ の実行時に、表のスコープを持つ共有ロックを取得することによって、リフレッシュ対象の表の整合点が設定されます。 この方法は、外部リフレッシュを実行しているときは使用できません。そのため、整合点を設定する別の方法を利用する必要があります。 ソースとターゲットの両方でポイント・イン・タイム・リカバリーを行う場合など、整合点を設定できない場合もあります。 可能な場合には (アンロードと再ロードを実行する場合など)、整合点を設定することを強くお勧めします。 これは、表に対するアクティビティーを静止するか、またはすべての更新アプリケーション・プログラムを停止するだけで実行できます。 この設定は、ソースとターゲットの両方で表の内容全体を再生成するためにプログラムを使用する場合など、必要でない場合もあります (そのようなプログラムは、それ自体のアクションによって暗黙的に表全体をロックすることを想定しています)。 整合点を設定する手順を実行できないと、上記のシナリオの後半で操作エラーが発生する可能性があります。

ミラーリング中の外部テーブル負荷に関する特別な考慮事項