2 Oracle Streamsレプリケーションの簡単な構成
2.1 Streamsレプリケーションの設定ウィザードを使用したレプリケーションの構成
Oracle Enterprise Manager Cloud ControlのOracle Streamsツールには、Oracle Streamsレプリケーション環境を構成するStreamsレプリケーションの設定ウィザードが含まれています。このウィザードを使用して、次のいずれかの特性を備えたOracle Streamsレプリケーション環境を構成できます。
-
ソース・データベース全体、ソース・データベース内の選択されたスキーマ、ソース・データベース内の選択された表領域、ソース・データベース内の選択された表またはソース・データベース内の表のサブセットに対する変更をレプリケートする
-
データ操作言語(DML)変更またはデータ定義言語(DDL)変更(あるいはその両方)をメンテナンスする
-
一方向または双方向のレプリケーション
-
ローカル取得またはダウンストリーム取得
このウィザードではレプリケーション環境の構成プロセスを実行でき、さらにこのウィザードを複数回実行することで、3つ以上のデータベースを使用するレプリケーション環境を構成できます。このウィザードを使用して構成できるレプリケーション環境のタイプには制限があります。たとえば、このウィザードでは、現在、同期取得は構成できません。
Oracle Streamsレプリケーション環境を即座に構成することも、またはウィザードを使用してスクリプトを生成することもできます。スクリプトを生成する場合は、スクリプトを実行してレプリケーション環境を構成する前に、スクリプトを確認し、必要に応じて編集できます。
このウィザードをオープンするには、Oracle Enterprise Manager Cloud Controlで次の手順を実行します。
注意:
Streamsレプリケーションの設定ウィザードでは、デフォルトで一方向のレプリケーションが構成されます。双方向のレプリケーションを構成するには、「レプリケーション・オプション」ページの「拡張オプション」セクションを開き、「双方向レプリケーションの設定」を選択します。双方向のレプリケーションを構成する場合は、競合解消が必要になることがあります。
関連項目:
-
このウィザードを使用してOracle Streamsレプリケーション環境を構成する場合の例は、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。
2.2 DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成
DBMS_STREAMS_ADM
パッケージのプロシージャを使用して、Oracle Streamsレプリケーション環境を構成できます。
ここでは、これらのプロシージャ、これらのプロシージャのいずれかの実行を準備する手順および一般的な使用例について説明します。
関連項目:
これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
2.2.1 Oracle Streamsレプリケーション構成プロシージャ
Oracle Streamsレプリケーション環境を構成する最も簡単な方法は、DBMS_STREAMS_ADM
パッケージにある次のいずれかの構成プロシージャを実行することです。
-
MAINTAIN_GLOBAL
: 2つのデータベース間でデータベース・レベルの変更をレプリケートするOracle Streams環境が構成されます。 -
MAINTAIN_SCHEMAS
: 2つのデータベース間で、指定されたスキーマに対する変更をレプリケートするOracle Streams環境が構成されます。 -
MAINTAIN_SIMPLE_TTS
: 宛先データベースでソース・データベースからの単一の表領域がクローニングされ、Oracle Streamsを使用して両方のデータベースでこの表領域がメンテナンスされます。 -
MAINTAIN_TABLES
: 2つのデータベース間で、指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。 -
MAINTAIN_TTS
: 宛先データベースでソース・データベースからの表領域セットがクローニングされ、Oracle Streamsを使用して両方のデータベースでこれらの表領域がメンテナンスされます。 -
PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
: 2つのデータベース間でデータベース・レベルの変更または指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。Oracle Streamsレプリケーションの構成を完了するには、これらのプロシージャをともに使用し、インスタンス化の操作を手動で実行する必要があります。通常、これらのプロシージャを使用して、データベースのメンテナンス操作を停止時間なしでまたは短い停止時間で実行します。詳細は、『Oracle Streams概要および管理』を参照してください。
これらのプロシージャでは、2つのデータベースを同時に構成しますので、1つのデータベースをソース・データベースとして、またもう一方のデータベースを宛先データベースとして指定する必要があります。これらのプロシージャを複数回実行することによって、3つ以上のデータベースを使用するレプリケーション環境を構成できます。
表2-1に、これらのプロシージャの必須パラメータを示します。
表2-1 Oracle Streamsレプリケーション構成プロシージャの必須パラメータ
パラメータ | プロシージャ | 説明 |
---|---|---|
|
すべてのプロシージャ |
生成されたデータ・ポンプ・エクスポート・ダンプ・ファイルの格納先となる、ソース・データベースを実行するコンピュータ・システム上にあるディレクトリのディレクトリ・オブジェクト。 注意: 指定したディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。 |
|
すべてのプロシージャ |
生成されたデータ・ポンプ・エクスポート・ダンプ・ファイルの転送先となる、宛先データベースを実行するコンピュータ・システム上にあるディレクトリのディレクトリ・オブジェクト。ダンプ・ファイルを使用して、宛先データベースでレプリケートされたデータベース・オブジェクトがインスタンス化されます。 注意: 指定したディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。 |
|
すべてのプロシージャ |
ソース・データベースのグローバル名。指定したデータベースには、レプリケートされるデータベース・オブジェクトが含まれている必要があります。 |
|
すべてのプロシージャ |
宛先データベースのグローバル名。宛先データベースにはレプリケートされるデータベース・オブジェクトが含まれている場合と含まれていない場合があります。宛先データベースにレプリケートされるデータベース・オブジェクトが存在しない場合は、データ・ポンプ・エクスポート/インポートによって、レプリケートされるデータベース・オブジェクトがインスタンス化されます。 ローカル・データベースが宛先データベースではない場合は、ローカル・データベースから宛先データベースへのデータベース・リンク(宛先データベースのグローバル名と同じ名前を使用)が存在している必要があり、またプロシージャを実行するユーザーがこのリンクにアクセス可能である必要があります。 |
|
|
レプリケーション用に構成されるスキーマ。 |
|
|
レプリケーション用に構成される表領域。 |
|
|
レプリケーション用に構成される表。 |
|
|
レプリケーション用に構成される表領域。 |
また、これらの各プロシージャには複数のオプション・パラメータが用意されています。bi_directional
パラメータは、重要なオプション・パラメータです。各データベースでレプリケートされたデータベース・オブジェクトへの変更を各データベースで取得し、また他のデータベースへ送信する場合は、bi_directional
パラメータをTRUE
に設定する必要があります。このパラメータのデフォルトの設定はFALSE
です。bi_directional
パラメータがFALSE
に設定されている場合、プロシージャでは、宛先データベースで行われた変更が取得されない一方向のレプリケーション環境を構成します。
これらのプロシージャでは、複数のタスクを実行して、Oracle Streamsレプリケーション環境を構成します。次のようなタスクがあります。
-
ソース・データベースのレプリケートされたデータベース・オブジェクトに対するサプリメンタル・ロギングを構成します。
-
bi_directional
パラメータがTRUE
に設定されている場合は、宛先データベースのレプリケートされたデータベース・オブジェクトに対するサプリメンタル・ロギングを構成します。 -
宛先データベースでデータベース・オブジェクトをインスタンス化します。宛先データベースにデータベース・オブジェクトが存在しない場合、プロシージャではデータ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。
-
ソース・データベースのレプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスを構成します。この取得プロセスには、ローカル取得プロセスまたはダウンストリーム取得プロセスを使用します。プロシージャが
source_database
パラメータで指定したデータベースで実行された場合、プロシージャでは、このデータベース上でローカル取得プロセスを構成します。プロシージャがsource_database
パラメータで指定したデータベース以外のデータベースで実行された場合、プロシージャでは、このプロシージャが実行されたデータベース上でダウンストリーム取得プロセスを構成します。 -
bi_directional
パラメータがTRUE
に設定されている場合は、宛先データベースのレプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスを構成します。この取得プロセスは、ローカル取得プロセスである必要があります。 -
各データベースで、取得された変更を格納する1つ以上のキューを構成します。
-
ソース・データベースのデータベース・オブジェクトに対する変更を宛先データベースに送信する伝播を構成します。
-
bi_directional
パラメータがTRUE
に設定されている場合は、宛先データベースのデータベース・オブジェクトに対する変更をソース・データベースに送信する伝播を構成します。 -
宛先データベースで、ソース・データベースからの変更を適用する適用プロセスを構成します。
-
bi_directional
パラメータがTRUE
に設定されている場合は、ソース・データベースで、宛先データベースからの変更を適用する適用プロセスを構成します。 -
取得プロセス、伝播および適用プロセスごとに、ルールおよびルール・セットを構成します。ルールでは、指定したデータベース・オブジェクトに対する変更をレプリケートするようにOracle Streamsクライアントに指示します。
-
宛先データベースでレプリケートされたデータベース・オブジェクトのインスタンス化SCNを設定します。
-
bi_directional
パラメータがTRUE
に設定されている場合は、ソース・データベースでレプリケートされたデータベース・オブジェクトのインスタンス化SCNを設定します。
ヒント:
これらのプロシージャのいずれかによって実行される全アクションの詳細を表示するには、プロシージャを使用してスクリプトを生成し、このスクリプトをテキスト・エディタで表示します。perform_actions
、script_name
およびscript_directory_object
パラメータを使用すると、スクリプトが生成できます。
これらのプロシージャでは、常にハブ・アンド・スポーク・レプリケーション環境のタグを構成します。これらのプロシージャおよびタグに関する重要な考慮事項は次のとおりです。
-
2データベース・レプリケーション環境を構成する場合は、これらのプロシージャを使用して環境を構成できます。これらのプロシージャでは、2データベース環境のタグを構成して、変更の循環を回避します。将来的にレプリケーション環境を拡張して3つ以上のデータベースを使用する計画がある場合は、タグの構成方法を理解することが重要です。拡張されたデータベース環境がハブ・アンド・スポーク環境ではない場合、変更の循環を回避するためにタグの変更が必要になる場合があります。
-
3つ以上のデータベースを含むレプリケーション環境を構成する場合、これらのプロシージャは、ハブ・アンド・スポーク・レプリケーション環境の構成にのみ使用できます。これらのプロシージャでは、ハブ・アンド・スポーク環境のタグを構成して、変更の循環を回避します。
-
n-wayレプリケーション環境を構成する場合は、これらのプロシージャを使用して環境を構成しないでください。これらのプロシージャを使用すると、変更の循環が発生する可能性があります。
注意:
現在、これらの構成プロシージャでは、変更を取得する取得プロセスのみを構成します。これらのプロシージャを使用して、同期取得を使用するレプリケーション環境を構成することはできません。同期取得を構成するには、DBMS_STREAMS_ADM
パッケージのADD_TABLE_RULES
およびADD_SUBSET_RULES
プロシージャを使用します。
関連項目:
-
DBMS_STREAMS_ADM
パッケージのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
2.2.2 構成プロシージャに関する重要な考慮事項
この項では、構成プロシージャに関する重要な考慮事項について説明します。また、これらの考慮事項に関連するいくつかのプロシージャ・パラメータについても説明します。
この項には、次の項目が含まれます。
関連項目:
これらのプロシージャのすべてのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
2.2.2.1 ソース・データベースに対するローカル取得またはダウンストリーム取得
この項のプロシージャでは、source_database
パラメータに指定したデータベースに対してローカル取得またはダウンストリーム取得のいずれかを構成できます。ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。
プロシージャが実行されるデータベースは、ソース・データベースに対する変更の取得データベースとして構成されます。そのため、ソース・データベースでのローカル取得を構成するには、ソース・データベースでプロシージャを実行します。宛先データベースでダウンストリーム取得を構成するには、destination_database
パラメータに指定されているデータベースでプロシージャを実行します。第3のデータベースでダウンストリーム取得を構成するには、source_database
パラメータまたはdestination_database
パラメータに指定されていないデータベースでプロシージャを実行します。
ソース・データベースまたは第3のデータベースを取得データベースに使用する場合、この項のプロシージャでは、取得データベースから宛先データベースに変更を送信するように伝播が構成されます。宛先データベースを取得データベースに使用して、双方向のレプリケーションを構成しない場合、データベース間でのこの伝播は不要です。この場合、capture_queue_name
パラメータとapply_queue_name
パラメータの値が同じであると、伝播は構成されません。これらの値が異なる場合は、宛先データベース内の2つのキュー間に伝播が構成されます。
注意:
-
この項のプロシージャでダウンストリーム取得を構成すると、常にアーカイブ・ログ・ダウンストリーム取得が構成されます。これらのプロシージャでは、リアルタイム・ダウンストリーム取得は構成されません。ただし、プロシージャを実行する前にリアルタイム・ダウンストリーム取得用のREDO転送サービスを構成して、プロシージャの完了後に
downstream_real_time_mine
取得プロセス・パラメータをY
に設定することができます。また、これらのプロシージャによって生成されるスクリプトを、リアルタイム・ダウンストリーム取得を構成するように変更することもできます。 -
この項のプロシージャで双方向のレプリケーションを構成する場合、宛先データベースの取得プロセスは、常にローカル取得プロセスになります。つまり、これらのプロシージャでは、常に宛先データベースに対する変更の取得プロセスが宛先データベースで実行されるように構成されます。
-
同期取得は構成プロシージャでは構成できません。
関連項目:
-
双方向のレプリケーションの詳細は、「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」および「一方向または双方向のレプリケーション」を参照してください
-
ローカル取得およびダウンストリーム取得の詳細は、『Oracle Streams概要および管理』を参照してください。
2.2.2.2 構成アクションの直接実行またはスクリプトを使用した実行
この項のプロシージャでは、Oracle Streamsレプリケーション環境を直接構成するか、または環境を構成するスクリプトを生成できます。スクリプトを実行するよりプロシージャを使用してレプリケーションを直接構成する方が簡単で、環境が即時に構成されます。ただし、次の理由でスクリプトを生成することもあります。
-
環境を構成する前にプロシージャによって実行される操作を確認する必要がある。
-
構成をカスタマイズするためにスクリプトを変更する必要がある。
たとえば、適用プロセスで、特定の表に変更を適用する前に、適用ハンドラを使用してこれらの変更にカスタマイズされた処理を行う場合があります。この場合、プロシージャを使用してスクリプトを生成し、適用ハンドラを追加するようにスクリプトを変更できます。
また、複数の表に対するDML変更をメンテナンスするが、これらの表のサブセットに対してのみDDL変更をメンテナンスする場合があります。この場合、include_ddl
パラメータをFALSE
に設定してMAINTAIN_TABLES
プロシージャを実行することによって、スクリプトを生成できます。適切な表に対するDDL変更をメンテナンスするようにスクリプトを変更できます。
perform_actions
パラメータは、プロシージャでレプリケーション環境を直接構成するかどうかを制御します。
-
この項のいずれかのプロシージャを実行する際にOracle Streams環境を直接構成する場合は、
perform_actions
パラメータをTRUE
に設定します。このパラメータのデフォルト値はTRUE
です。 -
この項のいずれかのプロシージャを実行する際に構成スクリプトを生成する場合は、
perform_actions
パラメータをFALSE
に設定し、script_name
およびscript_directory_object
パラメータを使用して構成スクリプトの名前と格納場所を指定します。
注意:
script_directory_object
パラメータは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。
2.2.2.3 これらのプロシージャによって構成されたOracle Streamsコンポーネント
これらのプロシージャでは、次のOracle Streamsクライアントが構成されます。
-
これらのプロシージャでは、ソース・データベースに対する変更を取得する取得プロセスが構成されます。双方向のレプリケーションが構成される場合は、宛先データベースに対する変更を取得する取得プロセスも構成されます。
-
取得データベースと宛先データベースが異なる場合、これらのプロシージャでは、取得データベースから宛先データベースに変更を送信する伝播が構成されます。
-
取得データベースと宛先データベースが同じ場合、伝播が作成されるかどうかはキュー名によって決まります。
-
capture_queue_name
パラメータとapply_queue_name
パラメータで異なるキュー名を指定すると、宛先データベース内の2つのキュー間に伝播が作成されます。 -
capture_queue_name
パラメータとapply_queue_name
パラメータで同じキュー名を指定すると、伝播は作成されず、ダウンストリーム取得プロセスと適用プロセスで同じキューが使用されます。この構成は、bi_directional
をFALSE
に設定して単一ソース・レプリケーション環境を構成している場合にのみ可能です。
-
-
双方向のレプリケーションが構成される場合、これらのプロシージャでは、宛先データベースからソース・データベースに変更を送信する伝播が構成されます。
-
これらのプロシージャでは、宛先データベースで変更を適用する適用プロセスが構成されます。これらの変更は、ソース・データベースで発生したものです。双方向のレプリケーションが構成される場合は、ソース・データベースに変更を適用する適用プロセスも構成されます。これらの変更は、宛先データベースで発生したものです。
デフォルトでは、capture_queue_name
パラメータとapply_queue_name
パラメータはNULL
に設定されます。これらのパラメータがNULL
に設定されている場合、これらのプロシージャでは、各取得プロセスおよび適用プロセスに対して別々のキューが構成されます。Oracle Streamsクライアントごとに別々の独自のキューが含まれていると、Oracle Streamsレプリケーション環境がより効率的に動作することがあります。
ただし、次の構成では、2つのOracle Streamsクライアントでキューが共有されます。
-
宛先データベースのダウンストリーム取得プロセスと適用プロセスでキューが共有される構成(この項の前述の説明を参照)
-
次のすべての条件が該当する構成
-
取得データベースがソース・データベースまたは第3のデータベースである。
-
bi_directional
パラメータがTRUE
に設定されている。 -
capture_queue_name
パラメータとapply_queue_name
パラメータに同じキュー名が指定されている。
この場合、宛先データベースのローカル取得プロセスと適用プロセスで同じキューが共有されます。ソース・データベースが取得データベースの場合は、ソース・データベースのローカル取得プロセスと適用プロセスでも同じキューが共有されます。
-
また、次の両方の条件に該当する場合、capture_name
およびcapture_queue_name
パラメータをNULL
に設定する必要があります。
-
宛先データベースを取得データベースに使用する。
-
bi_directional
パラメータがTRUE
に設定されている。
これらの両方の条件に該当する場合、この項のプロシージャでは宛先データベースで2つの取得プロセスが構成されるため、これらの取得プロセスには異なる名前を付ける必要があります。一方の取得プロセスがソース・データベースのダウンストリーム取得プロセスになり、もう一方の取得プロセスが宛先データベースに対する変更を取得するローカル取得プロセスになります。capture_name
およびcapture_queue_name
パラメータがNULL
に設定されている場合、これらの取得プロセスに対してシステムによって異なる名前が生成されます。両方の条件に該当し、capture_name
パラメータまたはcapture_queue_name
パラメータのいずれかがNULL
以外の値に設定されている場合、この項のプロシージャでエラーが発生します。
2.2.2.4 一方向または双方向のレプリケーション
この項のプロシージャでは、source_database
パラメータで指定されたデータベースをソース・データベースとする一方向(単一ソース)のOracle Streams構成、または両方のデータベースをソース・データベースと宛先データベースとする双方向のOracle Streams構成のいずれかが設定されます。詳細は、「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」を参照してください。
Oracle Streams構成を単一ソースとするか双方向とするかは、各プロシージャのbi_directional
パラメータで制御されます。
-
bi_directional
パラメータをFALSE
に指定した場合、取得プロセスがソース・データベースに対する変更を取得し、適用プロセスが宛先データベースでそれらの変更を適用します。宛先データベースを取得データベースに使用しない場合、伝播によって、取得された変更が宛先データベースに送信されます。このパラメータのデフォルト値はFALSE
です。 -
bi_directional
パラメータをTRUE
に設定した場合、個別の取得プロセスが各データベースに対する変更を取得し、伝播によってこれらの変更が他のデータベースに送信され、各データベースで他のデータベースからの変更が適用されます。
レプリケーション環境が双方向ではなく、宛先データベースで変更が許可されていない場合、Oracle Streamsはデータベース間で共有データベース・オブジェクトの同期化を保持します。ただし、レプリケーション環境が双方向ではなく、宛先データベースで独立した変更が許可されている場合、データベース間で共有データベース・オブジェクトが異なる場合があります。独立した変更は、ユーザー、アプリケーション、または第3のデータベースを含むレプリケーションによって行われます。
注意:
-
双方向のレプリケーションを構成する場合、競合解消の構成が必要な場合があります。
-
この項のいずれかのプロシージャを実行する際に
bi_directional
パラメータをTRUE
に設定した場合、プロシージャまたはプロシージャによって生成されたスクリプトの実行中に、宛先データベースの共有データベース・オブジェクトに対するデータ操作言語(DML)変更またはデータ定義言語(DDL)変更を許可しないでください。プロシージャで単一ソース・レプリケーション環境を構成する場合は、この制限は適用されません。 -
これらのプロシージャでは、レプリケート表は宛先データベースで読取り専用に構成されません。これらのいずれかのプロシージャを実行する際に
bi_directional
パラメータをFALSE
に設定し、レプリケート表を宛先データベースで読取り専用にする場合は、必要に応じて宛先データベースで権限を構成してください。ただし、適用プロセスの適用ユーザーは、レプリケートされたデータベース・オブジェクトに対するDML変更を行うことができる必要があります。権限を構成する方法は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
2.2.2.4.1 変更の循環とタグ
変更の循環は、変更が発生場所であるデータベースに再送されると発生します。通常は、それぞれの変更が無限ループを介して発生場所であるデータベースに送信される可能性があるため、変更の循環を回避する必要があります。このようなループがあると、データベースに意図しないデータが格納され、環境のネットワーキング・リソースとコンピュータ・リソースが過剰に使用される可能性があります。
bi_directional
パラメータがTRUE
に設定されている場合、これらのプロシージャでは双方向のレプリケーションが構成されます。また、双方向のOracle Streamsレプリケーション環境で変更の循環を回避するために、次のように環境が構成されます。
-
各データベースの適用プロセスによって、環境に固有の適用タグを持つ各変更が適用されます。適用タグとは、適用プロセスによって作成される各REDOレコードの一部であるOracle Streamsタグのことです。たとえば、プロシージャで双方向のレプリケーション用にデータベース
sfdb.net
およびnydb.net
を構成する場合、sfdb.net
の適用プロセスの適用タグは'1'
と等価の16進値になり、nydb.net
の適用プロセスの適用タグは'2'
と等価の16進値になります。この場合、適用された変更のタグが'1'
と等価の16進値である場合、その変更はnydb.net
データベースで発生したものであり、適用された変更のタグが'2'
と等価の16進値である場合、その変更はsfdb.net
で発生したものになります。 -
各データベースの取得プロセスによって、共有データベース・オブジェクトに対するすべての変更が取得されます。この取得は、それらのデータベース・オブジェクトに対する変更のREDOレコード内のタグに関係なく行われます。
-
各伝播によって、共有データベース・オブジェクトに対するすべての変更(他のデータベースで発生した変更は除く)が双方向レプリケーション環境の他のデータベースに送信されます。前述の例にあてはめると、
sfdb.net
での伝播によって、タグ値が'1'
と等価の16進値である変更を除くすべての変更がnydb.net
に送信されます(これらの変更はnydb.net
で発生したものであるためです)。同様に、nydb.net
での伝播によって、タグ値が'2'
と等価の16進値である変更を除くすべての変更がsfdb.net
に送信されます。タグ値が原因で伝播されない変更は破棄されます。
この項のプロシージャを使用して、環境内の第3のデータベースによってソース・データベースに変更が循環される複数方向のレプリケーションを構成することはできません。たとえば、これらのプロシージャを使用して、3つのデータベースによってそれぞれ環境内の他の2つのデータベースと変更が共有されるOracle Streamsレプリケーション環境を構成することはできません。このような環境は、n-wayレプリケーション環境と呼ばれることがあります。これらのプロシージャを使用してこのタイプの3方向のレプリケーション環境を構成すると、ソース・データベースに加えられた変更は、同じソース・データベースに循環されます。有効な3方向のレプリケーション環境では、特定の変更は各データベースに一度のみ行われます。
これらのプロシージャでは、ソース・データベースで行われた変更が循環して同じソース・データベースに戻らない場合、3つ以上のデータベースを含むOracle Streamsレプリケーション環境を構成できます。たとえば、プロシージャを複数回実行して、プライマリ・データベースが複数のセカンダリ・データベースと変更を共有する環境を構成できます。このような環境は、ハブ・アンド・スポーク・レプリケーション環境と呼ばれることがあります。
各ソース・データベースが他のソース・データベースと変更を共有する複数ソース環境で変更をレプリケートするように、Oracle Streams環境を手動で構成できます。また、生成されたスクリプトを変更してこの操作を行うこともできます。
関連項目:
-
ハブ・アンド・スポーク・レプリケーション環境を構成する場合の例については、「ハブ・アンド・スポーク・レプリケーションを構成する場合の例」を参照してください
2.2.2.5 データ定義言語(DDL)変更
include_ddl
パラメータは、DDL変更をメンテナンスするようにプロシージャでOracle Streamsレプリケーションを構成するかどうかを制御します。
-
DDL変更をメンテナンスしないOracle Streamsレプリケーション環境を構成するには、この項のいずれかのプロシージャを実行する際に、
include_ddl
パラメータをFALSE
に設定します。このパラメータのデフォルト値はFALSE
です。 -
DDL変更をメンテナンスするOracle Streamsレプリケーション環境を構成するには、この項のいずれかのプロシージャを実行する際に、
include_ddl
パラメータをTRUE
に設定します。
注意:
MAINTAIN_SIMPLE_TTS
プロシージャにはinclude_ddl
パラメータは含まれません。MAINTAIN_SIMPLE_TTS
プロシージャで構成するOracle Streamsレプリケーション環境では、DML変更のみがメンテナンスされます。
関連項目:
2.2.2.6 インスタンス化
MAINTAIN_GLOBAL
、MAINTAIN_SCHEMAS
およびMAINTAIN_TABLES
プロシージャでは、インスタンス化のオプションが提供されます。インスタンス化とは、ソース・データベースでデータベース・オブジェクトをインスタンス化のために準備するプロセスであり、オプションで、データベース・オブジェクトをソース・データベースから宛先データベースにコピーしたり、インスタンス化された各データベース・オブジェクトにインスタンス化SCNを設定します。
これら3つのプロシージャのいずれかを実行する場合、次のいずれかの方法でインスタンス化を実行するように選択できます。
-
データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化: このオプションでは、ソース・データベースで共有データベース・オブジェクトにデータ・ポンプでのエクスポートが実行され、宛先データベースでエクスポート・ダンプ・ファイルのデータ・ポンプでのインポートが実行されます。インポート時に各共有データベース・オブジェクトに対してインスタンス化SCNが設定されます。
このインスタンス化オプションを指定するには、
instantiation
パラメータを次のいずれかの値に設定します。-
MAINTAIN_GLOBAL
プロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_FULL
-
MAINTAIN_SCHEMAS
プロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_SCHEMA
-
MAINTAIN_TABLES
プロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_TABLE
bi_directional
パラメータがTRUE
に設定されている場合、プロシージャでは、ソース・データベースの各共有データベース・オブジェクトに対してもインスタンス化SCNが設定されます。このオプションを使用する場合は、データ・ポンプ・ファイルを保持するためのディレクトリ・オブジェクトを作成する必要があります。「必要なディレクトリ・オブジェクトの作成」を参照してください。
-
-
データ・ポンプでのネットワーク・インポートによるインスタンス化: このオプションでは、共有データベース・オブジェクトのデータ・ポンプでのネットワーク・インポートが実行されます。ネットワーク・インポートとは、エクスポート・ダンプ・ファイルを使用せずにデータ・ポンプでインポートを実行することを意味します。したがって、このオプションを使用する場合、インスタンス化のためにディレクトリ・オブジェクトを作成する必要はありません。インポート時に各共有データベース・オブジェクトに対してインスタンス化SCNが設定されます。
このインスタンス化オプションを指定するには、
instantiation
パラメータを次のいずれかの値に設定します。-
MAINTAIN_GLOBAL
プロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_FULL_NETWORK
-
MAINTAIN_SCHEMAS
プロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_SCHEMA_NETWORK
-
MAINTAIN_TABLES
プロシージャを実行する場合はDBMS_STREAMS_ADM.INSTANTIATION_TABLE_NETWORK
bi_directional
パラメータがTRUE
に設定されている場合、プロシージャでは、ソース・データベースの各共有データベース・オブジェクトに対してもインスタンス化SCNが設定されます。 -
-
インスタンス化を指定しない構成スクリプトの生成: このオプションでは、インスタンス化は実行されません。この設定は、
perform_actions
パラメータがFALSE
に設定されており、プロシージャで構成スクリプトを生成する場合にのみ有効です。この場合、構成スクリプトによって、インスタンス化、および各共有データベース・オブジェクトのインスタンス化SCNの設定は実行されません。かわりに、ユーザーがインスタンス化を実行し、インスタンス化SCNの値を適切に設定する必要があります。このインスタンス化オプションを指定するには、各プロシージャで
instantiation
パラメータをDBMS_STREAMS_ADM.INSTANTIATION_NONE
に設定します。
これらのいずれかのプロシージャで表のインスタンス化を実行する場合は、宛先データベースにその表を含む表領域が存在している必要があります。これらのいずれかのプロシージャでスキーマのインスタンス化を実行する場合は、宛先データベースにそのスキーマを含む表領域が存在している必要があります。
これらのプロシージャでダンプ・ファイルまたはネットワークのインスタンス化を実行すると、インスタンス化されたデータベース・オブジェクトが宛先データベースに存在しない場合、宛先データベースにデータベース・オブジェクトがインポートされますが、これには、ソース・データベースからのサプリメンタル・ロギング指定およびサポート・データベース・オブジェクト(索引、トリガーなど)が含まれます。ただし、インスタンス化の実行前に宛先データベースにデータベース・オブジェクトがすでに存在する場合は、宛先データベースにデータベース・オブジェクトはインポートされません。このため、ソース・データベースからのサプリメンタル・ロギング指定は宛先データベースのデータベース・オブジェクトに指定されず、サポート・データベース・オブジェクトはインポートされません。
PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャでは、インスタンス化が実行されません。必要なインスタンス化操作を、PRE_INSTANTIATION_SETUP
の実行後およびPOST_INSTANTIATION_SETUP
の実行前に手動で実行する必要があります。また、instantiation
パラメータをDBMS_STREAMS_ADM.INSTANTIATION_NONE
に設定してMAINTAIN_GLOBAL
、MAINTAIN_SCHEMAS
およびMAINTAIN_TABLES
プロシージャを使用した場合も、必要なインスタンス化操作を手動で実行する必要があります。
これらの場合、任意のインスタンス化方法を使用できます。たとえば、Recovery Manager(RMAN)のDUPLICATE
またはCONVERT
DATABASE
コマンドを使用してデータベースをインスタンス化したり、RMANのTRANSPORT
TABLESPACE
コマンドを使用して表領域をインスタンス化することができます。bi_directional
パラメータがTRUE
に設定されている場合、ソース・データベースおよび宛先データベースでインスタンス化SCNの値が適切に設定されていることを確認します。
注意:
-
MAINTAIN_SIMPLE_TTS
およびMAINTAIN_TTS
プロシージャでは、これらのインスタンス化オプションは提供されません。これらのプロシージャでは、表領域または表領域セットがクローニングされ、インスタンス化に必要なファイルが宛先データベースに送信され、宛先データベースで表領域または表領域セットがアタッチされることによって、常にインスタンス化が実行されます。 -
これらのいずれかのプロシージャでインスタンス化を実行する場合は、ソース・データベースにレプリケーションに対して構成するデータベース・オブジェクト、表領域または表領域セットが存在している必要があります。
-
RMANの
DUPLICATE
またはCONVERT
DATABASE
コマンドを使用してデータベースのインスタンス化を行う場合、宛先データベースを取得データベースとすることはできません。 -
MAINTAIN_TABLES
プロシージャでダンプ・ファイルまたはネットワークのインスタンス化を実行すると、インスタンス化の実行前にインスタンス化された表が宛先データベースに存在する場合は、このプロシージャによって表に対するインスタンス化SCNは設定されません。この場合は、プロシージャの完了後に表に対するインスタンス化SCNを手動で設定する必要があります。
2.2.3 必要なディレクトリ・オブジェクトの作成
ディレクトリ・オブジェクトは、ファイル・システム上のディレクトリの別名に類似しています。この項のいずれかのプロシージャを実行する場合、次のディレクトリ・オブジェクトが必要になる場合があります。
-
スクリプト・ディレクトリ・オブジェクトは、構成スクリプトを生成する場合に必要です。構成スクリプトは、プロシージャが実行されるコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行してスクリプト・ディレクトリ・オブジェクトを指定する場合、
script_directory_object
パラメータを使用します。 -
ソース・ディレクトリ・オブジェクトは、データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化を実行し、
MAINTAIN_GLOBAL
、MAINTAIN_SCHEMAS
、MAINTAIN_SIMPLE_TTS
、MAINTAIN_TABLES
またはMAINTAIN_TTS
のいずれかのプロシージャを使用する場合に必要です。データ・ポンプ・エクスポート・ダンプ・ファイルおよびログ・ファイルは、ソース・データベースが実行されるコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行してソース・ディレクトリ・オブジェクトを指定する場合、source_directory_object
パラメータを使用します。PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャを使用する場合、このディレクトリ・オブジェクトは不要です。 -
接続先ディレクトリ・オブジェクトは、データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化を実行し、
MAINTAIN_GLOBAL
、MAINTAIN_SCHEMAS
、MAINTAIN_SIMPLE_TTS
、MAINTAIN_TABLES
またはMAINTAIN_TTS
のいずれかのプロシージャを使用する場合に必要です。ソース・データベースが実行されているコンピュータ・システムから宛先データベースが実行されているコンピュータ・システムにデータ・ポンプ・エクスポート・ダンプ・ファイルが転送され、宛先データベースが実行されているコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行して接続先ディレクトリ・オブジェクトを指定する場合、destination_directory_object
パラメータを使用します。PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャを使用する場合、このディレクトリ・オブジェクトは不要です。
各ディレクトリ・オブジェクトは、SQL文CREATE
DIRECTORY
を使用して作成する必要があります。また、いずれかのプロシージャをコールするユーザーは、各ディレクトリ・オブジェクトに対するREAD
およびWRITE
権限を持っている必要があります。
たとえば、次の手順を実行し、/usr/db_files
ディレクトリに対応するディレクトリ・オブジェクトdb_dir
を作成します。
ディレクトリ・オブジェクトを作成するユーザーには、そのディレクトリ・オブジェクトに対するREAD
およびWRITE
権限が自動的に割り当てられます。Oracle Streamsレプリケーション環境を構成している場合は、通常Oracle Streams管理者がディレクトリ・オブジェクトを作成します。
注意:
ディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。
2.2.4 ローカル取得を使用した2データベース・レプリケーションを構成する場合の例
次の各例では、1つ以上のローカル取得プロセスを使用した2データベース・レプリケーション環境を構成します。
2.2.4.1 ローカル取得を使用した2データベース・グローバル・レプリケーションの構成
DBMS_STREAMS_ADM
パッケージの次のプロシージャを使用すると、データベース・レベルでレプリケーションを構成できます。
MAINTAIN_GLOBAL
プロシージャでは、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境からは自動的に除外されます。PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャでは、データベース・オブジェクトが自動的に除外されません。かわりに、これらのプロシージャを使用すると、レプリケーション環境から除外するデータベース・オブジェクトを指定できます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTED
データ・ディクショナリ・ビューを問い合せます。サポートされないデータベース・オブジェクトが除外されていない場合は、取得エラーが発生します。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、両方のデータベースが読取り/書込み可能な2データベース環境における双方向のレプリケーションを構成します。 |
|
この例では、各ソース・データベースに対してローカル取得を構成します。 |
|
この例では、両方のデータベースにおいてレプリケートされたデータベース・オブジェクトへの変更が可能です。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、DDL変更をメンテナンスします。 |
|
この例では、 |
この例では、プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。RMANによるデータベースのインスタンス化を実行します。
前述の表で示されているように、この例では、PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャを使用してデータベース・レプリケーションを構成します。レプリケーション構成では、Oracle Streamsによってサポートされていないすべてのデータベースが除外されます。この例では、ソース・データベースはdbs1.example.com
、宛先データベースはdbs2.example.com
です。
図2-1に、この例で作成されるレプリケーション環境の概要を示します。
注意:
取得プロセスでは、SYS
、SYSTEM
またはCTXSYS
スキーマ内の変更は取得されません。これらのスキーマに対する変更は、この項で説明するレプリケーション環境でOracle Streamsによってメンテナンスされません。
関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。
次の手順を実行して、PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャを使用してレプリケーション環境を構成します。
-
PRE_INSTANTIATION_SETUP
プロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。この構成では、次のタスクを完了する必要があります。
-
両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
-
ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。
-
ソース・データベース
dbs1.example.com
と宛先データベースdbs2.example.com
との間で、ネットワーク接続を構成します。 -
ソース・データベース
dbs1.example.com
から宛先データベースdbs2.example.com
へのデータベース・リンクを作成します。
「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
-
-
両方のデータベースが
ARCHIVELOG
モードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。 -
両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
-
両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
宛先データベースからソース・データベースへのデータベース・リンクが必要です。ただし、データベースのインスタンス化にRMANが使用されるため、インスタンス化の後にこのデータベース・リンクを作成する必要があります。レプリケーション環境が双方向であり、データベースのインスタンス化にRMANが使用されるため、このデータベース・リンクが必要です。
-
-
SQL*Plusで、Oracle Streams管理者としてソース・データベース
dbs1.example.com
に接続します。SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
-
PRE_INSTANTIATION_SETUP
プロシージャを実行します。DECLARE empty_tbs DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET; BEGIN DBMS_STREAMS_ADM.PRE_INSTANTIATION_SETUP( maintain_mode => 'GLOBAL', tablespace_names => empty_tbs, source_database => 'dbs1.example.com', destination_database => 'dbs2.example.com', perform_actions => TRUE, bi_directional => TRUE, include_ddl => TRUE, start_processes => TRUE, exclude_schemas => '*', exclude_flags => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED + DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML + DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL); END; /
start_processes
パラメータがTRUE
に設定されていることに注意してください。したがって、構成中に作成される各取得プロセスおよび適用プロセスは、自動的に起動されます。また、
exclude_schemas
およびexclude_flags
パラメータに指定されている値に注意してください。exclude_schemas
に指定されているアスタリスク(*
)は、データベース内の各スキーマの特定のデータベース・オブジェクトがレプリケーション環境から除外されることを示します。exclude_flags
パラメータに指定されている値は、サポートされていないすべてのデータベース・オブジェクトに対するDML変更およびDDL変更がレプリケーション環境から除外されることを示します。ルールは、これらのデータベース・オブジェクトを除外するために取得プロセスのネガティブ・ルール・セットに入れられます。プロシージャはソース・データベースで実行されるため、ソース・データベースでローカル取得が構成されます。
このプロシージャでは双方向のレプリケーション環境が構成されるため、プロシージャの実行中に宛先データベースの共有データベース・オブジェクトに対するDML変更またはDDL変更を許可しないでください。
プロシージャには、
apply_name
パラメータを指定しません。したがって、このパラメータには、デフォルトでNULL
が指定されます。apply_name
パラメータをNULL
に設定すると、ソース・データベースからの変更を適用する適用プロセスは、宛先データベース上に存在することができません。ソース・データベースからの変更を適用する適用プロセスが宛先データベースに存在する場合、NULL
でない値をapply_name
パラメータに指定します。構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。
このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。
-
インスタンス化を実行します。「インスタンス化とOracle Streamsレプリケーション」で説明されているいずれの方法でもインスタンス化を実行できます。この例では、次の手順を実行することによって、RMANの
DUPLICATE
コマンドを使用してインスタンス化を実行します。-
ソース・データベースのバックアップを作成します(存在しない場合)。RMANには、複製用に有効なバックアップが必要です。この例では、
dbs1.example.com
のバックアップが存在しない場合は作成します。注意:
RMANの
DUPLICATE
コマンドを実行する際にFROM
ACTIVE
DATABASE
オプションを使用する場合、ソース・データベースのバックアップは不要です。大規模なデータベースでは、FROM
ACTIVE
DATABASE
オプションの実行に大量のネットワーク・リソースが必要になります。この例では、このオプションは使用しません。 -
SQL*Plusで、Oracle Streams管理者としてソース・データベース
dbs1.example.com
に接続します。SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
-
RMANの
DUPLICATE
コマンドに指定する終了SCNを判断します。SET SERVEROUTPUT ON SIZE 1000000 DECLARE until_scn NUMBER; BEGIN until_scn:= DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; DBMS_OUTPUT.PUT_LINE('Until SCN: ' || until_scn); END; /
戻された終了SCNをメモします。この番号は手順4.hで使用します。この例では、戻された終了SCNが
45442631
であると想定します。 -
SQL*Plusで、管理ユーザーとしてソース・データベース
dbs1.example.com
に接続します。 -
現行のオンラインREDOログをアーカイブします。
ALTER SYSTEM ARCHIVE LOG CURRENT;
-
データベースの複製用に環境を準備します。宛先データベースを複製の補助インスタンスとして準備します。手順については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 を参照してください。
-
RMANクライアントを起動し、
TARGET
としてソース・データベースdbs1.example.com
、AUXILIARY
として宛先データベースdbs2.example.com
に接続します。関連項目:
RMANの
CONNECT
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 -
OPEN
RESTRICTED
オプションを指定してRMANのDUPLICATE
コマンドを実行し、宛先データベースでソース・データベースをインスタンス化します。OPEN
RESTRICTED
オプションは必須です。このオプションを指定すると、SQL文ALTER
SYSTEM
ENABLE
RESTRICTED
SESSION
を発行することによって、複製データベースで制限付きセッションを有効にできます。RMANは、複製データベースがオープン状態になる直前にこの文を発行します。UNTIL
SCN
句を使用して、複製用のSCNを指定できます。この句には、手順4.cで判断した終了SCNを使用します。アーカイブREDOログは、指定した終了SCN値以上で使用可能である必要があります。したがって、手順4.eでは、終了SCNを含むREDOログをアーカイブしています。DUPLICATE
コマンドのTO
database_name
に、複製データベースの名前を指定していることを確認してください。この例では、複製データベースはdbs2.example.com
です。したがって、この例のDUPLICATE
コマンドにはTO
dbs2.example.com
が含まれます。次に、RMANの
DUPLICATE
コマンドの例を示します。RMAN> RUN { SET UNTIL SCN 45442631; ALLOCATE AUXILIARY CHANNEL dbs2 DEVICE TYPE sbt; DUPLICATE TARGET DATABASE TO dbs2 NOFILENAMECHECK OPEN RESTRICTED; }
関連項目:
RMANの
DUPLICATE
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 -
SQL*Plusで、管理ユーザーとして宛先データベースに接続します。
-
グローバル名を変更します。RMANによるデータベースのインスタンス化を実行すると、宛先データベースはソース・データベースと同じグローバル名を持ちます。次の文を使用して、宛先データベースのグローバル名を元の名前に戻します。
ALTER DATABASE RENAME GLOBAL_NAME TO dbs2.example.com;
-
SQL*Plusで、Oracle Streams管理者として宛先データベース
dbs2.example.com
に接続します。 -
ソース・データベースからクローニングされた、ソース・データベースから宛先データベースへのデータベース・リンクを削除します。
DROP DATABASE LINK dbs2.example.com;
-
-
宛先データベースにOracle Streams管理者として接続したままで、宛先データベースからソース・データベースにデータベース・リンクを作成します。
CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin IDENTIFIED BY password USING 'dbs1.example.com';
このデータベース・リンクが必要な理由については、手順1を参照してください。
-
SQL*Plusで、Oracle Streams管理者としてソース・データベース
dbs1.example.com
に接続します。 -
POST_INSTANTIATION_SETUP
プロシージャを実行します。DECLARE empty_tbs DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET; BEGIN DBMS_STREAMS_ADM.POST_INSTANTIATION_SETUP( maintain_mode => 'GLOBAL', tablespace_names => empty_tbs, source_database => 'dbs1.example.com', destination_database => 'dbs2.example.com', perform_actions => TRUE, bi_directional => TRUE, include_ddl => TRUE, start_processes => TRUE, instantiation_scn => 45442630, exclude_schemas => '*', exclude_flags => DBMS_STREAMS_ADM.EXCLUDE_FLAGS_UNSUPPORTED + DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DML + DBMS_STREAMS_ADM.EXCLUDE_FLAGS_DDL); END; /
PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャの両方に指定されたパラメータ値が一致する必要があります。ただし、perform_actions
、script_name
、script_directory_object
およびstart_processes
は除きます。また、
instantiation_scn
パラメータが45442630
に設定されていることに注意してください。RMANのDUPLICATE
コマンドを実行すると、UNTIL
SCN
句で指定したSCN値より1つ少ない値まで、データベースが複製されます。したがって、手順4.h4でDUPLICATE
コマンドを実行した際に指定した終了SCN値から1を引く必要があります。この例では、終了SCNを45442631
に設定しています。したがって、instantiation_scn
パラメータは45442631 - 1の45442630
に設定する必要があります。インスタンス化中に宛先データベースの共有データベース・オブジェクトにインスタンス化SCNが設定されている場合、
instantiation_scn
パラメータをNULL
に設定する必要があります。たとえば、全データベースのエクスポート/インポート中にインスタンス化SCNが設定される場合があります。このプロシージャでは双方向のレプリケーション環境が構成されるため、プロシージャの実行中に宛先データベースの共有データベース・オブジェクトに対するDML変更またはDDL変更を許可しないでください。
構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。
このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。
-
SQL*Plusで宛先データベースに管理ユーザーとして接続し、
ALTER
SYSTEM
文を実行してRESTRICTED
SESSION
を無効化します。ALTER SYSTEM DISABLE RESTRICTED SESSION;
-
必要に応じて、共有データベース・オブジェクトの競合解消を構成します。
通常、双方向のレプリケーション環境では、競合が発生する可能性があります。
PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャによって作成された環境で競合が発生する可能性がある場合は、共有データベース・オブジェクトに対する変更をユーザーに許可する前に競合解消を構成します。詳細は、「Oracle Streamsの競合解消」を参照してください。
この例で構成された双方向のレプリケーション環境には、次の特性があります。
-
両方のデータベースでデータベース・サプリメンタル・ロギングが構成されています。
-
dbs1.example.com
データベースには、システム生成名を持つ2つのキューおよびキュー表があります。1つのキューはローカル取得プロセス用で、もう1つのキューは適用プロセス用です。 -
dbs2.example.com
データベースには、システム生成名を持つ2つのキューおよびキュー表があります。1つのキューはローカル取得プロセス用で、もう1つのキューは適用プロセス用です。 -
dbs1.example.com
データベースで、システム生成名を持つ取得プロセスが、Oracle Streamsによってサポートされているデータベース内のすべてのデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。 -
dbs2.example.com
データベースで、システム生成名を持つ取得プロセスが、Oracle Streamsによってサポートされているデータベース内のすべてのデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。 -
dbs1.example.com
データベースで実行されているシステム生成名を持つ伝播が、dbs1.example.com
データベースのキューからdbs2.example.com
データベースのキューに取得された変更を送信します。 -
dbs2.example.com
データベースで実行されているシステム生成名を持つ伝播が、dbs2.example.com
データベースのキューからdbs1.example.com
データベースのキューに取得された変更を送信します。 -
dbs1.example.com
で、システム生成名を持つ適用プロセスが、そのキューから変更をデキューしてこれらの変更をデータベース・オブジェクトに適用します。 -
dbs2.example.com
で、システム生成名を持つ適用プロセスが、そのキューから変更をデキューしてこれらの変更をデータベース・オブジェクトに適用します。 -
タグを使用して、変更の循環が回避されます。具体的には、適用プロセスによって適用される変更のREDOレコードにタグが含まれるように、各適用プロセスで適用タグが使用されます。各適用プロセスは、レプリケーション環境で一意の適用タグを使用します。各伝播は、同じデータベースで実行されている適用プロセスのタグを持つ変更を廃棄します。詳細は、「変更の循環とタグ」を参照してください。
2.2.4.2 ローカル取得を使用した2データベース・スキーマ・レプリケーションの構成
この例では、hr
スキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、ローカル取得プロセスを使用して変更を取得する2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名db1.example.com
およびdb2.example.com
を使用します。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、一方向または双方向のレプリケーションを構成する手順を説明します。双方向のレプリケーションを構成するには、追加の手順を完了し、構成プロシージャの実行時に |
|
この例では、ソース・データベースに対してローカル取得を構成します。 |
|
この例では、1つのデータベースまたは両方のデータベースで変更を許可するかどうかを選択できます。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、DDL変更をメンテナンスします。 |
|
この例では、 |
MAINTAIN_SCHEMAS
プロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMAS
プロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMAS
プロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMAS
プロシージャを実行する前に、db1.example.com
データベースとdb2.example.com
データベースの両方にhr
スキーマが存在します。
この例では、MAINTAIN_SCHEMAS
プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。
図2-2に、この例で作成される環境の概要を示します。双方向のレプリケーションに必要な追加コンポーネントはグレーで表示し、これらのコンポーネントのアクションは点線で示しています。
MAINTAIN_SCHEMAS
プロシージャを使用して環境を構成するには、次の手順を実行します。
-
次のタスクを完了して、2データベース・レプリケーション環境を準備します。
-
db1.example.com
データベースがdb2.example.com
データベースと通信できるようにネットワーク接続を構成します。データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。
-
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者が
strmadmin
であると想定しています。 -
db1.example.com
データベースからdb2.example.com
データベースへのデータベース・リンクを作成します。データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクは、他のデータベースのOracle Streams管理者に接続する必要があります。データベース・リンクの名前とサービス名の両方が
db2.example.com
である必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。 -
ARCHIVELOG
モードで実行するようにdb1.example.com
データベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOG
モードで実行する必要があります。ARCHIVELOG
モードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
-
-
双方向のレプリケーション環境を構成するには、次の手順を実行します。一方向のレプリケーション環境を構成する場合は、これらの手順は必要ありませんので、手順3に進みます。
-
db2.example.com
データベースからdb1.example.com
データベースへのデータベース・リンクを作成します。データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクは、他のデータベースのOracle Streams管理者に接続する必要があります。データベース・リンクの名前とサービス名の両方が
db1.example.com
である必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。 -
ARCHIVELOG
モードで実行するようにdb2.example.com
データベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOG
モードで実行する必要があります。ARCHIVELOG
モードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
-
-
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
-
次に示す必要なディレクトリ・オブジェクトを作成します。
-
ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトは
source_directory
であると想定しています。 -
宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトは
dest_directory
であると想定しています。
手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
-
-
SQL*Plusで、Oracle Streams管理者として
db1.example.com
データベースに接続します。SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
-
MAINTAIN_SCHEMAS
プロシージャを実行して、db1.example.com
データベースとdb2.example.com
データベース間でhr
スキーマのレプリケーションを構成します。構成しているレプリケーション環境に対して
bi_directional
パラメータが適切に設定されていることを確認します。このパラメータは、一方向のレプリケーションの場合にはFALSE
、双方向のレプリケーションの場合にはTRUE
に設定します。BEGIN DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS( schema_names => 'hr', source_directory_object => 'source_directory', destination_directory_object => 'dest_directory', source_database => 'db1.example.com', destination_database => 'db2.example.com', bi_directional => FALSE); -- Set to TRUE for bi-directional END; /
MAINTAIN_SCHEMAS
プロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースのレプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビュー
DBA_RECOVERABLE_SCRIPT
、DBA_RECOVERABLE_SCRIPT_PARAMS
、DBA_RECOVERABLE_SCRIPT_BLOCKS
およびDBA_RECOVERABLE_SCRIPT_ERRORS
に記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADM
パッケージのRECOVER_OPERATION
プロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。 -
双方向のレプリケーションを構成する場合は、両方のデータベースの
hr
スキーマあるすべての表に対して最新時刻競合解消を構成します。このスキーマには、countries
、departments
、employees
、jobs
、job_history
、locations
およびregions
の表が含まれています。手順については、「Oracle Streamsの競合解消」を参照してください。
関連項目:
Oracle Enterprise Manager Cloud Controlを使用してこのレプリケーション環境を構成する場合の例については、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。
2.2.4.3 ローカル取得を使用した2データベース表レプリケーションの構成
DBMS_STREAMS_ADM
パッケージのMAINTAIN_TABLES
プロシージャを使用すると、表レプリケーションを構成できます。この項の例では、このプロシージャを使用して、hr
スキーマ内の特定の表をメンテナンスするOracle Streamsレプリケーション環境を構成します。ソース・データベースはdbs1.example.com
で、接続データベースはdbs2.example.com
です。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。 |
|
この例では、ソース・データベースに対してローカル取得を構成します。 |
|
この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、共有データベース・オブジェクトのサブセットに対するDDL変更をメンテナンスします。 |
|
この例では、 |
レプリケーション環境では、共有データベース・オブジェクトに対する次のDML変更およびDDL変更がメンテナンスされます。
-
レプリケーション環境では、
hr
スキーマ内の次の表に対するDML変更がメンテナンスされます。-
departments
-
employees
-
countries
-
regions
-
locations
-
jobs
-
job_history
-
-
レプリケーション環境では、
hr
スキーマ内の次の表に対するDDL変更がメンテナンスされます。-
departments
-
employees
-
レプリケーション環境では、hr
スキーマ内の次の表に対するDDL変更はメンテナンスされません。
-
countries
-
regions
-
locations
-
jobs
-
job_history
この例では、MAINTAIN_TABLES
プロシージャでレプリケーション環境を直接構成しません。かわりに、構成スクリプトを生成し、departments
およびemployees
表に対するDDL変更がメンテナンスされるようにこのスクリプトを変更します。データ・ポンプ・ネットワーク・インポートによるインスタンス化が実行されます。
Oracle Streamsによってサポートされていない表は、レプリケートしないようにしてください。
図2-3に、この例で作成されるレプリケーション環境の概要を示します。
関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。
MAINTAIN_TABLES
プロシージャを使用して環境を構成するには、次の手順を実行します。
-
MAINTAIN_TABLES
プロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。この構成では、次のタスクを完了する必要があります。
-
両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
-
ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。
-
ソース・データベース
dbs1.example.com
と宛先データベースdbs2.example.com
との間で、ネットワーク接続を構成します。 -
ソース・データベース
dbs1.example.com
から宛先データベースdbs2.example.com
へのデータベース・リンクを作成します。 -
MAINTAIN_TABLES
プロシージャではデータ・ポンプ・ネットワーク・インポートによるインスタンス化が実行されるため、宛先データベースdbs2.example.com
からソース・データベースdbs1.example.com
へのデータベース・リンクを作成します。
「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
-
-
ソース・データベース
dbs1.example.com
がARCHIVELOG
モードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。 -
両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
-
両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
-
-
ソース・データベースでスクリプト・ディレクトリ・オブジェクトを作成します。この例では、このディレクトリ・オブジェクトは
script_directory
であると想定しています。手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
-
SQL*Plusで、Oracle Streams管理者としてソース・データベース
dbs1.example.com
に接続します。SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
-
MAINTAIN_TABLES
プロシージャを実行します。DECLARE tables DBMS_UTILITY.UNCL_ARRAY; BEGIN tables(1) := 'hr.departments'; tables(2) := 'hr.employees'; tables(3) := 'hr.countries'; tables(4) := 'hr.regions'; tables(5) := 'hr.locations'; tables(6) := 'hr.jobs'; tables(7) := 'hr.job_history'; DBMS_STREAMS_ADM.MAINTAIN_TABLES( table_names => tables, source_directory_object => NULL, destination_directory_object => NULL, source_database => 'dbs1.example.com', destination_database => 'dbs2.example.com', perform_actions => FALSE, script_name => 'configure_rep.sql', script_directory_object => 'script_directory', bi_directional => FALSE, include_ddl => FALSE, instantiation => DBMS_STREAMS_ADM.INSTANTIATION_TABLE_NETWORK); END; /
プロシージャによって生成された
configure_rep.sql
スクリプトでは、プロシージャのコールで指定されていないパラメータにデフォルト値が使用されます。スクリプトでは、作成するANYDATA
キュー、キュー表、取得プロセス、伝播および適用プロセスにシステム生成名が使用されます。MAINTAIN_TABLES
プロシージャに使用可能な追加のパラメータを使用して、異なる名前を指定することもできます。include_ddl
パラメータがFALSE
に設定されていることに注意してください。したがって、このスクリプトでは、表に対するDDL変更をメンテナンスするようにレプリケーション環境が構成されません。プロシージャには、
apply_name
パラメータを指定しません。したがって、このパラメータには、デフォルトでNULL
が指定されます。apply_name
パラメータをNULL
に設定すると、ソース・データベースからの変更を適用する適用プロセスは、宛先データベース上に存在することができません。ソース・データベースからの変更を適用する適用プロセスが宛先データベースに存在する場合、NULL
でない値をapply_name
パラメータに指定します。 -
configure_rep.sql
スクリプトを変更します。-
ソース・データベースが実行されているコンピュータ・システムの
script_directory
ディレクトリ・オブジェクトに対応するディレクトリにナビゲートします。 -
テキスト・エディタで
configure_rep.sql
スクリプトをオープンします。このスクリプトを変更する前に、このスクリプトをバックアップすることを検討してください。 -
スクリプトで、
hr.departments
およびhr.employees
表のルールを作成するADD_TABLE_RULES
およびADD_TABLE_PROPAGATION_RULES
プロシージャのコールを検索します。たとえば、取得プロセスのプロシージャ・コールは次のようになります。dbms_streams_adm.add_table_rules( table_name => '"HR"."DEPARTMENTS"', streams_type => 'CAPTURE', streams_name => '"DBS1$CAP"', queue_name => '"STRMADMIN"."DBS1$CAPQ"', include_dml => TRUE, include_ddl => FALSE, include_tagged_lcr => TRUE, source_database => 'DBS1.EXAMPLE.COM', inclusion_rule => TRUE, and_condition => get_compatible); dbms_streams_adm.add_table_rules( table_name => '"HR"."EMPLOYEES"', streams_type => 'CAPTURE', streams_name => '"DBS1$CAP"', queue_name => '"STRMADMIN"."DBS1$CAPQ"', include_dml => TRUE, include_ddl => FALSE, include_tagged_lcr => TRUE, source_database => 'DBS1.EXAMPLE.COM', inclusion_rule => TRUE, and_condition => get_compatible);
-
手順5.cで検索したプロシージャ・コールで、
include_ddl
パラメータの設定をTRUE
に変更します。たとえば、変更後の取得プロセスのプロシージャ・コールは次のようになります。dbms_streams_adm.add_table_rules( table_name => '"HR"."DEPARTMENTS"', streams_type => 'CAPTURE', streams_name => '"DBS1$CAP"', queue_name => '"STRMADMIN"."DBS1$CAPQ"', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'DBS1.EXAMPLE.COM', inclusion_rule => TRUE, and_condition => get_compatible); dbms_streams_adm.add_table_rules( table_name => '"HR"."EMPLOYEES"', streams_type => 'CAPTURE', streams_name => '"DBS1$CAP"', queue_name => '"STRMADMIN"."DBS1$CAPQ"', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => 'DBS1.EXAMPLE.COM', inclusion_rule => TRUE, and_condition => get_compatible);
すべての取得プロセス、伝播および適用プロセスのプロシージャ・コールを変更する必要があります。
-
configure_rep.sql
スクリプトを保存してクローズします。
-
-
SQL*Plusで、Oracle Streams管理者としてソース・データベース
dbs1.example.com
に接続します。 -
ソース・データベースで、次の構成スクリプトを実行します。
SET ECHO ON SPOOL configure_rep.out @configure_rep.sql
スクリプトを実行すると、データベース名およびOracle Streams管理者に関する情報を入力するように求められます。この構成スクリプトが完了すると、単一ソースのOracle Streamsレプリケーション環境が構成されます。また、このスクリプトによって、キュー、取得プロセス、伝播および適用プロセスが起動されます。
構成された単一ソース・レプリケーション環境には、次の特性があります。
-
ソース・データベースで、共有データベース・オブジェクトのサプリメンタル・ロギングが構成されています。
-
ソース・データベース
dbs1.example.com
には、システム生成名を持つキューおよびキュー表があります。 -
宛先データベース
dbs2.example.com
には、システム生成名を持つキューおよびキュー表があります。 -
ソース・データベースで、システム生成名を持つ取得プロセスが、
hr
スキーマ内のすべての表に対するDML変更、およびhr.departments
およびhr.employees
表に対するDDL変更を取得します。 -
ソース・データベースで実行されているシステム生成名を持つ伝播が、ソース・データベースのキューから宛先データベースのキューに取得された変更を送信します。
-
宛先データベースで、システム生成名を持つ適用プロセスが、キューから変更をデキューしてこれらの変更を宛先データベースの表に適用します。
2.2.5 ダウンストリーム取得を使用した2データベース・レプリケーションを構成する場合の例
次の各例では、ダウンストリーム取得プロセスを使用した2データベース・レプリケーション環境を構成します。
2.2.5.1 宛先でダウンストリーム取得を使用した表領域レプリケーションの構成
DBMS_STREAMS_ADM
パッケージの次のプロシージャを使用すると、表領域レプリケーションを構成できます。
MAINTAIN_SIMPLE_TTS
プロシージャを使用すると、単一の表領域にOracle Streamsレプリケーションを構成でき、MAINTAIN_TTS
プロシージャを使用すると、自己完結型の表領域セットにOracle Streamsレプリケーションを構成できます。これらのプロシージャでは、トランスポータブル表領域、データ・ポンプ、DBMS_STREAMS_TABLESPACE_ADM
パッケージおよびDBMS_FILE_TRANSFER
パッケージを使用して、環境が構成されます。
自己完結型の表領域には、その表領域の外部を指す表領域からの参照は含まれません。たとえば、表領域の索引が異なる表領域の表に対する索引である場合、その表領域は自己完結型ではありません。単一の表領域は、データ・ファイルを1つのみ使用する自己完結型の表領域です。表領域セットに複数の表領域が存在する場合、自己完結型の表領域セットには、その表領域セットの外部を指す表領域セット内からの参照は含まれません。
これらのプロシージャでは、レプリケーション用に構成された表領域が、ソース・データベースから宛先データベースにクローニングされます。MAINTAIN_SIMPLE_TTS
プロシージャでは、DBMS_STREAMS_TABLESPACE_ADM
パッケージのCLONE_SIMPLE_TABLESPACE
プロシージャが使用され、MAINTAIN_TTS
プロシージャでは、DBMS_STREAMS_TABLESPACE_ADM
パッケージのCLONE_TABLESPACES
プロシージャが使用されます。表領域がクローニングされると、この表領域はクローン操作が完了するまで自動的に読取り専用になります。
この項の例では、MAINTAIN_TTS
プロシージャを使用して、Oracle Streamsを使用して次の表領域をメンテナンスするOracle Streamsレプリケーション環境を構成します。
-
tbs1
-
tbs2
ソース・データベースはdbs1.example.com
で、接続データベースはdbs2.example.com
です。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。 |
|
この例では、ソース・データベース( |
|
この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、表領域および表領域内のデータベース・オブジェクトに対するDDL変更をメンテナンスします。 |
|
この例では、 |
この例では、MAINTAIN_TTS
プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。また、この例では、次のことを想定しています。
-
表領域
tbs1
およびtbs2
が、ソース・データベースdbs1.example.com
に自己完結型の表領域セットを構成しています。 -
表領域セットのデータ・ファイルは、いずれもソース・データベース
dbs1.example.com
の/orc/dbs
ディレクトリに存在します。 -
dbs2.example.com
データベースには現在、表領域セットは含まれていません。
MAINTAIN_SIMPLE_TTS
およびMAINTAIN_TTS
プロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。PRE_INSTANTIATION_SETUP
およびPOST_INSTANTIATION_SETUP
プロシージャを使用すると、レプリケーション環境から除外するデータベース・オブジェクトを指定できます。
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTED
データ・ディクショナリ・ビューを問い合せます。サポートされないデータベース・オブジェクトが除外されていない場合は、取得エラーが発生します。
図2-4に、この例で作成されるレプリケーション環境の概要を示します。
関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。
MAINTAIN_TTS
プロシージャを使用して環境を構成するには、次の手順を実行します。
構成された単一ソース・レプリケーション環境には、次の特性があります。
-
ソース・データベース
dbs1.example.com
で共有データベース・オブジェクトにサプリメンタル・ロギングが構成されています。 -
dbs1.example.com
データベースには、キュー表streams_queue_table
を使用するキューstreams_queue
があります。このキューは適用プロセス用です。 -
dbs2.example.com
データベースには、キュー表streams_queue_table
を使用するキューstreams_queue
があります。このキューは、ダウンストリーム取得プロセスと適用プロセスで共有されます。 -
dbs2.example.com
データベースでは、アーカイブ・ログ・ダウンストリーム取得プロセスcapture_tts
が、ソース・データベースに対する変更を取得します。具体的には、このダウンストリーム取得プロセスは、tbs1
およびtbs2
表領域内の表に対するDML変更、およびこれらの表領域およびそのデータベース・オブジェクトに対するDDL変更を取得します。異常に長い時間が経っても取得プロセスが有効化されない場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。
-
dbs2.example.com
では、適用プロセスapply_tts
が、そのキューから変更をデキューしてそれらの変更を共有データベース・オブジェクトに適用します。
2.2.5.2 宛先でダウンストリーム取得を使用したスキーマ・レプリケーションの構成
この例では、hr
スキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、宛先データベースでダウンストリーム取得プロセスを使用した2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名src.example.com
およびdest.example.com
を使用します。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。2データベース・レプリケーション環境の詳細は、「どのタイプのレプリケーション環境を構成するかの決定」を参照してください。
この例では、宛先データベースdest.example.com
でダウンストリーム取得プロセスが実行されます。したがって、変更の取得に必要なリソースは、ソース・データベースsrc.example.com
で解放されます。この例では、アーカイブ・ログ・ダウンストリーム取得プロセスではなく、リアルタイム・ダウンストリーム取得プロセスを構成します。リアルタイム・ダウンストリーム取得の利点は、ソース・データベースで行われた変更を取得するのに必要な時間が軽減されることです。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。 |
|
この例では、ソース・データベース( |
|
この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、表領域および表領域内のデータベース・オブジェクトに対するDDL変更をメンテナンスします。 |
|
この例では、 |
MAINTAIN_SCHEMAS
プロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMAS
プロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMAS
プロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMAS
プロシージャを実行する前に、src.example.com
データベースとdest.example.com
データベースの両方にhr
スキーマが存在します。
この例では、MAINTAIN_SCHEMAS
プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。
図2-5に、この例で作成される環境の概要を示します。
MAINTAIN_SCHEMAS
プロシージャを使用して環境を構成するには、次の手順を実行します。
-
次のタスクを完了して、2データベース・レプリケーション環境を準備します。
-
src.example.com
データベースがdest.example.com
データベースと相互に通信できるようにネットワーク接続を構成します。データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。
-
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者が
strmadmin
であると想定しています。 -
ソース・データベースから宛先データベースおよび宛先データベースからソース・データベースへのデータベース・リンクを作成します。この例では、次のデータベース・リンクを作成します。
-
src.example.com
データベースからdest.example.com
データベース。データベース・リンクの名前とサービス名の両方がdest.example.com
である必要があります。 -
dest.example.com
データベースからsrc.example.com
データベース。データベース・リンクの名前とサービス名の両方がsrc.example.com
である必要があります。
src.example.com
データベースは、dest.example.com
データベースで行うダウンストリーム取得プロセスのソース・データベースであるため、dest.example.com
データベースからsrc.example.com
データベースへのデータベース・リンクは必須です。このデータベース・リンクによって、取得プロセスの作成と構成が簡素化されます。各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、各データベース・リンクは、他のデータベースのOracle Streams管理者に接続する必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
-
-
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
-
ARCHIVELOG
モードで実行するように両方のデータベースを構成します。ダウンストリーム取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースとダウンストリーム取得データベースの両方をARCHIVELOG
モードで実行する必要があります。この例では、src.example.com
およびdest.example.com
データベースがARCHIVELOG
モードで実行されている必要があります。ARCHIVELOG
モードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。 -
宛先データベース(
dest.example.com
)をソース・データベースに対する変更の取得データベースとして使用するため、ソース・データベースsrc.example.com
から宛先データベースdest.example.com
へのログ・ファイルのコピーを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。 -
この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、ダウンストリーム・データベースでスタンバイREDOログを追加します。「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」を参照してください。
-
-
次に示す必要なディレクトリ・オブジェクトを作成します。
-
ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトは
source_directory
であると想定しています。 -
宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトは
dest_directory
であると想定しています。
手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
-
-
SQL*Plusで、Oracle Streams管理者として
dest.example.com
データベースに接続します。SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
-
引き続きOracle Streams管理者として
dest.example.com
データベースに接続したままで、MAINTAIN_SCHEMAS
プロシージャを実行して、src.example.com
データベースとdest.example.com
データベースの間にレプリケーションを構成します。BEGIN DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS( schema_names => 'hr', source_directory_object => 'source_directory', destination_directory_object => 'dest_directory', source_database => 'src.example.com', destination_database => 'dest.example.com', capture_name => 'capture', capture_queue_table => 'streams_queue_qt', capture_queue_name => 'streams_queue', apply_name => 'apply', apply_queue_table => 'streams_queue_qt', apply_queue_name => 'streams_queue'); END; /
MAINTAIN_SCHEMAS
プロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースのレプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。MAINTAIN_SCHEMAS
プロシージャの必須パラメータは、schema_names
、source_directory_object
、destination_directory_object
、source_database
およびdestination_database
のみです。この例では、他のパラメータを指定して、取得プロセス、取得プロセスのキュー表、取得プロセスのキュー、適用プロセス、適用プロセスのキュー表および適用プロセスのキューの名前を選択可能であることを示しています。これらのパラメータを指定しない場合は、システム生成名が使用されます。
構成プロシージャを使用してダウンストリーム取得を構成する場合は、キューとキュー表の名前を指定するパラメータが重要になります。このような構成では、取得プロセスと適用プロセスでダウンストリーム取得データベースの同じキューを使用してキュー間の変更の伝播を回避すると効率的です。この構成例では、効率を向上させるために、
capture_queue_name
パラメータとapply_queue_name
パラメータの両方にstreams_queue
を指定しています。また、capture_queue_table
パラメータとapply_queue_table
パラメータの両方にstreams_queue_qt
を指定しています。構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビュー
DBA_RECOVERABLE_SCRIPT
、DBA_RECOVERABLE_SCRIPT_PARAMS
、DBA_RECOVERABLE_SCRIPT_BLOCKS
およびDBA_RECOVERABLE_SCRIPT_ERRORS
に記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADM
パッケージのRECOVER_OPERATION
プロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。プロシージャが正常に完了したら、次の手順に進みます。
-
引き続きOracle Streams管理者として
dest.example.com
データベースに接続したままで、downstream_real_time_mine
取得プロセス・パラメータをY
に設定します。BEGIN DBMS_CAPTURE_ADM.SET_PARAMETER( capture_name => 'capture', parameter => 'downstream_real_time_mine', value => 'Y'); END; /
-
SQL*Plusで、管理ユーザーとしてソース・データベース
src.example.com
に接続します。 -
ソース・データベースで現行のログ・ファイルをアーカイブします。
ALTER SYSTEM ARCHIVE LOG CURRENT;
ソース・データベースで現行のログ・ファイルをアーカイブすると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。
取得プロセスがREDOデータを待機している時間が異常に長い場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。
関連項目:
Oracle Enterprise Manager Cloud Controlを使用してこのレプリケーション環境を構成する場合の例については、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。
2.2.5.3 第3のデータベースでダウンストリーム取得を使用したスキーマ・レプリケーションの構成
DBMS_STREAMS_ADM
パッケージのMAINTAIN_SCHEMAS
プロシージャを使用すると、スキーマ・レプリケーションを構成できます。この項の例では、このプロシージャを使用して、hr
スキーマをメンテナンスするOracle Streamsレプリケーション環境を構成します。ソース・データベースはdbs1.example.com
、宛先データベースはdbs3.example.com
です。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、両方のデータベースが読取り/書込み可能な2データベース環境における双方向のレプリケーションを構成します。 |
|
この例では、ソース・データベース( |
|
この例では、レプリケートされたデータベース・オブジェクトへの変更が両方のデータベースにおいて可能なレプリケーション環境を構成します。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、 |
|
この例では、 |
この例では、MAINTAIN_SCHEMAS
プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。
MAINTAIN_SCHEMAS
プロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTED
データ・ディクショナリ・ビューを問い合せます。サポートされないデータベース・オブジェクトが除外されていない場合は、取得エラーが発生します。
図2-6に、この例で作成されるレプリケーション環境の概要を示します。
関連項目:
Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。
MAINTAIN_SCHEMAS
プロシージャを使用して環境を構成するには、次の手順を実行します。
この例で構成された双方向のレプリケーション環境には、次の特性があります。
-
ソース・データベースおよび宛先データベースで共有データベース・オブジェクトのサプリメンタル・ロギングが構成されています。
-
dbs1.example.com
データベースには、キュー表rep_dest_queue_table
を使用するキューrep_dest_queue
があります。このキューは適用プロセス用です。 -
dbs3.example.com
データベースには、キュー表rep_capture_queue_table
を使用するキューrep_capture_queue
があります。このキューはローカル取得プロセス用です。 -
dbs3.example.com
データベースには、キュー表rep_dest_queue_table
を使用するキューrep_dest_queue
があります。このキューは適用プロセス用です。 -
dbs2.example.com
データベースには、キュー表rep_capture_queue_table
を使用するキューrep_capture_queue
があります。このキューはダウンストリーム取得プロセス用です。 -
dbs2.example.com
データベースで、リアルタイム・ダウンストリームの取得プロセスcapture_hr
が、hr
スキーマおよびソース・データベースのスキーマ内のデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。 -
dbs3.example.com
データベースで、ローカル取得プロセスcapture_hr
が、hr
スキーマおよび宛先データベースのスキーマ内のデータベース・オブジェクトに対するDML変更およびDDL変更を取得します。 -
dbs2.example.com
データベースで実行されている伝播prop_hr
が、dbs2.example.com
データベースのキューからdbs3.example.com
データベースのキューに取得された変更を送信します。 -
dbs3.example.com
データベースで実行されている伝播prop_hr
が、dbs3.example.com
データベースのキューからdbs1.example.com
データベースのキューに取得された変更を送信します。 -
dbs1.example.com
データベースで、適用プロセスapply_hr
が、rep_dest_queue
から変更をデキューしてそれらの変更をデータベース・オブジェクトに適用します。 -
dbs3.example.com
データベースで、適用プロセスapply_hr
が、rep_dest_queue
から変更をデキューしてそれらの変更をデータベース・オブジェクトに適用します。 -
タグを使用して、変更の循環が回避されます。具体的には、適用プロセスによって適用される変更のREDOレコードにタグが含まれるように、各適用プロセスで適用タグが使用されます。各適用プロセスは、レプリケーション環境で一意の適用タグを使用します。各伝播は、同じデータベースで実行されている適用プロセスのタグを持つ変更を廃棄します。詳細は、「変更の循環とタグ」を参照してください。
2.2.6 同期取得を使用した2データベース・レプリケーションを構成する場合の例
この例では、hr
スキーマの2つの表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、各データベースで同期取得を使用して変更を取得します。この例では、Oracle Streamsレプリケーション環境で、データベースのグローバル名にsync1.example.com
およびsync2.example.com
を使用します。ただし、例を完了するために、ご使用の環境の2つのデータベースに置き換えることもできます。
具体的に、この例では、sync1.example.com
およびsync2.example.com
データベースでhr.employees
およびhr.departments
表を共有するOracle Streamsの2データベース・レプリケーション環境を構成します。2つのデータベースは、すべてのDML変更をこれらの表にレプリケートします。
注意:
同期取得は、表レベルの変更のみ取得できます。スキーマ・レベルまたはデータベース・レベルの変更は取得できません。同期取得を構成するには、DBMS_STREAMS_ADM
パッケージのADD_TABLE_RULES
およびADD_SUBSET_RULES
プロシージャを使用します。
図2-7に、この例で作成される環境の概要を示します。
このレプリケーション環境を同期取得で構成するには:
-
次のタスクを完了して、2データベース・レプリケーション環境を準備します。
-
2つのデータベースが相互に通信できるようにネットワーク接続を構成します。詳細は、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
-
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。詳細は、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者が
strmadmin
であると想定しています。 -
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。詳細は、「Oracle Streamsレプリケーションの準備」を参照してください。
-
hr.employees
およびhr.departments
表が2つのデータベースに存在し、これらのデータベースで一貫していることを確認します。データベース・オブジェクトが1つのデータベースにのみ存在する場合は、エクスポート/インポートを使用してこれらを他のデータベースで作成および移入できます。エクスポート/インポートの詳細は、『Oracle Databaseユーティリティ』を参照してください。
-
-
各データベースに2つの
ANYDATA
キューを作成します。この例では、各データベースに次の2つのキューを作成します。-
Oracle Streams管理者
strmadmin
が所有する、capture_queue
という名前のキュー。このキューはデータベースでの同期取得によって使用されます。 -
Streams管理者
strmadmin
が所有する、apply_queue
という名前のキュー。このキューはデータベースでの適用プロセスによって使用されます。
詳細は、「ANYDATAキューの作成」を参照してください。
-
-
各データベースから他のデータベースへのデータベース・リンクを作成します。
-
sync1.example.com
データベースからsync2.example.com
データベースに、データベース・リンクを作成します。データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクはsync2.example.com
データベースでOracle Streams管理者に接続する必要があります。データベース・リンクの名前およびサービス名は、どちらもsync2.example.com
である必要があります。 -
sync2.example.com
データベースからsync1.example.com
データベースに、データベース・リンクを作成します。データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、データベース・リンクはsync1.example.com
データベースでOracle Streams管理者に接続する必要があります。データベース・リンクの名前およびサービス名は、どちらもsync1.example.com
である必要があります。
詳細は、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
-
-
sync1.example.com
データベースで適用プロセスを構成します。この適用プロセスは、sync2.example.com
データベースで取得され、sync1.example.com
データベースに伝播された共有表への変更を適用します。-
SQL*Plusを開き、
sync1.example.com
データベースにOracle Streams管理者として接続します。 -
次のように、適用プロセスを作成します。
BEGIN DBMS_APPLY_ADM.CREATE_APPLY( queue_name => 'strmadmin.apply_queue', apply_name => 'apply_emp_dep', apply_captured => FALSE); END; /
適用プロセスは永続キュー内の変更を適用するため、
apply_captured
パラメータがFALSE
に設定されます。これらは、同期取得によって取得された変更です。apply_captured
パラメータは、適用プロセスが取得プロセスによって取得された変更を適用する場合にのみTRUE
に設定する必要があります。適用プロセスは起動しないでください。
-
適用プロセス・ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.employees', streams_type => 'apply', streams_name => 'apply_emp_dep', queue_name => 'strmadmin.apply_queue', source_database => 'sync2.example.com'); END; /
このルールは、
apply_queue
キューに出現するhr.employees
表に対するすべてのDML変更を適用するよう適用プロセスapply_emp_dep
に指示します。ルールは、適用プロセスがsync2.example.com
ソース・データベースで取得された変更のみ適用することも指定します。 -
適用プロセス・ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'apply', streams_name => 'apply_emp_dep', queue_name => 'strmadmin.apply_queue', source_database => 'sync2.example.com'); END; /
このルールは、
apply_queue
キューに出現するhr.departments
表に対するすべてのDML変更を適用するよう適用プロセスapply_emp_dep
に指示します。ルールは、適用プロセスがsync2.example.com
ソース・データベースで取得された変更のみ適用することも指定します。
-
-
sync2.example.com
データベースで適用プロセスを構成します。この適用プロセスは、sync1.example.com
データベースで取得され、sync2.example.com
データベースに伝播された変更を適用します。-
SQL*Plusで、
sync2.example.com
データベースにOracle Streams管理者として接続します。SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
-
次のように、適用プロセスを作成します。
BEGIN DBMS_APPLY_ADM.CREATE_APPLY( queue_name => 'strmadmin.apply_queue', apply_name => 'apply_emp_dep', apply_captured => FALSE); END; /
適用プロセスは永続キュー内の変更を適用するため、
apply_captured
パラメータがFALSE
に設定されます。これらの変更は、同期取得によって取得されました。apply_captured
パラメータは、適用プロセスが取得プロセスによって取得された変更を適用する場合にのみTRUE
に設定する必要があります。適用プロセスは起動しないでください。
-
適用プロセス・ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.employees', streams_type => 'apply', streams_name => 'apply_emp_dep', queue_name => 'strmadmin.apply_queue', source_database => 'sync1.example.com'); END; /
このルールは、
apply_queue
キューに出現するすべてのDML変更をhr.employees
表に適用するよう適用プロセスapply_emp_dep
に指示します。ルールは、適用プロセスがsync1.example.com
ソース・データベースで取得された変更のみ適用することも指定します。 -
適用プロセス・ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'apply', streams_name => 'apply_emp_dep', queue_name => 'strmadmin.apply_queue', source_database => 'sync1.example.com'); END; /
このルールは、
apply_queue
キューに出現するすべてのDML変更をhr.departments
表に適用するよう適用プロセスapply_emp_dep
に指示します。ルールは、適用プロセスがsync1.example.com
ソース・データベースで取得された変更のみ適用することも指定します。
-
-
sync1.example.com
データベースのキューからsync2.example.com
データベースのキューに変更を送信する伝播を作成します。-
SQL*Plusで、
sync1.example.com
データベースにOracle Streams管理者として接続します。 -
sync2.example.com
データベースに対する変更を送信する伝播の作成を作成します。BEGIN DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES( table_name => 'hr.employees', streams_name => 'send_emp_dep', source_queue_name => 'strmadmin.capture_queue', destination_queue_name => 'strmadmin.apply_queue@sync2.example.com', source_database => 'sync1.example.com', queue_to_queue => TRUE); END; /
ADD_TABLE_PROPAGATION_RULES
プロシージャは、伝播およびポジティブ・ルール・セットを作成します。このプロシージャは、sync2.example.com
データベース内のapply_queue
キューのhr.employees
表にDML変更を送信するよう指示する伝播ルール・セットにルールの追加もします。 -
伝播ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES( table_name => 'hr.departments', streams_name => 'send_emp_dep', source_queue_name => 'strmadmin.capture_queue', destination_queue_name => 'strmadmin.apply_queue@sync2.example.com', source_database => 'sync1.example.com', queue_to_queue => TRUE); END; /
ADD_TABLE_PROPAGATION_RULES
プロシージャは、sync2.example.com
データベース内のapply_queue
キューのhr.departments
表にDML変更を送信するよう指示する伝播ルール・セットにルールを追加します。
-
-
sync2.example.com
データベースのキューからsync1.example.com
データベースのキューに変更を送信する伝播を作成します。-
SQL*Plusで、
sync2.example.com
データベースにOracle Streams管理者として接続します。 -
sync1.example.com
データベースに対する変更を送信する伝播の作成を作成します。BEGIN DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES( table_name => 'hr.employees', streams_name => 'send_emp_dep', source_queue_name => 'strmadmin.capture_queue', destination_queue_name => 'strmadmin.apply_queue@sync1.example.com', source_database => 'sync2.example.com', queue_to_queue => TRUE); END; /
ADD_TABLE_PROPAGATION_RULES
プロシージャは、伝播およびポジティブ・ルール・セットを作成します。このプロシージャでは、sync1.example.com
データベース内のapply_queue
キューのhr.employees
表にDML変更を送信するよう指示する伝播ルール・セットにルールを追加します。 -
伝播ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES( table_name => 'hr.departments', streams_name => 'send_emp_dep', source_queue_name => 'strmadmin.capture_queue', destination_queue_name => 'strmadmin.apply_queue@sync1.example.com', source_database => 'sync2.example.com', queue_to_queue => TRUE); END; /
ADD_TABLE_PROPAGATION_RULES
プロシージャは、sync1.example.com
データベース内のapply_queue
キューのhr.departments
表にDML変更を送信するよう指示する伝播ルール・セットにルールを追加します。
-
-
sync1.example.com
データベースで同期取得を構成します。-
SQL*Plusで、
sync1.example.com
データベースにOracle Streams管理者として接続します。 -
ADD_TABLE_RULES
プロシージャを実行して、同期取得を作成し、hr.employees
表に対する変更を取得するよう指示するルールを追加します。BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.employees', streams_type => 'sync_capture', streams_name => 'sync_capture', queue_name => 'strmadmin.capture_queue'); END; /
-
同期取得ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'sync_capture', streams_name => 'sync_capture', queue_name => 'strmadmin.capture_queue'); END; /
これらのプロシージャを実行して次のアクションを実行します。
-
現在のデータベースで
sync_capture
という名前の同期取得を作成します。同じ名前の同期取得は存在できません。 -
同期取得が有効化されます。同期取得を無効化することはできません。
-
strmadmin
が所有するcapture_queue
という名前の既存のキューで同期取得を関連付けます。 -
同期取得
sync_capture
のポジティブ・ルール・セットを作成します。このルール・セットはシステム生成名を持ちます。 -
hr.employees
表に対するDML変更を取得するルールを作成し、同期取得のポジティブ・ルール・セットにルールを追加します。このルールはシステム生成名を持ちます。 -
表に対して
DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION
ファンクションを自動的に実行することで、インスタンス化用にhr.employees
表を準備します。 -
hr.departments
表に対するDML変更を取得するルールを取得するルールを作成し、同期取得のポジティブ・ルール・セットにルールを追加します。このルールはシステム生成名を持ちます。 -
DBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION
ファンクションがhr.departments
表に対して自動的に実行され、この表がインスタンス化のために準備されます。
-
-
sync2.example.com
データベースで同期取得を構成します。-
SQL*Plusで、
sync2.example.com
データベースにOracle Streams管理者として接続します。 -
ADD_TABLE_RULES
プロシージャを実行して、同期取得を作成し、hr.employees
表に対する変更を取得するよう指示するルールを追加します。BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.employees', streams_type => 'sync_capture', streams_name => 'sync_capture', queue_name => 'strmadmin.capture_queue'); END; /
-
同期取得ルール・セットにルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'sync_capture', streams_name => 'sync_capture', queue_name => 'strmadmin.capture_queue'); END; /
手順8では、これらのプロシージャによって現在のデータベースで実行されるアクションについて説明します。
-
-
sync2.example.com
データベースで表のインスタンス化SCNを設定します。-
SQL*Plusで、
sync1.example.com
データベースにOracle Streams管理者として接続します。 -
sync2.example.com
データベースでhr.employees
表のインスタンス化SCNを設定します。DECLARE iscn NUMBER; -- Variable to hold instantiation SCN value BEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync2.example.com( source_object_name => 'hr.employees', source_database_name => 'sync1.example.com', instantiation_scn => iscn); END; /
-
sync2.example.com
データベースでhr.departments
表のインスタンス化SCNを設定します。DECLARE iscn NUMBER; -- Variable to hold instantiation SCN value BEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync2.example.com( source_object_name => 'hr.departments', source_database_name => 'sync1.example.com', instantiation_scn => iscn); END; /
インスタンス化SCNは、適用プロセスが表に変更を適用できる最小のSCNです。適用プロセスが
sync2.example.com
データベースの共有表への変更を適用する前に、インスタンス化SCNを各表に対して設定する必要があります。 -
-
sync1.example.com
データベースで表のインスタンス化SCNを設定します。-
SQL*Plusで、
sync2.example.com
データベースにOracle Streams管理者として接続します。 -
sync1.example.com
データベースでhr.employees
表のインスタンス化SCNを設定します。DECLARE iscn NUMBER; -- Variable to hold instantiation SCN value BEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync1.example.com( source_object_name => 'hr.employees', source_database_name => 'sync2.example.com', instantiation_scn => iscn); END; /
-
sync2.example.com
データベースでhr.departments
表のインスタンス化SCNを設定します。DECLARE iscn NUMBER; -- Variable to hold instantiation SCN value BEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); DBMS_APPLY_ADM.SET_TABLE_INSTANTIATION_SCN@sync1.example.com( source_object_name => 'hr.departments', source_database_name => 'sync2.example.com', instantiation_scn => iscn); END; /
-
-
-
SQL*Plusで、
sync1.example.com
データベースにOracle Streams管理者として接続します。 -
適用プロセスを開始します。
BEGIN DBMS_APPLY_ADM.START_APPLY( apply_name => 'apply_emp_dep'); END; /
-
SQL*Plusで、
sync2.example.com
データベースにOracle Streams管理者として接続します。 -
適用プロセスを開始します。
BEGIN DBMS_APPLY_ADM.START_APPLY( apply_name => 'apply_emp_dep'); END; /
-
-
sync1.example.com
およびsync2.example.com
の各データベースのhr.departments
およびhr.employees
の各表に対して、最新時刻競合解消を構成します。詳細は、「ビルトインの更新の競合ハンドラ」を参照してください。
次のような特性を持つ2データベース・レプリケーション環境が構成されます。
-
各データベースには、
sync_capture
という名前の同期取得があります。この同期取得は、hr.employees
表およびhr.departments
表に対するすべてのDML変更を取得します。 -
各データベースには、
capture_queue
という名前のキューがあります。このキューは、データベースでの同期取得用です。 -
各データベースには、
apply_emp_dep
という名前の適用プロセスがあります。この適用プロセスは、hr.employees
表およびhr.departments
表に対するすべてのDML変更を適用します。 -
各データベースには、
apply_queue
という名前のキューがあります。このキューは、データベースでの適用プロセス用です。 -
各データベースには、
send_emp_dep
という名前の伝播があります。この伝播は、ローカル・データベース内のcapture_queue
から、他のデータベース内のapply_queue
に変更を送信します。この伝播では、hr.employees
表およびhr.departments
表に対するすべてのDML変更が送信されます。 -
変更の循環を回避するため、次のようにタグが使用されています。
-
各適用プロセスでは、デフォルトの適用タグを使用します。デフォルトの適用タグは、
'00'
(ゼロが2つ)と等価の16進数になります。 -
各同期取得は、
NULL
タグを含むセッションの変更のみを取得します。したがって、同期取得は、ローカル適用プロセスによって適用される変更は取得しません。同期取得のルールは、これらの変更を取得しないよう同期取得に指示します。
レプリケーション環境で変更の循環を回避する方法の詳細は、「変更の循環とタグ」を参照してください。
-
Oracle Streamsレプリケーション構成を確認するには:
-
各データベースで、次の手順を実行して同期取得が構成されることを確認します。
-
SQL*Plusを起動して、データベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
-
次のように
ALL_SYNC_CAPTURE
データ・ディクショナリ・ビューを問い合せます。SELECT CAPTURE_NAME FROM ALL_SYNC_CAPTURE;
各データベースに
sync_capture
という名前の同期取得が存在していることを確認します。
-
-
各データベースで、伝播が有効化されていることを確認します。これを行うには、
DBA_PROPAGATION
ビューでSTATUS
列を問い合せます。 -
各データベースで、適用プロセスが有効化されていることを確認します。これを行うには、
DBA_APPLY
ビューでSTATUS
列を問い合せます。
変更をレプリケートするには、次の手順を実行します。
-
データベースの1つで、
hr.employees
表またはhr.departments
表に対してDML変更を行います。 -
変更のレプリケーションが完了するまで待ってから、SQL*Plusを使用して他のデータベースの
hr.employees
表またはhr.departments
表を問い合せて変更を表示します。
2.2.7 ハブ・アンド・スポーク・レプリケーションを構成する場合の例
この例では、hr
スキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsハブ・アンド・スポーク・レプリケーション環境を構成します。この例では、各データベースで取得プロセスを使用して、これらの変更を取得します。ハブ・アンド・スポーク・レプリケーションとは、中央ハブ・データベースが1つ以上のスポーク・データベースを使用して変更をレプリケートすることを意味します。スポーク・データベースは相互には直接通信しません。この構成例では、ハブ・データベースが、1つのスポーク・データベースで生成された変更を別のスポーク・データベースに送信します。
この例では、ハブ・データベースのグローバル名はhub.example.com
であり、スポーク・データベースのグローバル名はspoke1.example.com
およびspoke2.example.com
です。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
決定 | この例の前提 |
---|---|
この例では、ハブ・データベースのグローバル名が |
|
この例では、各データベースでローカル取得を構成します。 |
|
この例では、レプリケートされたデータベース・オブジェクトへの変更が3つのデータベースすべてにおいて可能なレプリケーション環境を構成します。 |
|
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
|
この例では、適用ハンドラを構成しません。 |
|
この例では、共有データベース・オブジェクトに対するDDL変更はメンテナンスしません。 |
|
この例では、 |
この例では、MAINTAIN_SCHEMAS
プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。
MAINTAIN_SCHEMAS
プロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTED
データ・ディクショナリ・ビューを問い合せます。サポートされないデータベース・オブジェクトが除外されていない場合は、取得エラーが発生します。
MAINTAIN_SCHEMAS
プロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMAS
プロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMAS
プロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMAS
プロシージャを実行する前に、各データベースにhr
スキーマが存在します。
図2-8に、この例で作成される環境の概要を示します。
MAINTAIN_SCHEMAS
プロシージャを使用して環境を構成するには、次の手順を実行します。
-
次のタスクを完了して、ハブ・アンド・スポーク・レプリケーション環境を準備します。
-
次のデータベースが相互に通信できるようにネットワーク接続を構成します。
-
hub.example.com
データベースとspoke1.example.com
データベース。 -
hub.example.com
データベースとspoke2.example.com
データベース。
データベース間のネットワーク接続の構成については、『Oracle Database 2日でデータベース管理者』を参照してください。
-
-
レプリケーション環境に参加する各データベースでOracle Streams管理者を構成します。手順については、「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。この例では、Oracle Streams管理者が
strmadmin
であると想定しています。 -
ハブ・データベースから各スポーク・データベースおよび各スポーク・データベースからハブ・データベースへのデータベース・リンクを作成します。この例では、次のデータベース・リンクを作成します。
-
hub.example.com
データベースからspoke1.example.com
データベース。データベース・リンクの名前とサービス名の両方がspoke1.example.com
である必要があります。 -
hub.example.com
データベースからspoke2.example.com
データベース。データベース・リンクの名前とサービス名の両方がspoke2.example.com
である必要があります。 -
spoke1.example.com
データベースからhub.example.com
データベース。データベース・リンクの名前とサービス名の両方がhub.example.com
である必要があります。 -
spoke2.example.com
データベースからhub.example.com
データベース。データベース・リンクの名前とサービス名の両方がhub.example.com
である必要があります。
各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。また、各データベース・リンクは、宛先データベースのOracle Streams管理者に接続する必要があります。手順については、「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
-
-
Oracle Streamsレプリケーション環境に参加する各データベースで初期化パラメータを適切に設定します。手順については、「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
-
ARCHIVELOG
モードで実行するように各ソース・データベースを構成します。取得プロセスがソース・データベースで生成された変更を取得するには、ソース・データベースをARCHIVELOG
モードで実行する必要があります。この例では、すべてのデータベースがARCHIVELOG
モードで実行されている必要があります。ARCHIVELOG
モードで実行するためのデータベースの構成の詳細は、『Oracle Database管理者ガイド』を参照してください。
-
-
次に示す必要なディレクトリ・オブジェクトを作成します。
-
ハブ・データベース
hub.example.com
のディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはhub_directory
であると想定しています。 -
スポーク・データベース
spoke1.example.com
のディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはspoke1_directory
であると想定しています。 -
スポーク・データベース
spoke2.example.com
のディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはspoke2_directory
であると想定しています。
手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
-
-
SQL*Plusで、Oracle Streams管理者として
hub.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
-
MAINTAIN_SCHEMAS
プロシージャを実行して、hub.example.com
データベースとspoke1.example.com
データベース間でレプリケーションを構成します。BEGIN DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS( schema_names => 'hr', source_directory_object => 'hub_directory', destination_directory_object => 'spoke1_directory', source_database => 'hub.example.com', destination_database => 'spoke1.example.com', capture_name => 'capture_hns', capture_queue_table => 'source_hns_qt', capture_queue_name => 'source_hns', propagation_name => 'propagation_spoke1', apply_name => 'apply_spoke1', apply_queue_table => 'destination_spoke1_qt', apply_queue_name => 'destination_spoke1', bi_directional => TRUE); END; /
MAINTAIN_SCHEMAS
プロシージャは多くの構成タスクを実行するため、実行に時間がかかる場合があります。プロシージャの実行中に宛先データベースのレプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)またはデータ定義言語(DDL)変更を許可しないでください。MAINTAIN_SCHEMAS
プロシージャの必須パラメータは、schema_names
、source_directory_object
、destination_directory_object
、source_database
およびdestination_database
のみです。また、構成プロシージャを使用して双方向のレプリケーションを構成する場合は、bi_directional
パラメータをTRUE
に設定する必要があります。この例では、他のパラメータを指定して、取得プロセス、取得プロセスのキュー表、取得プロセスのキュー、伝播、適用プロセス、適用プロセスのキュー表および適用プロセスのキューの名前を選択可能であることを示しています。これらのパラメータを指定しない場合は、システム生成名が使用されます。
構成プロシージャの実行時、そのプロシージャの進捗に関する情報は、データ・ディクショナリ・ビュー
DBA_RECOVERABLE_SCRIPT
、DBA_RECOVERABLE_SCRIPT_PARAMS
、DBA_RECOVERABLE_SCRIPT_BLOCKS
およびDBA_RECOVERABLE_SCRIPT_ERRORS
に記録されます。プロシージャでエラーが発生してプロシージャが停止した場合は、『Oracle Streamsレプリケーション管理者ガイド』でDBMS_STREAMS_ADM
パッケージのRECOVER_OPERATION
プロシージャを使用したこれらのエラーからのリカバリ手順を参照してください。 -
SQL*Plusで引き続きOracle Streams管理者として
hub.example.com
データベースに接続したままで、MAINTAIN_SCHEMAS
プロシージャを実行して、hub.example.com
データベースとspoke2.example.com
データベースの間にレプリケーションを構成します。BEGIN DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS( schema_names => 'hr', source_directory_object => 'hub_directory', destination_directory_object => 'spoke2_directory', source_database => 'hub.example.com', destination_database => 'spoke2.example.com', capture_name => 'capture_hns', capture_queue_table => 'source_hns_qt', capture_queue_name => 'source_hns', propagation_name => 'propagation_spoke2', apply_name => 'apply_spoke2', apply_queue_table => 'destination_spoke2_qt', apply_queue_name => 'destination_spoke2', bi_directional => TRUE); END; /
-
hub.example.com
、spoke1.example.com
およびspoke2.example.com
データベースのhr
スキーマにあるすべての表に対して最新時刻競合解消を構成します。このスキーマには、countries
、departments
、employees
、jobs
、job_history
、locations
およびregions
の表が含まれています。手順については、「Oracle Streamsの競合解消」を参照してください。
関連項目:
Oracle Enterprise Manager Cloud Controlを使用してこのレプリケーション環境を構成する場合の例については、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。