| Oracle® Streamsレプリケーション管理者ガイド 12cリリース1 (12.1) B71328-02 |
|
 前 |
 次 |
この章では、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が適用されるかどうかを判別できます。カスタム・ルールベースの変換または適用ハンドラの動作も、タグの値に依存させることが可能です。また、PL/SQLプロシージャを使用するカスタム・ルールベースの変換または適用ハンドラで、LCR用のSET_TAGメンバー・プロシージャを使用すると、既存のLCRのタグ値を設定できます。文DMLハンドラまたは変更ハンドラでは、既存のLCRのタグ値を設定できません。
|
関連項目:
|
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.example.comソース・データベースで実行された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.example.com',
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.EXAMPLE.COM' )
取得プロセスでこのルールを含むポジティブ・ルール・セットを使用すると、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.example.com',
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.EXAMPLE.COM' )
タグに関連する条件がないことに注意してください。取得プロセスでこのルールを含むポジティブ・ルール・セットを使用すると、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条件を追加、削除または変更できます。
|
関連項目:
|
グローバル・ルールを使用していて、データベース全体に対するDDLの変更を取得および適用する場合は、デフォルトでオンライン・バックアップ文が取得され、伝播および適用されます。通常は、データベース管理者はオンライン・バックアップ文のレプリケートを行いません。かわりに、元々それらが実行されるデータベースで実行することのみを考慮します。オンライン・バックアップ文では、ALTER TABLESPACEまたはALTER DATABASE文のBEGIN BACKUPおよびEND BACKUP句が使用されます。
オンライン・バックアップ文のレプリケートの回避策として、次の方針のいずれかを使用できます。
オンライン・バックアップ・プロシージャにDBMS_STREAMS.SET_TAGプロシージャへのコールを1つ以上含め、セッション・タグにオンライン・バックアップ文が取得プロセスで無視されるような値を設定します。
適用プロセスにDDLハンドラを使用し、オンライン・バックアップ文の適用を回避します。
|
注意: Recovery Manager(RMAN)を使用してオンライン・バックアップを実行する場合、オンライン・バックアップ文は使用されないため、バックアップ用の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は、デフォルトで変更の循環を回避するように設計されています。
Oracle Streamsの取得プロセス、同期取得、伝播および適用プロセスにタグと適切なルールを使用すると、このような変更の循環を回避できます。ここでは、一般的なOracle Streams環境、およびそれらの環境でタグとルールを使用して変更の循環を回避する方法について説明します。
この項の内容は次のとおりです。
n-wayレプリケーション環境とは、各データベースが他のすべてのデータベースのソース・データベースと宛先データベースを兼ねているレプリケーション環境のことです。各データベースは、他の各データベースと直接通信します。
たとえば、hrmultスキーマ内のデータベース・オブジェクトとデータを、3つのOracle Database mult1.example.com、mult2.example.comおよびmult3.example.com間でレプリケートする環境を考えます。hrmultスキーマ内の表に対するDML変更とDDL変更は、この環境の3つのデータベースすべてで取得され、環境内の他の各データベースに伝播されて、そこで適用されます。図10-1に、n-wayレプリケーション環境の例を示します。
前述の環境を次のように構成すると、変更の循環を回避できます。
各データベースで、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スキーマに対するすべての変更が他の各データベースに送信されます。そのため、この環境では変更が失われることはなく、すべてのデータベースが同期化されます。図10-2に、n-wayレプリケーション環境のデータベース内でタグを使用する方法を示します。
|
関連項目: この例の詳細は、『Oracle Streams拡張例』を参照してください。 |
ハブ・アンド・スポーク・レプリケーション環境とは、1つのプライマリ・データベース(ハブ)が複数のセカンダリ・データベース(スポーク)と通信するレプリケーション環境のことです。スポーク相互は直接通信しません。ハブ・アンド・スポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合と許可されていない場合があります。
レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されていない場合は、プライマリ・データベースによって、共有データに対するローカルの変更が取得され、それがすべてのセカンダリ・データベースに伝播され、それぞれのセカンダリ・データベースでローカルに適用されます。レプリケートされたデータベース・オブジェクトへの変更は1つの場所でのみ取得されるため、レプリケートされたデータベース・オブジェクトへの変更がセカンダリ・データベースで許可されていない場合、変更の循環は発生しません。
レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合、変更は次のように取得、伝播および適用されます。
プライマリ・データベースでは、共有データに対するローカルの変更が取得され、それがすべてのセカンダリ・データベースに伝播され、それぞれのセカンダリ・データベースでローカルに適用されます。
それぞれのセカンダリ・データベースでは、共有データに対するローカルの変更が取得され、それがプライマリ・データベースにのみ伝播され、プライマリ・データベースでローカルに適用されます。
プライマリ・データベースでは、それぞれのセカンダリ・データベースからの変更がローカルに適用されます。次に、これらの変更がプライマリ・データベースで取得され、変更の発生場所となったデータベースを除くすべてのセカンダリ・データベースに伝播されます。それぞれのセカンダリ・データベースでは、他のセカンダリ・データベースからの変更がプライマリ・データベースを経由してからローカルに適用されます。この構成は、適用による転送の一例です。
代替使用例では、キューによる転送を使用できます。この環境でキューによる転送を使用した場合、セカンダリ・データベースからの変更がプライマリ・データベースで適用されても、プライマリ・データベースでは取得されません。かわりに、これらの変更は、プライマリ・データベースのキューから、変更の発生場所となったデータベースを除くすべてのセカンダリ・データベースに転送されます。
|
関連項目: 適用による転送とキューによる転送の詳細は、『Oracle Streams概要および管理』を参照してください。 |
たとえば、1つのプライマリ・データベースps1.example.comと3つのセカンダリ・データベースps2.example.com、ps3.example.comおよびps4.example.com間で、hrスキーマ内のデータベース・オブジェクトとデータをレプリケートする環境を考えます。この環境では、hrスキーマ内の表に対するDML変更とDDL変更は、プライマリ・データベースと3つのセカンダリ・データベースで取得されます。次に、これらの変更が前述のとおり伝播され、適用されます。この環境では、プライマリ・データベースを介してセカンダリ・データベース間でデータを共有するために、キューによる転送ではなく適用による転送が使用されます。図10-3に、1つのプライマリ・データベースと複数のセカンダリ・データベースを含む環境の例を示します。
この環境を次のように構成すると、変更の循環を回避できます。
プライマリ・データベースps1.example.comの各適用プロセスを、変更の送信元サイトを示す非NULLのREDOタグを生成するように構成します。この環境の場合、プライマリ・データベースには、変更の送信元となるセカンダリ・データベースごとに少なくとも1つは適用プロセスがあります。たとえば、プライマリ・データベースの適用プロセスは、ps2.example.comセカンダリ・データベースから変更を受信すると、適用するすべての変更について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.example.com',
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.example.comに変更を伝播する場合に、そのタグが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つにあるキューには、適用プロセスによって行われた変更ではなく、そのデータベースでユーザー・セッションおよびアプリケーションによってローカルに行われた変更のみが含まれます。したがって、これらの伝播については、それ以上の構成は不要です。
この構成では、次の方法で変更の循環が防止されます。
セカンダリ・データベースで発生した変更が、そのセカンダリ・データベースに再び伝播されることはありません。
プライマリ・データベースで発生した変更が、そのプライマリ・データベースに再び伝播されることはありません。
環境内のどのデータベースで共有データに対して行われた変更も、すべて環境内の他の各データベースに伝播します。
そのため、この環境では変更が失われることはなく、すべてのデータベースが同期化されます。
図10-4に、プライマリ・データベースps1.example.comでのタグの使用方法を示します。
図10-5に、セカンダリ・データベースの1つ(ps2.example.com)でのタグの使用方法を示します。
この環境では、1つのプライマリ・データベースが複数のセカンダリ・データベースとデータを共有しますが、セカンダリ・データベースにはリモート・セカンダリ・データベースと呼ばれる他のセカンダリ・データベースが接続されています。この環境は、「ハブ・アンド・スポーク・レプリケーション環境」で説明した環境が拡張されたものです。
レプリケートされたデータベース・オブジェクトへの変更がリモート・セカンダリ・データベースで許可されている場合、リモート・セカンダリ・データベースはプライマリ・データベースとデータを直接共有しません。かわりに、セカンダリ・データベースを介してプライマリ・データベースと間接的にデータを共有します。そのため、共有データはプライマリ・データベース、それぞれのセカンダリ・データベースおよびそれぞれのリモート・セカンダリ・データベースに存在します。これらのデータベースのいずれかで行われた変更は、他のすべてのデータベースで取得し、伝播できます。図10-6に、1つのプライマリ・データベースと複数の拡張セカンダリ・データベースを含む環境を示します。
この種の環境では、次の方法で変更の循環を回避できます。
「ハブ・アンド・スポーク・レプリケーション環境」で説明した例の場合と同様の方法で、プライマリ・データベースを構成します。
「ハブ・アンド・スポーク・レプリケーション環境」で説明した例でそれぞれのセカンダリ・データベースを構成した場合と同様の方法で、それぞれのリモート・セカンダリ・データベースを構成します。唯一の違いは、リモート・セカンダリ・データベースは、プライマリ・データベースではなくセカンダリ・データベースとデータを直接共有することです。
それぞれのセカンダリ・データベースで、プライマリ・データベースからの変更のうち、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概要および管理』を参照してください。
この方法で環境を構成すると、変更の循環が防止され、どのデータベースで発生した変更も失われません。
現行セッションまたは適用プロセスによって生成されるタグの値を設定または取得できます。ここでは、タグ値の設定方法と取得方法について説明します。
この項では、現行セッション用のタグを設定する手順と取得する手順について説明します。
DBMS_STREAMSパッケージのSET_TAGプロシージャを使用すると、現行セッションで生成されるすべてのREDOエントリ用のタグを設定できます。たとえば、現行セッションでタグを'1D'の16進値に設定するには、次のプロシージャを実行します。
BEGIN
DBMS_STREAMS.SET_TAG(
tag => HEXTORAW('1D'));
END;
/
このプロシージャを実行すると、現行セッションでDML文またはDDL文によって生成される各REDOエントリのタグ値は1Dになります。このプロシージャを実行すると、現行セッションにのみ影響します。
SET_TAGプロシージャに関する考慮事項は次のとおりです。
このプロシージャは、トランザクション型ではありません。つまり、SET_TAGの影響はロールバックできません。
SET_TAGプロシージャを実行して、データ・ディクショナリの構築をデータベースで実行する前に非NULLセッション・タグを設定する場合は、ディクショナリの構築前に開始されたトランザクションのREDOエントリに、そのセッションに指定されたタグ値が含まれない可能性があります。したがって、セッションでSET_TAGプロシージャを実行する前にデータ・ディクショナリの構築を実行します。データ・ディクショナリは、DBMS_CAPTURE_ADM.BUILDプロシージャの実行時に構築されます。BUILDプロシージャは、取得プロセスの作成時に自動的に実行できます。
DBMS_STREAMSパッケージのGET_TAGプロシージャを使用すると、現行セッションで生成されるすべてのREDOエントリ用のタグを取得できます。たとえば、現行セッションのREDOエントリに生成されるタグの16進値を取得するには、次のプロシージャを実行します。
SET SERVEROUTPUT ON
DECLARE
raw_tag RAW(2048);
BEGIN
raw_tag := DBMS_STREAMS.GET_TAG();
DBMS_OUTPUT.PUT_LINE('Tag Value = ' || RAWTOHEX(raw_tag));
END;
/
また、次のようにDUALビューを問い合せると、現行セッションのタグ値を表示できます。
SELECT DBMS_STREAMS.GET_TAG FROM DUAL;
この項では、適用プロセス用のタグを設定する手順と削除する手順について説明します。
適用プロセスでは、変更をデータベースに適用するとき、またはハンドラを起動するときに、REDOエントリが生成されます。適用プロセスで生成される全REDOエントリ用のデフォルト・タグは、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを使用して適用プロセスを作成するとき、またはDBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャを使用して既存の適用プロセスを変更するときに設定できます。どちらのプロシージャでも、apply_tagパラメータを、適用プロセスで生成されるタグ用に指定する値に設定します。
たとえば、既存の適用プロセスstrep01_applyでREDOログに生成されるタグの値を'7'の16進値に設定するには、次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name => 'strep01_apply',
apply_tag => HEXTORAW('7'));
END;
/
このプロシージャを実行すると、適用プロセスで生成される各REDOエントリのタグ値が7になります。
適用プロセスの適用タグを削除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャで、remove_apply_tagパラメータをTRUEに設定します。適用タグを削除すると、適用プロセスで生成される各REDOエントリのタグはNULLになります。たとえば、次のプロシージャでは、適用プロセスstrep01_applyから適用タグが削除されます。
BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name => 'strep01_apply',
remove_apply_tag => TRUE);
END;
/
ここでは、現行セッション用のOracle Streamsタグと各適用プロセス用のデフォルト・タグを表示するために実行できる問合せについて説明します。
|
関連項目:
|
次のようにDUALビューを問い合せると、現行セッションについてすべてのREDOエントリ内で生成されたタグ値を表示できます。
SELECT DBMS_STREAMS.GET_TAG FROM DUAL;
出力は次のようになります。
GET_TAG -------------------------------------------------------------------------------- 1D
また、DBMS_STREAMS.GET_TAGファンクションをコールすると、セッション用のタグを判断できます。
DBA_APPLYデータ・ディクショナリ・ビューでAPPLY_TAGの値を問い合せると、各適用プロセスによって生成されるすべてのREDOエントリのデフォルト・タグを取得できます。たとえば、各適用プロセスによってREDOエントリ内で生成されるデフォルト・タグの16進値を取得するには、次の問合せを実行します。
COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A30 COLUMN APPLY_TAG HEADING 'Tag Value' FORMAT A30 SELECT APPLY_NAME, APPLY_TAG FROM DBA_APPLY;
出力は次のようになります。
Apply Process Name Tag Value ------------------------------ ------------------------------ APPLY_FROM_MULT2 00 APPLY_FROM_MULT3 00
適用プロセスに関連付けられているハンドラまたはカスタム・ルールベースの変換ファンクションでは、DBMS_STREAMS.GET_TAGファンクションをコールしてタグを取得できます。
