| Oracle® Streamsレプリケーション管理者ガイド 11g リリース2 (11.2) B61352-03 |
|
 前 |
 次 |
この章では、簡単な方法を使用したOracle Streamsレプリケーションの構成について説明します。
この章の内容は次のとおりです。
Oracle Enterprise ManagerのOracle Streamsツールには、Oracle Streamsレプリケーション環境を構成するStreamsレプリケーションの設定ウィザードが含まれています。このウィザードを使用して、次のいずれかの特性を備えたOracle Streamsレプリケーション環境を構成できます。
ソース・データベース全体、ソース・データベース内の選択されたスキーマ、ソース・データベース内の選択された表領域、ソース・データベース内の選択された表またはソース・データベース内の表のサブセットに対する変更をレプリケートする
データ操作言語(DML)変更またはデータ定義言語(DDL)変更(あるいはその両方)をメンテナンスする
一方向または双方向のレプリケーション
ローカル取得またはダウンストリーム取得
このウィザードではレプリケーション環境の構成プロセスを実行でき、さらにこのウィザードを複数回実行することで、3つ以上のデータベースを使用するレプリケーション環境を構成できます。このウィザードを使用して構成できるレプリケーション環境のタイプには制限があります。たとえば、このウィザードでは、現在、同期取得は構成できません。
Oracle Streamsレプリケーション環境を即座に構成することも、またはウィザードを使用してスクリプトを生成することもできます。スクリプトを生成する場合は、スクリプトを実行してレプリケーション環境を構成する前に、スクリプトを確認し、必要に応じて編集できます。
このウィザードをオープンするには、Enterprise Managerで次の手順を実行します。
「Oracle Streamsレプリケーションを構成する前に行う決定」で説明されている決定を確認します。Oracle Streamsレプリケーション環境に関する決定を行ってから、先に進みます。
Oracle Streamsレプリケーション環境を準備するタスクを完了します。「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
ウィザードにより一部のタスクは自動的に完了しますが、次のタスクは手動で完了する必要があります。
両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。まだ構成済みでない場合は、手順6の「Streams」ページを開いた後に、「Streams管理者ユーザー」リンクをクリックし、Oracle Enterprise Managerを使用してOracle Streamsを管理するOracle Streams管理者を構成する必要があります。
2つのデータベース間のネットワーク接続を構成します。「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
ソース・データベースになるデータベースがARCHIVELOGモードであることを確認します。双方向のレプリケーションを構成する場合は、両方のデータベースがARCHIVELOGモードである必要があります。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
Oracle Enterprise Managerで、Oracle Streams管理者としてデータベースにログインします。レプリケーション環境でソース・データベースになるデータベースにログインします。
データベースの「ホーム」ページに移動します。
「データ移動」をクリックして、「データ移動」サブページを開きます。
「Streams」セクションの「設定」をクリックして、「Streams」ページを開きます。
「Streamsレプリケーションの設定」セクションでは、構成するレプリケーション環境のタイプのオプションを選択します。
「ホスト資格証明」セクションでは、ソース・データベースを実行するホスト・コンピュータのユーザー名およびパスワードを入力します。
「続行」をクリックして、Streamsレプリケーションの設定ウィザードをオープンします。
これは、「Streams」ページの「表のレプリケート」を選択すると最初に表示されるウィザード・ページです。
|
注意: Streamsレプリケーションの設定ウィザードでは、デフォルトで一方向のレプリケーションが構成されます。双方向のレプリケーションを構成するには、「レプリケーション・オプション」ページの「拡張オプション」セクションを開き、「双方向レプリケーションの設定」を選択します。双方向のレプリケーションを構成する場合は、競合解消が必要になることがあります。 |
|
関連項目:
|
DBMS_STREAMS_ADMパッケージのプロシージャを使用して、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プロシージャを使用します。 |
|
関連項目:
|
この項では、構成プロシージャに関する重要な考慮事項について説明します。また、これらの考慮事項に関連するいくつかのプロシージャ・パラメータについても説明します。
この項の内容は次のとおりです。
|
関連項目: これらのプロシージャのすべてのパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この項のプロシージャでは、source_databaseパラメータに指定したデータベースに対してローカル取得またはダウンストリーム取得のいずれかを構成できます。ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。
プロシージャが実行されるデータベースは、ソース・データベースに対する変更の取得データベースとして構成されます。そのため、ソース・データベースでのローカル取得を構成するには、ソース・データベースでプロシージャを実行します。宛先データベースでダウンストリーム取得を構成するには、destination_databaseパラメータに指定されているデータベースでプロシージャを実行します。第3のデータベースでダウンストリーム取得を構成するには、source_databaseパラメータまたはdestination_databaseパラメータに指定されていないデータベースでプロシージャを実行します。
ソース・データベースまたは第3のデータベースを取得データベースに使用する場合、この項のプロシージャでは、取得データベースから宛先データベースに変更を送信するように伝播が構成されます。宛先データベースを取得データベースに使用して、双方向のレプリケーションを構成しない場合、データベース間でのこの伝播は不要です。この場合、capture_queue_nameパラメータとapply_queue_nameパラメータの値が同じであると、伝播は構成されません。これらの値が異なる場合は、宛先データベース内の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)ディスク・グループをポイントできません。 |
これらのプロシージャでは、次の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以外の値に設定されている場合、この項のプロシージャでエラーが発生します。
この項のプロシージャでは、source_databaseパラメータで指定されたデータベースをソース・データベースとする一方向(単一ソース)のOracle Streams構成、または両方のデータベースをソース・データベースと宛先データベースとする双方向のOracle Streams構成のいずれかが設定されます。詳細は、「1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定」を参照してください。
Oracle Streams構成を単一ソースとするか双方向とするかは、各プロシージャのbi_directionalパラメータで制御されます。
bi_directionalパラメータをFALSEに指定した場合、取得プロセスがソース・データベースに対する変更を取得し、適用プロセスが宛先データベースでそれらの変更を適用します。宛先データベースを取得データベースに使用しない場合、伝播によって、取得された変更が宛先データベースに送信されます。このパラメータのデフォルト値はFALSEです。
bi_directionalパラメータをTRUEに設定した場合、個別の取得プロセスが各データベースに対する変更を取得し、伝播によってこれらの変更が他のデータベースに送信され、各データベースで他のデータベースからの変更が適用されます。
レプリケーション環境が双方向ではなく、宛先データベースで変更が許可されていない場合、Oracle Streamsはデータベース間で共有データベース・オブジェクトの同期化を保持します。ただし、レプリケーション環境が双方向ではなく、宛先データベースで独立した変更が許可されている場合、データベース間で共有データベース・オブジェクトが異なる場合があります。独立した変更は、ユーザー、アプリケーション、または第3のデータベースを含むレプリケーションによって行われます。
|
注意:
|
変更の循環は、変更が発生場所であるデータベースに再送されると発生します。通常は、それぞれの変更が無限ループを介して発生場所であるデータベースに送信される可能性があるため、変更の循環を回避する必要があります。このようなループがあると、データベースに意図しないデータが格納され、環境のネットワーキング・リソースとコンピュータ・リソースが過剰に使用される可能性があります。
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環境を手動で構成できます。また、生成されたスクリプトを変更してこの操作を行うこともできます。
|
関連項目:
|
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変更のみがメンテナンスされます。 |
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の値が適切に設定されていることを確認します。
|
注意:
|
ディレクトリ・オブジェクトは、ファイル・システム上のディレクトリの別名に類似しています。この項のいずれかのプロシージャを実行する場合、次のディレクトリ・オブジェクトが必要になる場合があります。
スクリプト・ディレクトリ・オブジェクトは、構成スクリプトを生成する場合に必要です。構成スクリプトは、プロシージャが実行されるコンピュータ・システム上のこのディレクトリに格納されます。これらのいずれかのプロシージャを実行してスクリプト・ディレクトリ・オブジェクトを指定する場合、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を作成します。
SQL*Plusで、Oracle Streams管理者としてデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
次のように、ディレクトリ・オブジェクトを作成します。
CREATE DIRECTORY db_dir AS '/usr/db_files';
ディレクトリ・オブジェクトを作成するユーザーには、ディレクトリ・オブジェクトに対するREAD権限およびWRITE権限が自動的に付与されます。Oracle Streamsレプリケーション環境を構成している場合は、通常Oracle Streams管理者がディレクトリ・オブジェクトを作成します。
|
注意: ディレクトリ・オブジェクトは、自動ストレージ管理(ASM)ディスク・グループをポイントできません。 |
次の各例では、1つ以上のローカル取得プロセスを使用した2データベース・レプリケーション環境を構成します。
DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、データベース・レベルでレプリケーションを構成できます。
MAINTAIN_GLOBAL
PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP
MAINTAIN_GLOBALプロシージャでは、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境からは自動的に除外されます。PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャでは、データベース・オブジェクトが自動的に除外されません。かわりに、これらのプロシージャを使用すると、レプリケーション環境から除外するデータベース・オブジェクトを指定できます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
| 決定 | この例の前提 |
|---|---|
| どのタイプのレプリケーション環境を構成するかの決定 |
この例では、両方のデータベースが読取り/書込み可能な2データベース環境における双方向のレプリケーションを構成します。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、各ソース・データベースに対してローカル取得を構成します。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、両方のデータベースにおいてレプリケートされたデータベース・オブジェクトへの変更が可能です。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、DDL変更をメンテナンスします。 |
| レプリケーション環境の構成方法の決定 |
この例では、PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUPプロシージャを使用して環境を構成します。 |
この例では、プロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。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構成の進捗の監視」の手順に従います。
このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。
インスタンス化を実行します。第8章「インスタンス化と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をメモします。この番号は手順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を指定できます。この句には、手順cで判断した終了SCNを使用します。アーカイブREDOログは、指定した終了SCN値以上で使用可能である必要があります。したがって、手順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つ少ない値まで、データベースが複製されます。したがって、手順4hで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プロシージャによって作成された環境で競合が発生する可能性がある場合は、共有データベース・オブジェクトに対する変更をユーザーに許可する前に競合解消を構成します。
詳細は、第9章「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レコードにタグが含まれるように、各適用プロセスで適用タグが使用されます。各適用プロセスは、レプリケーション環境で一意の適用タグを使用します。各伝播は、同じデータベースで実行されている適用プロセスのタグを持つ変更を廃棄します。詳細は、「変更の循環とタグ」を参照してください。
この例では、hrスキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、ローカル取得プロセスを使用して変更を取得する2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名db1.example.comおよびdb2.example.comを使用します。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
| 決定 | この例の前提 |
|---|---|
| どのタイプのレプリケーション環境を構成するかの決定 |
この例では、一方向または双方向のレプリケーションを構成する手順を説明します。双方向のレプリケーションを構成するには、追加の手順を完了し、構成プロシージャの実行時にbi_directionalパラメータをTRUEに設定する必要があります。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、ソース・データベースに対してローカル取得を構成します。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、1つのデータベースまたは両方のデータベースで変更を許可するかどうかを選択できます。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、DDL変更をメンテナンスします。 |
| レプリケーション環境の構成方法の決定 |
この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。 |
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の表が含まれています。手順については、第9章「Oracle Streamsの競合解消」を参照してください。
|
関連項目: Oracle Enterprise Managerを使用してこのレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
DBMS_STREAMS_ADMパッケージのMAINTAIN_TABLESプロシージャを使用すると、表レプリケーションを構成できます。この項の例では、このプロシージャを使用して、hrスキーマ内の特定の表をメンテナンスするOracle Streamsレプリケーション環境を構成します。ソース・データベースはdbs1.example.comで、接続データベースはdbs2.example.comです。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
| 決定 | この例の前提 |
|---|---|
| どのタイプのレプリケーション環境を構成するかの決定 |
この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、ソース・データベースに対してローカル取得を構成します。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、共有データベース・オブジェクトのサブセットに対するDDL変更をメンテナンスします。 |
| レプリケーション環境の構成方法の決定 |
この例では、MAINTAIN_TABLESプロシージャを使用して環境を構成します。 |
レプリケーション環境では、共有データベース・オブジェクトに対する次の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);
手順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データベース・レプリケーション環境を構成します。
DBMS_STREAMS_ADMパッケージの次のプロシージャを使用すると、表領域レプリケーションを構成できます。
MAINTAIN_SIMPLE_TTS
MAINTAIN_TTS
PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP
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データベース環境で一方向のレプリケーションを構成します。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、ソース・データベース(dbs1.example.com)に対する変更を取得する、宛先データベース(dbs2.example.com)で実行されるダウンストリーム取得プロセスを構成します。ダウンストリーム取得プロセスは、アーカイブ・ログ・ダウンストリーム取得プロセスになります。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、表領域および表領域内のデータベース・オブジェクトに対するDDL変更をメンテナンスします。 |
| レプリケーション環境の構成方法の決定 |
この例では、MAINTAIN_TTSプロシージャを使用して環境を構成します。 |
この例では、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プロシージャを使用して環境を構成するには、次の手順を実行します。
MAINTAIN_TTSプロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
この構成について、次のタスクを実行する必要があります。
両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。
ソース・データベースdbs1.example.comと宛先データベースdbs2.example.comとの間で、ネットワーク接続を構成します。
ソース・データベースdbs1.example.comから宛先データベースdbs2.example.comへのデータベース・リンクを作成します。
宛先データベースでダウンストリーム取得が構成されるため、宛先データベースdbs2.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。
「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
両方のデータベースがARCHIVELOGモードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
両方のデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
宛先データベースはソース・データベースに対する変更の取得データベースとなるため、ソース・データベースdbs1.example.comから宛先データベースdbs2.example.comへのログ・ファイルのコピーを構成します。取得プロセスは、アーカイブ・ログ・ダウンストリーム取得プロセスになります。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。
次に示す必要なディレクトリ・オブジェクトを作成します。
ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはsource_directoryであると想定しています。
宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはdest_directoryであると想定しています。
手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
SQL*Plusで、Oracle Streams管理者として表領域セットを含むデータベースに接続します。この例では、dbs1.example.comデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
表領域セットの表領域のデータ・ファイルを含むディレクトリのディレクトリ・オブジェクトを作成します。たとえば、次の文を実行すると、/orc/dbsディレクトリに対応するディレクトリ・オブジェクトtbs_directoryが作成されます。
CREATE DIRECTORY tbs_directory AS '/orc/dbs';
データ・ファイルが複数のディレクトリに存在する場合、ディレクトリ・オブジェクトはそれらのディレクトリごとに存在する必要があり、手順6でMAINTAIN_TTSプロシージャを実行するユーザーが、それらのディレクトリ・オブジェクトに対するREAD権限を持っている必要があります。この例では、Oracle Streams管理者がディレクトリ・オブジェクトを作成するため、この権限を持っていることになります。
SQL*Plusで、Oracle Streams管理者として宛先データベースdbs2.example.comに接続します。
MAINTAIN_TTSプロシージャを実行します。
DECLARE
t_names DBMS_STREAMS_TABLESPACE_ADM.TABLESPACE_SET;
BEGIN
-- Tablespace names
t_names(1) := 'TBS1';
t_names(2) := 'TBS2';
DBMS_STREAMS_ADM.MAINTAIN_TTS(
tablespace_names => t_names,
source_directory_object => 'source_directory',
destination_directory_object => 'dest_directory',
source_database => 'dbs1.example.com',
destination_database => 'dbs2.example.com',
perform_actions => TRUE,
capture_name => 'capture_tts',
capture_queue_table => 'streams_queue_table',
capture_queue_name => 'streams_queue',
apply_name => 'apply_tts',
apply_queue_table => 'streams_queue_table',
apply_queue_name => 'streams_queue');
bi_directional => FALSE,
include_ddl => TRUE);
END;
/
このプロシージャが完了すると、単一ソースのOracle Streamsレプリケーション環境が構成されます。
このプロシージャは宛先データベースで実行されるため、宛先データベースで、ソース・データベースに対する変更のダウンストリーム取得が構成されます。構成プロシージャを使用してダウンストリーム取得を構成する場合は、キューとキュー表の名前を指定するパラメータが重要になります。このような構成では、取得プロセスと適用プロセスでダウンストリーム取得データベースの同じキューを使用してキュー間の変更の伝播を回避すると効率的です。この構成例では、効率を向上させるために、capture_queue_nameパラメータとapply_queue_nameパラメータの両方にstreams_queueを指定しています。また、capture_queue_tableパラメータとapply_queue_tableパラメータの両方にstreams_queue_tableを指定しています。
構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。
このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。
構成された単一ソース・レプリケーション環境には、次の特性があります。
ソース・データベース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が、そのキューから変更をデキューしてそれらの変更を共有データベース・オブジェクトに適用します。
この例では、hrスキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsレプリケーション環境を構成します。この例では、宛先データベースでダウンストリーム取得プロセスを使用した2データベース・レプリケーション環境を構成します。この例では、グローバル・データベース名src.example.comおよびdest.example.comを使用します。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。2データベース・レプリケーション環境の詳細は、「どのタイプのレプリケーション環境を構成するかの決定」を参照してください。
この例では、宛先データベースdest.example.comでダウンストリーム取得プロセスが実行されます。したがって、変更の取得に必要なリソースは、ソース・データベースsrc.example.comで解放されます。この例では、アーカイブ・ログ・ダウンストリーム取得プロセスではなく、リアルタイム・ダウンストリーム取得プロセスを構成します。リアルタイム・ダウンストリーム取得の利点は、ソース・データベースで行われた変更を取得するのに必要な時間が軽減されることです。時間が軽減されるのは、リアルタイム・ダウンストリーム取得プロセスではREDOログ・ファイルがアーカイブされるのを待たなくてもデータを取得できるためです。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
| 決定 | この例の前提 |
|---|---|
| どのタイプのレプリケーション環境を構成するかの決定 |
この例では、ソース・データベースが読取り/書込み可能であり、宛先データベースが読取り専用である2データベース環境で一方向のレプリケーションを構成します。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、ソース・データベース(src.example.com)に対する変更を取得する、宛先データベース(dest.example.com)で実行されるダウンストリーム取得プロセスを構成します。ダウンストリーム取得プロセスは、リアルタイム・ダウンストリーム取得プロセスになります。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、ソース・データベースでのみ変更が許可されているレプリケーション環境を構成します。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、表領域および表領域内のデータベース・オブジェクトに対するDDL変更をメンテナンスします。 |
| レプリケーション環境の構成方法の決定 |
この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。 |
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を使用してこのレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
DBMS_STREAMS_ADMパッケージのMAINTAIN_SCHEMASプロシージャを使用すると、スキーマ・レプリケーションを構成できます。この項の例では、このプロシージャを使用して、hrスキーマをメンテナンスするOracle Streamsレプリケーション環境を構成します。ソース・データベースはdbs1.example.com、宛先データベースはdbs3.example.comです。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
| 決定 | この例の前提 |
|---|---|
| どのタイプのレプリケーション環境を構成するかの決定 |
この例では、両方のデータベースが読取り/書込み可能な2データベース環境における双方向のレプリケーションを構成します。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、ソース・データベース(dbs1.example.com)に対する変更を取得する、第3のデータベースdbs2.example.comで実行されるダウンストリーム取得プロセスを構成し、dbs2.example.comの伝播が宛先データベース(dbs3.example.com)に取得された変更を伝播します。ダウンストリーム取得プロセスは、リアルタイム・ダウンストリーム取得プロセスになります。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、レプリケートされたデータベース・オブジェクトへの変更が両方のデータベースにおいて可能なレプリケーション環境を構成します。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、hrスキーマおよびhrスキーマ内のデータベース・オブジェクトに対するDDL変更がメンテナンスされます。 |
| レプリケーション環境の構成方法の決定 |
この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。 |
この例では、MAINTAIN_SCHEMASプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。
MAINTAIN_SCHEMASプロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。
図2-6に、この例で作成されるレプリケーション環境の概要を示します。
|
関連項目: Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別する手順については、『Oracle Streams概要および管理』を参照してください。 |
MAINTAIN_SCHEMASプロシージャを使用して環境を構成するには、次の手順を実行します。
MAINTAIN_SCHEMASプロシージャを実行する前に必要なタスクを実行します。手順については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください。
この構成について、次のタスクを実行する必要があります。
3つすべてのデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
ネットワーク接続性とデータベース・リンクの構成は、次のとおりです。
ソース・データベースdbs1.example.com、宛先データベースdbs3.example.comおよび第3のデータベースdbs2.example.comの3つすべてのデータベース間にネットワーク接続を構成します。
ソース・データベースdbs1.example.comから宛先データベースdbs3.example.comへのデータベース・リンクを作成します。
第3のデータベースでダウンストリーム取得が構成されるため、第3のデータベースdbs2.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。
第3のデータベースでダウンストリーム取得が構成されるため、第3のデータベースdbs2.example.comから宛先データベースdbs3.example.comへのデータベース・リンクを作成します。
レプリケーション環境は双方向になるため、宛先データベースdbs3.example.comからソース・データベースdbs1.example.comへのデータベース・リンクを作成します。
「ネットワーク接続性とデータベース・リンクの構成」を参照してください。
ソース・データベース、宛先データベースおよび第3のデータベースがARCHIVELOGモードであることを確認します。「各ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
すべてのデータベースの初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
第3のデータベース(dbs2.example.com)はソース・データベースに対する変更の取得データベースとなるため、ソース・データベースdbs1.example.comから第3のデータベースdbs2.example.comへのログ・ファイルのコピーを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。
この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、ダウンストリーム・データベース(dbs2.example.com)でスタンバイREDOログを追加します。「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」を参照してください。
次に示す必要なディレクトリ・オブジェクトを作成します。
ソース・データベースのソース・ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはsource_directoryであると想定しています。
宛先データベースの接続先ディレクトリ・オブジェクト。この例では、このディレクトリ・オブジェクトはdest_directoryであると想定しています。
手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
SQL*Plusで、Oracle Streams管理者として第3のデータベースdbs2.example.comに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
MAINTAIN_SCHEMASプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'hr',
source_directory_object => 'source_directory',
destination_directory_object => 'dest_directory',
source_database => 'dbs1.example.com',
destination_database => 'dbs3.example.com',
perform_actions => TRUE,
dump_file_name => 'export_hr.dmp',
capture_queue_table => 'rep_capture_queue_table',
capture_queue_name => 'rep_capture_queue',
capture_queue_user => NULL,
apply_queue_table => 'rep_dest_queue_table',
apply_queue_name => 'rep_dest_queue',
apply_queue_user => NULL,
capture_name => 'capture_hr',
propagation_name => 'prop_hr',
apply_name => 'apply_hr',
log_file => 'export_hr.clg',
bi_directional => TRUE,
include_ddl => TRUE,
instantiation => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
END;
/
このプロシージャでは双方向のレプリケーション環境が構成されるため、プロシージャの実行中に宛先データベースの共有データベース・オブジェクトに対するDML変更またはDDL変更を許可しないでください。
このプロシージャは第3のデータベースで実行されるため、第3のデータベースで、ソース・データベースに対する変更のダウンストリーム取得が構成されます。
構成操作の進捗を監視するには、「Oracle Streams構成の進捗の監視」の手順に従います。
このプロシージャでエラーが発生してプロシージャが停止した場合、エラーからのリカバリまたは構成操作のロールバックを実行する方法の詳細は、「操作エラーからのリカバリ」を参照してください。
downstream_real_time_mine取得プロセス・パラメータをYに設定します。
BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'capture_hr',
parameter => 'downstream_real_time_mine',
value => 'Y');
END;
/
ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースdbs1.example.comに接続します。
ソース・データベースで現行のログ・ファイルをアーカイブします。
ALTER SYSTEM ARCHIVE LOG CURRENT;
ソース・データベースで現行のログ・ファイルをアーカイブすると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。
取得プロセスがREDOデータを待機している時間が異常に長い場合は、アラート・ログでエラーを確認してください。詳細は、『Oracle Streams概要および管理』を参照してください。
必要に応じて、共有データベース・オブジェクトの競合解消を構成します。
通常、双方向のレプリケーション環境では、競合が発生する可能性があります。MAINTAIN_SCHEMASプロシージャで作成した環境で競合が発生する可能性がある場合は、競合解消を構成してから、共有データベース・オブジェクトに対する変更をユーザーに許可します。
詳細は、第9章「Oracle Streamsの競合解消」を参照してください。
この例で構成された双方向のレプリケーション環境には、次の特性があります。
ソース・データベースおよび宛先データベースで共有データベース・オブジェクトのサプリメンタル・ロギングが構成されています。
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レコードにタグが含まれるように、各適用プロセスで適用タグが使用されます。各適用プロセスは、レプリケーション環境で一意の適用タグを使用します。各伝播は、同じデータベースで実行されている適用プロセスのタグを持つ変更を廃棄します。詳細は、「変更の循環とタグ」を参照してください。
この例では、hrスキーマのすべての表に対するデータ操作言語(DML)変更をレプリケートするOracle Streamsハブ・アンド・スポーク・レプリケーション環境を構成します。この例では、各データベースで取得プロセスを使用して、これらの変更を取得します。ハブ・アンド・スポーク・レプリケーションとは、中央ハブ・データベースが1つ以上のスポーク・データベースを使用して変更をレプリケートすることを意味します。スポーク・データベースは相互には直接通信しません。この構成例では、ハブ・データベースが、1つのスポーク・データベースで生成された変更を別のスポーク・データベースに送信します。
この例では、ハブ・データベースのグローバル名はhub.example.comであり、スポーク・データベースのグローバル名はspoke1.example.comおよびspoke2.example.comです。ただし、使用している環境内でデータベースを置き換えて例を完成することもできます。
次の表では、この例で構成されたOracle Streamsレプリケーション環境に関して行った決定を示します。
| 決定 | この例の前提 |
|---|---|
| どのタイプのレプリケーション環境を構成するかの決定 |
この例では、ハブ・データベースのグローバル名がhub.example.comで、スポーク・データベースのグローバル名がspoke1.example.comおよびspoke2.example.comであるハブ・アンド・スポーク・レプリケーション環境を構成します。環境内のすべてのデータベースは読取り/書込み可能です。 |
| ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定 |
この例では、各データベースでローカル取得を構成します。 |
| 1つのデータベースまたは複数のデータベースで変更を許可するかどうかの決定 |
この例では、レプリケートされたデータベース・オブジェクトへの変更が3つのデータベースすべてにおいて可能なレプリケーション環境を構成します。 |
| レプリケーション環境に異なるレプリカを含めるかどうかの決定 |
この例では、複数のデータベースで同じ共有データベース・オブジェクトを構成します。 |
| レプリケーション環境で適用ハンドラを使用するかどうかの決定 |
この例では、適用ハンドラを構成しません。 |
| DDL変更をメンテナンスするかどうかの決定 |
この例では、共有データベース・オブジェクトに対するDDL変更はメンテナンスしません。 |
| レプリケーション環境の構成方法の決定 |
この例では、MAINTAIN_SCHEMASプロシージャを使用して環境を構成します。 |
この例では、MAINTAIN_SCHEMASプロシージャでレプリケーション環境を直接構成します。構成スクリプトは生成されません。データ・ポンプ・エクスポート・ダンプ・ファイルによるインスタンス化が実行されます。
MAINTAIN_SCHEMASプロシージャでは、各取得プロセスおよび適用プロセスのネガティブ・ルール・セットにルールを追加することによって、Oracle Streamsによってサポートされていないデータベース・オブジェクトがレプリケーション環境から自動的に除外されます。Oracle Streamsによってサポートされていないデータベース・オブジェクトを判別するには、DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せます。サポートされていないデータベース・オブジェクトが除外されていない場合、取得エラーが発生します。
MAINTAIN_SCHEMASプロシージャの実行時に、宛先データベースにレプリケーション用に構成されたデータベース・オブジェクトが存在する場合と存在しない場合があります。宛先データベースにデータベース・オブジェクトが存在しない場合、MAINTAIN_SCHEMASプロシージャでは、データ・ポンプ・エクスポート/インポートを使用して宛先データベースでデータベース・オブジェクトをインスタンス化します。インスタンス化中に、これらのデータベース・オブジェクトのインスタンス化SCNが設定されます。宛先データベースにすでにデータベース・オブジェクトが存在する場合、MAINTAIN_SCHEMASプロシージャでは、既存のデータベース・オブジェクトを保持し、これらのデータベース・オブジェクトのインスタンス化SCNを設定します。この例では、MAINTAIN_SCHEMASプロシージャを実行する前に、各データベースにhrスキーマが存在します。
図2-7に、この例で作成される環境の概要を示します。
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の表が含まれています。手順については、第9章「Oracle Streamsの競合解消」を参照してください。
|
関連項目: Oracle Enterprise Managerを使用してこのレプリケーション環境を構成する場合の例は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
DBMS_STREAMS_ADMパッケージの次のプロシージャでは、Oracle Streamsによってメンテナンスされるレプリケーション環境が構成されます。
MAINTAIN_GLOBAL
MAINTAIN_SCHEMAS
MAINTAIN_SIMPLE_TTS
MAINTAIN_TABLES
MAINTAIN_TTS
PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP
perform_actionsパラメータをTRUEに設定して、これらのいずれかのプロシージャでレプリケーション環境を直接構成すると、別のターミナル・ウィンドウで構成の進捗を監視できます。
次の手順を実行して、Oracle Streams構成の進捗を監視します。
SQL*Plusで、Oracle Streams管理者として取得データベースに接続します。構成プロシージャを実行しているウィンドウとは別のターミナル・ウィンドウを使用します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
構成操作の基本的な情報については、次の問合せを実行します。
COLUMN SCRIPT_ID HEADING 'Script ID' FORMAT A40 COLUMN CREATION_TIME HEADING 'Creation|Time' FORMAT A20 SELECT SCRIPT_ID, TO_CHAR(CREATION_TIME,'HH24:Mi:SS MM/DD/YY') CREATION_TIME FROM DBA_RECOVERABLE_SCRIPT;
出力は次のようになります。
Creation
Script ID Time
---------------------------------------- --------------------
64EE0DFCC374CE7EE040578C89174D3E 07:46:54 03/12/09
この出力には、構成操作のスクリプトIDおよび操作が開始された時間が示されています。
構成操作の進捗の詳細は、次の問合せを実行します。
COLUMN STATUS HEADING 'Status' FORMAT A12
COLUMN PROGRESS HEADING 'Steps|Completed' FORMAT A10
COLUMN ELAPSED_SECONDS HEADING 'Elapsed|Seconds' FORMAT A10
COLUMN CURRENT_STEP HEADING 'Current Step' FORMAT A20
COLUMN PROCEDURE HEADING 'Procedure' FORMAT A20
SELECT rs.STATUS,
rs.DONE_BLOCK_NUM||' of '||rs.TOTAL_BLOCKS PROGRESS,
TO_CHAR(TO_NUMBER(SYSDATE-rs.CREATION_TIME)*86400,9999.99) ELAPSED_SECONDS,
SUBSTR(TO_CHAR(rsb.FORWARD_BLOCK),1,100) CURRENT_STEP,
rs.INVOKING_PACKAGE||'.'||rs.INVOKING_PROCEDURE PROCEDURE
FROM DBA_RECOVERABLE_SCRIPT rs, DBA_RECOVERABLE_SCRIPT_BLOCKS rsb
WHERE rs.SCRIPT_ID = rsb.SCRIPT_ID AND
rsb.BLOCK_NUM = rs.DONE_BLOCK_NUM + 1;
出力は次のようになります。
Steps Elapsed
Status Completed Seconds Current Step Procedure
------------ ---------- ---------- -------------------- --------------------
EXECUTING 7 of 39 132 -- DBMS_STREAMS_ADM.MAI
-- Set up queue "STR NTAIN_SCHEMAS
MADMIN"."PROD$APPQ"
--
BEGIN
dbms_streams_adm.s
et_up_queue(
queue_ta
この出力には、構成操作に関する次の情報が示されています。
構成操作の現在の状態(GENERATING、NOT EXECUTED、EXECUTING、EXECUTEDまたはERROR)
完了した手順の数、および操作を完了するために必要な手順の合計数
構成操作が実行されている時間数(秒単位)
現在の手順によって実行されている操作
現在の手順で実行されているPL/SQLプロシージャ
