再同期処理

オブジェクト・トラッキング・リスト (OTL) 内の項目を使用して、1 次ノードと 2 次ノードで複製されるオブジェクトを再同期します。

OTL 項目には、 Db2® Mirror GUI を介して、または SQL を使用して QSYS2.RESYNC_STATUS ビュー。 RESYNC_STATUS ビューを参照のこと。

まれな失敗ケースで、通常の複製用に追加された OTL 項目が存在する場合があります。 再同期を開始する前に、ソース・ノードとターゲット・ノードの両方の OTL が比較され、特定オブジェクトに対する競合操作がないことが確認されます。 競合が検出された場合、ユーザーは、 Db2 Mirror GUI または QSYS2.CHANGE_RESYNC_ENTRIES プロシージャー。 OTLエントリーの比較の詳細については、 COMPARE_RESYNC_STATUSテーブル関数を参照のこと。

Db2 Mirror GUI を使用して、再同期の開始を妨げる競合を表示するには、オブジェクト・トラッキング・リストのアクション・セットから 「トラッキング・リストの競合の解決」 を選択します。

図 1. OTL の競合解決オプション
OTL の競合解決オプション

2 つのノード上のオブジェクト間で何が異なるかを判別するには、 Db2 Mirror インターフェースを使用してオブジェクトを比較します。

図 2. Db2 Mirror GUI を使用した OTL 競合の比較と解決
Db2 Mirror GUI を使用した OTL 競合の比較と解決

QSYS2.COMPARE_RESYNC STATUS が正常になると、再同期が開始されます。 再同期には、主に以下の 3 つのステップがあります。

  1. 再同期の準備
  2. 再同期のフェーズ 1 処理
  3. 再同期のフェーズ 2 処理

再同期の準備

再同期の準備を行う目的は、3 つあります。
  1. OTL 項目を処理する正しい順序を決定する。
  2. OTL 項目の処理を最適化する。
  3. 再同期に必要な追加項目を追加する。

OTL 項目の処理の順序

オブジェクトはその他のオブジェクトに依存する場合があります。 例えば、ライブラリー内のオブジェクトはそのライブラリーに依存します。また、オブジェクトはユーザー・プロファイルによって所有され、そのユーザー・プロファイルに依存します。論理ファイルは物理ファイルに依存します。 一部のケースでは、通常の複製のために多数の項目が OTL に追加される可能性があります。 例えば、ライブラリーが RCL に追加されると、複製されるオブジェクトごとに 1 つの項目が追加されます。 依存されるオブジェクトが従属オブジェクトよりも前に複製されるように、これらのオブジェクトは、正しい順序で処理される必要があります。 削除操作の場合は、その逆が必要になります。従属オブジェクトは、依存されるオブジェクトよりも前に処理される必要があります。

複雑なデータベース・ネットワークでは、複雑さのレベルが増します。 例えば、ビューまたは論理ファイルが複数の表または物理ファイルに依存していたり、参照制約によって、参照ネットワーク全体に対する DDL 操作が完了した後に追加の処理が必要になったりする可能性があります。 このようなタイプの状態に対処するために、データベース・ファイルはネットワークにグループ化されます。 どのオブジェクトが関連しているかを示すために、再同期の準備中に OTL 内のネットワーク番号が更新されます。

場合によっては、OTL 内の、あるトラッキングされた項目が、同じオブジェクトの別の項目に依存していることがあります。 例えば、表の列が追加された後に、その列に依存する制約がその同じ表に追加される場合があります。 このような場合、制約が追加される前に列が追加されることを保証するために、OTL 内のトラッキング・タイム・スタンプが使用されます。

OTL の項目の再同期は、並行して実行できます。 ただし、依存関係がある場合は、ある OTL 項目が処理される前に、別の OTL 項目の処理が完了している必要があります。

ユーザーは、オブジェクトの再同期の優先度を指定できます。 詳細については、 SET_RESYNC_PRIORITIES 手順を参照のこと。 項目を処理する順序を決定するときに、この優先度が考慮されます。 ただし、再同期が正しく機能するためには依存関係やデータベース・ネットワークの処理を考慮しなければならないため、この優先度は絶対ではありません。 データベース・ネットワーク内のデータベース・ファイルのうち最も高い優先順位が、再同期項目のネットワーク全体に適用されます。

OTL 項目の処理の最適化

OTL 内にある処理が必要な項目の数に応じて、再同期操作の実行は長時間になることがあります。 準備フェーズでは、以下の異なる 2 つの方法で操作が最適化されます。
  1. OTL 内の保管/復元項目は共通。 各項目を別々に処理することは可能ですが、保管/復元操作で複数のオブジェクトをバンドルすることによって、再同期のパフォーマンスが改善されます。 準備ステップでは、保管/復元操作がグループ化されます。
  2. OTL の特定の項目は不要な場合がある。 このような場合、OTL 項目の RESYNC_DEFERRED 列が RESYNC DEFERRED という値で更新されます。 例えば、
    • オブジェクトが削除され、削除項目が OTL に追加された場合、そのオブジェクトは削除されることになるので、そのオブジェクトに関するそれより前の項目は処理が不要な可能性があります。 同じオブジェクトに対する作成項目が前に存在し OTL に含まれている場合、作成と削除のいずれも処理する必要がありません。 一部のケースでは、潜在的な従属オブジェクトのため、この単純化はできません。
    • 再同期中に、あるオブジェクトの OTL 保管/復元項目が処理されるとき、そのオブジェクトの処理には、保管/復元項目の前と後に発生したあらゆる変更が組み込まれます。その理由は、保管/復元操作では現行オブジェクトが使用されるためです。

再同期に必要な追加項目の追加

データベース表または物理ファイルでは、それらを再同期するために特別な処理が必要です。
  • データベース物理ファイルの保管/復元 OTL 項目が処理される場合、1 次ノード上のアプリケーションは、I/O 変更の実行を続行できなければなりません。 これらのアプリケーションを中断させないために、保管/復元は、活動時保管を使用して実行されます。 保管/復元が実行されている間も I/O 変更は続行されるので、保管/復元が開始した後に変更された可能性がある行を処理するために、OTL IO 項目が追加されます。
  • 制約違反が発生しないようにするために、データベース I/O 操作の再同期の前にターゲット・ノードの参照制約は無効にされます。 エラーを回避するために、CHGPFCST 項目が OTL に追加されます。この項目は、データベース・ネットワーク全体の I/O 再同期が完了したときに処理されます。

再同期のフェーズ 1 処理

ほとんどのタイプの OTL 項目は、フェーズ 1 で処理されます。 ただし、最も数が多く実行時間も長くなる OTL 項目は一般的にデータベース I/O 項目であり、それらはフェーズ 2 で処理されます。 フェーズ 1 の間、2 次ノードは BLOCKED 状態になり、すべてのフェーズ 1 の OTL 項目の処理が完了するまでブロックされたままになります。

再同期がフェーズ 1 から抜けられなく状態が 2 つあります。
  • コミットによって、多数のデータベースおよび SQL DDL 操作が実行される。 したがって、コミットによって関連項目も OTL に追加されます。 これらの項目は、トランザクションの終了までロックされます。 再同期の準備フェーズは、それらの OTL の行に対するロックを獲得することでコミットまたはロールバックが発生するまで待機しなければなりません。 ロックを獲得できない場合、フェーズ 1 の項目の処理では、トラッキング・タイム・スタンプの順番で、ロックされた行よりも前にある項目のみが処理されます。 いずれかの OTL 行でロックなしのタイムアウトが発生するまで、準備フェーズは引き続き呼び出され、フェーズ 1 の項目は再同期されます。
  • フェーズ 2 で表または物理ファイルのデータベース I/O 項目を処理するためには、1 次ノードで、それらのファイルに対するデータベース DDL 操作が回避される必要があります。 ファイル・オブジェクト (ファイル・データではありません) に対して *SHRNUP ロックが獲得され、それによって DDL 操作が回避されます。ただし、I/O 操作は妨害されません。 コミットの制御下で実行されない相対的に実行時間が短いデータベース DDL 操作はごく少数であるため、*SHRNUP ロックを獲得できないということはほぼありません。 ただし、ロックを獲得できない場合は、ロックなしのタイムアウトが発生するまで、準備フェーズは引き続き呼び出され、フェーズ 1 の項目は再同期されます。 10 回試行しても *SHRNUP ロックを獲得できない場合、再同期は失敗します。

アプリケーションまたはユーザーは、フェーズ 1 の新しい OTL 項目が追加される操作を実行できるため、フェーズ 1 項目の最初のセットの処理が終わるとロックが獲得されることになります。その際、フェーズ 1 の残りの OTL 項目がすべて処理されるまでアプリケーションによる新しい OTL 項目の追加は遅延されます。 ほとんどのフェーズ 1 操作の実行時間は非常に短いです。 ロックが原因でアプリケーションの待機が発生するので、ベスト・プラクティスは、フェーズ 2 が開始されるまで実行時間の長いフェーズ 1 操作を最低限に抑えることです。

再同期が失敗すると、 Db2 Mirror GUI は、以下の図に示すように、OTL 再同期に問題があることを示します。

図3： 再同期の失敗
再同期の失敗

右クリックしてプルダウン・メニューを表示します。

図4： トラッキング・リストの表示
トラッキング・リストの表示

「トラッキング・リストの詳細の表示 (View Tracking List Details)」を選択します。

図 5. トラッキング・リストの詳細
トラッキング・リストの詳細

OTL には 2 つのエラー項目が表示されています。 両方のエラー・メッセージが、オブジェクト・ロックの障害であることを示しています。 フェーズ 1 処理は、両方のノードでオブジェクトのロックを獲得できなかったため、エラーが OTL に記録され、フェーズ 2 の前に処理が終了されました。

競合を解決するには、以下のようにします。
  1. ロック保有者を識別し、競合の原因となったロックを解放します。
  2. プルダウン・メニューから「Db2 Mirror の再開」を選択し、再同期を再試行します。

再同期のフェーズ 2 処理

再同期のフェーズ 1 が完了すると、フェーズ 2 再同期では以下の 3 つのステップが実行されます。
  1. フェーズ 1 では、フェーズ 2 で再同期される必要があるすべての表および物理ファイルに対する *SHRNUP ロックが獲得されました。 これらのロックは、DDL 操作によって表または物理ファイルが変更されるのを防ぎます。

    フェーズ 2 の再同期が終了すると、ロックは開放され、DDL が再度許可されます。

    フェーズ 2 の処理中は、必要に応じてレコード・ロックが獲得および開放されます。

  2. 再同期が必要な表または物理ファイル内では、内部属性が変更されます。 この属性により、2 次ノード上で稼働しているユーザーまたはアプリケーションは、これらの表または物理ファイルに対する更新、削除、および挿入を実行できなくなります。

    ネットワーク全体の再同期が完了すると、同じネットワーク内の関連するすべての表および物理ファイルで属性がリセットされます。

    フェーズ 2 では、1 次ノードに対して実行された更新、削除、および挿入に対応する操作が、2 次ノードに複製されます。 1 次ノードが変更を 2 次ノードに複製しているときに 1 次ノードでは I/O 操作が実行されるため、フェーズ 2 が開始すると、再同期が必要な行変更の数はそれ以上増えることはありません。むしろ、再同期が必要な行が、再同期の前にアプリケーションによって削除または更新された場合には、その数は減る可能性もあります。

  3. Db2 ミラー状態は ACTIVE になります。

データベース I/O は、常にフェーズ 2 で再同期されます。 スプール・ファイルの項目も、複製された出力待ち行列が移動、名前変更、または削除されない限り、フェーズ 2 で処理されます。

障害が原因で再同期フェーズ 2 が成功しない場合、複製状態は TRACKING/BLOCKEDに戻ります。 IASP上では、SYSBAS と IASP の両方が TRACKING/BLOCKED に戻ります。 SYSBAS レプリケーションを即時に再開することができ、IASP 内の再同期を妨げている問題に対処できます。