4 Oracle Streamsタグ

この章では、Oracle Streamsタグに関連する概念について説明します。

この章の内容は次のとおりです。

• タグの概要

• DBMS_STREAMS_ADMパッケージによって作成されるタグとルール

• タグとオンライン・バックアップ文

• タグと適用プロセス

• レプリケーション環境のOracle Streamsタグ

参照: 「Oracle Streamsタグの管理」

タグの概要

REDOログの各REDOエントリには、タグが関連付けられています。タグのデータ型はRAWです。デフォルトでは、ユーザーまたはアプリケーションがREDOエントリを生成する時点では、各REDOエントリのタグの値はNULLであり、NULLタグは領域をコンシュームしません。タグ値のサイズの上限は2000バイトです。

タグ値の解析方法を構成できます。たとえば、タグを使用すると、LCRに含まれている変更の発生場所が、ローカル・データベースであるか他のデータベースであるかを判断できるため、変更の循環（発生場所となったデータベースへのLCRの送信）を回避できます。タグは他のLCRの追跡にも使用できます。また、タグを使用して、LCRごとに接続先データベースのセットを指定することもできます。

REDOログ内で生成されるタグの値を制御するには、次の方法があります。

• DBMS_STREAMS.SET_TAGプロシージャを使用して、現行のセッションで生成されるREDOタグの値を指定します。セッション中にデータベースに変更があると、タグはその変更を記録するREDOエントリの一部となります。様々なセッションで同じタグ設定または異なるタグ設定を使用できます。

• DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャを使用して、適用プロセスの実行時に生成されるREDOタグの値を制御します。このタグ設定は、適用プロセス・コーディネータによって調整されるすべてのセッションで使用されます。デフォルトでは、適用プロセスで生成されるREDOエントリのタグ値は、'00'（2つのゼロ）と等価の16進数です。

取得プロセスのルール・セットに含まれるルールに基づき、変更に関するREDOエントリ内のタグ値によって、変更が取得されるかどうかを判断できます。同期取得のルール・セットに含まれるルールに基づき、変更に関するセッション・タグの値によって、変更が取得されるかどうかを判断できます。タグは、取得プロセスまたは同期取得によって取得されるLCRの一部となります。

同様に、タグがLCRの一部になっている場合は、そのタグの値によって、伝播でLCRが伝播されるかどうかと、適用プロセスでLCRが適用されるかどうかを判別できます。カスタム・ルールベースの変換、DMLハンドラまたはエラー・ハンドラの動作も、タグの値に依存させることが可能です。また、LCR用のSET_TAGメンバー・プロシージャを使用すると、既存のLCRのタグ値を設定できます。たとえば、カスタム・ルールベースの変換中にLCR内のタグを設定できます。

参照: LCR用のSET_TAGメンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 Oracle Streamsでルールを使用する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

DBMS_STREAMS_ADMパッケージによって作成されるタグとルール

DBMS_STREAMS_ADMパッケージのプロシージャを使用してルールを作成し、include_tagged_lcrパラメータをFALSEに設定すると、タグがNULLの場合にのみTRUEと評価される条件が各ルールに含まれます。DMLルールの条件は、次のとおりです。

:dml.is_null_tag()='Y'

DDLルールの条件は、次のとおりです。

:ddl.is_null_tag()='Y'

ポジティブ・ルール・セットに1つのルールが含まれており、そのルールに前述の条件が含まれている場合を考えます。この場合、Oracle Streams取得プロセス、同期取得、伝播および適用プロセスの動作は次のようになります。

• 取得プロセスによって変更が取得されるのは、変更に関するREDOログ・エントリ内のタグがNULLで、かつ、他のルール条件が変更についてTRUEと評価される場合のみです。

• 同期取得によって変更が取得されるのは、変更が行われるセッションのタグがNULLで、かつ、他のルール条件が変更についてTRUEと評価される場合のみです。

• 伝播によってLCRが伝播されるのは、LCR内のタグがNULLで、かつ、他のルール条件がLCRについてTRUEと評価される場合のみです。

• 適用プロセスによってLCRが適用されるのは、LCR内のタグがNULLで、かつ、他のルール条件がLCRについてTRUEと評価される場合のみです。

また、ネガティブ・ルール・セットに1つのルールが含まれており、そのルールに前述の条件が含まれている場合を考えます。この場合、Oracle Streams取得プロセス、伝播および適用プロセスの動作は次のようになります。

• 取得プロセスによって変更が廃棄されるのは、変更に関するREDOログ・エントリ内のタグがNULLで、かつ、他のルール条件が変更についてTRUEと評価される場合のみです。

• 伝播または適用プロセスによってLCRが廃棄されるのは、LCR内のタグがNULLで、かつ、他のルール条件がLCRについてTRUEと評価される場合のみです。

ほとんどの場合、タグ値に関係なく変更が廃棄されるようにルールをネガティブ・ルール・セットに追加するときは、include_tagged_lcrパラメータにTRUEを指定します。

DBMS_STREAMS_ADMパッケージの次のプロシージャでは、デフォルトでこれらの条件のいずれかを含むルールが作成されます。

• ADD_GLOBAL_PROPAGATION_RULES

• ADD_GLOBAL_RULES

• ADD_SCHEMA_PROPAGATION_RULES

• ADD_SCHEMA_RULES

• ADD_SUBSET_PROPAGATION_RULES

• ADD_SUBSET_RULES

• ADD_TABLE_PROPAGATION_RULES

• ADD_TABLE_RULES

前述の条件を含むルールを作成しない場合は、これらのプロシージャを実行するときにinclude_tagged_lcrパラメータをTRUEに設定します。この設定を使用すると、タグに関する条件はルールに含まれません。したがって、データベースの変更のルール評価はタグの値に依存しないことになります。

たとえば、dbs1.netソース・データベースで実行されたhr.locations表に対するすべてのDML変更について、TRUEと評価される表ルールを考えます。

ADD_TABLE_RULESプロシージャを実行してこのルールを生成する場合を考えます。

BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name               =>  'hr.locations',
    streams_type             =>  'capture',
    streams_name             =>  'capture',
    queue_name               =>  'streams_queue',
    include_tagged_lcr       =>  FALSE,  -- Note parameter setting
    source_database          =>  'dbs1.net',
    include_dml              =>  TRUE,
    include_ddl              =>  FALSE);
END;
/

include_tagged_lcrパラメータがデフォルトのFALSEに設定されていることに注意してください。ADD_TABLE_RULESプロシージャでは、次のようなルール条件を持つルールが生成されます。

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS'))
and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.NET' )

取得プロセスでこのルールを含むポジティブ・ルール・セットを使用すると、REDOエントリ内の変更に関するタグの値が'0'や'1'などの非NULL値の場合に、ルールがFALSEと評価されます。そのため、REDOエントリにhr.locations表の1行の変更が含まれていると、変更が取得されるのはREDOエントリのタグがNULLの場合のみになります。

ただし、ここではADD_TABLE_RULESの実行時にinclude_tagged_lcrパラメータがTRUEに設定されているとします。

BEGIN
  DBMS_STREAMS_ADM.ADD_TABLE_RULES(
    table_name               =>  'hr.locations',
    streams_type             =>  'capture',
    streams_name             =>  'capture',
    queue_name               =>  'streams_queue',
    include_tagged_lcr       =>  TRUE,   -- Note parameter setting
    source_database          =>  'dbs1.net',
    include_dml              =>  TRUE,
    include_ddl              =>  FALSE);
END;
/

この場合、ADD_TABLE_RULESプロシージャでは、次のようなルール条件を持つルールが生成されます。

(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS'))
and :dml.get_source_database_name() = 'DBS1.NET' )

タグに関連する条件がないことに注意してください。取得プロセスでこのルールを含むポジティブ・ルール・セットを使用すると、hr.locations表に対するDML変更についてREDOエントリ内のタグの値が'0'や'1'などの非NULL値の場合に、ルールがTRUEと評価されます。また、このルールは、タグがNULLの場合にもTRUEと評価されます。そのため、REDOエントリにhr.locations表のDML変更が含まれている場合は、タグの値に関係なく変更が取得されます。

既存のシステム作成ルールのis_null_tag条件を変更する場合は、DBMS_STREAMS_ADMパッケージの適切なプロシージャを使用して新規ルールを作成します。このルールは、is_null_tag条件を除き、変更するルールと同じである必要があります。次に、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを使用して、適切なルール・セットから古いルールを削除します。また、DBMS_STREAMS_ADMパッケージのルールを作成するプロシージャのand_conditionパラメータを使用して、タグに関連する条件をシステム作成ルールに追加できます。

DBMS_RULE_ADMパッケージでルールを作成した場合は、このパッケージのALTER_RULEプロシージャを使用して、is_null_tag条件を追加、削除または変更できます。

参照: DBMS_STREAMS_ADMパッケージのプロシージャで生成されるルールの例については、『Oracle Streams概要および管理』を参照してください。 DBMS_STREAMS_ADMパッケージおよびDBMS_RULE_ADM.ALTER_RULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 SET_TAGプロシージャの詳細は、「適用プロセスで生成されるタグ値の設定」を参照してください。

タグとオンライン・バックアップ文

グローバル・ルールを使用していて、データベース全体に対するDDLの変更を取得および適用する場合は、デフォルトでオンライン・バックアップ文が取得され、伝播および適用されます。通常は、データベース管理者はオンライン・バックアップ文のレプリケートを行いません。かわりに、元々それらが実行されるデータベースで実行することのみを考慮します。オンライン・バックアップ文では、ALTER TABLESPACEまたはALTER DATABASE文のBEGIN BACKUPおよびEND BACKUP句が使用されます。

オンライン・バックアップ文のレプリケートの回避策として、次の方針のいずれかを使用できます。

• オンライン・バックアップ・プロシージャにDBMS_STREAMS.SET_TAGプロシージャへのコールを1つ以上含め、セッション・タグにオンライン・バックアップ文が取得プロセスで無視されるような値を設定します。

• 適用プロセスにDDLハンドラを使用し、オンライン・バックアップ文の適用を回避します。

注意: Recovery Managerを使用してオンライン・バックアップを実行する場合、オンライン・バックアップ文は使用されないため、バックアップ用のOracle Streamsタグを設定する必要はありません。

参照: バックアップを実行する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タグと適用プロセス

適用プロセスでは、DML変更またはDDL変更の適用時に、接続先データベースのREDOログにエントリが生成されます。たとえば、適用プロセスで表の1行を更新する変更が適用されると、その変更は接続先データベースのREDOログに記録されます。これらのREDOエントリ内のタグは、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャのapply_tagパラメータを設定することで制御できます。たとえば、適用プロセスでは、'0'（ゼロ）または'1'の16進値と等価のREDOタグを生成できます。

適用プロセスによってREDOログ内で生成されるデフォルトのタグ値は'00'（2つのゼロ）です。この値は、DBMS_STREAMS_ADMパッケージのプロシージャまたはDBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成した場合の、適用プロセス用のデフォルトのタグ値です。この値は、単に非NULL値であることを示します。非NULL値であることが重要なのは、DBMS_STREAMS_ADMパッケージによって作成されたルールには、デフォルトでREDOエントリまたはLCR内でタグがNULLの場合にのみTRUEと評価される条件が含まれているためです。既存の適用プロセスのタグ値は、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャを使用して変更できます。

適用プロセスの適用ハンドラで生成されるREDOエントリには、SET_TAGプロシージャによってハンドラでタグに異なる値が設定される場合を除き、適用プロセスのタグ値が含まれます。DMLハンドラ、DDLハンドラまたはメッセージ・ハンドラがDBMS_STREAMSパッケージのSET_TAGプロシージャをコールすると、ハンドラによって生成される後続のREDOエントリには、適用プロセスのタグが異なる場合にも、SET_TAGコールで指定されたタグが含まれます。ハンドラが終了すると、適用プロセスで生成される後続のREDOエントリには、適用プロセス用に指定されたタグが含まれます。

参照: 適用プロセスの詳細は、「適用とOracle Streamsレプリケーション」を参照してください。 Oracle Streamsのルールに含まれるデフォルトのタグ条件の詳細は、「DBMS_STREAMS_ADMパッケージによって作成されるタグとルール」を参照してください。 「Oracle Streamsタグの管理」 DBMS_STREAMS_ADMパッケージおよびDBMS_APPLY_ADMパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

レプリケーション環境のOracle Streamsタグ

複数のデータベースがデータを両方向で共有しているOracle Streams環境では、タグを使用して変更の循環を回避できます。変更の循環とは、変更が発生場所であるデータベースに再送されることです。通常は、それぞれの変更が無限ループを介して発生場所であるデータベースに送信される可能性があるため、変更の循環を回避する必要があります。このようなループがあると、データベースに意図しないデータが格納され、環境のネットワーキング・リソースとコンピュータ・リソースが過剰に使用される可能性があります。Oracle Streamsは、デフォルトで変更の循環を回避するように設計されています。

Oracle Streamsの取得プロセス、同期取得、伝播および適用プロセスにタグと適切なルールを使用すると、このような変更の循環を回避できます。ここでは、一般的なOracle Streams環境、およびそれらの環境でタグとルールを使用して変更の循環を回避する方法について説明します。

この項の内容は次のとおりです。

• n-wayレプリケーション環境

• ハブ・アンド・スポーク・レプリケーション環境

• 複数の拡張セカンダリ・データベースを含むハブ・アンド・スポーク・レプリケーション環境

n-wayレプリケーション環境

n-wayレプリケーション環境とは、各データベースが他のすべてのデータベースのソース・データベースと接続先データベースを兼ねているレプリケーション環境のことです。各データベースは、他の各データベースと直接通信します。

たとえば、hrmultスキーマ内のデータベース・オブジェクトとデータを、3つのOracle Database mult1.net、mult2.netおよびmult3.net間でレプリケートする環境を考えます。hrmultスキーマ内の表に対するDML変更とDDL変更は、この環境の3つのデータベースすべてで取得され、環境内の他の各データベースに伝播されて、そこで適用されます。図4-1に、n-wayレプリケーション環境の例を示します。

図4-1 各データベースがソース・データベースと接続先データベースを兼ねている場合

図4-1「各データベースがソース・データベースと接続先データベースを兼ねている場合」の説明

前述の環境を次のように構成すると、変更の循環を回避できます。

• 各データベースで、1つの適用プロセスを各ソース・データベースからの変更について非NULLのREDOタグを生成するように構成します。DBMS_STREAMS_ADMパッケージのプロシージャを使用して適用プロセスを作成すると、その適用プロセスでは、デフォルトでREDOログに値'00'を持つ非NULLのタグが生成されます。この場合は、それ以上の操作をしなくても、適用プロセスでは非NULLのタグが生成されます。

  DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成する場合は、apply_tagパラメータを設定しないでください。この場合も、適用プロセスでは、デフォルトでREDOログに値'00'を持つ非NULLのタグが生成され、それ以上の操作は不要です。

• 各データベースの取得プロセスを、変更に関するREDOエントリ内のタグがNULLの場合にのみ、その変更を取得するように構成します。そのためには、取得プロセスで使用されるポジティブ・ルール・セットの各DMLルールに、次の条件が含まれていることを確認します。

  :dml.is_null_tag()='Y'
  

  各DDLルールには、次の条件が必要です。

  :ddl.is_null_tag()='Y'
  

  これらのルール条件は、変更のタグがNULLの場合にのみ取得プロセスで変更が取得されることを示します。DBMS_STREAMS_ADMパッケージを使用してルールを生成すると、各ルールにはデフォルトで前述の条件の1つが含まれます。

この構成では、適用プロセスによって適用されたすべての変更が再取得されることがないため（最初にソース・データベースで取得済であるため）、変更の循環が防止されます。各データベースからは、hrmultスキーマに対するすべての変更が他の各データベースに送信されます。そのため、この環境では変更が失われることはなく、すべてのデータベースが同期化されます。図4-2に、n-wayレプリケーション環境のデータベース内でタグを使用する方法を示します。

図4-2 各データベースがソース・データベースと接続先データベースを兼ねている場合のタグの使用

図4-2「各データベースがソース・データベースと接続先データベースを兼ねている場合のタグの使用」の説明

参照: この例の詳細は、第21章「n-wayレプリケーションの例」を参照してください。

ハブ・アンド・スポーク・レプリケーション環境

ハブ・アンド・スポーク・レプリケーション環境とは、1つのプライマリ・データベース（ハブ）が複数のセカンダリ・データベース（スポーク）と通信するレプリケーション環境のことです。スポークは相互には直接通信しません。ハブ・アンド・スポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合と許可されていない場合があります。

レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されていない場合は、プライマリ・データベースによって、共有データに対するローカルの変更が取得され、それがすべてのセカンダリ・データベースに伝播され、それぞれのセカンダリ・データベースでローカルに適用されます。レプリケートされたデータベース・オブジェクトへの変更は1つの場所でのみ取得されるため、レプリケートされたデータベース・オブジェクトへの変更がセカンダリ・データベースで許可されていない場合、変更の循環は発生しません。

レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合、変更は次のように取得、伝播および適用されます。

• プライマリ・データベースでは、共有データに対するローカルの変更が取得され、それがすべてのセカンダリ・データベースに伝播され、それぞれのセカンダリ・データベースでローカルに適用されます。

• それぞれのセカンダリ・データベースでは、共有データに対するローカルの変更が取得され、それがプライマリ・データベースにのみ伝播され、プライマリ・データベースでローカルに適用されます。

• プライマリ・データベースでは、それぞれのセカンダリ・データベースからの変更がローカルに適用されます。次に、これらの変更がプライマリ・データベースで取得され、変更の発生場所となったデータベースを除くすべてのセカンダリ・データベースに伝播されます。それぞれのセカンダリ・データベースでは、他のセカンダリ・データベースからの変更がプライマリ・データベースを経由してからローカルに適用されます。この構成は、適用による転送の一例です。

  代替使用例では、キューによる転送を使用できます。この環境でキューによる転送を使用した場合、セカンダリ・データベースからの変更がプライマリ・データベースで適用されても、プライマリ・データベースでは取得されません。かわりに、これらの変更は、プライマリ・データベースのキューから、変更の発生場所となったデータベースを除くすべてのセカンダリ・データベースに転送されます。

参照: 適用による転送とキューによる転送の詳細は、『Oracle Streams概要および管理』を参照してください。

たとえば、1つのプライマリ・データベースps1.netと3つのセカンダリ・データベースps2.net、ps3.netおよびps4.net間で、hrスキーマ内のデータベース・オブジェクトとデータをレプリケートする環境を考えます。この環境では、hrスキーマ内の表に対するDML変更とDDL変更は、プライマリ・データベースと3つのセカンダリ・データベースで取得されます。次に、これらの変更が前述のとおり伝播され、適用されます。この環境では、プライマリ・データベースを介してセカンダリ・データベース間でデータを共有するために、キューによる転送ではなく適用による転送が使用されます。図4-3に、1つのプライマリ・データベースと複数のセカンダリ・データベースを含む環境の例を示します。

図4-3 プライマリ・データベースが複数のセカンダリ・データベースとデータを共有している場合

図4-3「プライマリ・データベースが複数のセカンダリ・データベースとデータを共有している場合」の説明

この環境を次のように構成すると、変更の循環を回避できます。

• プライマリ・データベースps1.netの各適用プロセスを、変更の送信元サイトを示す非NULLのREDOタグを生成するように構成します。この環境の場合、プライマリ・データベースには、変更の送信元となるセカンダリ・データベースごとに少なくとも1つは適用プロセスがあります。たとえば、プライマリ・データベースの適用プロセスは、ps2.netセカンダリ・データベースから変更を受信すると、適用するすべての変更について16進値'2'と等価のRAW値を生成できます。そのためには、DBMS_APPLY_ADMパッケージのCREATE_APPLYまたはALTER_APPLYプロシージャで、apply_tagパラメータを非NULL値に設定します。

  たとえば、次のプロシージャを実行し、16進値'2'と等価のタグを持つREDOエントリを生成する適用プロセスを作成します。

  BEGIN
    DBMS_APPLY_ADM.CREATE_APPLY(
      queue_name      => 'strmadmin.streams_queue',
      apply_name      => 'apply_ps2',
      rule_set_name   => 'strmadmin.apply_rules_ps2',
      apply_tag       => HEXTORAW('2'),
      apply_captured  => TRUE);
  END;
  /
  

• それぞれのセカンダリ・データベースで、非NULLのREDOタグを生成するように適用プロセスを構成します。タグの正確な値は、非NULLであるかぎり無関係です。この環境の場合、それぞれのセカンダリ・データベースには、プライマリ・データベースからの変更を適用する適用プロセスが1つあります。

  DBMS_STREAMS_ADMパッケージのプロシージャを使用して適用プロセスを作成すると、その適用プロセスでは、デフォルトでREDOログに値'00'を持つ非NULLのタグが生成されます。この場合は、それ以上の操作をしなくても、適用プロセスでは非NULLのタグが生成されます。

  たとえば、セカンダリ・データベースに適用プロセスが存在せず、各セカンダリ・データベースでDBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを実行して、16進値'00'と等価のタグを持つ非NULLのREDOエントリを生成する適用プロセスを作成する場合を考えます。

  BEGIN
    DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
      schema_name     => 'hr',
      streams_type    => 'apply',
      streams_name    => 'apply',
      queue_name      => 'strmadmin.streams_queue',
      include_dml     => TRUE,
      include_ddl     => TRUE,
      source_database => 'ps1.net',
      inclusion_rule  => TRUE);
  END;
  /
  

• プライマリ・データベースで、タグに関係なく共有データの変更を取得するように取得プロセスを構成します。そのためには、DBMS_STREAMS_ADMパッケージ内の取得プロセスのルールを生成するプロシージャの1つを実行するときに、include_tagged_lcrパラメータをTRUEに設定します。DBMS_RULE_ADMパッケージを使用してプライマリ・データベースの取得プロセスのルールを作成する場合は、そのルールにis_null_tag条件が含まれないことを確認してください。これらの条件には、REDOログ内のタグが関係するためです。

  たとえば、プライマリ・データベースで次のプロシージャを実行し、DML取得プロセスのルールを1つとDDL取得プロセスのルールを1つ生成する場合を考えます。どちらのルールにも、hrスキーマ内の変更について、そのタグに関係なくTRUEと評価される条件が含まれているとします。

  BEGIN
    DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
      schema_name         => 'hr',
      streams_type        => 'capture',
      streams_name        => 'capture',
      queue_name          => 'strmadmin.streams_queue',
      include_tagged_lcr  => TRUE, -- Note parameter setting
      include_dml         => TRUE,
      include_ddl         => TRUE,
      inclusion_rule      => TRUE);
  END;
  /
  

• 各セカンダリ・データベースの取得プロセスを、変更に関するREDOエントリ内のタグがNULLの場合にのみ、その変更を取得するように構成します。そのためには、セカンダリ・データベースの取得プロセスで使用されるポジティブ・ルール・セットの各DMLルールに、次の条件が含まれていることを確認します。

  :dml.is_null_tag()='Y'
  

  各DDLルールには、次の条件が必要です。

  :ddl.is_null_tag()='Y'
  

  これらのルールは、変更のタグがNULLの場合にのみ取得プロセスで変更が取得されることを示します。DBMS_STREAMS_ADMパッケージを使用してルールを生成すると、各ルールにはデフォルトで前述の条件の1つが含まれます。DBMS_RULE_ADMパッケージを使用してセカンダリ・データベースの取得プロセスのルールを作成する場合は、各ルールに前述の条件の1つが含まれることを確認してください。

• プライマリ・データベースのキューからそれぞれのセカンダリ・データベースのキューへの伝播を1つ構成します。各伝播で使用するポジティブ・ルール・セットには、セカンダリ・データベースで発生した変更を除き、プライマリ・データベースのキューにあるすべてのLCRをセカンダリ・データベースのキューに伝播するように指示するルールを含める必要があります。

  たとえば、伝播がセカンダリ・データベースps2.netに変更を伝播する場合に、そのタグが16進値'2'と等価であれば、伝播のルールでは、タグが'2'のLCRを除き、hrスキーマに関連するすべてのLCRをセカンダリ・データベースに伝播する必要があります。行LCRの場合は、この種のルールに次の条件を含める必要があります。

  :dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('2')
  

  DDL LCRの場合は、この種のルールに次の条件を含める必要があります。

  :ddl.get_tag() IS NULL OR :ddl.get_tag()!=HEXTORAW('2')
  

  または、伝播でそのタグ値を持つLCRが廃棄されるように、伝播のネガティブ・ルール・セットにルールを追加できます。行LCRの場合は、この種のルールに次の条件を含める必要があります。

  :dml.get_tag()=HEXTORAW('2')
  

  DDL LCRの場合は、この種のルールに次の条件を含める必要があります。

  :ddl.get_tag()=HEXTORAW('2')
  

  DBMS_STREAMS_ADMパッケージのプロシージャでand_conditionパラメータを使用すると、これらの条件をシステム作成ルールに追加できます。また、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用すると、これらの条件を持つルールを作成できます。and_conditionパラメータで条件を指定する場合は、:dmlまたは:ddlのかわりに:lcrを指定します。and_conditionパラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

• それぞれのセカンダリ・データベースのキューからプライマリ・データベースのキューへの伝播を1つ構成します。セカンダリ・データベースの1つにあるキューには、適用プロセスによって行われた変更ではなく、そのデータベースでユーザー・セッションおよびアプリケーションによってローカルに行われた変更のみが含まれます。したがって、これらの伝播については、それ以上の構成は不要です。

この構成では、次の方法で変更の循環が防止されます。

• セカンダリ・データベースで発生した変更が、そのセカンダリ・データベースに再び伝播されることはありません。

• プライマリ・データベースで発生した変更が、そのプライマリ・データベースに再び伝播されることはありません。

• 環境内のどのデータベースで共有データに対して行われた変更も、すべて環境内の他の各データベースに伝播します。

そのため、この環境では変更が失われることはなく、すべてのデータベースが同期化されます。

図4-4に、プライマリ・データベースps1.netでのタグの使用方法を示します。

図4-4 プライマリ・データベースで使用されるタグ

図4-4「プライマリ・データベースで使用されるタグ」の説明

図4-5に、セカンダリ・データベースの1つ（ps2.net）でのタグの使用方法を示します。

図4-5 セカンダリ・データベースで使用されるタグ

図4-5「セカンダリ・データベースで使用されるタグ」の説明

参照: ハブ・アンド・スポーク・レプリケーション環境およびその構成例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。

複数の拡張セカンダリ・データベースを含むハブ・アンド・スポーク・レプリケーション環境

この環境では、1つのプライマリ・データベースが複数のセカンダリ・データベースとデータを共有しますが、セカンダリ・データベースにはリモート・セカンダリ・データベースと呼ばれる他のセカンダリ・データベースが接続されています。この環境は、「ハブ・アンド・スポーク・レプリケーション環境」で説明した環境が拡張されたものです。

レプリケートされたデータベース・オブジェクトへの変更がリモート・セカンダリ・データベースで許可されている場合、リモート・セカンダリ・データベースはプライマリ・データベースとデータを直接共有しません。かわりに、セカンダリ・データベースを介してプライマリ・データベースと間接的にデータを共有します。そのため、共有データはプライマリ・データベース、それぞれのセカンダリ・データベースおよびそれぞれのリモート・セカンダリ・データベースに存在します。これらのデータベースのいずれかで行われた変更は、他のすべてのデータベースで取得し、伝播できます。図4-6に、1つのプライマリ・データベースと複数の拡張セカンダリ・データベースを含む環境を示します。

図4-6 プライマリ・データベースと複数の拡張セカンダリ・データベース

図4-6「プライマリ・データベースと複数の拡張セカンダリ・データベース」の説明

この種の環境では、次の方法で変更の循環を回避できます。

• 「ハブ・アンド・スポーク・レプリケーション環境」で説明した例の場合と同様の方法で、プライマリ・データベースを構成します。

• 「ハブ・アンド・スポーク・レプリケーション環境」で説明した例でそれぞれのセカンダリ・データベースを構成した場合と同様の方法で、それぞれのリモート・セカンダリ・データベースを構成します。唯一の違いは、リモート・セカンダリ・データベースは、プライマリ・データベースではなくセカンダリ・データベースとデータを直接共有することです。

• それぞれのセカンダリ・データベースで、プライマリ・データベースからの変更のうち、16進値'00'と等価のREDOタグ値を持つ変更を適用するように、適用プロセスを1つ構成します。この値は、適用プロセスのデフォルトのタグ値です。

• それぞれのセカンダリ・データベースで、各リモート・セカンダリ・データベースからの変更のうち、そのリモート・セカンダリ・データベースに一意のREDOタグ値を持つ変更を適用するように、適用プロセスを1つ構成します。

• それぞれのセカンダリ・データベースの取得プロセスを、REDOログ内の共有データに対する変更を、そのタグ値に関係なくすべて取得するように構成します。

• それぞれのセカンダリ・データベースのキューからプライマリ・データベースのキューへの伝播を1つ構成します。伝播で使用するポジティブ・ルール・セットには、プライマリ・データベースで発生した変更を除き、セカンダリ・データベースのキューにあるすべてのLCRをプライマリ・データベースのキューに伝播するように指示するルールを含める必要があります。そのためには、LCR内のタグが'00'でない場合にのみTRUEと評価される条件をルールに追加します。たとえば、行LCRについて次のような条件を入力します。

  :dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('00')
  

  DBMS_STREAMS_ADMパッケージのプロシージャでand_conditionパラメータを使用すると、この条件をシステム作成ルールに追加できます。また、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用すると、この条件を持つルールを作成できます。and_conditionパラメータで条件を指定する場合は、:dmlまたは:ddlのかわりに:lcrを指定します。and_conditionパラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

• それぞれのセカンダリ・データベースのキューからそれぞれのリモート・セカンダリ・データベースのキューへの伝播を1つ構成します。各伝播で使用するポジティブ・ルール・セットには、リモート・セカンダリ・データベースで発生した変更を除き、セカンダリ・データベースのキューにあるすべてのLCRをリモート・セカンダリ・データベースのキューに伝播するように指示するルールを含める必要があります。そのためには、LCR内のタグがリモート・セカンダリ・データベースのタグ値と異なる場合にのみTRUEと評価される条件をルールに追加します。

  たとえば、リモート・セカンダリ・データベースのタグ値が16進値'19'と等価の場合は、行LCRについて次のような条件を入力します。

  :dml.get_tag() IS NULL OR :dml.get_tag()!=HEXTORAW('19')
  

  DBMS_STREAMS_ADMパッケージのプロシージャでand_conditionパラメータを使用すると、この条件をシステム作成ルールに追加できます。また、DBMS_RULE_ADMパッケージのCREATE_RULEプロシージャを使用すると、この条件を持つルールを作成できます。and_conditionパラメータで条件を指定する場合は、:dmlまたは:ddlのかわりに:lcrを指定します。and_conditionパラメータの詳細は、『Oracle Streams概要および管理』を参照してください。

この方法で環境を構成すると、変更の循環が防止され、どのデータベースで発生した変更も失われません。

参照: ハブ・アンド・スポーク・レプリケーション環境およびその構成例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。