Oracle GoldenGate Veridata 23c – どのように機能するのか

※ 本記事は、Veeratteshwaran Sridharによる”Oracle GoldenGate Veridata 23c – How does it work?“を翻訳したものです。

Oracle GoldenGate Veridataは、リアルタイムのデータ比較および修復ツールです。詳細はデータ・シートを参照してください。このブログでは、リアルタイム比較プロセスの背後にあるメカニズムについて説明します。

Oracle GoldenGate Veridataがデータをリアルタイムで比較するための2ステップのプロセスです。

1. 初期ステップまたは行のハッシュ・ステップMOOS – ほとんどが非同期
2. COOS – 非同期の確認

次に、何が起きているかを簡単に説明します。

初期ステップまたは行のハッシュ・ステップMOOS – ほとんどが非同期

• ソース/ターゲット・データベースから行データを取得
• データを標準形式に変換
• データをハッシュしてサーバーに送信
• 非同期の行データをMOOSキューに格納

COOS – 非同期の確認

• 各行を比較して正確な結果を保証
• 待機時間しきい値が構成された行ハッシュと並行して実行
• 同期要求からバッチ処理できることの確認
• リモート・データベースの優れたパフォーマンス
• プロファイル設定による制御
• パラレルでの参照の実行

詳しく説明します。

1. 初期ステップまたは行のハッシュ・ステップMOOS – ほとんどが非同期

これにより、比較プロセスの初期ステージがマークされます。Veridataエージェントは、開始後、指定した問合せを使用してソース表とターゲット表の両方から行を取得します。Oracle GoldenGate Veridataは、異機種間データ比較および修復ツールであり、ソース・データベースとターゲット・データベースが異なる場合にデータ型を標準化することで互換性を確保します。

データの取得には、主キー(PK)列値を直接フェッチする(実際の値がフェッチされる)一方で、非キー列はハッシュ化されて比較のためのネットワーク転送が最小限に抑えられます。この独自のハッシュ・プロセスにより、比較プロセスが合理化され、ソース・データベースとターゲット・データベースの行の類似性または差異を判断する信頼できる効率的な方法が提供されます。

また、デフォルトのハッシュ・オプションを変更することもできます。Oracle GoldenGate Veridataでは、ハッシュのみに依存するのではなく、比較のために非キー列の実際の値をフェッチするように設定できます。ただし、この調整によって、特に列数が多い場合、パフォーマンスの低下とネットワーク使用量の増加につながる可能性があります。

最初の比較の完了後、Oracle GoldenGate Veridataが一部の行の不一致を検出した場合、ユーザーに対して比較結果を表示しません。かわりに、これらの行をメモリー内の非同期(MOOS)キューに格納します。この予防は、同時リアルタイム・レプリケーションのために必要であり、レプリケーションの待機時間がある可能性があり、非同期行が転送中になる可能性があります。その後、レプリケーションによって再度同期されます。

2. COOS – 非同期の確認

確認または非同期確認(COOS)と呼ばれる検証プロセスでは、動的設定で行のステータスを検証することで、正確な結果が保証されます。このプロセスでは、MOOSキューから取得した行を使用して、ソースまたはターゲットに対する条件付き照会を行い、ステータスは後続の可能性の1つとして評価されます:

実行中:

最初に行は比較プロセス中に同期されませんでしたが、現在は修正されています。このシナリオでは、レプリケーションまたは同様のメカニズムによって変更が実装されていると想定されますが、Oracle GoldenGate Veridataでは行の同期を検証できませんでした。

同期中:

ソース行の値は、レプリケーションまたは同様のプロセスでターゲット行に転送されました。ステータスが「同期中」と表示されている場合でも、特に基礎となる表が常に変更されている場合、特定の時点で行が同期されることは保証されません。ただし、レプリケーションが正しく機能していることを示します。

永続的に非同期:

最初の比較ステップが実行されてから、行は変更されず、同期が取れない可能性が高いことを示します。

デフォルトでは、確認処理は最初の比較ステップと同時に実行されますが、各行の確認は、指定されたレプリケーション待機時間のしきい値を超えるまで遅延されます。たとえば、レイテンシが60秒に設定され、最初の比較ステップの10:00で非同期行が識別された場合、その行の確認ステップは10:01まで延期され、レプリケーションで保留中の変更が適用されるようになります。待機時間が考慮されると、行は確実に「非同期」としてマークされ、1つ以上の「非同期」レポートにカタログ化されます。

ここでは、ソース・データベースとターゲット・データベースの両方でEmployee表のデータを比較するシナリオについて説明します。比較ジョブを開始すると、プロセスは最初のステップ(初期比較ステップ)から開始されます。

Employee表には、主キー列EMP_IDが含まれています。前述のとおり、Oracle GoldenGate Veridataは、EMP_IDの実際の値を取得し、他の非キー列の値をハッシュします。進行中のレプリケーション・プロセスがあることに注意することが重要です。データ格差が発生した場合、たとえば、一部の10行が非同期であるとすると、Oracle GoldenGate Veridataはそれらをすぐに非同期として確認しません。

リアルタイムのレプリケーション設定と同時データ・レプリケーションでは、これらの10個の非同期行がターゲットにまだレプリケートされていない可能性があります。これはレイテンシが原因である可能性があります。そのため、Oracle GoldenGate Veridataは待機します。非同期行は、メモリー内のMOOSキューに格納されます。

待機時間のしきい値を超えた後、プロセスは「非同期の確認」ステップと呼ばれる2番目のステージに移動します。ここでは、ハッシュを使用せずに、非同期の行のみが調査されます。主キー列と非キー列の両方のすべての値は、元の形式(実際の値)で取得されます。非同期行は値別に比較されます。このステージの後に同じデータの不整合が続く場合、これらの行は非同期として確認されます。次に、ユーザーには、さらにアクションするための非同期行の詳細が表示されます。

これで、ユーザーはデータの修復を実行できます。

この記事を終える前に、私たちが理解する必要があることがいくつかあります。

レイテンシしきい値は、このコンテキストで重要です。前述のシナリオでは、60秒で確立されましたが、手動で調整できます。プロファイル構成内の「同期の遅延確認」パラメータがこのしきい値を制御します。ユーザーは、レプリケーション環境および発生する日次レイテンシについてよりよく理解できます。したがって、このパラメータは要件に応じてカスタマイズできます。

同期の遅延確認期限(秒):

レプリケーション・ラグを考慮するために、確認ステップを指定された秒数だけ遅延します。確認ステップを遅らせると、更新されたソース値が十分な速さでレプリケートされなかったために発生する偽の非同期結果の数が減少します。

詳細は、次のスクリーンショットを参照してください。

Oracle GoldenGate Veridataの比較は、次の2ステップのプロセスであることがわかっています:

1. 初期ステップまたは行のハッシュ・ステップMOOS – ほとんどが非同期
2. COOS – 非同期の確認

ただし、必ずしも2ステップのプロセスに従う必要はありません。ユーザーには、完全にバイパスするオプションがあり、特に「COOS – 非同期の確認」と呼ばれる2番目のステップをスキップします。

プロファイル構成の「非同期ステップの確認の実行」パラメータを使用すると、ユーザーは、Oracle GoldenGate Veridataのデータを比較するときに2番目のステップを実行するかバイパスするかを決定できます。

同期解除の確認ステップの実行:

確認ステップを実行するかどうかを制御します。デフォルトでは実行されます。「値」のチェック・ボックスの選択を解除すると、確認ステップがスキップされ、最初の(行ハッシュ)比較のみが実行されます。たとえば、ソース表のアクティビティが静止している場合や、レプリケーションによってターゲット表が継続的に更新されていない場合は、確認ステップをスキップできます。

視覚的な説明については、次のスクリーンショットを参照してください。

これにより、Oracle GoldenGate Veridata 23cの動作方法を包括的に把握できます。 

その他のリソース

• Veridata 23cデータ・シートを読む
• Veridata 23cのデモ・ビデオを見る
• Veridata 12cから23cへのアップグレード・ドキュメントを確認
• Veridataのドキュメントを読む
• Veridata 23c 提供開始のお知らせブログを読む