処理のための表の準備

この項では、処理のための表の準備方法について説明します。表の準備には次のタスクが必要です。

表における行の一意性の保証

Oracle GoldenGateでは、レプリケートされた更新および削除に対して正しいターゲット行を見つけるために、ソース表とターゲット表の形式の一意の行識別子が必要です。

KEYCOLS句がTABLE文またはMAP文内で使用されていない場合、Oracle GoldenGateは、使用する行識別子を次の優先順位で選択します。

  1. 主キー

  2. タイムスタンプまたはマテリアライズされていない計算結果列を含まない英数字順に最初の一意キー。

  3. 前述のキー・タイプのいずれも存在しない場合(表で別のタイプのキーが定義されていても)、Oracle GoldenGateでは、すべての列に対して疑似キーが作成されます。データベースでは、キー内でのOracle GoldenGateでサポートされていないもの、またはOracle GoldenGate構成から除外されているものを除き、一意のキーでの使用が許可されます。

ノート:表にその他の使用できないキーがある場合や、表にキーがまったくない場合、Oracle GoldenGateにより、該当するメッセージがレポート・ファイルに記録します。すべての列からキーを構築すると、ソース・システム上のOracle GoldenGateのパフォーマンスが妨げられます。ターゲットでは、このキーがReplicatであまり効率的でないより大きいWHERE句が使用される原因となります。

  1. 表に適切なキーがない場合、または既存のキーを使用しない場合は、表に一意の値が常に含まれる列があれば、代替キーを定義できます。ExtractのTABLEパラメータおよびReplicatのMAPパラメータ内にKEYCOLS句を含めることで、この代替キーを定義します。指定されたキーによって、Oracle GoldenGateで検出される既存の主キーまたは一意キーがオーバーライドされます。Oracle GoldenGateリファレンスのTABLE | MAPを参照してください。

一意索引から導出される主キーを持つ表

表に主キーがなく、索引付けされた列がNOT NULLである場合、MySQLでは一意索引が主キーにプロモートされます。これらのNOT NULL索引が複数ある場合、最初に作成された索引が主キーになります。Replicatでエラーが発生しないようにするには、ソース表とターゲット表でこれらの索引を同じ順序で作成します。

たとえば、ggvam.empという名前のソース表とターゲット表のそれぞれにfirst、middle、lastという列があり、それらすべてがNOT NULLとして定義されているとします。次の順序で一意索引を作成した場合、表定義が一致しないため、Oracle GoldenGateはターゲットで異常終了します。

ソース:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

ターゲット:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

この順序の結果、MySQLでは、ソースのfirst列の索引が主キーにプロモートされ、ターゲットのlast列の索引が主キーにプロモートされることになります。Oracle GoldenGateでは、メタデータ・レコードの作成時に主キーが識別子として選択されるため、メタデータが一致しなくなります。このエラーを回避するには、主キーにプロモートする列を決定し、ソースおよびターゲットでその索引を最初に作成します。

Oracle GoldenGateで使用する独自キーの指定

表に前述のタイプの行IDのいずれかがない場合や、それらの識別子を使用しないほうがよい場合、表に常に一意の値を含む列があるときは、代替キーを定義できます。ExtractのTABLEパラメータおよびReplicatのMAPパラメータ内にKEYCOLS句を含めることで、この代替キーを定義します。指定されたキーにより、Oracle GoldenGateで検出される既存の主キーまたは一意キーがオーバーライドされます。

キーのない表での行の変更の制限

ターゲット表に主キーまたは一意のキーがない場合、重複する行が存在する可能性があります。この場合、Oracle GoldenGateで更新または削除されるターゲット表の行数が多くなりすぎ、ソース・データとターゲット・データの同期がとれなくなる可能性があります。警告するエラー・メッセージは表示されません。更新される行数を制限するには、Replicatのパラメータ・ファイルで、DBOPTIONSパラメータをLIMITROWSオプションとともに使用します。LIMITROWSを使用すると、処理されるのは1行のみのため、ターゲット・システムでのOracle GoldenGateのパフォーマンスが向上することがあります。

トリガーおよびカスケード制約に関する考慮事項

トリガー

ターゲット表のトリガーを無効にするか、Oracle GoldenGateデータベース・ユーザーによる変更を無視するように変更します。Oracle GoldenGateでは、トリガーの結果として生成されるDMLがレプリケートされます。同じトリガーがターゲット表でアクティブになった場合、レプリケートされたバージョンのために重複となり、データベースでエラーが返されます。

カスケード制約に関する考慮事項

Oracle GoldenGateによって取得されるカスケード更新と削除はバイナリ・ログに記録されないため、取得されません。これは、MySQLとMariaDBの両方で有効です。たとえば、表間に親の子関係がある親表でdelete文を実行すると、子表に対してカスケード削除(存在する場合)が行われますが、バイナリ・ログでは記録されません。親表の削除または更新レコードのみがバイナリ・ログに記録され、Oracle GoldenGateによって取得される。

詳細は、https://mariadb.com/kb/en/replication-and-foreign-keys/およびhttps://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.htmlを参照してください。

カスケード操作を適切に処理するために、ソースでカスケード削除と更新を無効にし、親レコードを明示的に削除または更新するようにアプリケーションをコーディングしてから、親レコードを明示的に更新するようにアプリケーションをコーディングすることをお薦めします。または、ターゲット親表にソース親表と同じカスケード制約が構成されていることを確認する必要がありますが、これにより、特に双方向レプリケーションの場合にソースとターゲットの間で同期を取れていない状態が発生する可能性があります。