パラレルReplicat - 並列度および依存性計算 (2023/09/29)

https://blogs.oracle.com/dataintegration/post/parallel-replicat-parallelism-and-dependency-calculation

投稿者： Volker Kuhr | Senior Principal Product Manager

Oracleでは、大量のスループットを持つデータベースでパラレルReplicat (PR)を使用することをお薦めします。ソース・データベースは、多数のトランザクションを同時に管理する数百または数千のセッションを持つシステムである場合があります。ターゲット・データベースに変更を適用するReplicatプログラムは1つのみです。PRの並列性の適用は、このワークロードに対応する方法の問題を解決する鍵です。パラレルReplicatは、トランザクション整合性を維持しながらトランザクションをリアルタイムで正常に適用します。

次に例を示します。

1つのトランザクションが古いバックアップまたは履歴表からコンテンツを削除し、オンライン・オーダー・アプリケーションが完全に独立した表に対してトランザクションを実行する場合、PRはそれらのトランザクションの表間に関係がないことを識別し、PRはそれらのトランザクションのセットを同時に適用できます。ターゲット・システムでの削除トランザクションは、後でソース・データベースで開始された場合でも、ターゲット・データベースでオンライン順序よりも高速に終了する可能性があります。

もう1つのケースは、相互に依存するトランザクションに関するものです。たとえば、1つの表レコードと同じ表レコードOE.ORDERSを変更するとします。最初のトランザクションはINSERT操作を実行し、次のトランザクション・セットは同じレコードに対してUPDATE操作を実行します。この場合、PRは依存関係を識別し、Appliersは相互に待機する方法をスケジュールします。OE.ORDERSやOE.ORDER_ITEMSなどの表間の外部キー関係でも、パラレルReplicatで識別されます。

依存性の計算は、ターゲット・データベースの主キー、一意索引および外部キーの列に基づきます。このため、単純なレプリケーション環境(ソース・システムとターゲット・システムは同じ)について、ソース・データベースのスケジューリング列にサプリメンタル・ロギングを追加することが重要です。これは、事前にTRANDATA/SCHEMATRANDATAを追加した理由の1つです。変更のビフォア・イメージに基づいて、Replicatは依存性を計算し、それに応じてスケジュールします。

デフォルトでは、パラレルReplicatは4つのアプライヤを使用してトランザクションをパラレルに適用します。必要に応じて十分なCPUリソースが使用可能な場合は、パラレル化を増やしてレプリケーション・スループットを向上させることができます。これは、トランザクションの依存関係がない場合にスケーリングされます。

ソース・データベースの依存トランザクションの数が多い場合、ソース・データベースとターゲット・データベースがグローバルに整合するようにトランザクションの整合性を維持する必要があるため、レプリケーション・スループットが低下する可能性があります。

パラレルReplicatのアーキテクチャ(統合および非統合):

• 複数のマッパーがTrailファイルから変更を読み取り、メイン・プロセスに渡します。
• メイン・プロセスでは、変更がマージされ、アプライヤのトランザクションがスケジュールされます。
• 各アプライヤは完全なトランザクションを管理しています。(*)

通常、アプライヤの並列度のみを管理するには十分です。

実験をしよう:

1つ目のケースは、非依存トランザクションの例を示しています。INSERT操作は、完全に無関係なレコードで実行されています。

対照的に、2番目のケースは依存トランザクション・パターンの例を示しています。各トランザクションには、1つのレコードに対して1つのUPDATE操作もあります。

Replicatは、表U1に対する依存性を検出します。T02と、第2適用者は、第1適用者が第1トランザクションを終了するまで待機する必要があります。これは依存性WAITとしてカウントされます。

independent Workload	dependent Workload
begin   for i in 1..1000000 loop     insert into u1.t01 values (i,0);     if (mod(i,100) = 0) then         insert into u1.t02 values (i,0);       commit;     end if;   end loop; end; /	begin   insert into u1.t02 values (0,0);   commit;   for i in 1..1000000 loop     insert into u1.t01 values (i,0);     if (mod(i,100) = 0) then        update u1.t02 set b = i;       commit;     end if;   end loop; end; /

この例では、AdinClientを使用しています。WEB-UIから情報を取得したり、RESTコールを使用してGoldenGateインスタンスからデータを取得することもできます。次のコンテンツの一部はレポート・ファイル内に表示されることに注意してください。

statusコマンドを使用すると、現在のアクティブなアプライヤに関する情報が表示されます。これらのアプライヤは、データベースに対して同時にDML操作を実行しています。

adminclient> SEND REPLICAT REPN、STATUS

Independent Workload	Dependent Workload
Map Parallelism: 2 Min Apply Parallelism: 10 Current Apply Parallelism: 10 Max Apply Parallelism: 10 Active Appliers: 9	Map Parallelism: 2 Min Apply Parallelism: 10 Current Apply Parallelism: 10 Max Apply Parallelism: 10 Active Appliers: 0

statsコマンドは、パラレルReplicatについて、表間の依存性に関する情報も表示します。親表と子表が同じ場合、多くの場合、依存性は主キーまたは一意索引に基づきます。それ以外の場合は、表間に外部キー関係があります。

adminclient>STATS REPLICAT REPN

Independent Workload	Dependent Workload
Workload dependency statistics: <none>	Workload dependency statistics: CHILD               PARENT             COUNT =================   ================   ======= CDB1_PDB2.U1.T02    CDB1_PDB2.U1.T02   10000

さらに深く掘り下げて、依存関係グラフで依存関係を確認することもできます。これはパラレルReplicatでのみ使用できることに注意してください。

adminclient> SEND REPLICAT REPN、DEPENDENCYINFO

Independent Workload

Dependent Workload

Scheduler 0: Transaction groups currently being executed:         Group 0:4249226121.2.28.874         Group 1:4249226121.8.2.867         Group 2:4249226121.5.29.880         Group 3:4249226121.6.10.892         Group 4:4249226121.3.18.882         Group 5:4249226121.7.22.661         Group 6:4249226121.9.29.889         Group 7:4249226121.1.29.659         Group 8:4249226121.9.7.889         Group 9:4249226121.4.7.675

Scheduler 0: Transaction groups currently being executed:         Group 0:4249226121.5.23.872, 4249226121.6.12.881, 4249226121.9.23.879, 4249226121.2.7.867,                 4249226121.3.32.881, 4249226121.7.22.655, 4249226121.8.14.857, 4249226121.5.16.872,                 4249226121.6.7.883, 4249226121.1.7.653 Waiting transactions:          Transaction with XID 4249226121.9.11.879 is waiting on transaction with XID 4249226121.1.7.653         Transaction with XID 4249226121.2.17.865 is waiting on transaction with XID 4249226121.9.11.879         Transaction with XID 4249226121.4.33.665 is waiting on transaction with XID 4249226121.2.17.865         Transaction with XID 4249226121.3.3.881  is waiting on transaction with XID 4249226121.4.33.665         Transaction with XID 4249226121.6.20.881 is waiting on transaction with XID 4249226121.3.3.881         Transaction with XID 4249226121.8.27.857 is waiting on transaction with XID 4249226121.6.20.881         Transaction with XID 4249226121.9.28.874 is waiting on transaction with XID 4249226121.8.27.857         Transaction with XID 4249226121.5.33.872 is waiting on transaction with XID 4249226121.9.28.874         Transaction with XID 4249226121.2.33.864 is waiting on transaction with XID 4249226121.5.33.872         Transaction with XID 4249226121.8.1.858  is waiting on transaction with XID 4249226121.2.33.864

この実験では、ソース・データベースのトランザクションに与える影響を示します。依存関係を引き起こす変更のみがある場合でも、それらのトランザクションを管理するアプライヤは待機する必要があります。

この問題を解決する方法は?慎重に分析する必要がある2つの解決策がある場合があります。

1. 表をReplicatから生成する依存性を取り出し、別の(クラシック)Replicatに配置する場合があります。この場合、各Replicatが変更を独立して適用するため、依存性はなくなります。ただし、トランザクションはスライスされます。実験例の場合、これは正常に動作します。これは、トランザクション・パターンを深く理解する必要がある財務ビジネス・アプリケーションでは異なる場合があります。
2. ソースでトランザクション・パターンを変更すると、それらの依存関係を回避できます。実験的な例では、主キーの依存関係がないように、UPDATEをINSERTに変更できます。ただし、ビジネス・アプリケーションへのアクセス権がなく、トランザクション・パターン/ビジネス・ロジックを変更できない場合があります。

この簡単な実験ケースでは、PR内でトランザクションがどのように管理されるかを示します。ソース・データベースのワークロードとそのトランザクション・パターンに応じて、PRは並列性を完全に利用するかどうかを決定します。並列度を最大に増やすことができる場合があります。すべてのアプライヤは、トランザクションをデータベースに独立して実行します。並列度が高いほどパフォーマンスが向上しない場合もあります。また、分析を実行し、トランザクションの依存関係があるかどうかを確認するための手段(コマンド)も用意しています。