1. Oracle GoldenGateの管理
  2. Oracle GoldenGate管理:共通のコンポーネントと操作
  3. アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7 アクティブ/アクティブ構成のためのOracle GoldenGateの構成

この章では、アクティブ/アクティブ構成用にOracle GoldenGateを構成する方法について説明します。

内容は次のとおりです。

親トピック: Oracle GoldenGate管理:共通のコンポーネントと操作

7.1 アクティブ/アクティブ構成の概要

Oracle GoldenGateでは、アクティブ/アクティブ型の双方向構成がサポートされます。この構成では、同一のデータセットが含まれる2つのシステムが存在し、アプリケーション・ユーザーはどちらのシステムでもそれらのデータを変更できます。Oracle GoldenGateは、両方のデータセットを最新状態に維持するため、トランザクション・データ変更を一方のデータベースから他方のデータベースにレプリケートします。

simple_config_bidirectional.jpgの説明が続きます
図simple_config_bidirectional.jpgの説明

双方向構成では、各システムにアクティブなOracle GoldenGateプロセスの完全なセットがあります。Extractプロセスによって一方のシステムで取得されたデータは、他方のシステムに伝播され、ローカルReplicatプロセスによって適用されます。

この構成では、負荷分散がサポートされます。この機能は、ビジネス・アプリケーションが任意の2つのピアで同一である場合に、障害耐久力を確保するために使用できます。

Oracle GoldenGateでは、次のデータベースでアクティブ/アクティブ構成がサポートされます。

  • DB2(z/OSおよびLUW上)およびIBM i

  • MySQL

  • Oracle

  • PostgreSQL

  • SQL Server

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.2 アクティブ/アクティブ構成の考慮事項

アクティブ/アクティブ構成では、次の点を考慮する必要があります。また、使用中のデータベース・タイプに対応するOracle GoldenGateのインストレーションおよび構成のドキュメントを参照し、双方向構成をサポートする上で他になんらかの制限や要件がないか確認してください。

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.2.1 アプリケーション設計

アクティブ/アクティブ型のレプリケーションを使用する場合は、タイムゾーンを両方のシステムで同じにする必要があるため、そのタイムスタンプベースの競合解決および検出を動作できます。

アクティブ/アクティブ型のレプリケーションは、市販のパッケージ・ビジネス・アプリケーションでサポートされていない場合、それらのアプリケーションで使用することは推奨されません。これらのアプリケーションで障害となるのは次の点です。

  • パッケージ・アプリケーションには、Oracle GoldenGateでサポートされないオブジェクトおよびデータ型が含まれる可能性があります。

  • パッケージ・アプリケーションでは、ユーザーが制御できない自動DML操作が実行される可能性がありますが、その操作がOracle GoldenGateによってレプリケートされると、Replicatによる適用時に競合が発生します。

  • 通常、ユーザーは、アクティブ/アクティブ型のレプリケーションに必要とされる変更を行うためのデータ構造を制御できません。

親トピック: アクティブ/アクティブ構成の考慮事項

7.2.2 キー

競合を正確に検出するためには、すべてのレコードは一意の非NULL識別子である必要があります。可能であれば、主キーを作成してください。不可能な場合は、一意キーを使用するか、MAPパラメータおよびTABLEパラメータのKEYCOLSオプションを使用して代替キーを作成します。一意の識別子がないと、Oracle GoldenGateでは、WHERE句で有効なすべての列が使用されますが、表に大量の列が含まれる場合、これによってパフォーマンスが低下します。

データ整合性を保持してエラーを防止するため、特定の表で使用するキーには次のことが求められます。

  • その特定の表が存在するすべてのデータベースで同じ列が含まれる必要があります。

  • データベース間の対応する行の各セットで同じ値が含まれる必要があります。

親トピック: アクティブ/アクティブ構成の考慮事項

7.2.3 データベース生成による値

双方向構成では、データベース生成による順序値(Oracle順序など)をレプリケートしないでください。値の範囲は、重複しないように各システムで異なっている必要があります。たとえば、2つのデータベースが存在する環境では、一方のサーバーで偶数値を生成し、他方で奇数値を生成します。n個のサーバーが存在する環境では、各キーを異なる値で開始し、環境内のサーバーの数を単位として値を増分します。この方法は、すべてのタイプのアプリケーションまたはデータベースに使用できるわけではありません。アプリケーションが対応している場合、値に位置識別子を追加して強制的に一意性を確保できます。

親トピック: アクティブ/アクティブ構成の考慮事項

7.2.4 データベース構成

データベースの1つを、信頼できるソースとして指定する必要があります。これは、初期同期フェーズや必要な後続のすべての再同期時に他のデータベースの導出元になるプライマリ・データベースおよびそのホスト・システムです。信頼できるソースのデータは定期的にバックアップしてください。

親トピック: アクティブ/アクティブ構成の考慮事項

7.3 データ・ループの防止

双方向構成では、あるシステムから別のシステムにレプリケートされたSQL変更は、最初のシステムに再度レプリケートされないようにする必要があります。そうしないと、システム間でデータの移動が繰り返され、次の例のように無限ループに陥ります。

  1. ユーザー・アプリケーションがシステムAのある行を更新します。

  2. Extractは、システムAでその行を抽出してシステムBに送信します。

  3. Replicatは、システムBでその行を更新します。

  4. Extractは、システムBでその行を抽出してシステムAに戻します。

  5. その行がシステムAに適用されます(2回目)。

  6. このループが無限に継続します。

データのループバックを防止するには、状況に応じて次の処理を行う必要があります。

  • Replicatによって生成されるSQL操作を取得しないようにします。ただし、Extractのパラメータ・ファイルに指定されているオブジェクトがビジネス・アプリケーションに含まれる場合は、それらのビジネス・アプリケーションによって生成されるSQL操作の取得を有効化します。

  • ローカルReplicatトランザクションを識別します(Extractプロセスでそれらのトランザクションを無視するため)。

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.3.1 Replicatトランザクションの識別

Replicatトランザクションを識別するようにExtractを構成するには、Extractがデータを取得するデータベースについて、次の手順に従います。

内容は次のとおりです。

親トピック: データ・ループの防止

7.3.1.1 DB2 z/OS、DB2 LUWおよびDB2 for i

Extractのパラメータ・ファイルで次のパラメータ文を使用して、Replicatユーザー名を識別します。

TRANLOGOPTIONS EXCLUDEUSER user

このパラメータ文によって、このユーザーにより生成されるすべてのDDLおよびDMLトランザクションがReplicatトランザクションとしてマークされます。ユーザー名は、Extractによって読み取られるトランザクション・レコードに含まれます。

7.3.1.2 MySQL

Extractのパラメータ・ファイルで次のパラメータ文を使用して、Replicatのチェックポイント表の名前を識別します。

TRANLOGOPTIONS FILTERTABLE table_name

Replicatは、その各トランザクションの終了時に、チェックポイント手順の一環としてチェックポイント表にチェックポイントを書き込みます。(これは、ADD CHECKPOINTTABLEコマンドを使用して作成される表です。)各Replicatトランザクションにこの表への書込みが含まれるため、この表を使用して双方向構成のReplicatトランザクションを識別できます。FILTERTABLEによってチェックポイント表の名前を識別し、その表に対する操作が含まれるトランザクションをExtractで無視するようにします。

7.3.1.3 PostgreSQLおよびSQL Server

Extractのパラメータ・ファイルで次のパラメータ文を使用して、Replicatのチェックポイント表の名前を識別し、ADD TRANDATAコマンドによるサプリメンタル・ロギングに対してReplicatのチェックポイント表が有効になっていることを確認します。 

TRANLOGOPTIONS FILTERTABLE table_name

Replicatは、その各トランザクションの終了時に、チェックポイント手順の一環としてチェックポイント表にチェックポイントを書き込みます。(これは、ADD CHECKPOINTTABLEコマンドを使用して作成される表です。)各Replicatトランザクションにこの表への書込みが含まれるため、この表を使用して双方向構成のReplicatトランザクションを識別できます。FILTERTABLEによってチェックポイント表の名前を識別し、その表に対する操作が含まれるトランザクションをExtractで無視するようにします。

7.3.1.4 Oracle

Oracle環境でReplicatトランザクションを識別する方法は複数あります。Replicatがクラシックまたは統合モードである場合は、次のパラメータを使用します。

  • Replicatはデフォルトで00のタグを設定します。Replicatのパラメータ・ファイルでSETTAGオプションを指定してDBOPTIONSを使用し、Replicatで設定されるタグを変更します。Replicatは、指定した値(これらのトランザクションをREDOストリーム内で識別)で適用されるトランザクションにタグ付けします。有効値は、16進数で構成される単一のTAG値です。

  • Extractパラメータ・ファイルでTRANLOGOPTIONSパラメータをEXCLUDETAGオプションとともに使用します。Extractに関連付けられたログマイニング・サーバーは、SETTAG値のタグが付いたREDOを除外します。

    Replicatのパラメータ・ファイルでSETTAGを設定する方法は次のとおりです。 

    DBOPTIONS SETTAG 0935

    Extractのパラメータ・ファイルでEXCLUDETAGを設定する方法は次のとおりです。 

    TRANLOGOPTIONS EXCLUDETAG 0935

    複数のタグを除外する場合は、個別のTRANLOGOPTIONS EXCLUDETAG文をそれぞれ指定する必要があります。

トランザクション名またはReplicatユーザーのユーザーIDを使用して、Replicatトランザクションを識別することもできます。Extractの構成時に、どちらを無視するか選択できます。「Replicatトランザクションの取得の防止(Oracle)」を参照してください。

詳細は、『Oracle GoldenGateリファレンス』を参照してください。

7.3.2 Replicat操作の取得の防止

使用中のデータベースに応じて、Replicat操作を取得しないように明示的に指示する必要がある場合とない場合があります。

親トピック: データ・ループの防止

7.3.2.1 Replicatトランザクションの取得の防止(Oracle)

ReplicatによってOracleデータベースに適用されるSQLの取得を防止するために、Extractのキャプチャ・モードに応じて異なるオプションが用意されています。

  • Extractがクラシックまたは統合キャプチャ・モードである場合は、TRANLOGOPTIONSパラメータをEXCLUDETAG tagオプションとともに使用します。このパラメータを使用すると、Extractプロセスは、指定されたREDOタグの付いたトランザクションを無視します。タグ値の設定は、「Replicatトランザクションの識別」を参照してください。これはOracleの場合に推奨されるアプローチです。

  • Extractがクラシック・キャプチャ・モードである場合は、ExtractのTRANLOGOPTIONSパラメータをEXCLUDEUSERまたはEXCLUDEUSERIDオプションとともに使用して、ReplicatがDDLおよびDMLトランザクションの適用に使用しているユーザー名またはユーザーIDを除外します。複数のEXCLUDEUSER文を使用できます。指定されたユーザーは、GETREPLICATESまたはIGNOREREPLICATESパラメータのルールの対象になります。詳細は、「Replicatトランザクションの取得の防止(他のデータベース)」を参照してください。

7.3.2.2 Replicatトランザクションの取得の防止(他のデータベース)

Replicatによって他のデータベース・タイプ(Extractがクラシック・キャプチャ・モードで動作する場合はOracleを含む)に適用されるSQLの取得を防止するには、次のパラメータを使用します。

  • GETAPPLOPS | IGNOREAPPLOPS: Replicat以外のビジネス・アプリケーションによって生成されたデータ操作(DML)を、Extractが特定の証跡またはファイルに書き込む内容に含めるかどうかを制御します。

  • GETREPLICATES | IGNOREREPLICATES: Replicatによって生成されたDML操作を、Extractが特定の証跡またはファイルに書き込む内容に含めるかどうかを制御します。

7.3.3 双方向構成でのDDLレプリケーション

Oracleデータベースでのみ現在サポートされているDDLの双方向レプリケートでは、他にも考慮すべき事項があります。詳細は、Oracle DatabaseのためのOracle GoldenGateの使用のDDLレプリケーション環境の管理 を参照してください。

親トピック: データ・ループの防止

7.4 競合の管理

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

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)機能があります。詳細は、『Oracle Database XStreamガイド』のOracle GoldenGate自動競合検出および解決に関する項を参照してください。

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.5 追加情報

次のドキュメントには、Oracle GoldenGateの構成に関連する追加情報が記載されています。

  • その他のシステム要件、プロセス構成およびデータベースの設定要件については、使用中のデータベース・タイプに対応するOracle GoldenGateのインストレーションおよび構成のドキュメントを参照してください。

  • Oracle GoldenGateの変更取得および配信グループの構成方法の詳細は、オンライン変更同期の構成を参照してください。

  • Oracle GoldenGateのその他のチューニング・オプションは、Oracle GoldenGateのパフォーマンスのチューニングを参照してください。

  • Oracle GoldenGateのコマンドとパラメータの構文の詳細および説明は、『Oracle GoldenGateリファレンス』を参照してください。

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.6 アクティブ/アクティブ構成の作成

作成するオブジェクトのビジュアル表現は、図7-*を参照してください。

bidirectional_config.jpgの説明が続きます
図bidirectional_config.jpgの説明

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.6.1 両システムの前提条件

両方のシステムで次の前提条件を実行します。

  1. Replicatのチェックポイント表を作成します(Oracle統合Replicatを使用していない場合)。手順については、「チェックポイント表の作成」を参照してください。

  2. Managerプロセスの構成手順については、Managerおよびネットワーク通信の構成を参照してください。

親トピック: アクティブ/アクティブ構成の作成

7.6.2 プライマリ・システムからセカンダリ・システムに対する構成

次のステップでは、プライマリ・システムからセカンダリ・データベースへのデータ送信に必要なプロセスを追加します。

プライマリExtractグループを構成する手順

プライマリ・システムで次のステップを実行します。

  1. ADD EXTRACTコマンドを使用してプライマリExtractグループを作成します。説明上、このグループをext_1と呼びます。 

    ADD EXTRACT exte, {TRANLOG | INTEGRATED TRANLOG}, BEGIN time

  2. ADD EXTTRAILコマンドを使用してローカル証跡を追加します。説明上、この証跡をtrail_eastと呼びます。 

    ADD EXTTRAIL trail_east, EXTRACT exte

    EXTRACTでは、この証跡に書込みを行うext_1グループを指定します

  3. EDIT PARAMSコマンドを使用してext_1グループのパラメータ・ファイルを作成します。次のパラメータと、データベース環境に適用する他のパラメータを含めます。考えられるその他の必須パラメータの詳細は、使用中のデータベースに対応するOracle GoldenGateインストレーションおよびセットアップ・ガイドを参照してください。 

    -- Identify the Extract group:
EXTRACT exte
-- Specify database login information as needed for the database:
[SOURCEDB dsne][, USERIDALIAS alias]
-- Specify the local trail that this Extract writes to
-- and the encryption algorithm:
ENCRYPTTRAIL algorithm
EXTTRAIL trail_east
-- Exclude Replicat transactions. Uncomment ONE of the following:
-- DB2 z/OS, DB2 LUW, DB2 IBM i, and Oracle:
-- TRANLOGOPTIONS EXCLUDEUSER Replicat_user
-- Oracle integrated capture:
-- EXCLUDETAG tag
-- SQL Server:
-- TRANLOGOPTIONS FILTERTABLE schema.checkpointtable"
-- -- Teradata:
-- SQLEXEC 'SET SESSION OVERRIDE REPLICATION ON;'
-- SQLEXEC 'COMMIT;'
-- Log all scheduling columns for CDR and if using integrated Replicat
LOGALLSUPCOLS
-- Specify tables to be captured and (optional) columns to fetch:
TABLE [container.|catalog.]owner.* [, FETCHCOLS cols | FETCHCOLSEXCEPT cols];

データ・ポンプを構成する手順

プライマリ・システムで次のステップを実行します。

  1. ADD EXTRACTコマンドを使用してデータ・ポンプ・グループを作成します。説明上、このグループをpumpeと呼びます。 

    ADD EXTRACT pumpe, EXTTRAILSOURCE ea, BEGIN time

    EXTTRAILSOURCEでは、データソースとしてeaを指定します。

  2. ADD RMTTRAILコマンドを使用して、セカンダリ・システムに作成するリモート証跡を追加します。説明上、この証跡をerと呼びます。 

    ADD RMTTRAIL er, EXTRACT pumpr

    EXTRACTでは、この証跡に書込みを行うpump_1データ・ポンプを指定します。

    その他のADD RMTTRAILオプションは、『Oracle GoldenGateリファレンス』を参照してください。

    EDIT PARAMSコマンドを使用してpumprグループのパラメータ・ファイルを作成します。次のパラメータと、データベース環境に適用する他のパラメータを含めます。 

    -- Identify the data pump group:
EXTRACT pumpe
-- Specify database login information as needed for the database:
[SOURCEDB dsne][, USERIDALIAS alias]
-- Decrypt the data only if the data pump must process it.
-- DECRYPTTRAIL
-- Specify the name or IP address of the secondary system
-- and optional encryption of data over TCP/IP:
RMTHOSTOPTIONS system_2, MGRPORT port_number, ENCRYPT encryption_options
-- Specify remote trail and encryption algorithm on secondary system:
ENCRYPTTRAIL algorithm
RMTTRAIL remote_trail_1
-- Specify tables to be captured:
TABLE [container.|catalog.]owner.*;

Replicatグループを構成する手順

セカンダリ・システムで次のステップを実行します。

  1. DBLOGINコマンドを使用してデータベースに接続した後、Replicatチェックポイント表を作成します。『Oracle GoldenGateコマンド・ライン・インタフェース・リファレンス』のADD CHECKPOINTTABLEを参照してください。

  2. 次のコマンドを実行します。

    ADD CHECKPOINTTABLE schema.checkpointtable

  3. ADD REPLICATコマンドを使用してReplicatグループを作成します。説明上、このグループをrepeと呼びます。 

    ADD REPLICAT repe
[, PARALLEL | INTEGRATED | COORDINATED [MAXTHREADS number]]
, EXTTRAIL er, CHECKPOINTTABLE schema.checkpointtable

    EXTTRAILでは、このReplicatが読み取る証跡としてremote_trail_1を指定します。

  4. EDIT PARAMSコマンドを使用してrep_1グループのパラメータ・ファイルを作成します。次のパラメータと、データベース環境に適用する他のパラメータを含めます。考えられるその他の必須パラメータの詳細は、使用中のデータベースに対応するOracle GoldenGateインストレーションおよびセットアップ・ガイドを参照してください。 

    -- Identify the Replicat group:
REPLICAT repe
-- Specify database login information as needed for the database:
[TARGETDB dsnw][, USERIDALIAS alias]
-- Specify error handling rules:
REPERROR (error, response)
-- Set redo tag for Oracle only replicat via settag
-- Default is 00.
SETTAG tag_value
-- Valid for Oracle only. Specify tables for delivery, threads if coordinated Replicat 
-- and conflict-resolution:
MAP [container.|catalog.]owner.*, TARGET owner.*, COMPARECOLS (ON operation {ALL | KEY | KEYINCLUDING (col_list) | ALLEXCLUDING (col_list)}), RESOLVECONFLICT (conflict type (resolution_name, resolution_type COLS (col[,...]))
[, THREAD (thread_ID)]
[, THREADRANGE (thread_range[, column_list])]
;
-- Specify mapping of exceptions to exceptions table:
MAP [container.|catalog.]owner.*, TARGET owner.exceptions, EXCEPTIONSONLY;

親トピック: アクティブ/アクティブ構成の作成

7.6.3 セカンダリ・システムからプライマリ・システムに対する構成

次のステップでは、セカンダリ・システムからプライマリ・データベースへのデータ送信に必要なプロセスを追加します。

プライマリExtractグループを構成する手順

セカンダリ・システムで次のステップを実行します。

ノート:

この手順は、これまでに作成した構成を逆にするイメージです。

  1. ADD EXTRACTコマンドを使用してプライマリExtractグループを作成します。説明上、このグループをextnと呼びます。 

    ADD EXTRACT extn, {TRANLOG | INTEGRATED TRANLOG}, BEGIN time

  2. ADD EXTTRAILコマンドを使用してローカル証跡を追加します。説明上、この証跡をenと呼びます。 

    ADD EXTTRAIL en, EXTRACT extn

    Extractでは、この証跡に書込みを行うextnグループを指定します。

  3. EDIT PARAMSコマンドを使用してextnグループのパラメータ・ファイルを作成します。次のパラメータと、データベース環境に適用する他のパラメータを含めます。考えられるその他の必須パラメータの詳細は、使用中のデータベースに対応するOracle GoldenGateインストレーションおよびセットアップ・ガイドを参照してください。 

    -- Identify the Extract group:
EXTRACT extn
-- Specify database login information as needed for the database:
[SOURCEDB dsnn][, USERIDALIAS alias]
-- Specify the local trail that this Extract writes to
-- and the encryption algorithm:
ENCRYPTTRAIL algorithm
EXTTRAIL en 
-- Exclude Replicat transactions. Uncomment ONE of the following:
-- Db2 z/OS, Db2 LUW, Db2 IBM i, and Oracle:
-- TRANLOGOPTIONS EXCLUDEUSER Replicat_user
-- Oracle integrated capture:
-- EXCLUDETAG tag
-- SQL Server:
-- TRANLOGOPTIONS EXCLUDETRANS FILTERTABLE schema.checkpointtable
-- Oracle:
-- TRACETABLE trace_table_name
-- Log all scheduling columns for CDR and if using integrated Replicat
LOGALLSUPCOLS
-- Specify tables to be captured and (optional) columns to fetch:
TABLE [container.|catalog.]owner.* [, FETCHCOLS cols | FETCHCOLSEXCEPT cols];

    ノート:

    Oracle DBFSデータをレプリケートするには、各ノードのTABLE文で、内部的に生成されたローカルの読取り/書込みDBFS表を指定します。これらの表を識別し、Oracle GoldenGateによる伝播が行われるようにDBFSを構成する方法の詳細は、『Oracle DatabaseのためのOracle GoldenGateの使用』の必要なパッチの適用に関する項を参照してください。

データ・ポンプを構成する手順

セカンダリ・システムで次のステップを実行します。

  1. ADD EXTRACTコマンドを使用してデータ・ポンプ・グループを作成します。説明上、このグループをpumpnと呼びます。 

    ADD EXTRACT pumpn, EXTTRAILSOURCE en, BEGIN time

    EXTTRAILSOURCEでは、データソースとしてenを指定します。

  2. ADD RMTTRAILコマンドを使用して、プライマリ・システムに作成するリモート証跡を追加します。説明上、この証跡をrtと呼びます。 

    ADD RMTTRAIL rt, EXTRACT pumpn

    EXTRACTでは、この証跡に書込みを行うpumpnデータ・ポンプを指定します。

  3. EDIT PARAMSコマンドを使用してpump_2グループのパラメータ・ファイルを作成します。次のパラメータと、データベース環境に適用する他のパラメータを含めます。 

    -- Identify the data pump group:
EXTRACT pumpn
-- Specify database login information as needed for the database:
[SOURCEDB dsnn][, USERIDALIAS alias]
-- Decrypt the data only if the data pump must process it.
-- DECRYPTTRAIL
-- Specify the name or IP address of the primary system
-- and optional encryption of data over TCP/IP:
RMTHOSTOPTIONS system_1, MGRPORT port_number, ENCRYPT encryption_options
-- Specify the remote trail and encryption algorithm on the primary system:
ENCRYPTTRAIL algorithm
RMTTRAIL rt 
-- Specify tables to be captured:
TABLE [container.|catalog.]owner.*;

    ノート:

    Oracle DBFSデータをレプリケートするには、各ノードのTABLE文で、内部的に生成されたローカルの読取り/書込みDBFS表を指定します。これらの表を識別して、Oracle GoldenGateによる伝播が行われるようにDBFSを構成する方法の詳細は、『Oracle DatabaseのためのOracle GoldenGateの使用』のDBFSファイル・システムの構成に関する項を参照してください。

Replicatグループを構成する手順

プライマリ・システムで次のステップを実行します。

  1. DBLOGINコマンドを使用してデータベースに接続した後、Replicatチェックポイント表を作成します。『Oracle GoldenGateコマンド・ライン・インタフェース・リファレンス』のADD CHECKPOINTTABLEを参照してください。

  2. 次のコマンドを実行します。

    ADD CHECKPOINTTABLE schema.checkpointtable

  3. ADD REPLICATコマンドを使用してReplicatグループを作成します。説明上、このグループをrepsと呼びます。 

    ADD REPLICAT reps
[, PARALLEL | INTEGRATED | COORDINATED [MAXTHREADS number]]
, EXTTRAIL rt, CHECKPOINTTABLE schema.checkpointtable

    EXTTRAILでは、このReplicatが読み取る証跡としてremote_trail_1を指定します。

  4. EDIT PARAMSコマンドを使用してrep_2グループのパラメータ・ファイルを作成します。次のパラメータと、データベース環境に適用する他のパラメータを含めます。 

    -- Identify the Replicat group:
REPLICAT reps
-- Specify database login information as needed for the database:
[TARGETDB dsns][, USERIDALIAS alias]
-- Specify error handling rules:
REPERROR (error, response)
-- Specify tables for delivery, threads if coordinated Replicat 
-- and conflict-resolution:
MAP [container.|catalog.]owner.*, TARGET owner.*, COMPARECOLS (ON operation {ALL | KEY | KEYINCLUDING (col_list) | ALLEXCLUDING (col_list)}), RESOLVECONFLICT (conflict type (resolution_name, resolution_type COLS (col[,...]))
[, THREAD (thread_ID)]
[, THREADRANGE (thread_range[, column_list])]
;
-- Specify mapping of exceptions to exceptions table:
MAP [container.|catalog.]owner.*, TARGET owner.exceptions, EXCEPTIONSONLY;

    ノート:

    Oracle DBFSデータをレプリケートするには、各ノードのTABLE文で、内部的に生成されたローカルの読取り/書込みDBFS表を指定します。

親トピック: アクティブ/アクティブ構成の作成

7.7 競合の検出および解決の構成

この章では、Oracle GoldenGateの競合検出および解決(CDR)機能を使用する方法について説明します。アクティブ/アクティブ構成のOracle GoldenGateでは、同じデータセットを持つ複数のデータベース間でデータの同期性を維持する必要があるため、競合検出および解決が必要です。

内容は次のとおりです。

親トピック: アクティブ/アクティブ構成のためのOracle GoldenGateの構成

7.7.1 Oracle GoldenGate CDR機能の概要

Oracle GoldenGateの競合検出および解決(CDR)は、次の処理を行う基本的な競合解決ルーチンを備えています。

  • INSERTの一意性競合を解決します。

  • 行は存在するが、1つ以上の列の変更前イメージがデータベースの現行値と異なる場合に発生する、UPDATEの「データが見つからない」競合を解決します。

  • 行が存在しない場合に発生する、UPDATEの「データが見つからない」競合を解決します。

  • 行は存在するが、1つ以上の列の変更前イメージがデータベースの現行値と異なる場合に発生する、DELETEの「データが見つからない」競合を解決します。

  • 行が存在しない場合に発生する、DELETEの「データが見つからない」競合を解決します。

競合検出および解決(CDR)を使用するには、ターゲット・データベースがWindows、Linux、UNIXのいずれかのシステムに配置されている必要があります。これは、NonStopプラットフォーム上のデータベースに対してはサポートされません。

 CDRは、次のようなスカラー・データ型をサポートしています。

  • NUMERIC

  • DATE

  • TIMESTAMP

  • CHAR/NCHAR

  • VARCHAR/ NVARCHAR

つまり、これらの列タイプは、COMPARECOLSパラメータで使用でき、また、RESOLVECONFLICTパラメータのUSEMINおよびUSEMAXオプションの解決列として使用できます。RESOLVECONFLICTのUSEDELTAオプションに使用できるのは、NUMERIC列のみです。CDRは、LOB、抽象データ型(ADT)またはユーザー定義型(UDT)を含む列に使用しないでください。

ReplicatがBATCHSQLモードで動作する場合、競合解決は実行されません。BATCHSQLモードで競合が発生すると、ReplicatはGROUPTRANSOPSモードに戻り、さらに単一トランザクション・モードに戻ります。競合検出は3つのモードすべてで行われます。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

親トピック: 競合の検出および解決の構成

7.7.2 エラー処理のためのOracle GoldenGateパラメータ・ファイルの構成

CDRをエラー処理と併用して、解決済のエラーとCDRで解決できなかったエラーを取得する必要があります。

  1. 競合解決は、他のエラー処理パラメータ(HANDLECOLLSIONS、INSERTMISSINGUPDATESおよびREPERROR)の前に実行されます。REPERRORパラメータを使用して、CDRで解決できないエラーを処理するためのルール、またはCDRで処理しないエラーに関するルールを割り当てます。一部のエラーをREPERRORで処理し、残りをCDRで処理するのが適当なこともありますが、同じ競合を処理するようにREPERRORとCDRを構成した場合は、CDRが優先されます。INSERTMISSINGUPDATESパラメータとHANDLECOLLISIONSパラメータも、CDRで処理されない一部のエラーを処理するために使用できます。これらのパラメータの詳細は、『Oracle GoldenGateリファレンス』を参照してください。
  2. (オプション)例外表を作成します。例外MAP文とともに例外表を使用する場合(「エラー処理のためのOracle GoldenGateパラメータ・ファイルの構成」を参照)、Replicatは競合が発生しているすべての操作を(競合が解決したかどうかにかかわらず)、例外表にマップされる例外MAP文に送信します。UPDATEとDELETEの競合をReplicatで処理する場合は、この表の主キーを省略してください。そうしないと、整合性制約エラーが発生する可能性があります。

    少なくとも、例外表にターゲット表と同じ列を含める必要があります。これらの行には、Replicatがターゲットに適用した(または適用しようとした)各行イメージが格納されます。

    さらに、追加の列を定義してその他の情報を取得し、データをトランザクションの文脈で扱うのに役立てることができます。Oracle GoldenGateには、例外MAP文を通じてこの情報を取得するためのツールが用意されています(「エラー処理のためのOracle GoldenGateパラメータ・ファイルの構成」を参照)。そのような列には次のものがあります(これだけに限りません)。

    • 証跡レコードの変更前イメージ。これは、col1_beforeやcol2_beforeなどの名前を持つ、ターゲット列の複製です。

    • ターゲット列の現行値。これは、col1_currentやcol2_currentなどの名前を持つ、ターゲット列の複製です。

    • ターゲット表の名前

    • 競合のタイムスタンプ

    • 操作タイプ

    • データベースのエラー番号

    • (オプション)データベースのエラー・メッセージ

    • 競合が解決されたかどうか

  3. 例外MAP文を作成して、例外データを例外表にマップします。例外MAP文には次の要素が含まれます。

    • (必須)INSERTALLRECORDSオプション。このパラメータを指定すると、すべての列値が例外表にマップされるように、すべてのマップ済操作がINSERTに変換されます。

    • (必須)EXCEPTIONSONLYオプション。このパラメータを指定すると、エラーを生成する操作がマップされます(成功した操作はマップされません)。

    • (オプション)COLMAP句。例外表の列の名前および定義がソース表のものと同一であり、例外表にその列のみが含まれている場合、COLMAPは不要です。ただし、名前または定義が異なる場合、あるいは例外表に追加の列があり、それらの列に追加データを移入する場合は、COLMAP句を使用してすべての列をマップします。

親トピック: 競合の検出および解決の構成

7.7.2.1 追加データを例外表にマップするためのツール

次に示すのは、追加列に値を移入するためにCOLMAP句で使用できるツールです。

  • ソース列の名前および定義が例外表のターゲット列のものと同一である場合、明示的にマッピングを行う名前のかわりにUSEDEFAULTSキーワードを使用できます。それ以外の場合は、それらの列をCOLMAP句でマッピングする必要があります。たとえば: 

    COLMAP (exceptions_col1 = col1, [...])

  • ソース行の変更前イメージを例外表の列にマップするには、証跡レコードから列の変更前イメージを取得する@BEFORE変換関数を使用します。次の例は、@BEFOREの使用方法を示しています。 

    COLMAP (USEDEFAULTS, exceptions_col1 = @BEFORE (source_col1), &
exceptions_col2 = @BEFORE (source_col2), [...])

  • ターゲット行の現行イメージを例外表の列にマップするには、SQLEXEC問合せを使用してイメージを取得し、COLMAP句でqueryID.column構文を使用して問合せの結果を例外表の列にマップします。 

    COLMAP (USEDEFAULTS, name_current = queryID.name, phone_current = queryID.phone, [...])

  • タイムスタンプ、データベース・エラー、その他の環境情報をマップするには、該当するOracle GoldenGate列変換関数を使用します。たとえば、次の例では実行時の現行タイムスタンプをマップしています。

    res_date = @DATENOW ()

例外MAP文のCOLMAP句でこれらの機能を組み合せて詳細な例外表にデータを移入する方法は、例外表の追加の列を含むサンプル例外マッピングを参照してください。

これらの例で示したパラメータおよび列変換関数の使用方法と構文については、Oracle GoldenGateリファレンスfor Windows and UNIX を参照してください。

7.7.2.2 ソース列とターゲット列のみを含むサンプル例外マッピング

次のサンプル・パラメータ・ファイルは、以降のCDRの例で使用されるソース表およびターゲット表のエラー処理と単純な例外マッピングを示しています。この例でマップするのはソース列とターゲット列であり、追加の列はマップしません。次の理由から、この例の例外MAP文にはCOLMAP句は不要です。

  • ソースとターゲットの例外列は、名前と定義がそれぞれ同一です。

  • 例外表に他の列がありません。

    ノート:

    この例では、Replicatパラメータ・ファイルに必要なその他のパラメータ(プロセス名やログイン資格証明、特定のデータベース・タイプに必要なオプションのパラメータなど)を意図的に省略してあります。改行を使用してパラメータ文を複数の行に分割するときは、各行の末尾でアンパサンド(&)を使用します。

        -- REPERROR error handling: DEFAULT represents all error types. DISCARD
    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)
    -- Specifies a discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE
    -- The regular MAP statement with the CDR parameters
MAP fin.src, TARGET fin.tgt, &
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL), &
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)), &
);
    -- Starts the exceptions MAP statement by mapping the source table to the
    -- exceptions table.
MAP fin.src, TARGET fin.exception, &
    -- directs Replicat only to map operations that caused the error specified
    -- in REPERROR.
EXCEPTIONSONLY, &
    -- directs Replicat to convert all the exceptions to inserts into the
    -- exceptions table. This is why there cannot be a primary key constraint
    -- on the exceptions table.
INSERTALLRECORDS 
;
7.7.2.3 例外表の追加の列を含むサンプル例外マッピング

次のサンプル・パラメータ・ファイルは、以降のCDRの例で使用されるソース表およびターゲット表のエラー処理と複雑な例外マッピングを示しています。この例では、例外表にソース表と同じ行があり、コンテキスト・データを取得するための追加の列もあります。

ノート:

この例では、Replicatパラメータ・ファイルに必要なその他のパラメータ(プロセス名やログイン資格証明、特定のデータベース・タイプに必要なオプションのパラメータなど)を意図的に省略してあります。改行を使用してパラメータ文を複数の行に分割するときは、各行の末尾でアンパサンド(&)を使用します。

    -- REPERROR error handling: DEFAULT represents all error types. DISCARD
    -- writes operations that could not be processed to a discard file.
REPERROR (DEFAULT, DISCARD)
    -- Specifies the discard file.
DISCARDFILE /users/ogg/discards/discards.dsc, PURGE
    -- The regular MAP statement with the CDR parameters
MAP fin.src, TARGET fin.tgt, &
COMPARECOLS (ON UPDATE ALL, ON DELETE ALL), &
RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)), &
RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)), &
RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)) 
);
    -- Starts the exceptions MAP statement by mapping the source table to the -- exceptions table.
MAP fin.src, TARGET fin.exception, &
    -- directs Replicat only to map operations that caused the error specified
    -- in REPERROR.
EXCEPTIONSONLY, &
    -- directs Replicat to convert all the exceptions to inserts into the
    -- exceptions table. This is why there cannot be a primary key constraint
    -- on the exceptions table.
INSERTALLRECORDS &
    -- SQLEXEC query to select the values from the target record before the
    -- Replicat statement is applied. These are mapped to the *_target
    -- columns later.
SQLEXEC (id qry, query 'select name, phone, address, salary, balance, & comment, last_mod_time from fin.tgt where name = :p1', PARAMS(p1 = name )), &
    -- Start of the column mapping, specifies use default column definitions.
COLMAP ( &
    -- USEDEFAULTS maps the source columns to the target exceptions columns
    -- that receive the after image that Replicat applied or tried to apply.
    -- In this case, USEDEFAULTS can be used because the names and definitions 
    -- of the source and target exceptions columns are identical; otherwise
    -- the columns must be mapped explicitly in the COLMAP clause.
USEDEFAULTS, &
    -- captures the timestamp when the resolution was performed.
res_date = @DATENOW (), &
    -- captures and maps the DML operation type.
optype = @GETENV ('LASTERR', 'OPTYPE'), &
    -- captures and maps the database error number that was returned.
dberrnum = @GETENV ('LASTERR', 'DBERRNUM'), &
    -- captures and maps the database error that was returned.
dberrmsge = @GETENV ('LASTERR', 'DBERRMSG'), &
    -- captures and maps the name of the target table
tabname = @GETENV ('GGHEADER', 'TABLENAME'), &
    -- If the names and definitions of the source columns and the target
    -- exceptions columns were not identical, the columns would need to
    -- be mapped in the COLMAP clause instead of using USEDEFAULTS, as 
    -- follows:
       -- name_after = name, &
       -- phone_after = phone, &
       -- address_after = address, &
       -- salary_after = salary, &
       -- balance_after = balance, &
       -- comment_after = comment, &
       -- last_mod_time_after = last_mod_time &
    -- maps the before image of each column from the trail to a column in the
    -- exceptions table.
name_before = @BEFORE (name), &
phone_before = @BEFORE (phone), &
address_before = @BEFORE (address), &
salary_before = @BEFORE (salary), &
balance_before = @BEFORE (balance), &
comment_before = @BEFORE (comment), &
last_mod_time_before = @BEFORE (last_mod_time), &
    -- maps the results of the SQLEXEC query to rows in the exceptions table
    -- to show the current image of the row in the target.
name_current = qry.name, &
phone_current = qry.phone, &
address_current = qry.address, &
salary_current = qry.salary, &
balance_current = qry.balance, &
comment_current = qry.comment, &
last_mod_time_current = qry.last_mod_time)
;

例外表の作成と例外マッピングの使用の詳細は、「DML操作中のReplicatエラーの処理」を参照してください。

現在のルーチンがすべての状況で予定どおり動作することを確認したら、解決ルーチンのオーバーヘッドを削減するために、例外表に記録されるデータの量を減らすことができます。

7.7.3 競合解決のためのOracle GoldenGateパラメータ・ファイルの構成

競合検出および解決をサポートするには、次のパラメータが必要です。

  1. Replicatパラメータ・ファイル内のMAPパラメータのCOMPARECOLSオプションを使用して、ReplicatのWHERE句で変更前の値とともに使用する列を指定します。変更前の値は、更新および削除の競合を検出するために、ターゲット・データベースの現行値と比較されます。(デフォルトでは、ReplicatはWHERE句で主キーのみを使用しますが、これでは競合検出には不十分な場合があります)。
  2. MAPパラメータのRESOLVECONFLICTオプションを使用して、様々な操作や競合タイプに対する競合解決ルーチンを指定します。RESOLVECONFLICTをMAP文で複数回使用すると、競合タイプごとに異なる解決を指定できます。ただし、同じ競合タイプについてRESOLVECONFLICTを繰り返して使用することはできません。同じ競合は同じ最終結果となるように、すべてのデータベースで同一の競合解決手順を使用してください。1つの競合解決方法で、発生する可能性のあるすべての競合に対応できるわけではありません。障害のリスクを最小化するため、状況に応じて、論理的な優先順でコールできる複数のルーチンを作成する必要があります。

ノート:

表に主キーと他の一意索引または一意キーが含まれている場合は、他にも考慮すべき事項があります。COMPARECOLSパラメータとRESOLVECONFLICTパラメータで自動ルーチンが指定されている場合、一貫した方法で各行を一意に識別する必要があります。一貫した方法で行を識別できない場合、競合解決時にエラーが発生します。このような状況では、主キー以外の一意キーを無効化するか、または、SQLEXEC機能を使用してスローされたエラーを処理することで競合を解決できます。

これらのパラメータの詳細は、『Oracle GoldenGateリファレンス』を参照してください。これらのパラメータの詳細は、CDRの例1: USEMAX、OVERWRITE、DISCARDによるすべての競合タイプの処理以降の例を参照してください。

親トピック: 競合の検出および解決の構成

7.7.4 必要な列値をExtractで使用可能にする方法

CDRを使用するには、次の列値をログに記録して、Extractがその値を証跡に書き込めるようにする必要があります。

  • 各レコードの完全な変更前イメージ。一部のデータベースは、変更前イメージをログ・レコードに記録できないため、サプリメンタル・ロギングを使用してこの処理を行うよう構成する必要があります。ほとんどのサポート対象データベースでは、ADD TRANDATAコマンドをこの目的で使用できます。

  • LOGALLSUPCOLSパラメータを使用して、スケジュール列の完全な変更前イメージと変更後イメージが確実に証跡に書き込まれるようにします。スケジュール列は、主キー、一意索引および外部キーの列です。LOGALLSUPCOLSを使用すると、Extractでは、UPDATE操作の変更前イメージおよびUPDATEとDELETEの両操作のサプリメンタル・ロギング列すべての変更前イメージを証跡レコードに含めるようになります。

これらのパラメータとコマンドの詳細は、『Oracle GoldenGateリファレンス』を参照してください。これらのパラメータがCDRでどのように動作するかについては、「CDRの例1: USEMAX、OVERWRITE、DISCARDによるすべての競合タイプの処理」以降の例を参照してください。

親トピック: 競合の検出および解決の構成

7.7.5 Oracle GoldenGate CDRの構成

ソース・データベース、ターゲット・データベースおよびOracle GoldenGateを競合検出および解決のために構成するには、次のステップを実行します。ステップは次のとおりです。

親トピック: 競合の検出および解決の構成

7.7.5.1 CDR統計の表示

CDR機能には、競合解決の結果を表示するために次の方法が用意されています。

7.7.5.1.1 レポート・ファイル

Replicatは、CDR統計をレポート・ファイルに書き込みます。

Total CDR conflicts                 7
    CDR resolutions succeeded       6
    CDR resolutions failed          1
    CDR INSERTROWEXISTS conflicts   1
    CDR UPDATEROWEXISTS conflicts   4
    CDR UPDATEROWMISSING conflicts
    CDR DELETEROWEXISTS conflicts      1
    CDR DELETEROWMISSING conflicts     1

親トピック: CDR統計の表示

7.7.5.1.2 GGSCI

CDR統計は、STATS REPLICATコマンドをREPORTCDRオプションとともに使用して、GGSCIから表示することもできます。 

STATS REPLICAT group, REPORTCDR

親トピック: CDR統計の表示

7.7.5.1.3 列変換関数

次のCDR統計を取得し、必要に応じて、例外表にマップしたり、列変換関数からの入力を受け付ける他のOracle GoldenGateパラメータで使用できます。

  • Replicatで検出した競合の数

  • Replicatで解決した解決の数

  • Replicatで解決できなかった解決の数

これらの統計を取得するには、'STATS'または'DELTASTATS'情報タイプを指定して@GETENV列変換関数を使用します。結果は、現在のReplicatセッションに基づいています。Replicatが停止して再起動すると、統計はリセットされます。

特定の表またはワイルドカードで指定された表のセットについて統計が返されます。

@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_CONFLICTS')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','TABLE','SCHEMA.TABLNAME','CDR_RESOLUTIONS_FAILED')

Replicatパラメータ・ファイルのすべてのMAP文のすべての表について統計が返されます。 

@GETENV ('STATS','CDR_CONFLICTS')
@GETENV ('STATS','CDR_RESOLUTIONS_SUCCEEDED')
@GETENV ('STATS','CDR_RESOLUTIONS_FAILED')

前述の例の'STATS'情報タイプを'DELTASTATS'に置き換えると、前回の'DELTASTATS'の実行以降の数が返されます。

@GETENVの詳細は、『Oracle GoldenGateリファレンス』を参照してください。

親トピック: CDR統計の表示

7.7.6 CDRの例1: USEMAX、OVERWRITE、DISCARDによるすべての競合タイプの処理

この例では、USEMAX解決、OVERWRITE解決およびDISCARD解決を使用して、すべての競合タイプを解決します。

親トピック: 競合の検出および解決の構成

7.7.6.1 この例で使用する表

各例では同一のOracleデータベースを想定しています。

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

ソース・データベースでは、すべての列が補足的にログに記録されます。

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);
7.7.6.2 競合解決を指定したMAP文 
MAP fin.src, TARGET fin.tgt,
    COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
    RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)),
    );
7.7.6.3 MAP文の説明

次に、MAP文について説明します。

  • COMPARECOLSでは、更新および削除のReplicat WHERE句において、証跡レコード内のすべての列の変更前イメージを使用します。

  • DEFAULTでは、すべての競合タイプの列グループとしてすべての列を使用します。そのため、解決はすべての列に適用されます。

  • INSERTROWEXISTS競合には、USEMAX解決を使用します。つまり、挿入時に行が存在する場合は、last_mod_time列を解決列として使用し、証跡の値とデータベースの値のどちらが大きいかを判別します。証跡の値の方が大きい場合、レコードを適用しますが、挿入を更新に変更します。データベースの値の方が大きい場合、レコードを無視します。

  • UPDATEROWEXISTS競合には、USEMAX解決を使用します。つまり、更新時に行が存在する場合は、last_mod_time列を解決列として使用します。証跡の値の方が大きい場合、更新を適用します。

  • USEMINとUSEMAXを使用し、値がまったく同じ場合、RESOLVECONFLICTはトリガーされず、受け取った行は無視されます。USEMINEQとUSEMAXEQを使用し、値がまったく同じ場合、解決策はトリガーされます。

  • DELETEROWEXISTS競合には、OVERWRITE解決を使用します。つまり、削除操作時に行が存在する場合は、削除を適用します。

  • UPDATEROWMISSING競合には、OVERWRITE解決を使用します。つまり、更新時に行が存在しない場合は、更新を挿入に変更して適用します。

  • DELETROWMISSING競合には、DISCARD解決を使用します。つまり、削除操作時に行が存在しない場合は、証跡レコードを破棄します。

    ノート:

    USEMAXのかわりにUSEMAXEQ解決を使用すると、>=条件を適用できます。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

7.7.6.4 エラー処理

例外表に対するエラー処理の例は、「エラー処理のためのOracle GoldenGateパラメータ・ファイルの構成」を参照してください。

7.7.6.5 USEMAX解決によるINSERTROWEXISTSの処理

この例では、証跡とデータベースのレコードに対する適用可能な変更前イメージと変更後イメージを使用したUSEMAX解決を説明しています。ソースとターゲットに行が存在するが、一部またはすべての行の値が異なる場合の挿入の解決方法を示します。

表7-1 USEMAX解決によるINSERTROWEXISTS競合の処理

イメージ SQL コメント

証跡内の変更前イメージ

 
None (row was inserted on the source).

該当なし

証跡内の変更後イメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=100
balance=100
comment=NULL
last_mod_time='9/1/10 3:00'

last_mod_time='9/1/10 3:00は、解決列の変更後イメージです。変更後イメージが存在するため、これが解決の特定に使用されます。

ターゲット・データベースのイメージ

 
name='Mary'
phone='111111'
address='Ralston'
salary=200
balance=500
comment='aaa'
last_mod_time='9/1/10 1:00'

last_mod_time='9/1/10 1:00は、ターゲットの解決列の現行イメージであり、証跡内の解決列の値はこれと比較されます。

Replicatによって適用され、競合を検出する初期INSERT

SQLバインド変数:

1)'Mary'
2)'1234567890'
3)'Oracle Pkwy'
4)100
5)100
6)NULL
7)'9/1/10 3:00'

このSQLは、Maryに対する一意性競合を戻します。

競合を解決するためにReplicatによって適用されるUPDATE

SQLバインド変数:

1)'1234567890'
2)'Oracle Pkwy'
3)100
4)100
5)NULL
6)'9/1/10 3:00'
7)'Mary'
8)'9/1/10 3:00'

INSERTROWEXISTSに対してUSEMAXが指定されているため、Replicatは挿入を更新に変換し、証跡レコードのlast_mod_timeの値をデータベースの値と比較します。レコードの値の方が大きいため、証跡ファイル内の列の変更後イメージがターゲットに適用されます。

7.7.6.6 USEMAX解決によるUPDATEROWEXISTSの処理

この例では、証跡とデータベースのレコードに対する適用可能な変更前イメージと変更後イメージを使用したUSEMAX解決を説明しています。ソースとターゲットに行が存在するが、一部またはすべての行の値が異なる場合の更新の解決方法を示します。

表7-2 USEMAX解決によるUPDATEROWEXISTS競合の処理

イメージ SQL コメント

証跡内の変更前イメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=100
balance=100
comment=NULL
last_mod_time='9/1/10 3:00'

last_mod_time='9/1/10 3:00は、解決列の変更前イメージです。

証跡内の変更後イメージ

 
phone='222222'
address='Holly'
last_mod_time='9/1/10 5:00'

last_mod_time='9/1/10 5:00は、解決列の変更後イメージです。変更後イメージが存在するため、これが解決の特定に使用されます。

ターゲット・データベースのイメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=100
balance=600
comment='com'
last_mod_time='9/1/10 6:00'

last_mod_time='9/1/10 6:00は、ターゲットの解決列の現行イメージであり、証跡内の解決列の値はこれと比較されます。

Replicatによって適用され、競合を検出する初期UPDATE

SQLバインド変数:

1)'222222'
2)'Holly'
3)'9/1/10 5:00'
4)'Mary'
5)'1234567890'
6)'Oracle Pkwy'
7)100
8)100
9)NULL
10)'9/1/10 3:00'

balance、commentおよびlast_mod_timeの値がターゲット内で異なるため、このSQLはデータが見つからないというエラーを戻します。

COMPARECOLS文がALLに設定されているため、すべての列がWHERE句で使用されます。

競合を解決するためにReplicatによって適用されるUPDATE

SQLバインド変数:

1)'Mary'
2)'222222'
3)'Holly'
4)100
5)100
6)NULL
7)'9/1/10 5:00'
8)'Mary'
9)'9/1/10 5:00'

証跡レコードのlast_mod_timeの変更後の値の方がデータベースの現行値より小さいため、データベースの値は維持されます。Replicatは、主キーと、9/1/10 5:00より小さく設定されたlast_mod_time値を含むWHEREで操作を適用します。この基準に一致する行はないため、「データが見つからない」というエラーが発生して文は失敗しますが、条件に一致しない場合はUSEMAX解決が失敗すると予想されることから、Replicatはエラーを無視します。

7.7.6.7 OVERWRITE解決によるUPDATEROWMISSINGの処理

この例では、証跡とデータベースのレコードに対する適用可能な変更前イメージと変更後イメージを使用したOVERWRITE解決を説明しています。ターゲット行が存在しない場合の解決方法を示します。論理的な解決は、行をターゲットに上書きして両方のデータベースを再度同期させることであり、この方法が使用されます。

表7-3 OVERWRITE解決によるUPDATEROWMISSING競合の処理

イメージ SQL コメント

証跡内の変更前イメージ

 
name='Jane'
phone='333'
address='Oracle Pkwy'
salary=200
balance=200
comment=NULL
last_mod_time='9/1/10 7:00'

該当なし

証跡内の変更後イメージ

 
phone='4444'
address='Holly'
last_mod_time='9/1/10 8:00'

ターゲット・データベースのイメージ

 
None (row for Jane is missing)

Replicatによって適用され、競合を検出する初期UPDATE

SQLバインド変数:

1)'4444'
2)'Holly'
3)'9/1/10 8:00'
4)'Jane'
5)'333'
6)'Oracle Pkwy'
7)200
8)200
9)NULL
10)'9/1/10 7:00'

このSQLは、データが見つからないというエラーを戻します。COMPARECOLS文がALLに設定されているため、すべての列がWHERE句で使用されます。

競合を解決するためにReplicatによって適用されるINSERT

SQLバインド変数:

1)'Jane'
2)'4444'
3)'Holly'
4)200
5)200
6)NULL
7)'9/1/10 8:00'

OVERWRITEが解決であるため、更新は挿入に変更されます。列の変更後イメージがあれば使用され、ない場合は変更前イメージが使用されます。

7.7.6.8 DISCARD解決によるDELETEROWMISSINGの処理

この例では、証跡とデータベースのレコードに対する適用可能な変更前イメージと変更後イメージを使用したDISCARD解決を説明しています。ターゲット行が存在しない場合の解決方法を示します。ソースに対する削除の場合、ターゲット行が存在しなくてもかまわない(ターゲット行はいずれにせよ削除する必要がある)ため、解決方法は証跡内のDELETE操作を破棄することです。

表7-4 DISCARD解決によるDELETEROWMISSING競合の処理

イメージ SQL コメント

証跡内の変更前イメージ

 
name='Jane'
phone='4444'
address='Holly'
salary=200
balance=200
comment=NULL
last_mod_time='9/1/10 8:00'

該当なし

証跡内の変更後イメージ

 
None

該当なし

ターゲット・データベースのイメージ

 
None (row missing)

該当なし

Replicatによって適用され、競合を検出する初期DELETE

SQLバインド変数:

1)'Jane'
2)'4444'
3)'Holly'
4)200
5)200
6)NULL
7)'9/1/10 8:00'

このSQLは、データが見つからないというエラーを戻します。COMPARECOLS文がALLに設定されているため、すべての列がWHERE句で使用されます。

競合を解決するためにReplicatによって適用されるSQL

 
None

DELETEROWMISSINGの解決としてDISCARDが指定されているため、証跡からの削除が破棄ファイルに格納されます。

7.7.6.9 OVERWRITE解決によるDELETEROWEXISTSの処理

この例では、証跡とデータベースのレコードに対する適用可能な変更前イメージと変更後イメージを使用したOVERWRITE解決を説明しています。ここでは、ソース行は削除されたがターゲット行は存在する場合の解決方法を示します。この場合、OVERWRITE解決により、ターゲットに削除が適用されます。

表7-5 OVERWRITE解決によるDELETEROWEXISTS競合の処理

イメージ SQL コメント

証跡内の変更前イメージ

 
name='Mary'
phone='222222'
address='Holly'
salary=100
balance=100
comment=NULL
last_mod_time='9/1/10 5:00'

該当なし

証跡内の変更後イメージ

 
None

該当なし

ターゲット・データベースのイメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=100
balance=600
comment=com
last_mod_time='9/1/10 7:00'

行はターゲットに存在しますが、phone、address、balance、comment、last_mod_timeの各列が証跡内の変更前イメージと異なっています。

Replicatによって適用され、競合を検出する初期DELETE

SQLバインド変数:

1)'Mary'
2)'222222'
3)'Holly'
4)100
5)100d
6)NULL
7)'9/1/10 5:00'

COMPARECOLS文がALLに設定されているため、すべての列がWHERE句で使用されます。

変更前の値と現行値が異なるため、データが見つからないというエラーが発生します。

競合を解決するためにReplicatによって適用されるDELETE

SQLバインド変数:

1)'Mary'

OVERWRITEが解決であるため、(整合性エラーを回避するために)主キーのみを使用してDELETEが適用されます。

7.7.7 CDRの例2: USEDELTAおよびUSEMAXによるUPDATEROWEXISTSの処理

この例では、UPDATEにターゲット行は存在するが、キー以外の列が異なる場合、影響を受ける列に応じて2つの異なる解決タイプを使用してこの状況を処理し、問題を解決します。

親トピック: 競合の検出および解決の構成

7.7.7.1 この例で使用する表

各例では同一のOracleデータベースを想定しています。

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

ソース・データベースでは、すべての列が補足的にログに記録されます。

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);
7.7.7.2 MAP文 
MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE KEYINCLUDING (address, phone, salary, last_mod_time),
    ON DELETE KEYINCLUDING (address, phone, salary, last_mod_time)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary)),
    (DEFAULT, USEMAX (last_mod_time)));
7.7.7.3 MAP文の説明

UPDATEにターゲット行は存在するが、キー以外の列が異なるUPDATEROWEXISTS競合には、列に応じて2つの異なる解決を使用します。

  • delta_res_method解決では、salary列に対してUSEDELTA解決ロジックを使用し、値の変更が列の現行値に追加されるようにします。

  • DEFAULTでは、last_mod_time列を解決列として使用し、表(デフォルトの列グループ)のその他すべての列に対しUSEMAX解決ロジックを使用します。この列は行が変更されるたびに現在の時間で更新され、証跡内のこの列の値がターゲットの値と比較されます。証跡レコード内のlast_mod_timeの値がターゲット・データベースのlast_mod_timeの現行値より大きい場合は、name、phone、address、balance、commentおよびlast_mod_timeの変更がターゲットに適用されます。

COMPARECOLSでは、主キー(name 列)とaddress、phone、salary、last_mod_timeの各列をUPDATE操作とDELETE操作の競合検出のための比較列として使用します。(balance列とcomment列は比較されません。)

ノート:

USEMAXのかわりにUSEMAXEQ解決を使用すると、>=条件を適用できます。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

7.7.7.4 エラー処理

例外表に対するエラー処理の例は、「エラー処理のためのOracle GoldenGateパラメータ・ファイルの構成」を参照してください。

表7-6 USEDELTAおよびUSEMAXによるUPDATEROWEXISTSの処理

イメージ SQL コメント

証跡内の変更前イメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=100
balance=100
comment=NULL
last_mod_time='9/1/10 3:00'

last_mod_time='9/1/10 3:00は、USEMAX解決の解決列の変更前イメージです。

salary=100は、USEDELTA解決の変更前イメージです。

証跡内の変更後イメージ

 
phone='222222'
address='Holly'
salary=200
comment='new'
last_mod_time='9/1/10 5:00'

last_mod_time='9/1/10 5:00は、USEMAXの解決列の変更後イメージです。変更後イメージが存在するため、これが解決の特定に使用されます。

ターゲット・データベースのイメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=600
balance=600
comment='com'
last_mod_time='9/1/10 4:00'

last_mod_time='9/1/10 4:00は、ターゲットの解決列の現行イメージであり、証跡内の解決列の値はこれと比較されます。

salary=600は、USEDELTA解決のターゲット列の現行イメージです。

Replicatによって適用され、競合を検出する初期UPDATE

SQLバインド変数:

1)'222222'
2)'Holly'
3)200
4)'new'
5)'9/1/10 5:00'
6)'Mary'
7)'1234567890'
8)'Oracle Pkwy'
9)100
10)'9/1/10 3:00'

salaryとlast_mod_timeの値が異なるため、このSQLはデータが見つからないというエラーを戻します。(commentとbalanceの値も異なりますが、これらの列は比較されません。)

USEDELTAを使用してsalaryの競合を解決するためにReplicatによって適用されるUPDATE。

SQLバインド変数:

1)200
2)100
3)'Mary'

USEDELTAでは、証跡内のsalaryの変更後イメージ(200)と証跡内のsalaryの変更前イメージ(100)の差が、ターゲットのsalaryの現行値(600)に追加されます。結果は700です。 

600 + (200 - 100) = 700

USEMAXを使用してデフォルト列の競合を解決するためにReplicatによって適用されるUPDATE。

SQLバインド変数:

1)'222222'
2)'Holly'
3)'new'
4)'9/1/10 5:00'
5)'Mary'
6)'9/1/10 5:00'

USEMAXでは、証跡レコード内のlast_mod_timeの変更後の値がデータベースの現行値より大きいため、証跡レコードの変更後の値で行が更新されます。

salary列は、USEDELTA解決のUPDATEで解決されるため、ここでは設定していません。

7.7.8 CDRの例3: USEDELTA、USEMAXおよびIGNOREによるUPDATEROWEXISTSの処理

この例では、UPDATEにターゲット行は存在するが、キー以外の列が異なる場合、影響を受ける列に応じて3つの異なる解決タイプを使用してこの状況を処理し、競合を解決します。

親トピック: 競合の検出および解決の構成

7.7.8.1 この例で使用する表

各例では同一のOracleデータベースを想定しています。

CREATE TABLE tgt(
    name varchar2(30) primary key,
    phone varchar2(10),
    address varchar2(100),
    salary number,
    balance number,
    comment varchar2(100),
    last_mod_time timestamp);

ソース・データベースでは、すべての列が補足的にログに記録されます。

ADD TRANDATA scott.src, COLS (name, phone, address, salary, balance, comment, last_mod_time);
7.7.8.2 MAP文 
MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE ALLEXCLUDING (comment)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary, balance)),
    (max_res_method, USEMAX (last_mod_time), COLS (address, last_mod_time)),
    (DEFAULT, IGNORE));
7.7.8.3 MAP文の説明

  • UPDATEにターゲット行は存在するが、キー以外の列が異なるUPDATEROWEXISTS競合には、列に応じて2つの異なる解決を使用します。

    • delta_res_method解決では、salary列とbalance列に対してUSEDELTA解決ロジックを使用し、各値の変更が各列の現行値に追加されるようにします。

    • max_res_method解決では、address列とlast_mod_time列に対してUSEMAX解決ロジックを使用します。last_mod_time列が解決列です。この列は行が変更されるたびに現在の時間で更新され、証跡内のこの列の値がターゲットの値と比較されます。証跡レコード内のlast_mod_timeの値がターゲット・データベースのlast_mod_timeの現行値より大きい場合は、addressとlast_mod_timeの変更がターゲットに適用されます。そうでない場合、変更は無視され、ターゲット値が維持されます。

    • DEFAULTでは、表(デフォルトの列グループ)の残りの列(phoneとcomment)に対してIGNORE解決ロジックを使用します。Replicatでは、これらの列の変更は常に無視されます。

  • COMPARECOLSでは、comment列を除くすべての列を、UPDATE操作の競合検出における比較列として使用します。commentは更新のWHERE句では使用されませんが、証跡レコード内に変更前イメージを持つその他すべての列が使用されます。

    ノート:

    USEMAXのかわりにUSEMAXEQ解決を使用すると、>=条件を適用できます。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

7.7.8.4 エラー処理

例外表に対するエラー処理の例は、「エラー処理のためのOracle GoldenGateパラメータ・ファイルの構成」を参照してください。

表7-7 USEDELTA、USEMAXおよびIGNOREによるUPDATEROWEXISTSの処理

イメージ SQL コメント

証跡内の変更前イメージ

 
name='Mary'
phone='1234567890'
address='Oracle Pkwy'
salary=100
balance=100
comment=NULL
last_mod_time='9/1/10 3:00

last_mod_time='9/1/10 3:00は、USEMAX解決の解決列の変更前イメージです。

salary=100とbalance=100は、USEDELTA解決の変更前イメージです。

証跡内の変更後イメージ

 
phone='222222'
address='Holly'
salary=200
comment='new'
last_mod_time='9/1/10 5:00'

last_mod_time='9/1/10 5:00は、USEMAXの解決列の変更後イメージです。変更後イメージが存在するため、これが解決の特定に使用されます。

salary=200は、USEDELTA解決の唯一の変更後イメージです。balanceについては、変更前イメージが計算で使用されます。

ターゲット・データベースのイメージ

 
name='Mary'
phone='1234567890'
address='Ralston'
salary=600
balance=600
comment='com'
last_mod_time='9/1/10 4:00'

last_mod_time='9/1/10 4:00は、USEMAXのターゲットの解決列の現行イメージであり、証跡内の解決列の値はこれと比較されます。

salary=600とbalance=600は、USEDELTAのターゲット列の現行イメージです。

Replicatによって適用され、競合を検出する初期UPDATE

SQLバインド変数:

1)'222222'
2)'Holly'
3)200
4)'new'
5)'9/1/10 5:00'
6)'Mary'
7)'1234567890'
8)'Oracle Pkwy'
9)100
10)100
11)'9/1/10 3:00'

address、salary、balance、last_mod_timeの各列の値が異なるため、このSQLはデータが見つからないというエラーを戻します。

USEDELTAを使用してsalaryの競合を解決するためにReplicatによって適用されるUPDATE。

SQLバインド変数:

1)200
2)100
3)'Mary'

salaryには100の差がありますが、balanceの値に変更がなかったため、更新のSQLではsalaryは不要です。USEDELTAでは、証跡内のsalaryの変更後イメージ(200)と変更前イメージ(100)の差が、ターゲットのsalaryの現行値(600)に追加されます。結果は700です。

USEMAXの競合を解決するためにReplicatによって適用されるUPDATE。

SQLバインド変数:

1)'Holly'
2)'9/1/10 5:00'
3)'Mary'
4)'9/1/10 5:00'

証跡レコード内のlast_mod_timeの変更後の値がデータベースの現行値より大きいため、その列とaddress列が証跡レコードの変更後の値で更新されます。

salary列は、USEDELTA解決のUPDATEで解決されるため、ここでは設定していません。

IGNOREに対し、Replicatによって適用されるUPDATE。

SQLバインド変数:

1)'222222'
2)'new'
3)'Mary'

DEFAULT列グループ(phoneとcomment)にIGNOREが指定されているため、解決のSQLは適用されません。