| Oracle Streamsレプリケーション管理者ガイド 11g リリース1（11.1） E05776-02 |
|
 戻る |
 次へ |
この章では、Oracle Streamsレプリケーション環境でOracle Streams取得プロセス、同期取得、伝播およびOracle Streams適用プロセスを管理する方法について説明します。また、Oracle Streamsタグを管理し、Oracle Streams環境の接続先データベースでデータベースのPoint-in-Timeリカバリを実行する方法についても説明します。
この章の内容は次のとおりです。
取得プロセスまたは同期取得は、通常、データベースの変更を取得し、その変更を論理変更レコード（LCR）に変換して、ANYDATAキューにエンキューすることによって、変更をレプリケートするプロセスを開始します。次に、LCRを他のデータベースに伝播して、それらのデータベースで適用することで、レプリケーション・プロセスを完了できます。
ここでは、Oracle Streamsレプリケーション環境での取得プロセスの管理タスクについて説明します。
その他の管理タスクの実行が必要な場合もあります。
|
参照: 取得プロセスの管理の詳細は、『Oracle Streams概要および管理』を参照してください。 |
ローカルのソース・データベースに対する変更を取得するか、またはダウンストリーム・データベースの変更をリモートで取得する取得プロセスを作成できます。ダウンストリーム・データベースで取得プロセスを実行する場合、ソース・データベースのREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスはそのダウンストリーム・データベースでそのREDOデータ内の変更を取得します。
次のどのプロシージャでも、ローカルの取得プロセスを作成できます。
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
DBMS_CAPTURE_ADM.CREATE_CAPTURE
取得プロセスに関連付けるANYDATAキューが存在しない場合は、先にそのキューを作成してから、取得プロセスを作成します。
次の例では、DBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを実行して、ローカル取得プロセスを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name => 'hr',
streams_type => 'capture',
streams_name => 'strep01_capture',
queue_name => 'strep01_queue',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => FALSE,
source_database => NULL,
inclusion_rule => TRUE);
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
取得プロセスstrep01_captureが作成されます。この取得プロセスが作成されるのは、それが存在しない場合のみです。新規の取得プロセスが作成される場合、このプロシージャでは開始SCNも作成時点に設定されます。
取得プロセスが、既存のキューstrep01_queueに関連付けられます。
inclusion_ruleパラメータがTRUEに設定されているため、取得プロセスにポジティブ・ルール・セットがない場合は、ポジティブ・ルール・セットが作成され、取得プロセスに関連付けられます。このルール・セットでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ルール・セット名は、システムによって生成されます。
2つのルールが作成されます。一方は、hrスキーマとhrスキーマのデータベース・オブジェクトに対するDML変更についてTRUEと評価されるルールであり、他方は、それらに対するDDL変更についてTRUEと評価されるルールです。ルール名は、システムによって生成されます。
この2つのルールが、取得プロセスに関連付けられたポジティブ・ルール・セットに追加されます。inclusion_ruleパラメータがTRUEに設定されているため、ルールはポジティブ・ルール・セットに追加されます。
include_tagged_lcrパラメータがFALSEに設定されているため、変更にNULLタグが付いている場合にのみ、取得プロセスでREDOログ内の変更を取得するように指定されます。この動作は、取得プロセスのシステム作成ルールを介して実行されます。
source_databaseパラメータがNULLに設定されているため、ソース・データベースに対するローカルの変更を取得する取得プロセスが作成されます。ローカルの取得プロセスの場合、このパラメータにローカル・データベースのグローバル名を指定する場合もあります。
hrスキーマ内のすべてのデータベース・オブジェクトと、将来hrスキーマに追加されるすべてのデータベース・オブジェクトが、インスタンス化のために準備されます。
|
注意: 取得プロセスを起動または再起動する場合、開始SCNよりFIRST_CHANGE#値の小さいREDOログ・ファイルをスキャンする必要がある場合があります。取得プロセスによるスキャン前に必要なREDOログ・ファイルを削除すると、取得プロセスが異常終了します。先頭SCN、開始SCNおよび必須チェックポイントSCNを判断するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイントSCNを含むREDOログ・ファイルと、後続のすべてのREDOログ・ファイルが必要です。 |
|
注意:
|
|
参照: 取得プロセスを準備する方法の詳細、ダウンストリームの取得プロセスなどの取得プロセスを作成する方法の詳細、および取得プロセスの先頭SCNと開始SCNの詳細は、『Oracle Streams概要および管理』を参照してください。 |
次のプロシージャを使用して、同期取得を作成できます。
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE
次のOracle Streamsコンポーネントが存在しない場合は、同期取得を作成する前に作成しておきます。
同期取得と関連付けるANYDATAキュー
伝播（取得された変更を別のデータベースに送信する必要がある場合のみ）
取得された変更を適用する適用プロセス
次の例では、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを実行して、同期取得を作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.departments',
streams_type => 'sync_capture',
streams_name => 'sync_capture',
queue_name => 'strmadmin.streams_queue');
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
現行のデータベースに同期取得sync_captureが作成されます。同じ名前の同期取得は存在できません。
同期取得が有効化されます。同期取得を無効化することはできません。
同期取得が、既存のキューstreams_queueに関連付けられます。
同期取得sync_captureのポジティブ・ルール・セットが作成されます。このルール・セットはシステム生成名を持ちます。
hr.departments表に対するDML変更を取得するルールが作成され、同期取得のポジティブ・ルール・セットに追加されます。このルールはシステム生成名を持ちます。
ADD_TABLE_RULESプロシージャを実行したユーザーが、取得ユーザーとして構成されます。
DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATIONファンクションがhr.employees表に対して自動的に実行され、hr.employees表がインスタンス化のために準備されます。
|
注意:
|
|
参照:
|
取得プロセスを使用して変更を取得する場合は、列に対する変更が接続先データベースで正常に適用されるように、ソース・データベースで特定の列のサプリメンタル・ロギングを指定する必要があります。ここでは、ソース・データベースでサプリメンタル・ロギングを管理する方法について説明します。
|
注意:
|
ここでは、無条件ログ・グループの作成について説明します。
表の主キー列のみを含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にPRIMARY KEYオプションを指定してALTER TABLE文を実行します。
たとえば、次の文では、無条件のログ・グループにhr.regions表の主キー列が追加されます。
ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ログ・グループはシステム生成名を持ちます。
表のすべての列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にALLオプションを指定して、ALTER TABLE文を実行します。
たとえば、次の文では、無条件のログ・グループにhr.departments表のすべての列が追加されます。
ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
ログ・グループはシステム生成名を持ちます。
選択した列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句にALWAYSを指定して、ALTER TABLE文を実行します。必要に応じて、これらのログ・グループにキー列を含めることができます。
たとえば、次の文では、無条件のログ・グループlog_group_dep_pkにhr.departments表のdepartment_id列およびmanager_id列が追加されます。
ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG GROUP log_group_dep_pk (department_id, manager_id) ALWAYS;
ALWAYS指定があるため、このログ・グループは無条件のログ・グループになります。
ここでは、条件付きログ・グループの作成について説明します。
ALTER TABLE文のADD SUPPLEMENTAL LOG DATA句で、次のオプションを使用できます。
FOREIGN KEYオプション: 表の外部キー列を含む条件付きログ・グループが作成されます。
UNIQUEオプション: 表の一意キー列およびビットマップ索引列を含む条件付きログ・グループが作成されます。
1つのALTER TABLE文に複数のオプションを指定する場合、各オプションに対して個別の条件付きログ・グループが作成されます。
たとえば、次の文では、2つの条件付きログ・グループが作成されます。
ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA (UNIQUE, FOREIGN KEY) COLUMNS;
一方の条件付きログ・グループには表の一意キー列およびビットマップ索引列が含まれ、他方には表の外部キー列が含まれます。どちらのログ・グループもシステム生成名を持ちます。
|
注意: UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。 |
追加するように選択したすべての列を含む条件付きのサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句を指定して、ALTER TABLE文を実行します。ログ・グループを条件付きにするには、ALWAYS指定を含めないでください。
たとえば、hr.jobs表のmin_salaryおよびmax_salary列が、接続先データベースで競合解消用の列リストに含まれているとします。次の文では、min_salaryおよびmax_salary列が条件付きのログ・グループlog_group_jobs_crに追加されます。
ALTER TABLE hr.jobs ADD SUPPLEMENTAL LOG GROUP log_group_jobs_cr (min_salary, max_salary);
条件付きまたは無条件のサプリメンタル・ログ・グループを削除するには、ALTER TABLE文にDROP SUPPLEMENTAL LOG GROUP句を使用します。たとえば、サプリメンタル・ログ・グループlog_group_jobs_crを削除するには、次の文を実行します。
ALTER TABLE hr.jobs DROP SUPPLEMENTAL LOG GROUP log_group_jobs_cr;
ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列について、サプリメンタル・ロギングを指定するオプションもあります。データベース全体に対する変更を取得するように取得プロセスを構成する場合は、このオプションを選択できます。ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを指定するには、次のSQL文を発行します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
主キー列、一意キー列、ビットマップ索引列および外部キー列がすべてのソース・データベースと接続先データベースで同一の場合に、このコマンドをソース・データベースで実行すると、すべての接続先データベースで主キー列、一意キー列、ビットマップ索引列および外部キー列に必要なサプリメンタル・ロギングが提供されます。PRIMARY KEYオプションを指定した場合に、表が変更されると、行の主キーのすべての列がREDOログ・ファイルに記録されます（無条件ロギング）。UNIQUEオプションを指定した場合に、一意キーまたはビットマップ索引に属するいずれかの列が変更されると、行の一意キーおよびビットマップ索引のすべての列がREDOログ・ファイルに記録されます（条件付きロギング）。FOREIGN KEYオプションを指定した場合に、外部キーに属するいずれかの列が変更されると、行の外部キーのすべての列がREDOログ・ファイルに記録されます（条件付きロギング）。
これらのオプションは省略できます。たとえば、データベースのすべての外部キー列に対してサプリメンタル・ロギングが必要でない場合、FOREIGN KEYオプションを省略できます。次に例を示します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE) COLUMNS;
PRIMARY KEY、UNIQUEおよびFOREIGN KEYのみでなく、ALLオプションを使用することもできます。ALLオプションを指定すると、行が変更された場合に、その行のすべての列（LOB、LONG、LONG RAW、ユーザー定義型およびOracleが提供する型の列を除く）がREDOログ・ファイルに記録されます（無条件ロギング）。
サプリメンタル・ロギングの文は実行ごとに結果を記録します。異なる識別キーを指定して2つのALTER DATABASE ADD SUPPLEMENTAL LOG DATAコマンドを連続して発行すると、どちらのキーに対してもサプリメンタル・ロギングが行われます。
|
注意: UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。 |
ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを削除するには、ALTER DATABASE DROP SUPPLEMENTAL LOG DATA文を発行します。すべての主キー列、一意キー列、ビットマップ索引列および外部キー列のデータベース・サプリメンタル・ロギングを削除するには、次のSQL文を発行します。
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
|
注意: キー列のデータベース・サプリメンタル・ロギングを削除しても、既存の表レベルのサプリメンタル・ログ・グループには影響しません。 |
ここでは、Oracle Streamsレプリケーション環境でのLCRのステージングと伝播の管理タスクについて説明します。
その他の管理タスクの実行が必要な場合もあります。
|
参照: メッセージのステージングと伝播の管理の詳細は、『Oracle Streams概要および管理』を参照してください。 |
Oracle Streamsレプリケーション環境では、ANYDATAキューによって、取得された変更をカプセル化するLCRがステージングされます。これらのキューは、ソース・データベースから接続先データベースへストリームを介してLCRが伝播される際に、取得プロセス、同期取得、伝播および適用プロセスで使用されます。
ANYDATAキューを作成するには、DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用します。このプロシージャを使用すると、作成するANYDATAキューについて次の要素を指定できます。
キューのキュー表
キュー表のSTORAGE句
キュー名
キューの保護キュー・ユーザーとして構成され、キューに対するENQUEUEおよびDEQUEUE権限が付与されるキュー・ユーザー
キューに関するコメント
このプロシージャでは、保護キューとトランザクション型のキューを兼ねるキューが作成され、そのキューが起動されます。
たとえば、strmadminスキーマで、キュー表strep01_queue_tableを含むANYDATAキューstrep01_queueを作成するには、次のプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.SET_UP_QUEUE(
queue_table => 'strmadmin.strep01_queue_table',
queue_name => 'strmadmin.strep01_queue');
END;
/
DBMS_AQADMパッケージのプロシージャを使用して、ANYDATAキューを作成することもできます。
|
参照: ANYDATAキューの管理の詳細は、『Oracle Streams概要および管理』を参照してください。 |
データベース間でLCRをレプリケートするには、LCRが最初にキュー内でステージングされたデータベースから、適用されるデータベースに、LCRを伝播させる必要があります。これを行うには、多くの個別の伝播を使用する場合があります。
次のどのプロシージャでも、伝播を作成できます。
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES
DBMS_PROPAGATION_ADM.CREATE_PROPAGATION
伝播を作成する前に、次のタスクを完了する必要があります。
存在しない場合は、伝播のソース・キューと宛先キューを作成します。 手順については、「LCRをステージングするANYDATAキューの作成」を参照してください。
ソース・キューを含むデータベースと宛先キューを含むデータベースの間のデータベース・リンクを作成します。伝播用のデータベース・リンクを作成する方法の詳細は、『Oracle Streams概要および管理』を参照してください。
次の例では、DBMS_STREAMS_ADMパッケージのADD_SCHEMA_PROPAGATION_RULESプロシージャを実行して、伝播を作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES(
schema_name => 'hr',
streams_name => 'strep01_propagation',
source_queue_name => 'strmadmin.strep01_queue',
destination_queue_name => 'strmadmin.strep02_queue@rep2.net',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => FALSE,
source_database => 'rep1.net',
inclusion_rule => TRUE,
queue_to_queue => TRUE);
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
伝播strep01_propagationが作成されます。この伝播が作成されるのは、それが存在しない場合のみです。
伝播で現行のデータベース内のstrep01_queueからrep2.netデータベース内のstrep02_queueにLCRを伝播するように指定されます。
destination_queue_nameパラメータに@rep2.netが指定されているため、伝播でrep2.netデータベース・リンクを使用してLCRを伝播させるように指定されます。
inclusion_ruleパラメータがTRUEに設定されているため、伝播にポジティブ・ルール・セットがない場合は、ポジティブ・ルール・セットが作成され、伝播に関連付けられます。このルール・セットでは、評価コンテキストSYS.STREAMS$_EVALUATION_CONTEXTが使用されます。ルール・セット名は、システムによって生成されます。
2つのルールが作成されます。一方は、hrスキーマの表に対するDML変更の結果を含む行LCRについてTRUEと評価されるルールであり、他方は、hrスキーマまたはhrスキーマのデータベース・オブジェクトに対するDDL変更を含むDDL LCRについてTRUEと評価されるルールです。ルール名は、システムによって生成されます。
この2つのルールが、伝播に関連付けられたポジティブ・ルール・セットに追加されます。inclusion_ruleパラメータがTRUEに設定されているため、ルールはポジティブ・ルール・セットに追加されます。
include_tagged_lcrパラメータがFALSEに設定されているため、NULLタグがある場合にのみ伝播でLCRを伝播させるように設定されます。この動作は、伝播のシステム作成ルールを介して実行されます。
伝播させるLCRのソース・データベースとしてrep1.netが指定されます。このデータベースは、現行のデータベースでなくてもかまいません。この伝播では、ソース・データベースの異なるソース・キュー内のLCRは伝播されません。
キュー・ツー・キュー伝播の伝播ジョブが作成されます。
|
注意: キュー・ツー・キュー伝播を使用するには、伝播に使用されるキューが含まれる各データベースの互換レベルが10.2.0以上である必要があります。 |
|
参照: 伝播を作成する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
適用プロセスによって論理変更レコード（LCR）が適用されるか、またはLCRを実行する適用ハンドラにLCRが送信されると、LCRのレプリケーション・プロセスは完了します。これによって、LCRにカプセル化されたデータベース変更が、LCRが適用されるデータベースと共有されます。
ここでは、Oracle Streamsレプリケーション環境での適用プロセスの管理タスクについて説明します。
その他の管理タスクの実行が必要な場合もあります。
|
参照: 適用プロセスの管理の詳細は、『Oracle Streams概要および管理』を参照してください。 |
この項では、取得論理変更レコード（LCR）を適用する適用プロセスを作成する手順について説明します。取得LCRとは、取得プロセスで取得されたLCRです。
次のどのプロシージャでも、取得LCRを適用する適用プロセスを作成できます。
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
DBMS_APPLY_ADM.CREATE_APPLY
適用プロセスに関連付けるANYDATAキューが存在しない場合は、先にそのキューを作成してから、適用プロセスを作成します。
次の例では、DBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを実行して、取得LCRを適用する適用プロセスを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name => 'hr',
streams_type => 'apply',
streams_name => 'strep01_apply',
queue_name => 'strep02_queue',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => FALSE,
source_database => 'rep1.net',
inclusion_rule => TRUE);
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
取得LCRをローカル・データベースに適用する適用プロセスstrep01_applyが作成されます。この適用プロセスが作成されるのは、それが存在しない場合のみです。永続LCRを適用する適用プロセスを作成するには、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用する必要があります。
適用プロセスが、既存のキューstrep02_queueに関連付けられます。
inclusion_ruleパラメータがTRUEに設定されているため、適用プロセスにポジティブ・ルール・セットがない場合は、ポジティブ・ルール・セットが作成され、適用プロセスに関連付けられます。このルール・セットでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ルール・セット名は、システムによって生成されます。
2つのルールが作成されます。一方は、hrスキーマの表に対するDML変更の結果を含む行LCRについてTRUEと評価されるルールであり、他方は、hrスキーマまたはhrスキーマのデータベース・オブジェクトに対するDDL変更を含むDDL LCRについてTRUEと評価されるルールです。ルール名は、システムによって生成されます。
inclusion_ruleパラメータがTRUEに設定されているため、この2つのルールが、適用プロセスに関連付けられたポジティブ・ルール・セットに追加されます。
適用プロセスのapply_tagが、'00'（2つのゼロ）と等価の16進値に設定されます。適用プロセスで生成されるREDOエントリのタグは、この値になります。
include_tagged_lcrパラメータがFALSEに設定されているため、NULLタグがある場合にのみ適用プロセスでLCRを適用するように設定されます。この動作は、適用プロセスのシステム作成ルールを介して実行されます。
適用プロセスでrep1.netソース・データベースからのLCRを適用するように指定されます。適用プロセスでデキューされるLCRは、適用プロセスのルール・セット内のルールによって決定されます。適用プロセスでrep1.net以外のソース・データベースからのLCRがデキューされた場合、エラーが発生します。
|
注意:
|
|
参照: 適用プロセスを作成する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
この項では、永続LCRおよび永続ユーザー・メッセージを適用する適用プロセスを作成する方法について説明します。永続LCRとは、同期取得で取得されたか、またはアプリケーションによって構成およびエンキューされた、行の論理変更レコード（行LCR）です。永続ユーザー・メッセージとは、アプリケーションによってエンキューされた任意の型のメッセージです。
永続LCRおよび永続ユーザー・メッセージを適用する適用プロセスを作成するには、DBMS_APPLY_ADM.CREATE_APPLYプロシージャを使用する必要があります。具体的には、apply_capturedパラメータをFALSEに設定してこのプロシージャを実行する必要があります。
適用プロセスに関連付けるANYDATAキューが存在しない場合は、先にそのキューを作成してから、適用プロセスを作成します。
次の例では、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを実行して、永続LCRおよび永続ユーザー・メッセージを適用する適用プロセスを作成します。
BEGIN
DBMS_APPLY_ADM.CREATE_APPLY(
queue_name => 'streams_queue',
apply_name => 'sync_apply',
rule_set_name => 'strmadmin.sync_rule_set',
message_handler => NULL,
ddl_handler => NULL,
apply_user => NULL,
apply_database_link => NULL,
apply_tag => NULL,
apply_captured => FALSE,
precommit_handler => NULL,
negative_rule_set_name => NULL);
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
適用プロセスsync_applyが作成されます。同じ名前の適用プロセスは存在できません。
適用プロセスが、既存のキューstreams_queueに関連付けられます。
適用プロセスが、既存のルール・セットsync_rule_setに関連付けられます。このルール・セットは、適用プロセスのポジティブ・ルール・セットです。
メッセージ・ハンドラが適用プロセスで使用されないように指定されます。
DDLハンドラが適用プロセスで使用されないように指定されます。
apply_userパラメータがNULLであるため、変更を適用するユーザーがCREATE_APPLYプロシージャを実行するユーザーになるように指定されます。
apply_database_linkパラメータがNULLに設定されているため、適用プロセスによってローカル・データベースに変更が適用されるように指定されます。
適用プロセスで生成される各REDOエントリのタグがNULLになるように指定されます。
取得LCRが適用プロセスで適用されないように指定されます。したがって、適用プロセスで、適用プロセス・キューの永続キュー部分に含まれている永続LCRまたは永続ユーザー・メッセージを適用できます。
プリコミット・ハンドラが適用プロセスで使用されないように指定されます。
ネガティブ・ルール・セットが適用プロセスで使用されないように指定されます。
適用プロセスの作成後、DBMS_STREAMS_ADMパッケージの1つ以上のプロシージャを実行して、適用プロセスのルール・セットにルールを追加します。このルールによって、適用プロセスは、指定されたデータベース・オブジェクトのLCRを適用するように指示されます。
|
注意:
|
|
参照: 適用プロセスを作成する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
この項では、表の代替キー列を設定および削除する手順について説明します。
適用プロセスで表に変更が適用される場合に、代替キー列を使用すると、主キーを持つ表の主キー列を置換するか、主キーを持たない表の主キー列として使用できます。表の代替キー列を設定するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用します。この設定は、ローカルの変更をデータベースに適用するすべての適用プロセスに適用されます。
たとえば、hr.employees表の代替キー列をfirst_name列、last_name列およびhire_date列に設定し、employee_id列を置換するには、次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.SET_KEY_COLUMNS(
object_name => 'hr.employees',
column_list => 'first_name,last_name,hire_date');
END;
/
|
注意:
|
表の代替キー列を削除するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャで、column_listまたはcolumn_tableパラメータにNULLを指定します。表に主キーがある場合は、代入主キーを削除すると、適用プロセスではデータベースに対するローカルの変更にその表の主キーが使用されます。
たとえば、hr.employees表の代替キー列を削除するには、次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.SET_KEY_COLUMNS(
object_name => 'hr.employees',
column_list => NULL);
END;
/
この項では、DMLハンドラを作成、設定および削除する手順について説明します。
DMLハンドラには、次のシグネチャが必要です。
PROCEDURE user_procedure ( parameter_name IN ANYDATA);
この場合、user_procedure はプロシージャ名で、parameter_name はプロシージャに渡されるパラメータの名前です。プロシージャに渡されるパラメータは、行LCRがANYDATAにカプセル化されたものです。
ユーザー・プロシージャには、次の制限が適用されます。
COMMIT文またはROLLBACK文は実行しないでください。これらの文を実行すると、LCRを含むトランザクションの一貫性が損なわれる危険性があります。
行LCR用のEXECUTEメンバー・プロシージャを使用して行を操作する場合は、1回の行操作で複数行を操作しないでください。複数行を操作するDML文は、手動で構成して実行する必要があります。
コマンド・タイプがUPDATEまたはDELETEの場合、LCR用のEXECUTEメンバー・プロシージャを使用して送り直す行操作では、古い値のリストにキー全体を含める必要があります。キーは、SET_KEY_COLUMNSプロシージャで代替キーを指定しないかぎり、主キー、または1つ以上のNOT NULL列を含む最小の一意キーです。キーが指定されていない場合、キーは、LOB、LONGおよびLONG RAW以外のすべての列で構成されます。
コマンド・タイプがINSERTの場合、LCR用のEXECUTEメンバー・プロシージャを使用して送り直す行操作では、新規の値のリストにキー全体を含める必要があります。それ以外の場合は、行が重複する可能性があります。キーは、SET_KEY_COLUMNSプロシージャで代替キーを指定しないかぎり、主キー、または1つ以上のNOT NULL列を含む最小の一意キーです。キーが指定されていない場合、キーは、LOB、LONGおよびLONG RAW以外のすべての列で構成されます。
DMLハンドラは、行LCRのカスタマイズされた処理に使用できます。たとえば、ハンドラでLCRを変更し、LCR用のEXECUTEメンバー・プロシージャを使用して実行できます。DMLハンドラ内で行LCRを実行すると、適用プロセスではDMLハンドラを再度コールせずにLCRが適用されます。
また、DMLハンドラを使用してDML変更の履歴を記録することもできます。たとえば、DMLハンドラでは、処理するLCRに関する情報を表に挿入し、EXECUTEメンバー・プロシージャを使用してそのLCRを適用できます。この種のDMLハンドラを作成するには、まず履歴情報を保持する表を作成します。
CREATE TABLE strmadmin.history_row_lcrs(
timestamp DATE,
source_database_name VARCHAR2(128),
command_type VARCHAR2(30),
object_owner VARCHAR2(32),
object_name VARCHAR2(32),
tag RAW(10),
transaction_id VARCHAR2(10),
scn NUMBER,
commit_scn NUMBER,
old_values SYS.LCR$_ROW_LIST,
new_values SYS.LCR$_ROW_LIST)
NESTED TABLE old_values STORE AS old_values_ntab
NESTED TABLE new_values STORE AS new_values_ntab;
CREATE OR REPLACE PROCEDURE history_dml(in_any IN ANYDATA) IS lcr SYS.LCR$_ROW_RECORD; rc PLS_INTEGER; BEGIN -- Access the LCR rc := in_any.GETOBJECT(lcr); -- Insert information about the LCR into the history_row_lcrs table INSERT INTO strmadmin.history_row_lcrs VALUES (SYSDATE, lcr.GET_SOURCE_DATABASE_NAME(), lcr.GET_COMMAND_TYPE(), lcr.GET_OBJECT_OWNER(), lcr.GET_OBJECT_NAME(), lcr.GET_TAG(), lcr.GET_TRANSACTION_ID(), lcr.GET_SCN(), lcr.GET_COMMIT_SCN, lcr.GET_VALUES('old'), lcr.GET_VALUES('new', 'n')); -- Apply row LCR lcr.EXECUTE(TRUE); END; /
|
注意:
|
|
参照:
|
DMLハンドラでは、適用プロセスによってデキューされた、特定の表に対する特定の操作を含む各行LCRが処理されます。同じ表に複数のDMLハンドラを指定して、その表に対する異なる操作を処理できます。ローカル・データベース内の指定した表に変更を適用するすべての適用プロセスで、指定したDMLハンドラが使用されます。
DMLハンドラを設定するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。たとえば、次のプロシージャでは、hr.locations表に対するUPDATE操作用のDMLハンドラが設定されます。したがって、変更をローカルに適用する適用プロセスでは、hr.locations表に対するUPDATE操作を含む行LCRをデキューするときに、その行LCRが処理のためにstrmadminスキーマのhistory_dml PL/SQLプロシージャに送信されます。適用プロセスでは、この種の変更を含む行LCRが直接適用されることはありません。
この例では、apply_nameパラメータはNULLに設定されています。したがって、このDMLハンドラは、データベースのすべての適用プロセスで使用される一般的なDMLハンドラになります。
BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name => 'hr.locations',
object_type => 'TABLE',
operation_name => 'UPDATE',
error_handler => FALSE,
user_procedure => 'strmadmin.history_dml',
apply_database_link => NULL,
apply_name => NULL);
END;
/
|
注意:
|
DMLハンドラの設定を解除するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。このプロシージャを実行するときに、特定の表に対する特定の操作について、user_procedureパラメータをNULLに設定します。DMLハンドラの設定を解除すると、変更をローカルに適用する適用プロセスでは、この種の変更を含む行LCRが直接適用されます。
たとえば、次のプロシージャでは、hr.locations表に対するUPDATE操作用のDMLハンドラの設定が解除されます。
BEGIN
DBMS_APPLY_ADM.SET_DML_HANDLER(
object_name => 'hr.locations',
object_type => 'TABLE',
operation_name => 'UPDATE',
error_handler => FALSE,
user_procedure => NULL,
apply_name => NULL);
END;
/
この項では、適用プロセスのDDLハンドラを作成、指定および削除する手順について説明します。
|
注意: 適用されたDDL LCRは、すべて自動的にコミットされます。したがって、DDLハンドラがDDL LCRのEXECUTEメンバー・プロシージャをコールすると、自動的にコミットが実行されます。 |
|
参照:
|
DDLハンドラには、次のシグネチャが必要です。
PROCEDURE handler_procedure ( parameter_name IN ANYDATA);
handler_procedure はプロシージャ名で、parameter_name はプロシージャに渡されるパラメータの名前です。プロシージャに渡されるパラメータは、DDL LCRがANYDATAにカプセル化されたものです。
DDLハンドラは、DDL LCRのカスタマイズされた処理に使用できます。たとえば、ハンドラでLCRを変更し、LCR用のEXECUTEメンバー・プロシージャを使用して実行できます。DDLハンドラ内でDDL LCRを実行すると、適用プロセスではDDLハンドラを再度コールせずにLCRが適用されます。
また、DDLハンドラを使用してDDL変更の履歴を記録することもできます。たとえば、DDLハンドラでは、処理するLCRに関する情報を表に挿入し、EXECUTEメンバー・プロシージャを使用してそのLCRを適用できます。
この種のDDLハンドラを作成するには、まず履歴情報を保持する表を作成します。
CREATE TABLE strmadmin.history_ddl_lcrs( timestamp DATE, source_database_name VARCHAR2(128), command_type VARCHAR2(30), object_owner VARCHAR2(32), object_name VARCHAR2(32), object_type VARCHAR2(18), ddl_text CLOB, logon_user VARCHAR2(32), current_schema VARCHAR2(32), base_table_owner VARCHAR2(32), base_table_name VARCHAR2(32), tag RAW(10), transaction_id VARCHAR2(10), scn NUMBER);
CREATE OR REPLACE PROCEDURE history_ddl(in_any IN ANYDATA) IS lcr SYS.LCR$_DDL_RECORD; rc PLS_INTEGER; ddl_text CLOB; BEGIN -- Access the LCR rc := in_any.GETOBJECT(lcr); DBMS_LOB.CREATETEMPORARY(ddl_text, TRUE); lcr.GET_DDL_TEXT(ddl_text); -- Insert DDL LCR information into history_ddl_lcrs table INSERT INTO strmadmin.history_ddl_lcrs VALUES( SYSDATE, lcr.GET_SOURCE_DATABASE_NAME(), lcr.GET_COMMAND_TYPE(), lcr.GET_OBJECT_OWNER(), lcr.GET_OBJECT_NAME(), lcr.GET_OBJECT_TYPE(), ddl_text, lcr.GET_LOGON_USER(), lcr.GET_CURRENT_SCHEMA(), lcr.GET_BASE_TABLE_OWNER(), lcr.GET_BASE_TABLE_NAME(), lcr.GET_TAG(), lcr.GET_TRANSACTION_ID(), lcr.GET_SCN()); -- Apply DDL LCR lcr.EXECUTE(); -- Free temporary LOB space DBMS_LOB.FREETEMPORARY(ddl_text); END; /
DDLハンドラでは、適用プロセスによってデキューされたDDL LCRがすべて処理されます。適用プロセスのDDLハンドラを設定するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでddl_handlerパラメータを使用します。たとえば、次のプロシージャでは、適用プロセスstrep01_applyのDDLハンドラにstrmadminスキーマ内のhistory_ddlプロシージャが設定されます。
BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name => 'strep01_apply',
ddl_handler => 'strmadmin.history_ddl');
END;
/
DDLハンドラでは、適用プロセスによってデキューされたDDL LCRがすべて処理されます。適用プロセスのDDLハンドラを削除するには、DBMS_APPLY_ADMパッケージのALTER_APPLYプロシージャでremove_ddl_handlerパラメータをTRUEに設定します。たとえば、次のプロシージャでは、適用プロセスstrep01_applyからDDLハンドラが削除されます。
BEGIN
DBMS_APPLY_ADM.ALTER_APPLY(
apply_name => 'strep01_apply',
remove_ddl_handler => TRUE);
END;
/
仮想依存性定義とは、接続先データベースで適用されるトランザクション間の依存性を検出するために、適用プロセスで使用される依存性の記述です。仮想依存性定義は、適用プロセスの並列性が2以上で、依存性が接続先データベースのデータ・ディクショナリに制約で記述されていない場合に役立ちます。仮想依存性定義には、値依存性とオブジェクト依存性の2つのタイプがあります。
値依存性では、一意キーなどの表の制約または複数の表の列の関係を定義します。オブジェクト依存性では、接続先データベースの2つのオブジェクト間の親子関係を定義します。
ここでは、仮想依存性定義の使用について説明します。
値依存性を設定または設定解除するには、DBMS_APPLY_ADMパッケージのSET_VALUE_DEPENDENCYプロシージャを使用します。ここでは、仮想依存性の使用例について説明します。
この例では、ソース・データベースと接続先データベースの間で多数の表を共有し、表を所有するスキーマがこれらの2つのデータベースで異なる環境を使用します。また、このレプリケーション環境では、ソース・データベースが米国に存在し、接続先データベースが英国に存在します。設計会社は多数の表を使用して製品設計を記述していますが、ソース・データベースの表では米国の測定寸法（インチ、フィートなど）が使用され、接続先データベースの表ではメートル寸法が使用されています。ソース・データベースでデータベース・オブジェクトを所有するスキーマの名前はus_designsですが、接続先データベースでのスキーマの名前はuk_designsです。したがって、共有データベース・オブジェクトのスキーマ名を適用前に変更する必要があり、また、すべての測定寸法を米国の測定寸法からメートル寸法に変換する必要があります。データベース・オブジェクト間に依存性を持たせるために、両方のデータベースで同じ制約が使用されます。
ルールベースの変換で必要な変更を行うことができますが、複数のLCRをパラレルで適用することが目的です。ルールベースの変換では、LCRをシリアルで適用する必要があります。そのため、LCRに必要な変更を行うためにDMLハンドラが接続先データベースに構成され、適用プロセスの並列性は5に設定されています。この環境では、接続先データベースには、ソース・データベースから送信されるLCRのスキーマus_designsに関する情報は含まれていません。適用プロセスはLCRを適用ハンドラに渡す前に依存性を計算するため、適用プロセスにはLCR間の依存性に関する情報が必要です。値依存性を使用すると、これらの依存性を記述できます。
この例では、多数の表で個別の設計が記述され、これらの各表に主キーが含まれていると想定しています。これらの表の1つにdesign_53が存在し、その主キー列はkey_53です。また、表all_designs_summaryにはすべての個別の設計の概要が含まれ、この表には各設計表の外部キー列が含まれます。all_designs_summaryには、design_53表の主キーの外部キーであるkey_53列が含まれます。これらの表の関係を適用プロセスに通知するには、次のプロシージャを実行して、接続先データベースで値依存性を作成します。
BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name => 'key_53_foreign_key',
object_name => 'us_designs.design_53',
attribute_list => 'key_53');
END;
/
BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name => 'key_53_foreign_key',
object_name => 'us_designs.all_designs_summary',
attribute_list => 'key_53');
END;
/
LCRにはソース・データベース（us_designs）のスキーマが含まれているため、値依存性でそのソース・データベースのスキーマが使用されていることに注意してください。適用プロセスが行LCRをDMLハンドラに渡した後、そのDMLハンドラによってスキーマがuk_designsに変更されます。
値依存性を設定解除するには、dependency_nameパラメータに値依存性の名前を指定し、object_nameパラメータにNULLを指定して、SET_VALUE_DEPENDENCYプロシージャを実行します。たとえば、以前に設定されたkey_53_foreign_key値依存性を設定解除するには、次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name => 'key_53_foreign_key',
object_name => NULL,
attribute_list => NULL);
END;
/
この例では、ソース・データベースでは共有表に対して外部キー制約が使用され、接続先データベースではこれらの表に対して制約が使用されていない環境を使用します。このレプリケーション環境では、接続先データベースは、問合せよりはるかに頻繁にデータの書込みが行われるデータ・ウェアハウスとして使用されています。書込み操作を最適化するために、接続先データベースに制約は定義されていません。
このような環境では、トランザクションを一貫して適用するために、接続先データベースで実行されている適用プロセスに制約を通知する必要があります。値依存性を使用すると、適用プロセスにこれらの制約を通知できます。
たとえば、oeスキーマのordersおよびorder_items表が、この環境のソース・データベースおよび接続先データベース間で共有されていると想定します。ソース・データベースでは、order_id列はorders表の主キーであり、order_items表のorder_id列は、orders表の主キー列と一致する外部キーです。接続先データベースでは、これらの制約は削除されています。次のプロシージャを実行して、接続先データベースで、これらの表の列の関係を適用プロセスに通知する値依存性を作成します。
BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name => 'order_id_foreign_key',
object_name => 'oe.orders',
attribute_list => 'order_id');
END;
/
BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name => 'order_id_foreign_key',
object_name => 'oe.order_items',
attribute_list => 'order_id');
END;
/
また、この環境では、適用プロセスが一貫してトランザクションを適用できるように、次の操作を実行する必要もあります。
ソース・データベースで一意キーおよびビットマップ索引を含む各列に値依存性を設定します。
DBMS_APPLY_ADM.SET_KEY_COLUMNSプロシージャを実行して、ソース・データベースで主キー列である列の代替キー列を設定します。
以前に設定した値依存性を設定解除するには、次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.SET_VALUE_DEPENDENCY(
dependency_name => 'order_id_foreign_key',
object_name => NULL,
attribute_list => NULL);
END;
/
オブジェクト依存性を作成または削除するには、DBMS_APPLY_ADMパッケージのCREATE_OBJECT_DEPENDENCYおよびDROP_OBJECT_DEPENDENCYプロシージャを使用します。ここでは、オブジェクト依存性を作成および削除する詳細な手順を示します。
オブジェクト依存性は、特定の表の行LCRが常に他の表の行LCRより前に適用される必要があり、接続先データベースのデータ・ディクショナリにこの関係を持たせる制約が含まれていない場合に使用できます。オブジェクト依存性を定義する場合、最初に適用される必要がある行LCRを含む表が親表であり、2番目に適用される必要がある行LCRを含む表が子表です。
たとえば、次の特性を持つOracle Streamsレプリケーション環境を考えます。
ordスキーマ内の次の表は、ソース・データベースと接続先データベースで共有されます。
customers表には、顧客の発送住所などの顧客の情報が含まれます。
orders表には、各注文の情報が含まれます。
order_items表には、各注文で注文されたアイテムの情報が含まれます。
ship_orders表には、発送の準備が完了した注文の情報は含まれていますが、顧客の詳細情報または各注文で発送される個々のアイテムの情報は含まれていません。
ship_orders表には、制約によって定義された、他の表との関係はありません。
注文の情報はソース・データベースに入力され、接続先データベースに伝播されて適用されます。
接続先データベースのサイトは、注文が顧客に発送されるウェアハウスです。このサイトで、DMLハンドラはship_orders、customers、ordersおよびorder_items表の情報を使用して、顧客の発送住所および発送アイテムを含むレポートを生成します。
DMLハンドラによって生成されたレポートの情報は、発送注文記録が作成される時刻まで一貫性がある必要があります。接続先データベースのオブジェクト依存性によって、この目的が達成されます。この場合、ship_orders表は、子表customers、ordersおよびorder_itemsの親表です。ship_ordersがこれらの表の親であるため、ship_orders表の記録が入力された後にこれらの表に対して行われた変更は、DMLハンドラが発送注文のレポートを作成するまで適用されません。
これらのオブジェクト依存性を作成するには、接続先データベースで次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY(
object_name => 'ord.customers',
parent_object_name => 'ord.ship_orders');
END;
/
BEGIN
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY(
object_name => 'ord.orders',
parent_object_name => 'ord.ship_orders');
END;
/
BEGIN
DBMS_APPLY_ADM.CREATE_OBJECT_DEPENDENCY(
object_name => 'ord.order_items',
parent_object_name => 'ord.ship_orders');
END;
/
「オブジェクト依存性の作成」で作成したオブジェクト依存性を削除するには、次のプロシージャを実行します。
BEGIN
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY(
object_name => 'ord.customers',
parent_object_name => 'ord.ship_orders');
END;
/
BEGIN
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY(
object_name => 'ord.orders',
parent_object_name => 'ord.ship_orders');
END;
/
BEGIN
DBMS_APPLY_ADM.DROP_OBJECT_DEPENDENCY(
object_name => 'ord.order_items',
parent_object_name => 'ord.ship_orders');
END;
/
この項では、次のタスクについて説明します。
更新の競合ハンドラを設定するには、DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを使用します。更新の競合解消ハンドラを作成する場合は、次のいずれかの事前作成方法を使用できます。
OVERWRITE
DISCARD
MAXIMUM
MINIMUM
たとえば、Oracle Streams環境のdbs1.netでhr.jobs表に対する変更を取得して、dbs2.net接続先データベースに伝播し、そこで適用する場合を考えます。この環境の場合、アプリケーションでは両方のデータベースのhr.jobs表に対してDML変更を実行できますが、特定のDML変更に競合がある場合は、dbs1.netデータベースでの変更でdbs2.netデータベースでの変更を常に上書きする必要があります。この環境では、dbs2.netデータベースでOVERWRITEハンドラを指定して、この目標を達成できます。
dbs2.netデータベースでhrスキーマ内のhr.jobs表について更新の競合ハンドラを指定するには、dbs2.netで次のプロシージャを実行します。
DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'job_title';
cols(2) := 'min_salary';
cols(3) := 'max_salary';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name => 'hr.jobs',
method_name => 'OVERWRITE',
resolution_column => 'job_title',
column_list => cols);
END;
/
データベース上で実行中の、指定の表に変更を適用するすべての適用プロセスでは、指定した更新の競合ハンドラがローカルに使用されます。
|
注意:
|
DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを実行すると、既存の更新の競合ハンドラを変更できます。既存の競合ハンドラを更新するには、そのハンドラと同じ表および解消列を指定します。
「更新の競合ハンドラの設定」で作成した更新の競合ハンドラを変更するには、hr.jobs表および解消列としてのjob_title列を指定します。この更新の競合ハンドラを変更するには、異なるタイプの事前作成方法または異なる列リスト、あるいはその両方を指定できます。ただし、更新の競合ハンドラの解消列を変更する場合は、ハンドラを削除して再作成する必要があります。
たとえば、環境に変更があり、競合が発生した場合にdbs1.netからの変更を廃棄する必要があるが、dbs1.netからの以前の変更によってdbs2.netの変更が上書きされている場合を考えます。dbs2.netデータベースでDISCARDハンドラを指定すると、この目標を達成できます。
dbs2.netデータベースでhrスキーマ内のhr.jobs表について既存の更新の競合ハンドラを変更するには、次のプロシージャを実行します。
DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'job_title';
cols(2) := 'min_salary';
cols(3) := 'max_salary';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name => 'hr.jobs',
method_name => 'DISCARD',
resolution_column => 'job_title',
column_list => cols);
END;
/
DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを実行すると、既存の更新の競合ハンドラを削除できます。既存の競合ハンドラを削除するには、メソッドにNULLを指定し、その競合ハンドラと同じ表、列リストおよび解消列を指定します。
たとえば、「更新の競合ハンドラの設定」で作成し、「既存の更新の競合ハンドラの変更」で変更した更新の競合ハンドラを削除する必要があるとします。この更新の競合ハンドラを削除するには、次のプロシージャを実行します。
DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'job_title';
cols(2) := 'min_salary';
cols(3) := 'max_salary';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name => 'hr.jobs',
method_name => NULL,
resolution_column => 'job_title',
column_list => cols);
END;
/
DBMS_APPLY_ADMパッケージのCOMPARE_OLD_VALUESプロシージャを使用すると、非キー列の競合検出を停止できます。
たとえば、hr.employees表の競合解消用にtime列を構成すると想定します（「MAXIMUM」を参照）。この場合、表の他の非キー列の競合検出を停止するように指定できます。これを行うには、time列を追加してトリガーを作成した後（前述の項を参照）、hr.employees表の列を更新の競合ハンドラの列リストに追加します。
DECLARE
cols DBMS_UTILITY.NAME_ARRAY;
BEGIN
cols(1) := 'first_name';
cols(2) := 'last_name';
cols(3) := 'email';
cols(4) := 'phone_number';
cols(5) := 'hire_date';
cols(6) := 'job_id';
cols(7) := 'salary';
cols(8) := 'commission_pct';
cols(9) := 'manager_id';
cols(10) := 'department_id';
cols(11) := 'time';
DBMS_APPLY_ADM.SET_UPDATE_CONFLICT_HANDLER(
object_name => 'hr.employees',
method_name => 'MAXIMUM',
resolution_column => 'time',
column_list => cols);
END;
/
この例では、主キーに更新がないことを想定しているため、列リストに表の主キーは含まれていません。ただし、他のキー列は列リストに含まれています。
接続先データベースでUPDATEおよびDELETE操作の両方を行う表のすべての非キー列について、競合検出を停止するには、次のプロシージャを実行します。
DECLARE
cols DBMS_UTILITY.LNAME_ARRAY;
BEGIN
cols(1) := 'first_name';
cols(2) := 'last_name';
cols(3) := 'email';
cols(4) := 'phone_number';
cols(5) := 'hire_date';
cols(6) := 'job_id';
cols(7) := 'salary';
cols(8) := 'commission_pct';
DBMS_APPLY_ADM.COMPARE_OLD_VALUES(
object_name => 'hr.employees',
column_table => cols,
operation => '*',
compare => FALSE);
END;
/
operationパラメータのアスタリスク（*）は、UPDATEおよびDELETE操作の両方について競合検出が停止されたことを意味します。このプロシージャを実行すると、データベース上で実行中の、指定の表に変更をローカルに適用するすべての適用プロセスでは、指定した列の競合は検出されません。したがって、この例では、time列のみが競合検出に使用されます。
|
注意: この項の例では、更新の競合ハンドラを設定してから、非キー列の競合検出を停止しています。ただし、非キー列の競合検出を停止する前に、更新の競合ハンドラは必要ありません。 |
|
参照:
|
現行セッションまたは適用プロセスによって生成されるタグの値を設定または取得できます。ここでは、タグ値の設定方法と取得方法について説明します。
この項では、現行セッション用のタグを設定する手順と取得する手順について説明します。
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接続先の分割およびマージは、次の場合に役立ちます。
取得プロセスで、複数の接続先データベースに送信される変更を取得する場合。
宛先キューが、取得プロセスによって取得された、伝播される変更の受入れを停止した場合。たとえば、宛先キューは、キューが含まれているデータベースが停止した場合、宛先キューで問題が発生した場合、キューが含まれているデータベースを実行しているコンピュータ・システムが停止した場合、または他のなんらかの理由によって、変更の受入れを停止する場合があります。
この場合、取得されても宛先キューに送信できない変更はソース・キューに残り、ソース・キューのサイズが増加します。最終的に、ソース・キューの取得LCRはハード・ディスクにオーバーフローし、Oracle Streamsレプリケーション環境のパフォーマンスが低下します。
図9-1に、宛先で問題が発生したOracle Streamsレプリケーション環境を示します。接続先データベースAが停止し、接続先データベースAに対するメッセージが取得データベースのキューに蓄積されています。
次のデータ・ディクショナリ・ビューを使用すると、伝播で問題が発生しているかどうかを判別できます。
V$BUFFERED_QUEUESビューを問い合せて、バッファ・キュー内のメッセージの数およびハード・ディスクにオーバーフローしたメッセージの数を確認します。
DBA_PROPAGATIONおよびV$PROPAGATION_SENDERビューを問い合せて、データベース内の伝播および各伝播の状態を確認します。
このような状況でのパフォーマンスの低下を回避するには、DBMS_STREAMS_ADMパッケージのSPLIT_STREAMS、MERGE_STREAMS_JOBおよびMERGE_STREAMSプロシージャを使用します。SPLIT_STREAMSプロシージャは、問題が発生している伝播宛先に対するストリームを、取得プロセスから他の宛先に送信されている他のすべてのストリームから分割します。また、SPLIT_STREAMSプロシージャは、取得プロセス、キューおよび伝播をクローニングします。クローニングされたこれらのコンポーネントは、分割されたストリームで使用されます。変更を伝播できないストリームは分割されますが、他の宛先に対するストリームは、通常どおり続行されます。
図9-2に、SPLIT_STREAMSプロシージャによって作成される、クローニングされたストリームを示します。
問題が発生した宛先が再度使用可能になったら、クローニングされた取得プロセスを起動します。これによって、クローニングされたストリームが、接続先データベースへのメッセージの送信を再開します。
図9-3に、起動されて実行されている接続先データベースA、および取得データベースで有効になっているクローニングされた取得プロセスを示します。クローニングされたストリームの送信が開始され、元のストリームに対する遅延の回復が開始されます。
図9-3 クローニングされたストリームの送信開始および元のOracle Streamsに対する遅延の回復
クローニングされた伝播が元のいずれかの伝播に対する遅延を回復したら、次のいずれかのプロシージャを実行して、これらのストリームをマージできます。
MERGE_STREAMSプロシージャ: 分割されたストリームを、元の取得プロセスから送信されている他のストリームとマージします。
MERGE_STREAMS_JOBプロシージャ: ストリームがユーザー指定マージしきい値の範囲内かどうかを判別します。ストリームがマージしきい値の範囲内の場合、MERGE_STREAMS_JOBプロシージャはMERGE_STREAMSプロシージャを実行します。ストリームがマージしきい値の範囲外の場合、MERGE_STREAMS_JOBプロシージャは何も実行しません。
MERGE_STREAMS_JOBプロシージャは、ストリームをマージする前にそれらのストリームをマージする準備が整っているかどうかを確認するため、通常は、MERGE_STREAMSプロシージャを直接実行するのではなく、MERGE_STREAMS_JOBプロシージャを実行することをお薦めします。
図9-4に、MERGE_STREAMSプロシージャの実行結果を示します。Oracle Streamsレプリケーション環境に元のコンポーネントが存在し、すべてのストリームが正常に送信されています。
SPLIT_STREAMSプロシージャでストリームを分割した場合、auto_merge_thresholdパラメータを使用すると、宛先の問題が解決されたときに、ストリームを元の取得プロセスと自動的にマージできます。クローニングされた伝播の宛先キューでメッセージの受入れが開始されたら、クローニングされた取得プロセスを起動して、クローニングされた取得プロセスが元の取得プロセスに対する遅延を回復するまで待機できます。クローニングされた取得プロセスがほぼ遅延を回復したら、auto_merge_thresholdパラメータ設定によって、分割されたストリームが自動的にマージされるか、手動でマージされるかが決定されます。
auto_merge_thresholdが正数に設定されている場合、SPLIT_STREAMSプロシージャは、スケジュールが設定されたOracle Schedulerジョブを作成します。このジョブによって、MERGE_STREAMS_JOBプロシージャが実行され、auto_merge_thresholdパラメータに指定された値と等しいマージしきい値が指定されます。ジョブは、作成後にそのスケジュールを変更することができます。
この場合、クローニングされた取得プロセスと元の取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEの差（秒単位）が、auto_merge_thresholdパラメータに指定された値以下であれば、分割されたストリームは元のストリームと自動的にマージされます。CAPTURE_MESSAGE_CREATE_TIMEは、取得された変更がREDOログに記録された時間を記録します。
auto_merge_thresholdがNULLまたは0（ゼロ）に設定されている場合、分割されたストリームは元のストリームと自動的にマージされません。分割されたストリームを元のストリームとマージするには、MERGE_STREAMS_JOBまたはMERGE_STREAMSプロシージャを手動で実行します。
SPLIT_STREAMSおよびMERGE_STREAMSプロシージャは、アクションを直接実行するか、またはアクションを実行するスクリプトを生成してスクリプトの実行時にアクションを実行できます。スクリプトを実行するよりプロシージャを使用してアクションを直接実行する方が簡単で、分割操作またはマージ操作が即時に実行されます。ただし、次の理由でスクリプトを生成することもあります。
ストリームを分割またはマージする前にプロシージャによって実行されるアクションを確認する必要がある。
アクションをカスタマイズするためにスクリプトを変更する必要がある。
たとえば、クローニングされた取得プロセスのルール・セットのルールを変更する場合、スクリプトを変更することがあります。Oracle Streamsレプリケーション環境によっては、ソース・データベースに対して行われた変更のサブセットのみが各接続先データベースに送信され、各接続先データベースが異なる変更のサブセットを受信する場合があります。このような環境では、クローニングされた伝播によって伝播される変更のみを取得するように、クローニングされた取得プロセスのルール・セットを変更できます。
各プロシージャのperform_actionsパラメータは、プロシージャでアクションを直接実行するかどうかを制御します。
この項のいずれかのプロシージャを実行する際にストリームを直接分割またはマージする場合は、perform_actionsパラメータをTRUEに設定します。このパラメータのデフォルト値はTRUEです。
この項のいずれかのプロシージャを実行する際にスクリプトを生成する場合は、perform_actionsパラメータをFALSEに設定し、script_nameおよびscript_directory_objectパラメータを使用してスクリプトの名前と格納場所を指定します。
次の項では、ストリームを分割およびマージする手順について説明します。
いずれの例も、Oracle Streamsレプリケーション環境に次の特性があります。
1つの取得プロセスstrms_captureで、3つの接続先データベースに送信される変更を取得します。
接続先データベースの宛先キューに変更を送信する伝播は、次のとおりです。
strms_prop_a
strms_prop_b
strms_prop_c
キューstreams_queueが、3つすべての伝播のソース・キューです。
strms_prop_a伝播の宛先に問題が発生しています。この伝播は、メッセージを宛先キューに送信できません。また、保持されているメッセージによって、ソース・キューstreams_queueのサイズが増加しています。
他の2つの伝播（strms_prop_bおよびstrms_prop_c）は、メッセージを正常に伝播しています。
|
参照: SPLIT_STREAMSプロシージャおよびMERGE_STREAMSプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
この項の例では、ストリームを直接分割およびマージします。そのため、SPLIT_STREAMSプロシージャのperform_actionsパラメータはTRUEに設定されています。また、この例では、ストリームを適切なタイミングで自動的にマージします。そのため、SPLIT_STREAMSプロシージャのauto_merge_thresholdパラメータは正数（60）に設定されています。
次の手順を実行して、ストリームを直接分割し、自動的にマージします。
SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
次のプロシージャを実行して、伝播strms_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播から分割します。
DECLARE
schedule_name VARCHAR2(30);
job_name VARCHAR2(30);
BEGIN
schedule_name := 'merge_job1_schedule';
job_name := 'merge_job1';
DBMS_STREAMS_ADM.SPLIT_STREAMS(
propagation_name => 'strms_prop_a',
cloned_propagation_name => 'cloned_prop_a',
cloned_queue_name => 'cloned_queue',
cloned_capture_name => 'cloned_capture',
perform_actions => TRUE,
auto_merge_threshold => 60,
schedule_name => schedule_name,
merge_job_name => job_name);
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
新しいキューcloned_queueが作成されます。
cloned_queueキューからstrms_prop_a伝播によって使用されている既存の宛先キューにメッセージを伝播する新しい伝播cloned_prop_aが作成されます。クローニングされた伝播cloned_prop_aでは、元の伝播strms_prop_aと同じルール・セットが使用されます。
取得プロセスstrms_captureが停止されます。
元の伝播strms_prop_aの確認済SCNが問い合されます。確認済SCNとは、伝播によって送信された変更を適用する適用プロセスによって最後に確認されたSCNです。伝播の確認済SCNは、DBA_PROPAGATIONビューのACKED_SCN値に示されます。
新しい取得プロセスcloned_captureが作成されます。cloned_captureの開始SCNは、strms_prop_a伝播の確認済SCNの値に設定されます。クローニングされた取得プロセスcloned_captureでは、元の取得プロセスstrms_captureと同じルール・セットが使用されます。
元の伝播strms_prop_aが削除されます。
開始SCNがstrms_prop_a伝播の確認済SCNの値に設定された、元の取得プロセスstrms_captureが起動されます。
スケジュールmerge_job1_scheduleが設定されたOracle Schedulerジョブmerge_job1が作成されます。ジョブとスケジュールは両方とも、SPLIT_STREAMSプロシージャを実行したユーザーによって所有されます。このスケジュールは、SPLIT_STREAMSプロシージャが完了すると実行が開始されます。初期スケジュールは、システムによって定義されますが、他のOracle Schedulerジョブを変更する場合と同じ方法で変更できます。手順については、『Oracle Database管理者ガイド』を参照してください。
cloned_prop_aの宛先で発生した問題を解決します。伝播されたメッセージがcloned_prop_aの宛先キューで受け入れられ、それらのメッセージを接続先データベースの適用プロセスでデキューして処理できるようになったら、問題は解決しています。
Oracle Streams管理者として接続したまま、次のプロシージャを実行して、クローニングされた取得プロセスを起動します。
exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');
クローニングされた取得プロセスcloned_captureの実行が開始されると、ルール・セットを満たす、確認済SCN以降の変更が取得されます。これらの変更は、cloned_prop_a伝播によって伝播され、接続先データベースの適用プロセスによって処理されます。
この場合、Oracle Schedulerジョブは、スケジュールに従ってMERGE_STREAMS_JOBプロシージャを実行します。クローニングされた取得プロセスcloned_captureと元の取得プロセスstrms_captureのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEの差が60秒以下であれば、MERGE_STREAMS_JOBプロシージャによって、ストリームをマージする準備ができていると判断されます。MERGE_STREAMS_JOBプロシージャは、MERGE_STREAMSプロシージャを自動的に実行してストリームをマージします。
MERGE_STREAMSプロシージャを実行すると、次のアクションが実行されます。
クローニングされた取得プロセスcloned_captureが停止されます。
元の取得プロセスstrms_captureが停止されます。
伝播strms_prop_aが再作成されます。この伝播では、streams_queueキューからcloned_prop_a伝播によって使用されている既存の宛先キューにメッセージが伝播されます。再作成された伝播strms_prop_aでは、クローニングされた伝播cloned_prop_aと同じルール・セットが使用されます。
元の取得プロセスstrms_captureが、次の2つのSCN値のうちで小さい方のSCN値から起動されます。
クローニングされた伝播cloned_prop_aの確認済SCN
元の取得プロセスによって取得された変更を伝播する他の伝播（この例では伝播strms_prop_bおよびstrms_prop_c）の最も小さい確認済SCN
strms_capture取得プロセスが起動されると、このプロセスによって取得済の変更が再取得されたり、クローニングされた取得プロセスcloned_captureによって取得済の変更が取得される場合があります。いずれの場合も、関連する適用プロセスによって、重複して受信した変更が破棄されます。
クローニングされた伝播cloned_prop_aが削除されます。
クローニングされた取得プロセスcloned_captureが削除されます。
クローニングされたキューcloned_queueが削除されます。
ストリームがマージされた後は、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。
この項の例では、スクリプトを生成して実行し、ストリームを分割およびマージします。そのため、SPLIT_STREAMSプロシージャのperform_actionsパラメータは、FALSEに設定されています。また、この例では、ストリームを適切なタイミングで手動でマージします。そのため、SPLIT_STREAMSプロシージャのauto_merge_thresholdパラメータは、NULLに設定されています。
次の手順を実行して、スクリプトを使用し、ストリームを分割およびマージします。
SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
ディレクトリ・オブジェクトdb_dirが存在しない場合は、プロシージャによって生成されるスクリプトを保持できるようにこのディレクトリ・オブジェクトを作成します。
CREATE DIRECTORY db_dir AS '/usr/db_files';
次のプロシージャを実行して、ストリームを分割するスクリプトを生成します。
DECLARE
schedule_name VARCHAR2(30);
job_name VARCHAR2(30);
BEGIN
DBMS_STREAMS_ADM.SPLIT_STREAMS(
propagation_name => 'strms_prop_a',
cloned_propagation_name => 'cloned_prop_a',
cloned_queue_name => 'cloned_queue',
cloned_capture_name => 'cloned_capture',
perform_actions => FALSE,
script_name => 'split.sql',
script_directory_object => 'db_dir',
auto_merge_threshold => NULL,
schedule_name => schedule_name,
merge_job_name => job_name);
END;
/
このプロシージャを実行すると、split.sqlスクリプトが生成されます。このスクリプトには、伝播strms_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播から分割するアクションが含まれています。
db_dirディレクトリ・オブジェクトによって使用されるディレクトリに移動して、テキスト・エディタでsplit.sqlスクリプトをオープンします。
スクリプトを確認し、必要に応じて変更します。
スクリプトを保存してクローズします。
Oracle Streams管理者としてSQL*Plusに接続したままで、スクリプトを実行します。
@/usr/db_files/split.sql
このスクリプトを実行すると、次のアクションが実行されます。
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャが実行され、新しいキューcloned_queueが作成されます。
DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャが実行され、新しい伝播cloned_prop_aが作成されます。この新しい伝播では、cloned_queueキューからstrms_prop_a伝播によって使用されている既存の宛先キューにメッセージが伝播されます。クローニングされた伝播cloned_prop_aでは、元の伝播strms_prop_aと同じルール・セットが使用されます。
CREATE_PROPAGATIONプロシージャによって、original_propagation_nameパラメータがstrms_prop_aに、auto_merge_thresholdパラメータがNULLに設定されます。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、取得プロセスstrms_captureが停止されます。
元の伝播strms_prop_aの確認済SCNが問い合されます。確認済SCNとは、伝播によって送信された変更を適用する適用プロセスによって最後に確認されたSCNです。伝播の確認済SCNは、DBA_PROPAGATIONビューのACKED_SCN値に示されます。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャが実行され、新しい取得プロセスcloned_captureが作成されます。cloned_captureの開始SCNは、strms_prop_a伝播の確認済SCNの値に設定されます。クローニングされた取得プロセスcloned_captureでは、元の取得プロセスstrms_captureと同じルール・セットが使用されます。
DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャが実行され、元の伝播strms_prop_aが削除されます。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャが実行され、開始SCNがstrms_prop_a伝播の確認済SCNの値に設定された、元の取得プロセスstrms_captureが起動されます。
cloned_prop_aの宛先で発生した問題を解決します。伝播されたメッセージがcloned_prop_aの宛先キューで受け入れられ、それらのメッセージを接続先データベースの適用プロセスでデキューして処理できるようになったら、問題は解決しています。
Oracle Streams管理者として接続したまま、次のプロシージャを実行して、クローニングされた取得プロセスを起動します。
exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');
クローニングされた取得プロセスが元の取得プロセスに対する遅延を回復する（またはほぼ回復する）まで、Oracle Streamsレプリケーション環境を監視します。具体的には、各取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATION_TIME列を問い合せます。
次の問合せを実行して、各取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEを定期的に確認します。
SELECT CAPTURE_NAME,
TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY')
FROM GV$STREAMS_CAPTURE;
クローニングされた取得プロセスcloned_captureと元の取得プロセスstrms_captureのCAPTURE_MESSAGE_CREATE_TIMEの差が比較的小さくなるまで、次の手順には進まないでください。
次のプロシージャを実行して、ストリームをマージするスクリプトを生成します。
BEGIN
DBMS_STREAMS_ADM.MERGE_STREAMS(
cloned_propagation_name => 'cloned_prop_a',
perform_actions => FALSE,
script_name => 'merge.sql',
script_directory_object => 'db_dir');
END;
/
このプロシージャを実行すると、merge.sqlスクリプトが生成されます。このスクリプトには、伝播cloned_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播とマージするアクションが含まれています。
db_dirディレクトリ・オブジェクトによって使用されるディレクトリに移動して、テキスト・エディタでmerge.sqlスクリプトをオープンします。
スクリプトを確認し、必要に応じて変更します。
スクリプトを保存してクローズします。
Oracle Streams管理者としてSQL*Plusに接続したままで、スクリプトを実行します。
@/usr/db_files/merge.sql
このスクリプトを実行すると、次のアクションが実行されます。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、クローニングされた取得プロセスcloned_captureが停止されます。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、元の取得プロセスstrms_captureが停止されます。
DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャが実行され、伝播strms_prop_aが再作成されます。この伝播では、streams_queueキューからcloned_prop_a伝播によって使用されている既存の宛先キューにメッセージが伝播されます。再作成された伝播strms_prop_aでは、クローニングされた伝播cloned_prop_aと同じルール・セットが使用されます。
元の取得プロセスstrms_captureが、次の2つのSCN値のうちで小さい方のSCN値から起動されます。
クローニングされた伝播cloned_prop_aの確認済SCN
元の取得プロセスによって取得された変更を伝播する他の伝播（この例では伝播strms_prop_bおよびstrms_prop_c）の最も小さい確認済SCN
strms_capture取得プロセスが起動されると、このプロセスによって取得済の変更が再取得されたり、クローニングされた取得プロセスcloned_captureによって取得済の変更が取得される場合があります。いずれの場合も、関連する適用プロセスによって、重複して受信した変更が破棄されます。
DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャが実行され、クローニングされた伝播cloned_prop_aが削除されます。
DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャが実行され、クローニングされた取得プロセスcloned_captureが削除されます。
DBMS_STREAMS_ADMパッケージのREMOVE_QUEUEプロシージャが実行され、クローニングされたキューcloned_queueが削除されます。
スクリプトが正常に実行された後は、ストリームがマージされ、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。
通常、あるデータベースが別のデータベースのクローンである場合、データベース管理者はそのデータベースのDBIDおよびグローバル名を変更します。V$DATABASE動的パフォーマンス・ビューでDBID列を問い合せると、データベースのDBIDを確認できます。また、GLOBAL_NAME静的データ・ディクショナリ・ビューを問い合せると、データベースのグローバル名を確認できます。ソース・データベースのDBIDまたはグローバル名を変更すると、そのソース・データベースで発生した変更を取得する既存の取得プロセスは使用不可になります。ソース・データベースで発生した変更を取得する取得プロセスは、ローカルの取得プロセスまたはダウンストリームの取得プロセスである場合があります。ソース・データベースの変更を適用する既存の適用プロセスも、使用不可になります。ただし、伝播ルールを変更する必要がある可能性はありますが、既存の同期取得および伝播を再作成する必要はありません。
DBIDまたはグローバル名を変更したソース・データベースに対する変更を取得プロセスまたは同期取得で取得している場合は、次の手順を実行します。
ソース・データベースを停止します。
STARTUP RESTRICTを使用し、RESTRICTED SESSIONを有効化してソース・データベースを再起動します。
DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを使用して、取得プロセスを削除します。取得プロセスは、ソース・データベースのローカルの取得プロセスか、またはリモート・データベースのダウンストリームの取得プロセスである場合があります。同期取得を削除する必要はありません。
ソース・データベースでALTER SYSTEM SWITCH LOGFILE文を実行します。
ソース・データベースですでに変更が取得されている場合は、このソース・データベースで発生した変更を適用するすべての接続先データベースで、データを手動で再同期化します。まだデータベースで変更が取得されていない場合は、この手順は不要です。
ソース・データベース名を条件として使用しているルールを変更します。必要に応じて、これらのルールでソース・データベース名をソース・データベースの新しいグローバル名に変更します。環境内のローカル・データベースおよびリモート・データベースで、取得プロセス、伝播および適用プロセスのルールを変更する必要がある場合があります。通常、同期取得ルールには、ソース・データベースの条件は含まれていません。
手順3で削除した取得プロセスからの変更を適用する適用プロセスを削除します。適用プロセスを削除するには、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを使用します。同期取得で取得した変更を適用する適用プロセスは、削除する必要はありません。
ソース・データベースの変更を適用する接続先データベースごとに、手順7で削除した適用プロセスを再作成します。各適用プロセスを、削除される前と同じルール・セットに関連付ける必要がある場合があります。 手順については、「取得LCRを適用する適用プロセスの作成」を参照してください。
必要に応じて、手順3で削除した取得プロセスを再作成します。取得プロセスを、手順3で削除した取得プロセスと同じルール・セットに関連付ける必要がある場合があります。 手順については、「取得プロセスの作成」を参照してください。
ソース・データベースで、再作成した取得プロセスによって変更が取得されるデータベース・オブジェクトについて、インスタンス化の準備を行います。「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。
ソース・データベースの変更を適用する接続先データベースごとに、ソース・データベースの変更を適用するすべてのデータベース・オブジェクトについて、インスタンス化SCNを設定します。手順については、「接続先データベースでのインスタンス化SCNの設定」を参照してください。
ALTER SYSTEM DISABLE RESTRICTED SESSION文を使用し、RESTRICTED SESSIONを無効化します。
ソース・データベースの変更を適用する接続先データベースごとに、手順8で作成した適用プロセスを起動します。
ソース・データベースで、手順9で作成した取得プロセスを起動します。
|
参照: DBNEWIDユーティリティを使用してデータベースのDBIDを変更する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソース環境のソース・データベースを現在の時点までリカバリできない場合、この項で説明する方法を使用して、そのソース・データベースを環境内の他のソース・データベースと再同期化できます。データベースを現在の時点までリカバリできない理由には、アーカイブREDOログの破損や、オンラインREDOログ・グループのメディア障害などがあります。
たとえば、ある両方向のOracle Streams環境で、2つのデータベースが、レプリケートされたデータベース・オブジェクトおよびデータを共有していると想定します。この例では、再同期化する必要のあるデータベースをデータベースA、環境内の他のソース・データベースをデータベースBとします。この両方向のOracle Streams環境内のデータベースAを再同期化するには、次の手順を実行します。
データベースBがデータベースAから送信されたすべての変更を適用しているかどうか検証します。データベースBでV$BUFFERED_SUBSCRIBERSデータ・ディクショナリ・ビューを問い合せると、これらの変更を適用する適用プロセスのキュー内に適用されていない変更があるかどうかを判別できます。このような問合せの例については、『Oracle Streams概要および管理』の「各バッファ・キューからLCRをデキューする伝播の表示」の例を参照してください。すべての変更が適用されたら、次の手順に進みます。
DBMS_STREAMS_ADMパッケージのREMOVE_STREAMS_CONFIGURATIONプロシージャを実行して、データベースAからOracle Streams構成を削除します。このプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
データベースBで、データベースAの変更を適用する適用プロセスを削除します。後の手順で適用プロセスを再作成するため、この適用プロセスで使用されているルール・セットは削除しないでください。
「既存の複数ソース環境への新規データベースの追加」の手順を完了し、Oracle Streams環境内にデータベースAを再度追加します。
Point-in-Timeリカバリとは、指定した現在以外の時刻、SCNまたはログ順序番号までデータベースをリカバリすることです。ここでは、Oracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する方法について説明します。
|
参照: Point-in-Timeリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
単一ソースのOracle Streamsレプリケーション環境とは、共有データのソース・データベースが1つのみの環境です。単一ソースのOracle Streams環境のソース・データベースでデータベースのPoint-in-Timeリカバリが必要であり、ソース・データベースで生成される変更を取得するすべての取得プロセスが実行されている場合は、これらの取得プロセスを停止してから、リカバリ操作を実行する必要があります。ソース・データベースで生成される変更を取得するローカルの取得プロセス、およびダウンストリームの取得プロセスの両方を停止する必要があります。通常、データベース管理者は、Point-in-Timeリカバリ中にデータベースのログ順序番号をリセットします。ALTER DATABASE OPEN RESETLOGS文は、ログ順序番号をリセットする文の一例です。
この項の手順では、次の特性を持つ単一ソース・レプリケーション環境を想定しています。
ローカル取得プロセスまたはダウンストリーム取得プロセスである取得プロセスstrm01_captureが1つのみ存在します。
グローバル名dest.netを持つ接続先データベースが1つのみ存在します。
接続先データベースに、適用プロセスstrm01_applyが1つのみ存在します。
ソース・データベースでPoint-in-Timeリカバリを実行する必要がある場合、接続先データベースで適用されるトランザクションを使用してこの項の手順を実行すると、ソース・データベースでできるかぎり多くのトランザクションをリカバリできます。この項の手順では、ソースのPoint-in-Time SCNより後に接続先データベースで適用されたトランザクションを識別し、ソース・データベースでそれらのトランザクションを実行することを想定しています。
|
注意: 単一ソースのOracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する場合は、適用プロセス・パラメータCOMMIT_SERIALIZATIONをFULLに設定することをお薦めします。 |
単一ソースのOracle Streamsレプリケーション環境のソース・データベースでPoint-in-Timeリカバリを実行するには、次の手順を実行します。
ソース・データベースでPoint-in-Timeリカバリを実行します（実行済でない場合）。後の手順で必要になるため、Point-in-TimeリカバリSCNをメモします。
ソース・データベースが制限付きモードになっていることを確認します。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して、取得プロセスを停止します。
ソース・データベースで、データ・ディクショナリの構築を実行します。
SET SERVEROUTPUT ON
DECLARE
scn NUMBER;
BEGIN
DBMS_CAPTURE_ADM.BUILD(
first_scn => scn);
DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/
手順13で必要になるため、戻されたSCN値をメモします。
接続先データベースで、適用プロセスのキューに含まれるソース・データベースからのすべてのトランザクションが適用されるまで待機します。これらのトランザクションが適用されると、適用プロセスはアイドル状態になります。V$STREAMS_APPLY_READERおよびV$STREAMS_APPLY_SERVERの両方で、STATE列を問い合せることができます。両方のビューで適用プロセスの状態がIDLEになってから、次の手順に進む必要があります。
接続先データベースで問合せを実行して、適用されたトランザクションの最大SCNを判断します。
適用プロセスが実行中の場合は、次の問合せを実行します。
SELECT HWM_MESSAGE_NUMBER FROM V$STREAMS_APPLY_COORDINATOR WHERE APPLY_NAME = 'STRM01_APPLY';
適用プロセスが無効化されている場合は、次の問合せを実行します。
SELECT APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS WHERE APPLY_NAME = 'STRM01_APPLY';
後の手順で必要になるため、問合せで戻される最大適用SCNをメモします。
手順6で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCNより小さい場合、手順8に進みます。手順6で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCN以上である場合、適用プロセスは、Point-in-TimeリカバリSCNの後で、ソース・データベースからのいくつかのトランザクションを適用しています。この場合は、次の手順を実行します。
ソース・データベースで、Point-in-Time SCNの後に適用されたトランザクションを手動で実行します。これらのトランザクションをソース・データベースで実行する場合は、トランザクションが取得プロセスによって取得されないようにセッションのOracle Streamsタグを設定していることを確認します。Oracle Streamsセッション・タグが設定されていないと、これらの変更が接続先データベースに循環される場合があります。手順については、「現行セッションのOracle Streamsタグの管理」を参照してください。
ソース・データベースで、制限付きセッションを無効化します。
手順7を完了している場合、手順12に進みます。手順6で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCNより小さい場合、適用プロセスは、Point-in-TimeリカバリSCNの後で、ソース・データベースからのどのトランザクションも適用していません。この場合は、次の手順で操作します。
ソース・データベースで、制限付きセッションを無効化します。
接続先データベースで適用プロセスが実行中であることを確認します。
DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを使用して、元の取得プロセスのmaximum_scn取得プロセス・パラメータを、Point-in-TimeリカバリSCNに設定します。
元の取得プロセスの開始SCNを、適用プロセスの最も古いSCNに設定します。実行中の適用プロセスの最も古いSCNを判断するには、接続先データベースで、V$STREAMS_APPLY_READER動的パフォーマンス・ビューのOLDEST_SCN_NUM列を問い合せます。取得プロセスの開始SCNを設定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを実行する際にstart_scnパラメータを指定します。
次のプロシージャを実行して、取得プロセスがアラート・ログに情報を書き込むことを確認します。
BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'strm01_capture',
parameter => 'write_alert_log',
value => 'Y');
END;
/
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、元の取得プロセスを起動します。
DBA_CAPTUREデータ・ディクショナリ・ビューのCAPTURED_SCN列を問い合せて、元の取得プロセスがmaximum_scn設定値までのすべての変更を取得していることを確認します。問合せで戻される値がmaximum_scn値以上である場合、取得プロセスは自動的に停止します。取得プロセスが停止したら、次の手順に進みます。
アラート・ログでLAST_ENQUEUE_MESSAGE_NUMBERの値を検索します。後の手順で必要になるため、この値をメモします。
接続先データベースで、すべての変更が適用されるまで待機します。接続先データベースで次の問合せを実行すると、適用プロセスstrm01_applyで適用される変更を監視できます。
SELECT DEQUEUED_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_READER
WHERE APPLY_NAME = 'STRM01_APPLY' AND
DEQUEUED_MESSAGE_NUMBER = last_enqueue_message_number;
手順hでアラート・ログから検出したLAST_ENQUEUE_MESSAGE_NUMBERを、問合せの最後の行のlast_enqueue_message_number に代入します。この問合せが行を戻す場合、取得データベースからのすべての変更は接続先データベースで適用されています。
適用プロセスのリーダー・サーバーおよび各適用サーバーの状態がIDLEになっていることも確認します。たとえば、適用プロセスstrm01_applyに次の問合せを実行します。
SELECT STATE FROM V$STREAMS_APPLY_READER WHERE APPLY_NAME = 'STRM01_APPLY'; SELECT STATE FROM V$STREAMS_APPLY_SERVER WHERE APPLY_NAME = 'STRM01_APPLY';
どちらの問合せでもIDLEが戻ったら、次の手順に進みます。
接続先データベースで、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを使用して、適用プロセスを削除します。
接続先データベースで、新規の適用プロセスを作成します。新規の適用プロセスでは、元の適用プロセスと同じキューおよびルール・セットが使用される必要があります。
接続先データベースで、DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、新規の適用プロセスを起動します。
DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを使用して、元の取得プロセスを削除します。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して新規の取得プロセスを作成し、手順12で削除した取得プロセスと置き換えます。手順4でデータ・ディクショナリの構築によって戻されたSCNを、first_scnおよびstart_scnの両方のパラメータに指定します。新規の取得プロセスでは、元の取得プロセスと同じキューおよびルール・セットが使用される必要があります。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、新規の取得プロセスを起動します。
複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソースのOracle Streams環境のソース・データベースでデータベースのPoint-in-Timeリカバリが必要な場合、環境内の他のソース・データベースを使用して、Point-in-Timeリカバリ後にリカバリ対象のソース・データベースに対して行われた変更を再取得できます。
たとえば、複数ソースのOracle Streams環境で、あるソース・データベースが時刻T2に使用不可になり、それ以前の時刻T1までのPoint-in-Timeリカバリを実行する場合があります。T1までリカバリされると、リカバリ対象のデータベースでT1からT2の間に実行されたトランザクションは、リカバリ済のデータベースで失われます。ただし、リカバリ対象のデータベースが使用不可になる前に、これらのトランザクションが他のソース・データベースに伝播され、適用されていたと想定します。この場合、この他のソース・データベースを使用して、リカバリ済のデータベースに失われた変更をリストアできます。
具体的には、Point-in-Timeリカバリ後にリカバリ対象のデータベースに対して行われた変更をリストアするには、取得プロセスを構成してこれらの変更を他のソース・データベースのREDOログから再取得し、それらの変更を再取得したデータベースからリカバリ済のデータベースに伝播によって伝播して、リカバリ済のデータベースの適用プロセスで適用します。
他のソース・データベースで発生し、T1からT2の間にリカバリ対象のデータベースで適用された変更も失われているため、それらの変更をリカバリする必要があります。これを行うには、他のソース・データベースで取得プロセスを変更して、それ以前のSCNから変更の取得を開始します。このSCNは、リカバリ対象のデータベースの適用プロセスの最も古いSCNです。
リカバリ済のデータベースに失われた変更をリストアするには、次のSCN値が必要です。
Point-in-Time SCN: リカバリ対象のデータベースのPoint-in-TimeリカバリのSCN。
インスタンス化SCN: 変更が再適用されている間に、リカバリ済のデータベースでリカバリに含まれていた各データベース・オブジェクトに設定する必要があるインスタンス化SCNのSCN値。他のソース・データベースでは、このSCN値は、他のソース・データベースで適用され、リカバリ済のデータベースで失われた最初のトランザクションのコミットSCNより小さい値に相当します。
開始SCN: 他のソース・データベースで変更を再取得するために作成される取得プロセスに設定する開始SCNのSCN値。このSCN値は、他のソース・データベースの適用プロセスが、リカバリ済のデータベースで失われたトランザクションの適用を開始した最も古いSCNに相当します。この取得プロセスは、そのソース・データベース用に他のソース・データベースを使用するローカルの取得プロセスまたはダウンストリームの取得プロセスである場合があります。
最大SCN: 失われた変更を再取得するために作成される取得プロセスのmaximum_scnパラメータに設定する必要があるSCN値。取得プロセスは、このSCN値に達した時点で変更の取得を停止します。他のソース・データベースの現行のSCNが、この値に使用されます。
リカバリ対象のデータベースでPoint-in-Timeリカバリを実行する際に、Point-in-Time SCNをメモする必要があります。DBMS_STREAMS_ADMパッケージのGET_SCN_MAPPINGプロシージャを使用すると、他の必要なSCN値を判断できます。
|
参照: GET_SCN_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
Oracle Streams環境の接続先データベースでデータベースのPoint-in-Timeリカバリが必要な場合は、Point-in-Timeリカバリ後に適用された取得済の変更を再適用する必要があります。
関連する取得プロセスごとに、次のいずれかの方法を選択して、Oracle Streams環境の接続先データベースでPoint-in-Timeリカバリを実行できます。
接続先データベースで適用される変更を取得する既存の取得プロセスについて、開始SCNをリセットします。
接続先データベースで再適用する必要のある変更を取得するように、新規の取得プロセスを作成します。
新規の取得プロセスを作成するよりも、既存の取得プロセスの開始SCNをリセットする方が簡単です。ただし、複数の接続先データベースで適用される変更が取得プロセスによって取得されると、Point-in-Timeリカバリを実行していないデータベースも含め、すべての接続先データベースに変更が再送信されます。変更がすでに接続先データベースで適用されている場合、その変更は適用プロセスで廃棄されますが、複数の接続先データベースに変更を再送信するために必要なネットワーク・リソースとコンピュータ・リソースを、使用しないようにすることが必要な場合があります。この場合は、リカバリ済の接続先データベースにのみ変更を伝播するように、新規の取得プロセスと新規の伝播を作成して一時的に使用できます。
ここでは、次の各タスクの手順について説明します。
Point-in-Timeリカバリを実行した接続先データベースに複数の適用プロセスがある場合は、この項で説明するタスクの1つを適用プロセスごとに実行してください。
リカバリ中の接続先データベースに関して、次のいずれかの条件がTRUEである場合、どちらの方法も使用できません。
伝播では、永続LCRが接続先データベースに伝播されます。いずれの方法でも、接続先データベースでは、永続LCRではなく取得LCRのみが再適用されます。
有向ネットワーク構成では、接続先データベースは取得プロセスからのLCRをその他のデータベースに伝播させる目的で使用されますが、接続先データベースにはこの取得プロセスからのLCRは適用されません。
接続先データベースの適用プロセスの最も古いメッセージ番号が、この適用プロセス用の変更を取得する取得プロセスの先頭SCNより小さい値です。接続先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号（最も古いSCN）が表示されます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
ソース・データベースで次の問合せを実行すると、各取得プロセスの先頭SCNが表示されます。
SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;
対象の開始SCNを含むアーカイブ・ログ・ファイルが使用不可になっています。
環境でこれらのいずれかの条件がTRUEである場合、この項で説明している方法は使用できません。かわりに、すべての接続先データベースでデータを手動で再同期化する必要があります。
|
注意: 単一ソースのレプリケーション環境で取得と適用の複合を使用している場合に接続先データベースでPoint-in-Timeリカバリを実行すると、Oracle Streamsの取得プロセスは、再起動時に変更を取得する場所を自動的に検出します。追加の手順は必要ありません。詳細は、『Oracle Streams概要および管理』を参照してください。 |
|
参照: 取得プロセスに関連するSCN値および有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。 |
Point-in-Timeリカバリを実行するために、既存の取得プロセスの開始SCNをリセットするように決定した場合は、次の手順を実行します。
複数ソースのOracle Streams環境で、接続先データベースがソース・データベースでもある場合は、「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順を実行します。
ソース・データベースのソース・キューから接続先データベースの宛先キューに変更を伝播させる伝播を削除します。伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを使用します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、ソース・データベースの伝播を含め、接続先データベースへのパスに含まれる各中間データベースで伝播を削除します。
削除する伝播で使用されているルール・セットは削除しないでください。
既存の取得プロセスが、接続先データベースで構成されるダウンストリーム取得プロセスである場合、手順3でPoint-in-Timeリカバリを実行すると、ダウンストリーム取得プロセスは接続先データベースと同じ時点にリカバリされます。 この場合、この項の手順3より後の手順は不要です。 必要なREDOログ・ファイルは取得プロセスで使用可能であることに注意してください。
|
注意: 適切な伝播を削除する必要があります。伝播を無効化するのみでは不十分です。手順7で伝播を再作成します。この時点で削除すると、取得プロセスの開始SCNをリセットした後に作成されたLCRのみが確実に伝播されます。 |
|
参照: 有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。 |
接続先データベースでPoint-in-Timeリカバリを実行します。
接続先データベースで、適用プロセスについてソース・データベースからの最も古いメッセージ番号（最も古いSCN）を問い合せます。次に、問合せ結果をメモします。最も古いメッセージ番号とは、適用する必要があると思われる最も古いシステム変更番号（SCN）です。
接続先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号が表示されます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して、既存の取得プロセスを停止します。
既存の取得プロセスの開始SCNをリセットします。
そのためには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを実行し、start_scnパラメータを手順4の問合せでメモした値に設定します。たとえば、取得プロセスstrm01_captureの開始SCNを値829381993にリセットするには、次のALTER_CAPTUREプロシージャを実行します。
BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name => 'strm01_capture',
start_scn => 829381993);
END;
/
ソース・データベースと接続先データベースの間で有向ネットワークを使用していない場合は、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して、変更をソース・キューから宛先キューに伝播させる新規の伝播を作成します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、ソース・データベースの伝播を含め、接続先データベースへのパスに含まれる各中間データベースで、新規の伝播を作成します。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、既存の取得プロセスを起動します。
Point-in-Timeリカバリを実行するために新規の取得プロセスを作成するように決定した場合は、次の手順を実行します。
複数ソースのOracle Streams環境で、接続先データベースがソース・データベースでもある場合は、「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順を実行します。
ソース・データベースと接続先データベースの間で有向ネットワークを使用していない場合は、ソース・データベースのソース・キューから接続先データベースの宛先キューに変更を伝播させる伝播を削除します。伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを使用します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、最後の中間データベースと接続先データベースの間でLCRを伝播する伝播を削除します。他の中間データベースやソース・データベースでは、伝播を削除する必要はありません。
|
注意: 適切な伝播を削除する必要があります。伝播を無効化するのみでは不十分です。 |
|
参照: 有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。 |
接続先データベースでPoint-in-Timeリカバリを実行します。
接続先データベースで、適用プロセスについてソース・データベースからの最も古いメッセージ番号（最も古いSCN）を問い合せます。次に、問合せ結果をメモします。最も古いメッセージ番号とは、適用する必要があると思われる最も古いシステム変更番号（SCN）です。
接続先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号が表示されます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して、取得プロセスで使用するキューをソース・データベースに作成します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、ソース・データベースの新規キューを含め、接続先データベースへのパスに含まれる各中間データベースでキューを作成します。接続先データベースでは新規キューを作成しないでください。
ソース・データベースと接続先データベースの間で有向ネットワークを使用していない場合は、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して、変更を手順5で作成したソース・キューから宛先キューに伝播させる新規の伝播を作成します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、ソース・データベースから最初の中間データベースへの伝播を含め、接続先データベースへのパスに含まれる各中間データベースで伝播を作成します。これらの伝播では、手順7で作成する取得プロセスによって取得された変更が、手順5で作成したキュー間で伝播されます。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して、ソース・データベースで新規の取得プロセスを作成します。source_queueパラメータを手順5で作成したローカル・キューに設定し、start_scnパラメータを手順4の問合せでメモした値に設定します。元の取得プロセスで使用していたルール・セットも指定します。元の取得プロセスで使用していたルール・セットによって、リカバリした接続先データベースに送信する必要のない変更が取得される場合は、一部のルールを元のルール・セットと共有するようにカスタマイズした小型のルール・セットを作成して使用できます。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、手順7で作成した取得プロセスを起動します。
リカバリ後のデータベースの適用プロセスの最も古いメッセージ番号が、ソース・データベースの元の取得プロセスの取得番号に近づいた時点で、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して元の取得プロセスを停止します。
接続先データベースでは、次の問合せを使用すると、適用プロセスについてソース・データベースからの最も古いメッセージ番号を判断できます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
ソース・データベースでは、次の問合せを使用すると、元の取得プロセスの取得番号を判断できます。
SELECT CAPTURE_NAME, CAPTURE_MESSAGE_NUMBER FROM V$STREAMS_CAPTURE;
リカバリ後のデータベースの適用プロセスの最も古いメッセージ番号が、ソース・データベースの元の取得プロセスの取得番号を超えた時点で、手順7で作成した新規の取得プロセスを削除します。
ソース・データベースと接続先データベースの間で有向ネットワークを使用していない場合は、手順6で作成した新規の伝播を削除します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、ソース・データベースの新規の伝播を含め、接続先データベースへのパスに含まれる各中間データベースで新規の伝播を削除します。
ソース・データベースと接続先データベースの間で有向ネットワークを使用していない場合は、手順5で作成したキューを削除します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、ソース・データベースの新規キューを含め、接続先データベースへのパスに含まれる各中間データベースで新規キューを削除します。接続先データベースではキューを削除しないでください。
ソース・データベースと接続先データベースの間で有向ネットワークを使用していない場合は、ソース・データベースの元のソース・キューから接続先データベースの宛先キューに変更を伝播させる伝播を作成します。伝播を作成するには、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと接続先データベースの間に中間データベースがある場合は、最後の中間データベースから接続先データベースへの伝播を再作成します。これは、手順2で削除した伝播です。
手順9で停止した取得プロセスを起動します。
