この章では、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
)でのタグの使用方法を示します。
関連項目: ハブ・アンド・スポーク・レプリケーション環境およびその構成例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
この環境では、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概要および管理』を参照してください。
この方法で環境を構成すると、変更の循環が防止され、どのデータベースで発生した変更も失われません。
関連項目: ハブ・アンド・スポーク・レプリケーション環境およびその構成例については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
現行セッションまたは適用プロセスによって生成されるタグの値を設定または取得できます。ここでは、タグ値の設定方法と取得方法について説明します。
この項では、現行セッション用のタグを設定する手順と取得する手順について説明します。
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
ファンクションをコールしてタグを取得できます。