競合の管理

アクティブ/アクティブ構成では、統一された競合解決手順をすべてのシステムに用意しておく必要があります。競合は即座に識別され、可能なかぎり自動的に処理される必要がありますが、様々なビジネス・アプリケーションがこの処理に関する独自の要件セットを持っています。

Oracle GoldenGateは非同期ソリューションであるため、個別のシステム上にある同一のデータセットに対して(ほぼ)同時に変更が行われた場合、競合が発生する可能性があります。競合は、同時変更のタイミングが次の非同期状態のいずれかにつながる場合に発生します。

  • Replicatが、一意性整合性制約(PRIMARY KEY制約やUNIQUE制約など)に違反する挿入操作または更新操作を適用すると、一意性競合が発生します。この競合タイプの例としては、2つの異なるデータベースから2つのトランザクションが発生し、各トランザクションが同じ主キー値で表に行を挿入する場合があげられます。

  • Replicatが、同じ行への別の更新と競合する更新を適用すると、更新競合が発生します。更新競合が発生するのは、異なるデータベースから生じた2つのトランザクションがほぼ同時に同じ行を更新した場合です。証跡レコードに格納されている古い値(変更前の値)とターゲット・データベース内の同じ行の現行値との間に差異があると、Replicatは更新競合を検出します。

  • 2つのトランザクションが異なるデータベースから生じ、一方が行を削除するのと同時にもう一方が同じ行を更新または削除すると、削除競合が発生します。この場合、その行は存在せず、更新も削除もできません。主キーが存在しないため、Replicatは行を見つけられません。

たとえば、データベースAのユーザーAがある行を更新し、データベースBのユーザーBが同じ行を更新するとします。ユーザーAのトランザクションがデータベースBに同期されるより前にユーザーBのトランザクションが実行されると、レプリケートされたトランザクションで競合が発生します。

3つのデータベースが関与するさらに複雑な例を基に、順序にまつわるさらに複雑な競合について説明します。A、B、Cという3つのデータベースがあるとします。あるユーザーがデータベースAに行を挿入すると、その行はデータベースBにレプリケートされます。次に、別のユーザーがその行をデータベースBで変更すると、行の変更がデータベースCにレプリケートされます。Bからの行の変更が、データベースAからの行の挿入より前にデータベースCに到着した場合、Cは競合を検出します。

可能であれば、競合発生のすべての可能性を最小化または排除してください。そのいくつかの方法を次に示します。

  • 各データベースで変更できる列を制限するようにアプリケーションを構成します。たとえば、地理的地域に基づいてアクセスを制限できます(異なる販売地域でその独自の顧客レコードのみを変更できるようにするなど)。別の例として、あるデータベースの顧客サービス・アプリケーションには顧客表のNAME列とADDRESS列の変更のみを許可し、別のデータベースの財務アプリケーションにはBALANCE列の変更のみを許可することが可能です。どちらの例の場合でも、同じレコードの同時更新による競合は発生しません。

  • 同期のレイテンシを最小限に抑えます。データベースAのユーザーAとデータベースBのユーザーBがほぼ同時に同じ行を更新しても、ユーザーBのトランザクションが完了する前にユーザーAのトランザクションがターゲット行にレプリケートされていれば、競合は回避されます。Oracle GoldenGateプロセスのパフォーマンス向上のための推奨事項は、Oracle GoldenGateのパフォーマンスのチューニングを参照してください。

競合を回避するには、レプリケーション・レイテンシを最小限に抑える必要があります。競合が避けられない場合は、Oracle GoldenGateの競合検出および解決(CDR)機能または独自に開発した方法によって、競合をすみやかに特定し、可能なかぎり自動的に解決する必要があります。独自の方法は、SQLEXECとユーザー・イグジット機能を通じてOracle GoldenGate処理に統合できます。Oracle GoldenGateを使用した競合の処理の詳細は、「手動の競合検出および解決」を参照してください。

Oracleデータベースには、自動競合検出解決(CDR)機能があります。詳細は、「自動競合検出および解決」を参照してください。