処理のための表の準備

Db2 LUWのOracle GoldenGate環境で使用するために表を準備するには、次のタスクを実行する必要があります。

トリガーおよびカスケード制約の無効化

ターゲットのDb2 LUW表で、トリガー、カスケード削除制約、およびカスケード更新制約を無効化します。Oracle GoldenGateでは、トリガーまたはカスケード制約の結果として生成されるDMLがレプリケートされます。同じトリガーや制約がターゲット表でアクティブになった場合、レプリケートされたバージョンのために重複となり、データベースでエラーが返されます。ソース表にemp_srcsalary_src、ターゲット表にemp_targsalary_targを使用している次の例について考えます。

  1. emp_srcに削除が発行されます。
  2. それによって、削除がsalary_srcにカスケードされます。
  3. Oracle GoldenGateが、両方の削除をターゲットに送信します。
  4. 親削除が最初に到達し、emp_targに適用されます。
  5. 親削除によって、削除がsalary_targにカスケードされます。
  6. salary_srcのカスケードされた削除が、salary_targに適用されます
  7. 行は、すでにステップ5で削除されているため、見つかりません。

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

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

TABLEまたはMAP文でKEYCOLS句が使用されないかぎり、Oracle GoldenGateは、使用する行識別子を次の優先順位に従って選択します。
  1. 主キー

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

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

    ノート:

    表に使用可能な他のキーがない場合や、表にキーがまったくない場合、Oracle GoldenGateは該当するメッセージをレポート・ファイルに記録します。すべての列からキーを作成すると、ソース・システムのOracle GoldenGateのパフォーマンスが低下します。ターゲットでは、このキーはReplicatであまり効率的でないより大きいWHERE句が使用される原因となります。
  4. 表に適切なキーがない場合、あるいは既存のキーを使用しない場合は、表に一意の値が常に含まれる列があれば、代替キーを定義できます。ExtractのTABLEパラメータおよびReplicatのMAPパラメータ内にKEYCOLS句を含めることで、この代替キーを定義します。指定したキーにより、Oracle GoldenGateで検出される既存の主キーまたは一意キーはオーバーライドされます。Oracle GoldenGateパラメータおよび機能リファレンスTABLE | MAPを参照してください。

KEYCOLSを使用したカスタム・キーの指定

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

キー変更の防止

Oracle GoldenGateで表のデータの抽出が開始された後で、キーに列を追加しないでください。このルールは、主キー、一意キー、KEYCOLSキー、またはすべての列キーに適用されます。Db2 LUWでは、表に追加される列の変更前イメージは提供されません。ソースでキー内の列が更新された場合、Oracle GoldenGateでは更新のレプリケートの際、ターゲット表の現在の値と比較するために変更前イメージが必要になります。

マテリアライズ問合せ表の維持

ソースとターゲットのマテリアライズ問合せ表(MQT)間の同等性を維持するには、ベース表をレプリケートしますが、MQTはレプリケートしません。ターゲット・データベースでは、Replicatがベース表に適用する変更に基づいてMQTが整備されます。

これらの表を構成するためのルールを次に示します。

  • ベース表をTABLEおよびMAP文に含めます。

  • MQTはTABLEおよびMAP文に含めないでください。

  • MQT名が通常の表名とともに解決される可能性はありますが、TABLEおよびMAP文でワイルドカードを使用できます。Oracle GoldenGateは、ワイルドカードを使用した表リストからMQTを自動的に除外します。ただし、ExtractのTABLE文でMQTを名前によって明示的にリストすると、Extractが異常終了する原因となります。

テンポラル表の作成

テンポラル表とは、表データの履歴と有効期間を管理する表です。Oracle GoldenGateでは、テンポラル表を使用して、表内で削除または更新される古い行すべてを管理します。テンポラル表は、その行やデータのビジネス有効期間を管理する場合にも使用されます。たとえば、Oracle GoldenGateでは行の有効期間を管理します。テンポラル表には、システム期間、アプリケーション期間、およびバイテンポラル表の3種類があります。

テンポラル表への変換

既存の表をテンポラル表に変換できますが、それにより表の構造が変更されます。この項では、表の構造がどのように変更されるかについて説明します。この項の各例では、次に示すサンプルの既存表を3種類すべてのテンポラル表に変換します。

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

例1   既存表をシステム期間テンポラル表に変換。

サンプルの既存表をシステム期間テンポラル表に変換するには、次のようにSYSTEM_PERIOD列、transaction id列およびSYSTEM_TIME期間を追加します。

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info 
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

次に、次のいずれかの方法を使用して新しいテンポラル表の履歴表を作成します。

  • 	CREATE TABLE hist_policy_info
    (
     policy_id     CHAR(4) NOT NULL,
    coverage     INT NOT NULL,
    sys_start    TIMESTAMP(12) NOT NULL ,
    sys_end      TIMESTAMP(12) NOT NULL,
    ts_id            TIMESTAMP(12) NOT NULL
     	       );
     ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
    
  • CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;
    

    RESTRICT ON DROP句を使用すると、システム期間テンポラル表の削除中に履歴表は削除できません。それ以外は、関連するテンポラル表の削除中に履歴表が暗黙的に削除されます。RESTRICT ON DROPを使用せずに、履歴表を作成できます。履歴表を明示的に削除することはできません。

    履歴表の作成時にはGENERATED ALWAYS句を使用しないようにしてください。また、ベース表の特定の行に対して多数の更新が行われ、それにより同じ主キーのセットで履歴表に何件もの挿入がトリガーされる場合があるため、システム期間テンポラル表の主キーもここでは適用されません。これ以外にも、履歴表の構造は関連するシステム期間テンポラル表とまったく同じであることが必要です。履歴表にはシステム期間テンポラル表と同数の列を同じ順序で設定する必要があります。履歴表の列は明示的に追加、削除または変更できません。次の文を使用して、システム期間テンポラル表をその履歴表と関連付ける必要があります。

     ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.
    

    表のGENERATED ALWAYS列は、常にデータベース・マネージャによって移入される列であり、ユーザーがこれらの列を制御することはできません。データベース・マネージャは、システム時間に基づいてこれらの列に移入します。

    既存の行では、追加されたSYSTEM_PERIOD列とtransaction id列に、次のようなデフォルト値が設定されます。

    POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
    --------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
    ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
    DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
    ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
    

    テンポラル表の更新を開始すると、関連する履歴表に変更前イメージが移入されます。

例2   既存表をアプリケーション期間テンポラル表に変換。

サンプルの既存表をアプリケーション期間テンポラル表に変換するには、次のように時間列およびBUSINESS_TIME期間を追加します。

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

時間列を追加するときは、既存の時間列のビジネス有効期間の値を入力する際、bus_start列には必ずbus_endよりも小さい値が設定されていることを確認する必要があります(これらの列が各行のビジネス有効期間を示すため)。

新しいアプリケーション期間テンポラル表は次のように表示されます。

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002
例3   既存表をバイテンポラル表に変換。

サンプルの既存表をバイテンポラル表に変換するには、次のようにSYSTEM_PERIOD列、時間列をSYSTEM_TIME期間およびBUSINESS_TIME期間とともに追加します。

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info 
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);
 
ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

時間列を追加するときは、既存の時間列のビジネス有効期間の値を入力する際、bus_start列には必ずbus_endよりも小さい値が設定されていることを確認する必要があります(これらの列が各行のビジネス有効期間を示すため)。

次に、次のいずれかの方法を使用して新しいテンポラル表の履歴表を作成します。

  • 	CREATE TABLE hist_policy_info
    (
     policy_id     CHAR(4) NOT NULL,
    coverage     INT NOT NULL,
    sys_start    TIMESTAMP(12) NOT NULL ,
    sys_end      TIMESTAMP(12) NOT NULL,
    ts_id            TIMESTAMP(12) NOT NULL
     	       );
     ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
    CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;
    
  • RESTRICT ON DROP句を使用すると、システム期間テンポラル表の削除中に履歴表は削除できません。それ以外は、関連するテンポラル表の削除中に履歴表が暗黙的に削除されます。RESTRICT ON DROPを使用せずに、履歴表を作成できます。履歴表を明示的に削除することはできません。

    履歴表の作成時にはGENERATED ALWAYS句を使用しないようにしてください。また、ベース表の特定の行に対して多数の更新が行われ、それにより同じ主キーのセットで履歴表に何件もの挿入がトリガーされる場合があるため、システム期間テンポラル表の主キーもここでは適用されません。これ以外にも、履歴表の構造は関連するシステム期間テンポラル表とまったく同じであることが必要です。履歴表にはシステム期間テンポラル表と同数の列を同じ順序で設定する必要があります。履歴表の列は明示的に追加、削除または変更できません。次の文を使用して、システム期間テンポラル表をその履歴表と関連付ける必要があります。

     ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.
    

    表のGENERATED ALWAYS列は、常にデータベース・マネージャによって移入される列であり、ユーザーがこれらの列を制御することはできません。データベース・マネージャは、システム時間に基づいてこれらの列に移入します。

    既存の行では、追加されたSYSTEM_PERIOD列とtransaction id列に、次のようなデフォルト値が設定されます。

    POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
    --------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
    ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
    DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
    ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
    

    テンポラル表の更新を開始すると、関連する履歴表に変更前イメージが移入されます。

既存の行では、追加されたSYSTEM_TIME期間、トランザクションIDおよび時間の各列に、次のようなデフォルト値が設定されます。

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

ユーザーがテンポラル表の更新を開始すると、履歴表に変更前イメージが移入されます。

例4   異種環境でのレプリケーション。

適用側にテンポラル表がない異種構成でレプリケートできるのはシステム期間テンポラル表とバイテンポラル表のみであり、関連する履歴表はレプリケートできません。この状況でレプリケーションを実行する際は、SYSTEM_PERIOD列とトランザクションID列の値を処理する必要があります。これらの列にはターゲット・データベースでサポートされない値が含まれている可能性があります。最初にマップ変換関数を使用して、これらの値をターゲット・データベースでサポートされる形式に変換してから、列を適切にマップする必要があります。

たとえば、MySQLのDATETIME範囲は1000-01-01 00:00:00.000000から9999-12-31 23:59:59.999999までです。タイムスタンプ値0001-01-01-00.00.00.000000000000はMySQLにレプリケートできません。このような値をレプリケートするには、この値をMySQLのDATETIME1000-01-01 00:00:00.000000に変換してから、列をマップする必要があります。次の行がpolicy_infoシステム期間表にある場合:

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

この行をMySQLにレプリケートするには、次のようにcolmap()関数を使用します。

map source_schema.policy_info, target target_schema.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

テンポラル表を使用したレプリケーション

次のいずれかの方法を選択して、システム期間テンポラル表またはバイテンポラル表を次のようにレプリケートできます。

  • テンポラル表を別のテンポラル表にのみレプリケートします。これがデフォルトの動作です。SYSTEM_TIME期間列とトランザクションID列は適用側で自動生成される列なので、Oracle GoldenGateではレプリケートされません。データベース・マネージャは、システム・クロック時間とデフォルト値を使用して、ターゲット・テンポラル表の列に移入します。これらの列の元の値はそのまま使用して、次のいずれかを実行します。

    • ターゲット・テンポラル表に追加のタイムスタンプ列を追加し、列を適切にマップします。追加の列は関連する履歴表に自動的に追加されます。

    • 適用側で非テンポラル表を使用し、列を適切にマップします。このシナリオで、履歴表は管理できません。

    • ソースがDb2 LUWで、ターゲットが異なるデータベースである異種構成では、自動生成された列を無視できます。また、適切な列変換関数を使用して列値をターゲット・データベースでサポートされている形式に変換し、その値をターゲット列に適切にマップすることもできます。

    または

  • テンポラル表は関連する履歴表とともにテンポラル表と履歴表にそれぞれレプリケートできますが、その場合はレプリケート・パラメータDBOPTIONS SUPPRESSTEMPORALUPDATESを指定する必要があります。キャプチャ対象のテンポラル表と履歴表の両方をExtractパラメータ・ファイルに指定する必要があります。Oracle GoldenGateでは、SYSTEM_TIME期間列とトランザクションID列の値をレプリケートします。データベース・インスタンスに、適用側でストアド・プロシージャを実行する実行権限があることを確認する必要があります。

デフォルト・レプリケーションの使用中はSYSTEM_TIME期間列とtransactionstart id列が自動生成のままなので、Oracle GoldenGateで競合の検出や解決はできません。これらの列はset句とwhere句には指定できません。SUPPRESSTEMPORALUPDATESパラメータを使用する場合、Oracle GoldenGateではCDRがサポートされます。