| Oracle® Streamsレプリケーション管理者ガイド 12cリリース1 (12.1) B71328-02 |
|
 前 |
 次 |
この章では、Oracle Streamsレプリケーション環境を準備する方法について説明します。また、Oracle Streamsレプリケーション環境を準備する場合のベスト・プラクティスについても説明します。
この章の内容は次のとおりです。
|
関連項目: Oracle Streamsの概要は、『Oracle Streams概要および管理』を参照してください。このマニュアルでは、『Oracle Streams概要および管理』で説明する概念を理解していることを想定しています。 |
レプリケーションとは、複数のデータベースのデータベース・オブジェクトおよびデータを共有するプロセスです。レプリケートされたデータベース・オブジェクトおよびデータを複数のデータベースでメンテナンスするために、あるデータベース上でデータベース・オブジェクトのいずれかが変更されると、その変更は他のデータベースと共有されます。このプロセスによって、データベース・オブジェクトおよびデータは、レプリケーション環境にあるすべてのデータベースで、同期状態が保たれます。Oracle Streamsレプリケーション環境では、変更が発生したデータベースはソース・データベース、変更が共有されるデータベースは宛先データベースと呼ばれます。
Oracle Streamsを使用する場合、データ操作言語(DML)変更またはデータ定義言語(DDL)変更のレプリケーションでは、通常、次の3つの手順が実行されます。
取得プロセス、同期取得またはアプリケーションによって、1つ以上の論理変更レコード(LCR)が作成され、エンキューされます。LCRは、データベース変更を説明する特定の形式のメッセージです。取得プロセスではREDOログから取得した変更がLCRに再フォーマットされ、同期取得では内部メカニズムを使用して変更がLCRに再フォーマットされ、アプリケーションではLCRを構成できます。変更がDML操作の場合、各行LCRでは、ソース・データベースのレプリケートされた表に対するDML操作による行の変更がカプセル化されます。変更がDDL操作の場合、DDL LCRでは、ソース・データベースのレプリケートされたデータベース・オブジェクトに対するDDL変更がカプセル化されます。
伝播によって、ステージングされたLCRが別のキューに伝播されますが、通常、このキューはLCRが取得されたデータベースとは別のデータベースに存在します。LCRは、宛先データベースに到達する前に、複数の異なるキューに伝播できます。
宛先データベースでは、適用プロセスによって変更がコンシュームされます。適用プロセスでは、LCRをデキューしてレプリケートされたデータベース・オブジェクトに直接適用するか、またはLCRをデキューして適用ハンドラに送信できます。Oracle Streamsレプリケーション環境では、適用ハンドラによって、カスタマイズされたLCRの処理が実行されます。適用ハンドラでは、LCRの変更をレプリケートされたデータベース・オブジェクトに適用するか、または他のなんらかの方法でLCRをコンシュームできます。
手順1および手順3は必須ですが、取得プロセスまたは同期取得では変更をキューにエンキューでき、適用プロセスでは同じキューから変更をデキューできる場合があるため、手順2はオプションです。また、アプリケーションで、LCRを宛先データベースに直接エンキューすることもできます。さらに、Oracle DatabaseがOracle以外のデータベースと情報を共有している異機種間レプリケーション環境では、LCRを伝播せずに、適用プロセスがOracle以外のデータベースに直接変更を適用できます。
図1-1に、Oracle Streamsレプリケーション環境での情報の流れを示します。
このマニュアルでは、レプリケーションにOracle Streamsを使用する方法について説明します。また、次の情報も含まれます。
Oracle Streamsレプリケーションに関する概念
Oracle Streamsレプリケーション環境の構成手順
Oracle Streamsレプリケーション環境の管理、監視およびトラブルシューティングの手順
Oracle Streamsレプリケーション環境を作成およびメンテナンスする例
レプリケーションは、情報共有形式の1つです。Oracle Streamsではレプリケーションが実行可能になり、また、メッセージ、イベントの管理と通知、データ・ウェアハウスのロード、データ保護など、他の情報共有形式も使用できます。
|
関連項目: Oracle Streamsの詳細は、『Oracle Streams概要および管理』を参照してください。 |
Oracle Streamsレプリケーションを使用する一般的な理由は、次のとおりです。
可用性: レプリケーションを使用すると複数のサイト間でアクティビティのバランスを保つことができるため、共有データへの高速なローカル・アクセスが可能になります。一部のユーザーが1つのサーバーにアクセスしてる間に、他のユーザーは別のサーバーにアクセスできるため、すべてのサーバーの負荷が削減されます。また、ユーザーはアクセス・コストが最も低いレプリケーション・サイト(通常、ユーザーから地理的に最も近いサーバー)のデータを利用できます。
パフォーマンスおよびネットワーク負荷の削減: レプリケーションを使用すると複数のサイト間でアクティビティのバランスを保つことができるため、共有データへの高速のローカル・アクセスが可能になります。一部のユーザーが1つのサーバーにアクセスしてる間に、他のユーザーは別のサーバーにアクセスできるため、すべてのサーバーの負荷が削減されます。アプリケーションでは、1つの中央サーバーにアクセスするかわりに、様々な地域サーバーにアクセスできます。この構成によってネットワーク負荷を大幅に削減できます。
ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールは、Oracle Databaseの組込み部分であるルール・エンジンによって評価されます。ルールによって、Oracle Streamsレプリケーション環境での情報の流れが制御されます。次の各コンポーネントはルール・エンジンのクライアントです。
取得プロセス
同期取得
伝播
適用プロセス
ルールを使用して、これらの各Oracle Streamsクライアントの動作を制御します。ルール・セットは複数のルールで構成されています。取得プロセス、伝播および適用プロセスにはポジティブ・ルール・セットおよびネガティブ・ルール・セットを関連付けることができますが、同期取得で使用できるのはポジティブ・ルール・セットのみです。
レプリケーション環境では、Oracle Streamsクライアントは、論理変更レコード(LCR)がルール・セットを満たす場合に操作を実行します。一般的に、LCRについてTRUEと評価されるルールがネガティブ・ルール・セットに存在せず、LCRについてTRUEと評価されるルールがポジティブ・ルール・セットに1つでも存在する場合に、LCRはOracle Streamsクライアントのルール・セットを満たします。Oracle Streamsクライアントがポジティブ・ルール・セットおよびネガティブ・ルール・セットの両方に関連付けられている場合、常にネガティブ・ルール・セットが先に評価されます。
具体的には、Oracle Streamsレプリケーション環境では、次の方法で情報の流れを制御します。
取得プロセスでREDOログから取得または廃棄する変更を指定します。REDOログで検出された変更が取得プロセスのルール・セットを満たす場合、取得プロセスはその変更を取得します。REDOログで検出された変更が取得プロセスのルール・セットを満たさない場合、取得プロセスはその変更を廃棄します。
同期取得で取得または廃棄する変更を指定します。表に対するDML変更が同期取得のルール・セットを満たす場合、同期取得はその変更を取得します。表に対するDML変更が同期取得のルール・セットを満たさない場合、同期取得はその変更を廃棄します。
伝播であるキューから別のキューに伝播させるか、または廃棄するLCRを指定します。キュー内のLCRが伝播のルール・セットを満たす場合、伝播はそのLCRを送信します。キュー内のLCRが伝播のルール・セットを満たさない場合、伝播はそのLCRを廃棄します。
適用プロセスでデキューするか、または廃棄するLCRを指定します。キュー内のLCRが適用プロセスのルール・セットを満たす場合、適用プロセスはLCRをデキューおよび処理します。キュー内のLCRが適用プロセスのルール・セットを満たさない場合、適用プロセスはそのLCRを廃棄します。
Oracleが提供するDBMS_STREAMS_ADMのPL/SQLパッケージを使用して、Oracle Streamsレプリケーション環境のルールを作成できます。このシステム作成ルールは、次のレベルで指定できます。
表レベル: 特定の表に対する変更についてTRUEと評価されるルール条件を含みます。
スキーマ・レベル: 特定のスキーマおよびそのスキーマ内のデータベース・オブジェクトに対する変更についてTRUEと評価されるルール条件を含みます。
グローバル・レベル: データベースに対するすべての変更についてTRUEと評価されるルール条件を含みます。
また、1つのシステム作成ルールがDML変更またはDDL変更のどちらかについてTRUEと評価される場合はありますが、両方がそのように評価されることはありません。そのため、たとえば、特定の表に対するDML変更とDDL変更の両方をレプリケートするには、その表に対する表レベルのDMLルールおよび表レベルのDDLルールの両方が必要です。
Oracle Streamsでは、サブセット・ルールを使用した表データのサブセット化もサポートされています。データベース内のレプリケートされた表にデータのサブセットのみが含まれている場合は、データの適切なサブセットのみがレプリケートされるようにOracle Streamsを構成できます。たとえば、あるデータベースは、特定の部門についてのみ従業員のデータをメンテナンスできます。レプリケーション環境の他の1つ以上のデータベースに、従業員表のすべてのデータが含まれている場合があります。この場合、サブセット・ルールでは、サブセット表を使用してその部門の従業員データの変更をレプリケートできますが、他部門の従業員の変更はレプリケートできません。
サブセット化は、Oracle Streamsの情報の流れの中で、どの時点でも実行できます。つまり、取得プロセスまたは同期取得では、サブセット・ルールを使用して特定の表に対する変更のサブセットを取得でき、伝播では、サブセット・ルールを使用して特定の表に対する変更のサブセットを伝播でき、適用プロセスでは、サブセット・ルールを使用して特定の表に対する変更のサブセットを適用できます。
|
注意: 同期取得では表ルールのみが使用されます。スキーマ・ルールおよびグローバル・ルールは無視されます。 |
|
関連項目: Oracle Streamsでルールを使用する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
Oracle Streamsレプリケーションを構成する前に、次の決定を行います。
レプリケーション環境を構成する前に、まず、レプリケーション環境に含めるデータベースの数、レプリケートするデータベース・オブジェクト、およびレプリケーション環境でのデータベースの変更の流れを決定します。
次の項では、最も一般的なタイプのレプリケーション環境について説明します。
これらの一般的なレプリケーション環境で要件が満たされない場合は、Oracle Streamsを使用して、ほぼすべてのタイプのカスタム・レプリケーション環境を構成できます。たとえば、カスタム・レプリケーション環境では、データベースの変更を、宛先データベースに適用する前に複数の中間データベースを介して送信できます。
2データベース・レプリケーション環境は、レプリケートされたデータベース・オブジェクトを2つのデータベースのみで共有するレプリケーション環境です。一方のデータベースでレプリケートされたデータベース・オブジェクトに対して行われた変更は、取得された後、もう一方のデータベースに直接送信されて適用されます。2データベース・レプリケーション環境では、一方のデータベースのみでデータベース・オブジェクトに対する変更が許可される場合も、両方のデータベースでデータベース・オブジェクトに対する変更が許可される場合もあります。
レプリケートされたデータベース・オブジェクトに対する変更が一方のデータベースのみで許可されている場合、もう一方のデータベースには、これらのデータベース・オブジェクトの読取り専用レプリカが含まれます。これを単方向レプリケーション環境と呼び、通常は次の基本コンポーネントが含まれます。
1つ目のデータベースには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
1つ目のデータベースには、取得した変更を2つ目のデータベースに送信する伝播があります。
2つ目のデータベースには、1つ目のデータベースから変更を適用する適用プロセスがあります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図1-2に、単方向レプリケーション用に構成された2データベース・レプリケーション環境を示します。
2データベース・レプリケーション環境では、両方のデータベースで、レプリケートされたデータベース・オブジェクトを変更できます。この場合、データベース・オブジェクトに対する変更は、両方のデータベースで取得され、他方のデータベースに送信されて取得されます。これを双方向レプリケーション環境と呼び、通常は次の基本コンポーネントが含まれます。
各データベースには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
各データベースには、取得した変更をもう一方のデータベースに送信する伝播があります。
各データベースには、もう一方のデータベースから変更を適用する適用プロセスがあります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図1-3に、双方向レプリケーション用に構成された2データベース・レプリケーション環境を示します。
通常、双方向レプリケーション環境では、レプリケートされたデータベース・オブジェクトの同期化を維持するために競合解消を構成する必要があります。Oracle Enterprise Manager Cloud ControlのStreamsレプリケーションの設定ウィザードまたはDBMS_STREAMS_ADMパッケージの構成プロシージャを使用して、2データベース・レプリケーション環境を構成できます。
ハブアンドスポーク・レプリケーション環境は、集中データベース(ハブ)がセカンダリ・データベース(スポーク)と通信する環境です。スポーク相互は直接通信しません。ハブ・アンド・スポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトへの変更がスポークで許可されている場合と許可されていない場合があります。
スポークが変更を許可しない場合、スポークにはハブのデータベース・オブジェクトの読取り専用レプリカが含まれます。このタイプのハブアンドスポーク・レプリケーション環境には、通常は次の基本コンポーネントがあります。
ハブには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
ハブには、取得された変更を各スポークに送信する伝播があります。
各スポークには、ハブから変更を適用する適用プロセスがあります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図1-4に、読取り専用スポークのあるハブアンドスポーク・レプリケーション環境を示します。
スポークがデータベース・オブジェクトに対する変更を許可する場合、通常は変更が取得されてハブに送信され、ハブが他のスポークに変更をレプリケートします。このタイプのハブアンドスポーク・レプリケーション環境には、通常は次の基本コンポーネントがあります。
ハブには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
ハブには、取得された変更を各スポークに送信する伝播があります。
各スポークには、レプリケートされたデータベース・オブジェクトに対する変更を取得する取得プロセスまたは同期取得があります。
各スポークには、スポークで行われた変更をハブに送信する伝播があります。
各スポークには、ハブからの変更と他のスポークからの変更を適用する適用プロセスがあります。
ハブには、各スポークからの変更を適用する個別の適用プロセスがあります。各適用プロセスは、それぞれのスポークから変更を適用する必要があります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図1-5に、読取り/書込みスポークのあるハブアンドスポーク・レプリケーション環境を示します。
通常、スポーク・データベースでの変更が許可されるハブアンドスポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトの同期化を維持するために競合解消を構成する必要があります。ハブアンドスポーク・レプリケーション環境では、レプリケートされたデータベース・オブジェクトに対する変更が一部のスポークでは許可されますが、残りのスポークでは許可されない場合があります。
たとえば、保険会社が本社と販売代理店で顧客データを共有する場合にこの構成を使用します。この構成のネットワーク・バーションはエンド・スポークとハブの接続性が制限されている場合、特に有用です。販売代理店には本社に接続する支社へ直接の接続性があっても、本社への直接の接続性がないとします。このネットワーク・ルーティングのタイプは、すべてのロケーションに直接接続する場合に発生する一部の複雑さを排除します。ハブアンドスポーク構成はデータ・ウェアハウス環境にも有用です。データ・ウェアハウス環境では、詳細データが各ストアまたはスポークで維持され、より高レベルのデータはデータ・ウェアハウスまたはハブで共有されます。
Oracle Enterprise Manager Cloud ControlのStreamsレプリケーションの設定ウィザードまたはDBMS_STREAMS_ADMパッケージの構成プロシージャを使用して、ハブアンドスポーク・レプリケーション環境を構成できます。
n-wayレプリケーション環境は、各データベースが環境内の他のデータベースと相互に直接通信する環境です。あるデータベースでレプリケートされたデータベース・オブジェクトに対する変更は、取得されて環境内の他の各データベースに直接送信され、そこで適用されます。
n-wayレプリケーション環境には、通常は次の基本コンポーネントがあります。
各データベースには、レプリケートされたデータベース・オブジェクトに対する変更を取得する1つ以上の取得プロセスまたは同期取得があります。
各データベースには、取得された変更を他のデータベースに相互に送信する伝播があります。
各データベースには、他の各データベースからの変更を適用する適用プロセスがあります。別の適用プロセスが、各ソース・データベースから変更を適用する必要があります。
パフォーマンスを最適化するために、各取得プロセスと適用プロセスには固有のキューがあります。
図1-6に、n-wayレプリケーション環境を示します。
オラクル社が提供する次のパッケージを使用して、n-wayレプリケーション環境を構成できます。
DBMS_STREAMS_ADMでは、キューの設定、取得プロセスまたは同期取得の作成、伝播の作成、適用プロセスおよびレプリケーション環境でのルールおよびルール・セットの構成などの、ほとんどの構成アクションを実行できます。
DBMS_CAPTURE_ADMでは、レプリケーション環境で構成した取得プロセスを開始できます。
DBMS_APPLY_ADMでは、競合解消を構成し、その他の構成タスクと同様に適用プロセスを開始できます。
n-way構成は、データのスケーラビリティおよび可用性を必要とする組織によって頻繁に使用されます。これらのアプリケーションでよく使用されるのが世界中のレプリカを使用するfollow the sunモデルです。たとえば、米国、欧州およびアジアにコール・センターがあり、それぞれに顧客データの完全なコピーがあるとします。顧客からの電話は、時刻に応じて適切なコール・センターにルーティングされます。各コール・センターからは、データに対する高速かつローカルなアクセスを確保しています。サイトがなんらかの理由で使用不可能になった場合、トランザクションは存続しているロケーションにルーティングできます。このタイプの構成は、複数のロケーション間でロード・バランシングの提供にも使用します。
通常、n-wayレプリケーション環境では、レプリケートされたデータベース・オブジェクトの同期化を維持するために競合解消を構成する必要があります。
n-wayレプリケーション環境の構成は、このマニュアルの対象外です。n-wayレプリケーション環境を構成する例の詳細は、「Oracle Streamsの拡張例」を参照してください。
ローカル取得とは、ソース・データベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得とは、ソース・データベース以外のデータベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得を使用する主な理由は、ソース・データベースの負荷を削減して、パフォーマンスを向上させることです。
ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。次のいずれかのデータベースを取得データベースとして使用できます。
ソース・データベース(ローカル取得)
宛先データベース(ダウンストリーム取得)
第3のデータベース(ダウンストリーム取得)
図1-7に、取得データベースの役割を示します。
ソース・データベースまたは第3のデータベースを取得データベースとして使用すると、伝播によって、取得データベースから宛先データベースに変更が送信されます。宛先データベースを取得データベースとして使用すると、取得プロセスと適用プロセスで同じキューが使用されるため、データベース間でこの伝播を行う必要はありません。
ダウンストリーム取得プロセスを構成する場合は、構成するダウンストリーム取得プロセスのタイプを決定する必要があります。次のタイプを使用できます。
リアルタイム・ダウンストリーム取得プロセスの構成: ソース・データベースのREDO転送サービスがREDOデータをダウンストリーム・データベースに送信し、ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)でネットワークを介してREDOデータを受け取り、スタンバイREDOログにREDOデータを格納します。
アーカイブ・ログ・ダウンストリーム取得プロセスの構成: ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスでそれらのアーカイブREDOログ・ファイル内の変更を取得します。これらのログ・ファイルは、REDO転送サービスを使用して自動的に転送するか、またはFTPなどの方法を使用して手動で転送できます。
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更の取得にかかる時間が短縮されるという利点があります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルがアーカイブされるまで待たずにREDOログ・ファイルから変更を取得できるため、時間が短縮されます。1つのダウンストリーム・データベースで、同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成することはできますが、複数のソース・データベースに対するリアルタイム・ダウンストリーム取得を構成することはできません。
リアルタイム・ダウンストリーム取得と比較して、アーカイブ・ログ・ダウンストリーム取得では、ダウンストリーム・データベースで複数のソース・データベースからのダウンストリーム取得プロセスを使用できるという利点があります。複数のソース・データベースから1つのダウンストリーム・データベースにREDOログ・ファイルをコピーし、それらのREDOログ・ファイル内の変更を取得するように複数のアーカイブ・ログ・ダウンストリーム取得プロセスを構成することができます。
リアルタイム・ダウンストリーム取得プロセスを構成する場合は、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」および「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」の手順を完了する必要があります。
REDO転送サービスによってダウンストリーム・データベースに自動的に転送されるアーカイブREDOログ・ファイルを使用するアーカイブ・ログ・ダウンストリーム取得プロセスを構成する場合は、「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」の手順を完了する必要があります。
|
注意: これらのプロシージャのいずれかでデータベースのインスタンス化にRMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用する場合、宛先データベースは取得データベースとして使用できません。 |
|
関連項目:
|
レプリケーション環境では、レプリケートされた特定のデータベース・オブジェクトに対する変更は1つのデータベースにのみ制限できます。この場合、レプリケートされたデータベース・オブジェクトは、レプリケーション環境内の1つのデータベースで読取り/書込み可能となり、他のデータベースでは読取り専用となります。また、レプリケーション環境では、レプリケートされたデータベース・オブジェクトに対する変更を2つ以上のデータベースで実行できます。
レプリケートされたデータベース・オブジェクトを2つ以上のデータベースで変更できると、競合が発生する可能性があります。競合は、LCR内の古い値と、表内の予期されるデータが一致しないことです。複数データベース上で同じデータに対して同時のデータ操作言語(DML)操作を許可しているOracle Streamsレプリケーション環境では、競合が発生する可能性があります。通常、競合は、レプリケートされた表の同じ行が2つ以上のデータベースでほぼ同時に変更されると発生します。競合が解消されない場合、レプリカ・データベースのデータに一貫性がなくなる可能性があります。
通常、競合が発生する可能性があるのは、次のような一般的なタイプのレプリケーション環境です。
レプリケートされたデータベース・オブジェクトが両方のデータベースで読取り/書込み可能な2データベース環境での双方向のレプリケーション
レプリケートされたデータベース・オブジェクトがハブおよび1つ以上のスポークで読取り/書込み可能なハブ・アンド・スポーク・レプリケーション
レプリケートされたデータベース・オブジェクトが複数のデータベースで読取り/書込み可能なn-wayレプリケーション
これらの一般的なタイプのレプリケーション環境の詳細は、「どのタイプのレプリケーション環境を構成するかの決定」を参照してください。
Oracle Streamsには、競合を自動的に解消するためのビルトイン競合ハンドラが用意されています。また、ビジネス・ルールに固有のデータ競合を解消するために、独自のカスタム競合ハンドラを作成することもできます。この種の競合ハンドラは、プロシージャDMLハンドラまたはエラー・ハンドラに付属させることができます。
構成するレプリケーション環境で競合が発生する可能性がある場合は、競合ハンドラを作成してそれらの競合を解消するようにします。
Oracle Streamsレプリケーションでは、複数データベースで異なるデータベース・オブジェクトの共有がサポートされます。Oracle Streams環境では、異なるデータベースに、異なる構造を持つレプリケートされたデータベース・オブジェクトを含めることができます。Oracle Streamsレプリケーションでは、ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEと評価される場合に発生する、論理変更レコード(LCR)に対する変更です。LCRに必要な変更を宛先データベースで適用できるように、取得、伝播または適用中のルールベースの変換を構成できます。
たとえば、ソース・データベースの表は、宛先データベースの表と同じデータを持っていても、一部の列名が異なる場合があります。この場合、ルールベースの変換によって、宛先データベースで正常に適用されるように、ソース・データベースからのLCRにある列名を変更できます。
ルールベースの変換には、宣言とカスタムの2つのタイプがあります。宣言ルールベースの変換では、スキーマ名の変更、表名の変更、列の追加、列名の変更、列リストの保持、列の削除などの行LCRの一般的な変換を実行できます。このような変換は、DBMS_STREAMS_ADMパッケージのプロシージャを使用して指定します。Oracle Streamsでは、PL/SQLを起動せずに内部的に宣言変換が実行されます。
カスタム・ルールベースの変換では、変換を実行するユーザー定義PL/SQLファンクションが必要です。Oracle Streamsでは、変換を実行するPL/SQLファンクションが起動されます。カスタム・ルールベースの変換を実行すると、取得LCR、永続LCRまたはユーザー・メッセージを変更できます。たとえば、カスタム・ルールベースの変換で、LCR内にある特定の列のデータ型を変更できます。カスタム・ルールベースの変換は、入力としてANYDATAオブジェクトを取り、ANYDATAオブジェクトを戻すPL/SQLファンクションとして定義する必要があります。
ルールベースの変換は、Oracle Streamsの情報の流れの中で、どの時点でも実行できます。取得プロセスまたは同期取得は、ポジティブ・ルール・セットのルールが変更についてTRUEと評価される場合に、この変更についてルールベースの変換を実行できます。同様に、伝播または適用プロセスは、ポジティブ・ルール・セットのルールがLCRについてTRUEと評価される場合に、このLCRについて、ルールベースの変換を実行できます。
レプリケーション環境にデータベース・オブジェクトの異なるコピーを含める場合は、LCRが宛先データベースで正常に適用されるように、LCRを変更するルールベースの変換を作成します。
|
注意: このマニュアルでは、「ルールベースの変換」という用語は、本文が宣言ルールベースの変換とカスタム・ルールベースの変換の両方に該当する場合に使用されます。このマニュアルでは、必要に応じて、2つのタイプのルールベースの変換を区別しています。 |
|
関連項目: ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。 |
適用ハンドラを使用すると、適用プロセスにより、SQL文のコレクションまたはユーザーが作成したPL/SQLプロシージャにメッセージが渡されて処理されます。
次のタイプの適用ハンドラを使用できます。
文DMLハンドラでは、SQL文のコレクションを使用して行の論理変更レコード(行LCR)を処理します。
プロシージャDMLハンドラでは、PL/SQLプロシージャを使用して行LCRを処理します。
DDLハンドラでは、PL/SQLプロシージャを使用してDDL LCRを処理します。
メッセージ・ハンドラでは、PL/SQLプロシージャを使用してユーザー・メッセージを処理します。
プリコミット・ハンドラでは、PL/SQLプロシージャを使用してトランザクションのコミット情報を処理します。
エラー・ハンドラでは、PL/SQLプロシージャを使用して適用エラーの原因となった行LCRを処理します。
適用ハンドラでは、カスタマイズした方法でメッセージを処理できます。たとえば、LCRの変更が適用された後で、ハンドラで表に対する変更を監査したり、LCRをキューにエンキューしたりできます。その後、再エンキューされたLCRをアプリケーションで処理できます。また、ハンドラを使用して、データベースに対する変更を監査することもできます。
レプリケーション環境でLCRをカスタマイズされた方法で処理する必要がある場合は、目的を達成するために使用する必要がある適用ハンドラを決定してください。次に、カスタム処理を実行するPL/SQLプロシージャを作成して、環境の構成時にそれらのプロシージャを適用ハンドラとして指定します。
|
関連項目: 『Oracle Streams概要および管理』 |
通常、レプリケーション環境では、レプリケートされたデータベース・オブジェクトに対するデータ操作言語(DML)変更がメンテナンスされます。DML変更には、INSERT、UPDATE、DELETEおよびLOBの更新操作が含まれます。レプリケーション環境でデータ定義言語(DDL)変更もメンテナンスするかどうかを決定する必要があります。DDL変更が発生する文には、CREATE TABLE、ALTER TABLE、ALTER TABLESPACE、ALTER DATABASEなどがあります。
一部のOracle Streamsレプリケーション環境では、各データベースに同じデータベース・オブジェクトが存在すると想定されます。この場合、Oracle Streamsを使用してDDL変更をメンテナンスすると、共有データベース・オブジェクトを簡単に同期化できます。ただし、一部のOracle Streamsレプリケーション環境では、データベースによって共有データベース・オブジェクトが異なる必要があります。たとえば、2つの異なるデータベースで、ある表の名前または形状が異なっている場合があります。これらの環境では、ルールベースの変換および適用ハンドラを使用して、データベース間で共有可能になるように変更を変換できるため、Oracle Streamsを使用してDDL変更をメンテナンスする必要はありません。この場合、DDL変更が必要な各データベースで手動で変更を加える必要があります。
データ定義言語(DDL)変更をレプリケートする際、制約または索引に対してシステム生成名を許可しないでください。異なるデータベースのオブジェクト名が一致しないため、これらのデータベース・オブジェクトに対する変更は、宛先データベースで失敗する可能性が高いです。また、宛先データベースが異なる場合、STORAGE句によって問題が発生する場合もあります。Oracle Streams環境でDDLをレプリケートしないことを決定する場合、環境内の各データベースですべての表構造の変更を手動で実行する必要があります。
|
関連項目:
|
Oracle Streamsレプリケーション環境を構成する場合、次の3つのオプションを使用できます。
Streamsレプリケーションの設定ウィザードを実行して、2つのデータベース間のレプリケーションを構成します。このウィザードを複数回実行すると、3つ以上のデータベースを含むレプリケーション環境を構成できます。
このウィザードでは、レプリケーション環境の構成プロセスを実行できますが、このウィザードを使用して構成できるレプリケーション環境のタイプには制限があります。たとえば、このウィザードでは、現在、同期取得は構成できません。
レプリケーション構成ウィザードの詳細は、「Streamsレプリケーションの設定ウィザードを使用したレプリケーションの構成」およびOracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。
DBMS_STREAMS_ADMが提供されているPL/SQLパッケージの構成プロシージャを実行して、2つのデータベース間のレプリケーションを構成します。このプロシージャを複数回実行すると、3つ以上のデータベースを含むレプリケーション環境を構成できます。
次のプロシージャによって、Oracle Streamsレプリケーションが構成されます。
MAINTAIN_GLOBALプロシージャ: 2つのデータベース間でデータベース・レベルの変更をレプリケートするOracle Streams環境が構成されます。
MAINTAIN_SCHEMASプロシージャ: 2つのデータベース間で、指定されたスキーマに対する変更をレプリケートするOracle Streams環境が構成されます。
MAINTAIN_SIMPLE_TTSプロシージャ: 宛先データベースでソース・データベースからの単一の表領域がクローニングされ、Oracle Streamsを使用して両方のデータベースでこの表領域がメンテナンスされます。
MAINTAIN_TABLESプロシージャ: 2つのデータベース間で、指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。
MAINTAIN_TTSプロシージャ: 宛先データベースでソース・データベースからの表領域セットがクローニングされ、Oracle Streamsを使用して両方のデータベースでこれらの表領域がメンテナンスされます。
これらのプロシージャでは、1回のプロシージャ・コールで複数のOracle Streamsコンポーネントが構成され、これらのプロシージャは、Oracle Streamsのベスト・プラクティスに自動的に従います。それらは、一方向、双方向およびハブ・アンド・スポークのレプリケーション環境の構成に適しています。
これらのプロシージャの詳細は、「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
各Oracle Streamsコンポーネントを個別に構成します。これらのコンポーネントには、キュー、取得プロセス、同期取得、伝播、適用プロセスなどがあります。このオプションは、n-wayレプリケーション環境を構成する場合またはウィザードや構成プロシージャでは構成できない別のタイプのレプリケーション環境を構成する場合に選択します。
レプリケーション環境の各コンポーネントを個別に構成する方法の詳細は、第3章「Oracle Streamsレプリケーションの柔軟な構成」を参照してください。
構成するレプリケーション環境のタイプによっては、構成オプションが限定される場合があります。「どのタイプのレプリケーション環境を構成するかの決定」を参照してください。
表1-1に、各タイプのレプリケーション環境で使用可能な構成オプションを示します。
表1-1 Oracle Streamsレプリケーションの構成オプション
| レプリケーション環境のタイプ | 構成オプションと例 |
|---|---|
|
Oracle Enterprise Manager Cloud ControlのStreamsレプリケーションの設定ウィザード。例は次のとおりです。
提供の 各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。
|
|
|
Oracle Enterprise Manager Cloud ControlのStreamsレプリケーションの設定ウィザード。例は次のとおりです。
提供の 各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。 |
|
|
提供の 各Oracle Streamsコンポーネントの個別の構成。 |
|
|
読取り/書込み可能なハブ、および1つ以上の読取り/書込み可能なスポークを持つハブ・アンド・スポーク・レプリケーション |
Oracle Enterprise Manager Cloud ControlのStreamsレプリケーションの設定ウィザード。例は次のとおりです。
提供の 各Oracle Streamsコンポーネントの個別の構成。 |
|
各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。
|
|
|
カスタム・レプリケーション環境 |
各Oracle Streamsコンポーネントの個別の構成。手順については、第3章「Oracle Streamsレプリケーションの柔軟な構成」を参照してください。例は次のとおりです。
|
レプリケーション環境を構成する前に、「Oracle Streamsレプリケーションを構成する前に実行するタスク」で説明されているタスクを完了します。
ここでは、Oracle Streamsレプリケーションを構成する前に実行するタスクについて説明します。
Oracle Streams環境を構成および管理するには、適切な権限を持つ新しいユーザーを作成するか、それらの権限を既存のユーザーに付与します。SYSまたはSYSTEMユーザーをOracle Streams管理者として使用しないでください。また、Oracle Streams管理者は、デフォルト表領域としてSYSTEM表領域を使用しないでください。
通常、Oracle Streams管理者のユーザー名はstrmadminですが、適切な権限を持つすべてのユーザーがOracle Streams管理者になることができます。この項の例では、Oracle Streams管理者のユーザー名としてstrmadminを使用します。
関連する各Oracle StreamsデータベースでOracle Streams管理者用に個別の表領域を作成します。この表領域には、スキーマ所有のバッファ・キューからオーバーフローしたすべてのメッセージを含む、Oracle Streams管理者スキーマで作成されたすべてのオブジェクトが格納されます。
|
関連項目: Oracle Enterprise Manager Cloud Controlを使用してOracle Streams管理者を作成する手順についてはOracle Enterprise Manager Cloud Controlのオンライン･ヘルプを参照してください。 |
Oracle Streamsを使用する環境の各データベースでOracle Streams管理者を構成するには、次の手順を実行します。
SQL*Plusで、ユーザーの作成、権限の付与および表領域の作成を行うことができる管理ユーザーとして接続します。これ以降のすべての手順は、この管理ユーザーとして接続したまま実行します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Streams管理者用の表領域を作成するか、既存の表領域を使用します。たとえば、次の文では、Oracle Streams管理者用の新規表領域が作成されます。
CREATE TABLESPACE streams_tbs DATAFILE '/usr/oracle/dbs/streams_tbs.dbf' SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
Oracle Streams管理者の役割を果たす新規ユーザーを作成するか、既存のユーザーを使用します。たとえば、ユーザーstrmadminを作成し、このユーザーがstreams_tbs表領域を使用するように指定するには、次の文を実行します。
CREATE USER strmadmin IDENTIFIED BY password
DEFAULT TABLESPACE streams_tbs
QUOTA UNLIMITED ON streams_tbs;
|
注意: 管理ユーザー用の適切なパスワードを入力してください。 |
|
関連項目: パスワード選択のガイドラインについては、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
次のようにして、Oracle Streams管理者にDBAロールを付与します。
GRANT DBA TO strmadmin;
|
注意: 取得プロセス、同期取得および適用プロセスを作成または変更するユーザーには、DBAロールが必要です。ユーザーがこれらのタスクを実行する必要がない場合は、ユーザーのDBAロールを取り消すことができます。 |
DBMS_STREAMS_AUTHパッケージのGRANT_ADMIN_PRIVILEGEプロシージャを実行します。
ユーザー作成サブプログラム内のパッケージのサブプログラムを実行する場合、ユーザーには、パッケージに対する明示的なEXECUTE権限が必要です。また、ユーザー作成サブプログラム内のビューを問い合せる場合は、そのデータ・ディクショナリ・ビューに対する明示的なREADまたはSELECT権限が必要です。これらの権限は、ロールでは付与できません。これらの権限をOracle Streams管理者に付与するには、GRANT_ADMIN_PRIVILEGEプロシージャを実行するか、または直接付与します。
GRANT_ADMIN_PRIVILEGEプロシージャでは、パラメータ設定に応じて、Oracle Streams管理者にこれらの権限が直接付与されるか、またはこれらの権限を付与するために編集して実行できるスクリプトが生成されます。
|
関連項目: このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限を直接付与する場合:
次のプロシージャを実行します。
BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee => 'strmadmin',
grant_privileges => TRUE);
END;
/
GRANT_ADMIN_PRIVILEGEプロシージャを使用してスクリプトを生成する場合:
手順は次のとおりです。
SQL文CREATE DIRECTORYを使用して、スクリプトの生成先のディレクトリにディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトは、ディレクトリの別名に類似しています。たとえば、コンピュータ・システムの/usr/adminディレクトリにディレクトリ・オブジェクトstrms_dirを作成するには、次のプロシージャを実行します。
CREATE DIRECTORY strms_dir AS '/usr/admin';
GRANT_ADMIN_PRIVILEGEプロシージャを実行して、スクリプトgrant_strms_privs.sqlを生成し、そのスクリプトをコンピュータ・システムの/usr/adminディレクトリに配置します。
BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee => 'strmadmin',
grant_privileges => FALSE,
file_name => 'grant_strms_privs.sql',
directory_name => 'strms_dir');
END;
/
プロシージャによって権限が直接付与されないようにgrant_privilegesパラメータがFALSEに設定されていることに注意してください。また、手順aで作成したディレクトリ・オブジェクトがdirectory_nameパラメータに指定されていることを確認してください。
生成されたスクリプトを必要に応じて編集し、変更を保存します。
SQL*Plusで次のスクリプトを実行します。
SET ECHO ON SPOOL grant_strms_privs.out @/usr/admin/grant_strms_privs.sql SPOOL OFF
スプール・ファイルをチェックして、すべての付与が正常に実行されていることを確認します。エラーが存在する場合は、スクリプトを編集してエラーを修正してから再実行します。
必要に応じて、次の追加の権限を付与します。
Oracle Enterprise Manager Cloud Controlを使用してOracle Streamsコンポーネント含むデータベースを管理する場合は、Oracle Streams管理者がOracle Enterprise Manager管理ユーザーとなるように構成します。これにより、Oracle Enterprise Manager Cloud Controlジョブの実行に必要な権限など、Oracle Enterprise Manager Cloud Controlで必要な追加の権限が付与されます。Oracle Enterprise Manager管理ユーザーの作成については、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。
ローカル・データベースでアクションを実行する権限をリモートのOracle Streams管理者に付与します。これらの権限を付与するには、DBMS_STREAMS_AUTHパッケージのGRANT_REMOTE_ADMIN_ACCESSプロシージャを使用します。この権限は、リモートのOracle Streams管理者が、ローカルのOracle Streams管理者に接続して管理アクションを実行するデータベース・リンクを使用する場合に付与します。具体的には、次のいずれかの条件に該当する場合にこれらの権限を付与します。
ローカル・ソース・データベースで発生した変更を取得するリモート・ダウンストリーム・データベースでダウンストリーム取得プロセスを構成し、そのダウンストリーム取得プロセスでデータベース・リンクを使用してソース・データベースで管理アクションを実行する。
ローカル・データベースで適用プロセスを構成し、リモートのOracle Streams管理者を使用してローカル・データベースのレプリケートされたデータベース・オブジェクトにインスタンス化SCN値を設定する。
適用プロセスに適用ユーザーが指定されていない場合は、他のユーザーが所有している適用オブジェクトに対してDML変更およびDDL変更を実行するために必要な権限をOracle Streams管理者に付与します。適用ユーザーが指定されている場合、適用ユーザーにはこれらの権限が必要です。これらの権限は、直接またはロールを介して付与できます。
適用プロセスに適用ユーザーが指定されていない場合は、Oracle Streams適用プロセスによって実行され、他のユーザーが所有しているPL/SQLサブプログラムに対するEXECUTE権限をOracle Streams管理者に付与します。これらのサブプログラムは、適用ハンドラまたはエラー・ハンドラで使用できます。適用ユーザーが指定されている場合、適用ユーザーにはこれらの権限が必要です。これらの権限は、直接付与する必要があります。ロールを介して付与することはできません。
Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントによって使用されるルールにカスタム・ルールベースの変換で指定され、他のユーザーが所有しているPL/SQLファンクションに対するEXECUTE権限をOracle Streams管理者に付与します。取得プロセスまたは同期取得で取得ユーザーが指定されている場合、その取得ユーザーにはこれらの権限が必要です。適用プロセスで適用ユーザーが指定されている場合、その適用ユーザーにはこれらの権限が必要です。これらの権限は、直接付与する必要があります。ロールを介して付与することはできません。
必要に応じて、データベース・オブジェクトを変更する権限をOracle Streams管理者に付与します。たとえば、Oracle Streams管理者が別のスキーマ内の表にサプリメンタル・ログ・グループを作成する必要がある場合、Oracle Streams管理者にはその表を変更する権限が必要です。これらの権限は、直接またはロールを介して付与できます。
Oracle Streams管理者がOracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントによって使用されるキューを所有しておらず、キューの作成時にそのキューのキュー・ユーザーとして指定されていない場合、Oracle Streams管理者がメッセージをキューにエンキューしたり、キューからデキューできるようにするには、Oracle Streams管理者をそのキューの保護キュー・ユーザーとして構成する必要があります。また、Oracle Streams管理者には、そのキューに対するENQUEUE権限またはDEQUEUE権限(あるいはその両方)が必要な場合があります。キューを管理する方法の詳細は、『Oracle Streams概要および管理』を参照してください。
Oracle Streams管理者がアクセスする必要がある場合がある任意のオブジェクト・タイプに対するEXECUTE権限をOracle Streams管理者に付与します。これらの権限は、直接またはロールを介して付与できます。
Oracle Streams管理者が、Oracle Streamsのインスタンス化中にデータ・ポンプを使用してデータベース・オブジェクトに対するエクスポート操作とインポート操作を実行する場合は、Oracle Streams管理者にEXP_FULL_DATABASEおよびIMP_FULL_DATABASEのロールを付与します。
Oracle Database Vaultがインストールされている場合は、次のアクションを実行するユーザーにBECOME USERシステム権限が付与されている必要があります。
取得プロセスの作成または変更
適用プロセスの作成または変更
Oracle Database Vaultがインストールされていない場合は、これらのアクションを実行するユーザーにBECOME USERシステム権限を付与する必要はありません。必要に応じて、これらのいずれかのアクションの完了後に、ユーザーのBECOME USERシステム権限を取り消すことができます。
Oracle Streamsを使用する環境の各データベースで前述のすべての手順を繰り返します。
Oracle Streamsを使用してデータベース間で情報を共有する場合は、これらのデータベース間にネットワーク接続とデータベース・リンクを構成します。
Oracle Databaseの場合、データベースで相互に通信できるようにネットワークとOracle Netを構成します。
Oracle以外のデータベースの場合、Oracle DatabaseとOracle以外のデータベースで通信できるようにOracle Database Gatewayを構成します。
あるデータベースのソース・キューから別のデータベースの宛先キューにメッセージを伝播する場合は、ソース・キューを含むデータベースと宛先キューを含むデータベースの間にプライベート・データベース・リンクを作成します。各データベース・リンクでは、データベース間でメッセージを伝播するユーザー用にCONNECT TO句を使用する必要があります。
ソース・データベースから宛先データベースへのデータベース・リンクは常に必要です。データベース・リンクの名前は、宛先データベースのグローバル名と一致している必要があります。
次のいずれかの場合、宛先データベースからソース・データベースへのデータベース・リンクが必要です。
Oracle Streamsレプリケーション環境を双方向にする場合。
インスタンス化中にデータ・ポンプでのネットワーク・インポートを実行する場合。
宛先データベースを、ソース・データベースに対する変更のダウンストリーム取得の取得データベースに使用する場合。
データベースのインスタンス化にRMANのDUPLICATEまたはCONVERT DATABASEコマンドを使用する場合。
instantiation_scnパラメータをNULL以外の値に設定してPOST_INSTANTIATION_SETUPプロシージャを実行すると、宛先データベースでDBMS_APPLY_ADMパッケージのSET_GLOBAL_INSTANTIATION_SCNプロシージャが実行されるため、このデータベース・リンクが必要になります。SET_GLOBAL_INSTANTIATION_SCNプロシージャにはこのデータベース・リンクが必要です。このデータベース・リンクは、RMANによるインスタンス化の実行後、POST_INSTANTIATION_SETUPプロシージャを実行する前に作成する必要があります。
いずれの場合においても、データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。
第3のデータベースをソース・データベースに対する変更のダウンストリーム取得の取得データベースに使用する場合は、次のデータベース・リンクも必要です。
第3のデータベースからソース・データベースへのデータベース・リンク。データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。
第3のデータベースから宛先データベースへのデータベース・リンク。データベース・リンクの名前は、宛先データベースのグローバル名と一致している必要があります。
各データベース・リンクは、Oracle Streams管理者のスキーマに作成する必要があります。たとえば、ソース・データベースのグローバル名がdbs1.example.com、宛先データベースのグローバル名がdbs2.example.com、各データベースのOracle Streams管理者がstrmadminの場合、次の文を実行すると、ソース・データベースから宛先データベースへのデータベース・リンクが作成されます。
CONNECT strmadmin@dbs1.example.com Enter password: password CREATE DATABASE LINK dbs2.example.com CONNECT TO strmadmin IDENTIFIED BY password USING 'dbs2.example.com';
宛先データベースからソース・データベースへのデータベース・リンクが必要な場合、次の文を実行すると、このデータベース・リンクが作成されます。
CONNECT strmadmin@dbs2.example.com Enter password: password CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin IDENTIFIED BY password USING 'dbs1.example.com';
第3のデータベースを取得データベースに使用する場合、第3のデータベースからソース・データベースおよび宛先データベースへのデータベース・リンクが必要です。たとえば、第3のデータベースがdbs3.example.comの場合、次の文を実行すると、第3のデータベースからソース・データベースと宛先データベースへのデータベース・リンクが作成されます。
CONNECT strmadmin@dbs3.example.com Enter password: password CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin IDENTIFIED BY password USING 'dbs1.example.com'; CREATE DATABASE LINK dbs2.example.com CONNECT TO strmadmin IDENTIFIED BY password USING 'dbs2.example.com';
RMANを使用してデータベースのインスタンス化を実行した場合、インスタンス化中にソース・データベースのデータベース・リンクが宛先データベースにコピーされます。このコピーされたデータベース・リンクは、宛先データベースで削除する必要があります。この場合、レプリケーションが双方向で、宛先データベースからソース・データベースへのデータベース・リンクが必要な場合、インスタンス化後にこのデータベース・リンクを作成する必要があります。
|
関連項目:
|
Oracle Streamsレプリケーション環境では、取得プロセスによって取得される変更を生成する各ソース・データベースはARCHIVELOGモードである必要があります。ダウンストリーム取得プロセスでは、リアルタイム・ダウンストリーム取得プロセスを構成する場合、ダウンストリーム・データベースもARCHIVELOGモードで実行する必要があります。ダウンストリーム・データベースでアーカイブ・ログ・ダウンストリーム取得プロセスのみを実行する場合は、ダウンストリーム・データベースをARCHIVELOGモードで実行する必要はありません。
Oracle Real Application Clusters(Oracle RAC)環境でOracle Streamsを構成している場合は、すべてのインスタンスからのすべてのスレッドのアーカイブ・ログ・ファイルが、取得プロセスを実行するインスタンスから使用できる必要があります。この要件は、ローカルおよびダウンストリーム取得プロセスの両方に関連します。
|
注意: 同期取得では、ARCHIVELOGモードは不要です。 |
|
関連項目:
|
Oracle Streams環境の構成、操作、信頼性およびパフォーマンスには、いくつかの初期化パラメータが重要となります。使用するOracle Streams環境に応じてこれらのパラメータを適切に設定します。
表1-2に、Oracle Streamsに関連する初期化パラメータを示します。この表には、各パラメータが変更可能かどうかが示されています。変更可能な初期化パラメータは、インスタンスの実行中にALTER SYSTEM文を使用して変更できます。変更可能なパラメータの中には、ALTER SESSION文を使用して単一のセッションに対して変更できるものもあります。
表1-2 Oracle Streamsに関連する初期化パラメータ
| パラメータ | 値 | 説明 |
|---|---|---|
|
デフォルト: 範囲: 変更の可否: 可 |
データベース・リンクの名前を接続先のデータベースと同じ名前にする必要があるかどうかを指定します。 Oracle Streamsを使用してデータベース間で情報を共有するには、Oracle Streams環境の各データベースで、このパラメータを |
|
|
デフォルト: 範囲: 次の値
変更の可否: 可 |
リモートの接続先へのREDOログの送信およびリモートのREDOログの受信を有効または無効にし、Data Guard構成の各データベースに一意のデータベース名( ダウンストリーム取得を使用し、REDO転送サービスによってREDOデータをダウンストリーム・データベースにコピーするには、 |
|
|
デフォルト: なし 範囲: なし 変更の可否: 可 |
ログ・アーカイブの宛先を31個まで定義します。ここで、 ダウンストリーム取得を使用し、REDO転送サービスによってREDOデータをダウンストリーム・データベースにコピーするには、ダウンストリーム取得プロセスを実行するサイトでログのアーカイブ先を1つ以上設定する必要があります。 |
|
|
デフォルト: 範囲: 次のいずれか
変更の可否: 可 |
対応するアーカイブ先の可用性の状態を指定します。パラメータの接尾辞( ダウンストリーム取得を使用し、REDO転送サービスによってREDOデータをダウンストリーム・データベースにコピーするには、ダウンストリーム・データベースの |
|
|
デフォルト: 構成に応じて 範囲: オペレーティング・システム依存の値 変更の可否: 不可 |
REDOエントリをREDOログ・ファイルにバッファするときに使用されるメモリー量(バイト単位)を指定します。REDOログ・エントリには、データベース・ブロック・バッファに加えられた変更のレコードが含まれます。 データベースでOracle Streams取得プロセスが実行されている場合は、このパラメータを適切に設定して、取得プロセスがハード・ディスクではなくREDOログ・バッファからREDOログ・レコードを読み取るようにしてください。 |
|
|
デフォルト: 範囲: 変更の可否: 不可 |
システム全体でOracle Database用に使用可能な最大メモリーを指定します。
関連項目: 「Oracle Streamsプールの構成」 |
|
|
デフォルト: 範囲: 変更の可否: 可 |
システム全体でOracle Database用に使用可能なメモリーを指定します。
関連項目: 「Oracle Streamsプールの構成」 |
|
|
デフォルト: 範囲: 変更の可否: 不可 |
1つのセッションでリモート・データベースに対して同時にオープンできる接続の最大数を指定します。これらの接続には、データベース・リンクに加え、外部プロシージャやカートリッジが含まれ、それぞれ別々のプロセスが使用されます。 Oracle Streams環境では、このパラメータをデフォルト値の |
|
|
デフォルト: 範囲: 変更の可否: 不可 |
Oracleに同時に接続できるオペレーティング・システム・ユーザー・プロセスの最大数を指定します。 このパラメータの値で、ロックやスレーブ・プロセスなどのすべてのバックグラウンド・プロセスを使用できるようにしてください。Oracle Streamsでは、取得プロセス、適用プロセス、XStreamインバウンド・サーバーおよびXStreamアウトバウンド・サーバーでバックグラウンド・プロセスが使用されます。伝播では、取得と適用の複合構成でバックグラウンド・プロセスが使用されます。取得と適用の複合を使用しない構成の伝播では、Oracle Schedulerスレーブ・プロセスが使用されます。 |
|
|
デフォルト: 次の式から導出された値
範囲: 変更の可否: 不可 |
システムで作成できるセッションの最大数を指定します。 データベースで1つ以上の取得プロセス、適用プロセスを、XStreamアウトバウンド・サーバーまたはXStreamインバウンド・サーバーを実行するには、このパラメータのサイズを大きくする必要がある場合があります。データベースのバックグラウンド・プロセスごとにセッションが必要になります。 |
|
|
デフォルト: 起動時のSGAの初期サイズ 範囲: 変更の可否: 不可 |
データベース・インスタンスの存続期間に対するシステム・グローバル領域(SGA)の最大サイズを指定します。
関連項目: 「Oracle Streamsプールの構成」 |
|
|
デフォルト: 範囲: 変更の可否: 可 |
すべてのシステム・グローバル領域(SGA)コンポーネントの合計サイズを指定します。
このパラメータを0(ゼロ)以外の値に設定すると、Oracle Streamsプールのサイズは自動共有メモリー管理で管理されます。 関連項目: 「Oracle Streamsプールの構成」 |
|
|
デフォルト:
32ビット・プラットフォームで 範囲: グラニュル・サイズからオペレーティング・システム依存の値の間 変更の可否: 可 |
共有プールのサイズ(バイト単位)を指定します。共有プールには、共有カーソル、ストアド・プロシージャおよび制御構造などの構造が含まれます。
関連項目: 「Oracle Streamsプールの構成」 |
|
|
デフォルト: 範囲: 変更の可否: 可 |
Oracle Streamsプールのサイズ(バイト単位)を指定します。Oracle Streamsプールには、バッファ・キュー・メッセージが含まれています。また、Oracle Streamsプールは、パラレル取得時およびパラレル適用時の内部通信にも使用されます。
このパラメータは変更可能です。インスタンスの実行中にこのパラメータを0(ゼロ)まで小さくすると、Oracle Streamsのプロセスとジョブが実行されない場合があります。 Oracle Streamsコンポーネントに対応するための十分なメモリーがあることを確認してください。最低要件は次のとおりです。
たとえば、取得プロセスの並列性を3に設定する場合、その取得プロセスには少なくとも45MB必要です。データベースに2つのバッファ・キューが存在する場合、それらのバッファ・キューには20MB以上が必要です。適用プロセスの並列性を4に設定する場合、その適用プロセスには少なくとも4MB必要です。
関連項目: 「Oracle Streamsプールの構成」 |
|
|
デフォルト:
範囲: 変更の可否: 可 |
時間に関連する統計を収集するかどうかを指定します。 Oracle Streamsに関連する動的パフォーマンス・ビューで経過時間の統計を収集するには、このパラメータを |
|
|
デフォルト: 範囲: 変更の可否: 可 |
コミットされたUNDO情報をデータベース内に保存する期間(秒単位)を指定します。 1つ以上の取得プロセスを実行しているデータベースでは、このパラメータを設定して適切なUNDO保存期間を指定してください。 1つ以上の取得プロセスを実行していて、適切な設定がわからない場合は、このパラメータを |
|
関連項目:
|
Oracle Streamsプールは、Oracle Streamsで使用されるシステム・グローバル領域(SGA)のメモリーの一部です。Oracle Streamsプールではメモリーにバッファ・キュー・メッセージが格納され、取得プロセス、適用プロセス、XStreamアウトバウンド・サーバーおよびXStreamインバウンド・サーバー用のメモリーが用意されています。Oracle Streamsプールは、取得プロセスで取得されたLCRを常に格納し、アプリケーションによってバッファ・キューにエンキューされたLCRとメッセージを格納します。
Oracle Streamsプールは、データベースで次のいずれかのアクションが初めて発生した場合に初期化されます。
メッセージがバッファ・キューにエンキューされた場合。
Oracle Streamsコンポーネントによって、バッファ・キュー内のメッセージが操作されます。これらのコンポーネントには、取得プロセス、伝播、適用プロセス、XStreamアウトバウンド・サーバーおよびXStreamインバウンド・サーバーが含まれます。また、データ・ポンプ・エクスポート/インポート操作ではバッファ・キューが使用されるため、これらの操作が行われるとOracle Streamsプールが初期化されます。
Oracle Real Application Clusters(Oracle RAC)を使用していない構成で、永続キューからメッセージがデキューされた場合。
永続キューからのデキュー操作を最適化するために、Oracle Streamsプールが使用されます。Oracle RAC構成では、永続キューからのデキュー操作の最適化にOracle Streamsプールは使用されません。
取得プロセスが起動された場合。
伝播が作成された場合。
適用プロセスが起動された場合。
XStreamアウトバウンド・サーバーが起動された場合。
XStreamインバウンド・サーバーが起動された場合。
Oracle Streamsプールのサイズは、次のいずれかの方法で決定されます。
|
注意: Oracle Streamsプールを初期化できない場合、ORA-00832エラーが戻されます。この場合は、まず、SGAにOracle Streamsプール用の十分な領域があることを確認してください。必要に応じて、SGA_MAX_SIZE初期化パラメータをリセットしてSGAサイズを増やしてください。次に、MEMORY_TARGET、MEMORY_MAX_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZE初期化パラメータの1つ以上を設定してください。 |
MEMORY_TARGETまたはMEMORY_MAX_TARGET初期化パラメータを0(ゼロ)以外の値に設定した場合、Oracle Streamsプールのサイズは自動メモリー管理機能によって自動的に管理されます。自動メモリー管理を使用する場合でも、次の初期化パラメータは引き続き設定できます。
SGA_TARGET初期化パラメータも0(ゼロ)以外の値に設定すると、自動メモリー管理でその値がシステム・グローバル領域(SGA)の最小値として使用されます。
STREAMS_POOL_SIZE初期化パラメータも0(ゼロ)以外の値に設定すると、自動メモリー管理でその値がOracle Streamsプールの最小値として使用されます。
自動メモリー管理によってOracle Streamsプールに割り当てられている現行のメモリーは、V$MEMORY_DYNAMIC_COMPONENTSビューを問い合せることによって表示できます。
|
注意: 現在、MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータは一部のプラットフォームではサポートされていません。 |
|
関連項目:
|
次の条件に該当する場合、Oracle Streamsプールのサイズは自動共有メモリー管理機能によって自動的に管理されます。
MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータの両方が0(ゼロ)に設定されている。
SGA_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている。
自動共有メモリー管理を使用している場合に、STREAMS_POOL_SIZE初期化パラメータも0(ゼロ)以外の値に設定すると、自動共有メモリー管理でその値がOracle Streamsプールの最小値として使用されます。環境が適切に動作するためにOracle Streamsプールに最小メモリー量が必要な場合は、最小サイズを設定できます。自動共有メモリー管理によってOracle Streamsプールに割り当てられている現行のメモリーは、V$SGA_DYNAMIC_COMPONENTSビューを問い合せることによって表示できます。
|
関連項目:
|
Oracle Streamsプールのサイズは、次の条件に該当する場合にSTREAMS_POOL_SIZEパラメータで指定する値(バイト単位)です。
MEMORY_TARGET、MEMORY_MAX_TARGETおよびSGA_TARGET初期化パラメータがすべて0(ゼロ)に設定されている。
STREAMS_POOL_SIZE初期化パラメータが0(ゼロ)以外の値に設定されている。
Oracle Streamsプールのサイズを手動で設定する場合は、V$STREAMS_POOL_ADVICE動的パフォーマンス・ビューを使用して、STREAMS_POOL_SIZE初期化パラメータの適切な設定を確認できます。
|
関連項目: 『Oracle Streams概要および管理』 |
MEMORY_TARGET、MEMORY_MAX_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZEパラメータがすべて0(ゼロ)に設定されている場合、Oracle Streamsプールのサイズはデフォルトで設定されます。Oracle Streamsプールのサイズがデフォルトで設定されている場合、データベースでのOracle Streamsの初回使用時に、共有プールの10%と同等のメモリー量がバッファ・キャッシュからOracle Streamsプールに転送されます。バッファ・キャッシュはDB_CACHE_SIZE初期化パラメータによって設定され、共有プール・サイズはSHARED_POOL_SIZE初期化パラメータによって設定されます。
たとえば、Oracle Streamsを初めて使用する前に、データベースの次の構成について検討します。
DB_CACHE_SIZEが100MBに設定されている。
SHARED_POOL_SIZEが80MBに設定されている。
MEMORY_TARGET、MEMORY_MAX_TARGET、SGA_TARGETおよびSTREAMS_POOL_SIZEがすべて0(ゼロ)に設定されている。
この構成を前提とした場合、Oracle Streamsの初回使用後に割り当てられるメモリー量は次のようになります。
バッファ・キャッシュには92MBが割り当てられます。
共有プールには80MBが割り当てられます。
Oracle Streamsプールには8MBが割り当てられます。
取得プロセスを使用して変更を取得する場合は、列に対する変更が宛先データベースで正常に適用されるように、ソース・データベースで特定の列にサプリメンタル・ロギングを指定する必要があります。サプリメンタル・ロギングによって、これらの列に関する追加の情報がREDOログに記録されます。この追加の情報は、取得プロセスによって取得されて論理変更レコード(LCR)に含められ、適用プロセスによって変更を適切に適用するために必要とされる場合があります。
この項の内容は次のとおりです。
|
注意: サプリメンタル・ロギングは、同期取得を使用してデータベース・オブジェクトに対する変更を取得する場合は必要ありません。 |
|
関連項目: サプリメンタル・ロギング指定を示す問合せについては、『Oracle Streams概要および管理』を参照してください。 |
サプリメンタル・ロギングには、データベース・サプリメンタル・ロギングと表サプリメンタル・ロギングの2種類があります。データベース・サプリメンタル・ロギングではデータベース全体のサプリメンタル・ロギングが指定されますが、表サプリメンタル・ロギングでは、特定の表のサプリメンタル・ロギングに使用するログ・グループを指定できます。表サプリメンタル・ロギングを使用する場合は、無条件ログ・グループと条件付きログ・グループのどちらかを選択できます。
無条件ログ・グループでは、表が変更されると、指定した列が変更の影響を受けるかどうかに関係なく、その列のビフォア・イメージがログに記録されます。無条件ログ・グループは、「常時ログ・グループ」と呼ばれることがあります。条件付きログ・グループでは、ログ・グループ内の少なくとも1列が変更される場合にのみ、指定したすべての列のビフォア・イメージがログに記録されます。
データベース・レベルのサプリメンタル・ロギング、表レベルの無条件ログ・グループおよび表レベルの条件付きログ・グループによって、変更ログに記録する古い値が決定されます。
取得プロセスによって取得されたLCRを、1つ以上の適用プロセスを使用して適用する予定の場合は、宛先データベースの表内にある次のタイプの列について、ソース・データベースでサプリメンタル・ロギングを使用可能にする必要があります。
宛先データベースで変更が適用される表の主キーに使用されるソース・データベースの列はすべて、ログ・グループに無条件でログを記録するか、主キー列のデータベース・サプリメンタル・ロギングによってログを記録する必要があります。
変更を適用する適用プロセスの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースの一意制約列は、条件付きでログに記録する必要があります。一意制約列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。
変更を適用する適用プロセスの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースの外部キー列は、条件付きでログに記録する必要があります。外部キー列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。
変更を適用する適用プロセスの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースのビットマップ索引列は、条件付きでログに記録する必要があります。ビットマップ索引列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。
宛先データベースで適用プロセスの代替キー列として使用されるソース・データベースの列は、無条件でログに記録する必要があります。表の代替キー列を指定するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用します。
ソース・データベースの複数の列が宛先データベースの列リストに使用されている場合、適用時に競合解消用の列リストで指定された列は、条件付きでログに記録する必要があります。
宛先データベースの文DMLハンドラ、変更ハンドラ、プロシージャDMLハンドラまたはエラー・ハンドラで使用されるソース・データベースの列は、無条件でログに記録する必要があります。
ルールまたはルールベースの変換で使用されるソース・データベースの列は、無条件でログに記録する必要があります。
宛先データベースで値の仮想依存性定義に指定されているソース・データベースの列は、無条件でログに記録する必要があります。
宛先データベースで表の行のサブセット化を指定する場合は、宛先表に含まれるソース・データベースの列またはサブセット条件に含まれるソース・データベースの列を、無条件でログに記録する必要があります。適用プロセスの行のサブセット化条件を指定するには、DBMS_STREAMS_ADMパッケージのADD_SUBSET_RULESプロシージャでdml_conditionパラメータを使用します。
ソース・データベースでこれらのタイプの列にサプリメンタル・ロギングを使用しないと、これらの列が関係する変更は宛先データベースで正しく適用されない可能性があります。
|
注意: LOB、LONG、LONG RAW、ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)およびOracle提供の型(Any型、XML型、空間型、メディア型など)のデータ型の列は、サプリメンタル・ログ・グループに含めることはできません。 |
|
関連項目:
|
ここでは、無条件サプリメンタル・ログ・グループの作成について説明します。
表の主キー列のみを含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にPRIMARY KEYオプションを指定してALTER TABLE文を実行します。
たとえば、次の文では、無条件のログ・グループにhr.regions表の主キー列が追加されます。
ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ログ・グループはシステム生成名を持ちます。
表のすべての列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にALLオプションを指定して、ALTER TABLE文を実行します。
たとえば、次の文では、無条件のログ・グループにhr.regions表のすべての列が追加されます。
ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
ログ・グループはシステム生成名を持ちます。
選択した列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句にALWAYSを指定して、ALTER TABLE文を実行します。必要に応じて、これらのログ・グループにキー列を含めることができます。
たとえば、次の文では、無条件のログ・グループlog_group_dep_pkにhr.departments表のdepartment_id列およびmanager_id列が追加されます。
ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG GROUP log_group_dep_pk (department_id, manager_id) ALWAYS;
ALWAYS指定があるため、このログ・グループは無条件のログ・グループになります。
ここでは、条件付きログ・グループの作成について説明します。
ALTER TABLE文のADD SUPPLEMENTAL LOG DATA句で、次のオプションを使用できます。
FOREIGN KEYオプション: 表の外部キー列を含む条件付きログ・グループが作成されます。
UNIQUEオプション: 表の一意キー列およびビットマップ索引列を含む条件付きログ・グループが作成されます。
1つのALTER TABLE文に複数のオプションを指定する場合、各オプションに対して個別の条件付きログ・グループが作成されます。
たとえば、次の文では、2つの条件付きログ・グループが作成されます。
ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA (UNIQUE, FOREIGN KEY) COLUMNS;
一方の条件付きログ・グループには表の一意キー列およびビットマップ索引列が含まれ、他方には表の外部キー列が含まれます。どちらのログ・グループもシステム生成名を持ちます。
|
注意: UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。 |
追加するように選択したすべての列を含む条件付きのサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句を指定して、ALTER TABLE文を実行します。ログ・グループを条件付きにするには、ALWAYS指定を含めないでください。
たとえば、hr.jobs表のmin_salaryおよびmax_salary列が、宛先データベースで競合解消用の列リストに含まれているとします。次の文では、min_salaryおよびmax_salary列が条件付きのログ・グループlog_group_jobs_crに追加されます。
ALTER TABLE hr.jobs ADD SUPPLEMENTAL LOG GROUP log_group_jobs_cr (min_salary, max_salary);
条件付きまたは無条件のサプリメンタル・ログ・グループを削除するには、ALTER TABLE文にDROP SUPPLEMENTAL LOG GROUP句を使用します。たとえば、サプリメンタル・ログ・グループlog_group_jobs_crを削除するには、次の文を実行します。
ALTER TABLE hr.jobs DROP SUPPLEMENTAL LOG GROUP log_group_jobs_cr;
ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列について、サプリメンタル・ロギングを指定するオプションがあります。データベース全体に対する変更を取得するように取得プロセスを構成する場合は、このオプションを選択できます。ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを指定するには、次のSQL文を発行します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
主キー列、一意キー列、ビットマップ索引列および外部キー列がすべてのソース・データベースと宛先データベースで同一の場合に、このコマンドをソース・データベースで実行すると、すべての宛先データベースで主キー列、一意キー列、ビットマップ索引列および外部キー列に必要なサプリメンタル・ロギングが提供されます。PRIMARY KEYオプションを指定した場合に、表が変更されると、行の主キーのすべての列がREDOログ・ファイルに記録されます(無条件ロギング)。UNIQUEオプションを指定した場合に、一意キーまたはビットマップ索引に属するいずれかの列が変更されると、行の一意キーおよびビットマップ索引のすべての列がREDOログ・ファイルに記録されます(条件付きロギング)。FOREIGN KEYオプションを指定した場合に、外部キーに属するいずれかの列が変更されると、行の外部キーのすべての列がREDOログ・ファイルに記録されます(条件付きロギング)。
これらのオプションの1つ以上を省略できます。たとえば、データベースのすべての外部キー列に対してサプリメンタル・ロギングが必要でない場合、次の例に示すとおり、FOREIGN KEYオプションを省略できます。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE) COLUMNS;
PRIMARY KEY、UNIQUEおよびFOREIGN KEYのみでなく、ALLオプションを使用することもできます。ALLオプションを指定すると、行が変更された場合に、その行のすべての列(LOB、LONG、LONG RAW、ユーザー定義型およびOracleが提供する型の列を除く)がREDOログ・ファイルに記録されます(無条件ロギング)。
サプリメンタル・ロギングの文は実行ごとに結果を記録します。異なる識別キーを指定して2つのALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を連続して発行すると、どちらのキーに対してもサプリメンタル・ロギングが行われます。
|
注意: UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。 |
|
関連項目: データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを削除するには、ALTER DATABASE DROP SUPPLEMENTAL LOG DATA文を発行します。すべての主キー列、一意キー列、ビットマップ索引列および外部キー列のデータベース・サプリメンタル・ロギングを削除するには、次のSQL文を発行します。
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;
|
注意: キー列のデータベース・サプリメンタル・ロギングを削除しても、既存の表レベルのサプリメンタル・ログ・グループには影響しません。 |
DBMS_CAPTURE_ADMパッケージの次のプロシージャでは、サプリメンタル・ロギングが自動的に指定されます。
BUILD
PREPARE_GLOBAL_INSTANTIATION
PREPARE_SCHEMA_INSTANTIATION
PREPARE_TABLE_INSTANTIATION
BUILDプロシージャでは、ALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を実行することで、データベース・サプリメンタル・ロギングが自動的に指定されます。ほとんどの場合、BUILDプロシージャは取得プロセスの作成時に自動的に実行されます。
PREPARE_GLOBAL_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_TABLE_INSTANTIATIONプロシージャでは、インストール用に準備された表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが自動的に指定されます。
DBMS_STREAMS_ADMパッケージの特定のプロシージャでは、前述のプロシージャが自動的に実行されます。詳細は、「自動的にオブジェクトを準備するDBMS_STREAMS_ADMパッケージのプロシージャ」を参照してください。
|
関連項目: これらのプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
ソース・データベースでのローカル取得プロセスを使用するように決定した場合、ログ・ファイルを転送する必要はありません。ただし、REDO転送サービスを使用してアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、レプリケーション環境を構成する前に、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。この決定の詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。
次のいずれかの方法を使用してダウンストリーム取得を構成する場合は、この項の手順を完了する必要があります。
DBMS_STREAMS_ADMが提供されているPL/SQLパッケージの構成プロシージャを実行して、2つのデータベース間のレプリケーションを構成する方法
各Oracle Streamsコンポーネントを個別に構成する方法
これらの方法の詳細は、「レプリケーション環境の構成方法の決定」を参照してください。
|
ヒント: Oracle Enterprise Manager Cloud Controlを使用して、ログ・ファイルの転送およびダウンストリーム取得プロセスを構成できます。手順については、Oracle Enterprise Manager Cloud Controlのオンライン･ヘルプを参照してください。 |
次の手順を実行して、ソース・データベースのREDOログ・ファイルを取得データベースに転送するための準備、および取得データベースでそれらのREDOログ・ファイルを受け入れるための準備を行います。
ソース・データベースでダウンストリーム・データベースと通信できるように、Oracle Netを構成します。
|
関連項目: 『Oracle Database Net Services管理者ガイド』 |
両方のデータベースで、REDOデータの転送がサポートされるように認証を構成します。
REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合は、そのファイルをダウンストリーム取得データベース・システムの適切なディレクトリにコピーします。ソース・データベースとダウンストリーム取得データベースで、同じパスワード・ファイルを使用する必要があります。
|
関連項目: REDO転送の認証要件の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
ソース・データベースからダウンストリーム・データベースにREDOデータを転送するREDO転送サービスを構成するために、ソース・データベースで次の初期化パラメータを設定します。
LOG_ARCHIVE_DEST_n: ダウンストリーム・データベースにREDOデータが転送されるように、1つ以上のLOG_ARCHIVE_DEST_n初期化パラメータを構成します。このパラメータの次の属性を次の方法で設定します。
SERVICE: ダウンストリーム・データベースのネットワーク・サービス名を指定します。
ASYNCまたはSYNC: REDO転送モードを指定します。
ASYNCを指定するメリットは、ソース・データベースのパフォーマンスにほとんど影響を与えないことです。ダウンストリーム・データベースまたはネットワークのパフォーマンスが低い場合は、ASYNCを使用してソース・データベースのパフォーマンスへの影響を回避することをお薦めします。
SYNCを指定するメリットは、ASYNCを指定した場合より高速にダウンストリーム・データベースにREDOデータが送信されることです。また、SYNC AFFIRMを指定すると、MAXIMUM AVAILABILITYスタンバイ保護モードと同様に動作します。SQL文ALTER DATABASE STANDBY DATABASE TO MAXIMIZE AVAILABILITYを指定しても、Oracle Streamsの取得プロセスに影響しないことに注意してください。
NOREGISTER: この属性を指定すると、アーカイブREDOログ・ファイルの位置が、ダウンストリーム・データベースの制御ファイルに記録されません。
VALID_FOR: (ONLINE_LOGFILE,PRIMARY_ROLE)または(ONLINE_LOGFILE,ALL_ROLES)のいずれかを指定します。
TEMPLATE: アーカイブ・ログ・ダウンストリームの取得プロセスを構成するときには、ダウンストリーム・データベースでアーカイブREDOログ用のディレクトリおよびフォーマット・テンプレートを指定します。TEMPLATE属性は、ダウンストリーム・データベースのLOG_ARCHIVE_FORMAT初期化パラメータ設定を上書きします。TEMPLATE属性は、リモートの接続先でのみ有効です。各ソース・データベースで、フォーマットに%t、%sおよび%rのすべての変数を使用していることを確認します。
リアルタイム・ダウンストリームの取得プロセスを構成するときには、TEMPLATE属性を指定しないでください。
DB_UNIQUE_NAME: ダウンストリーム・データベースの一意の名前。ダウンストリーム・データベースでDB_UNIQUE_NAME初期化パラメータに指定した名前を使用します。
次に、リアルタイム・ダウンストリーム取得プロセスにダウンストリーム・データベースdbs2を指定するLOG_ARCHIVE_DEST_n設定の例を示します。
LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbs2'
次に、アーカイブ・ログ・ダウンストリーム取得プロセスにダウンストリーム・データベースdbs2を指定するLOG_ARCHIVE_DEST_n設定の例を示します。
LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) TEMPLATE=/usr/oracle/log_for_dbs1/dbs1_arch_%t_%s_%r.log DB_UNIQUE_NAME=dbs2'
リアルタイム・ダウンストリーム取得とアーカイブ・ログ・ダウンストリーム取得の違いの詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。
|
ヒント: アーカイブ・ログ・ダウンストリーム取得プロセスを構成している場合は、リモート・ソース・データベースからのログ・ファイルとローカル・データベースのログ・ファイルを別々に保持するTEMPLATE属性の値を指定してください。また、ダウンストリーム・データベースに複数のソース・データベースからのログ・ファイルが含まれている場合、各ソース・データベースからのログ・ファイルを個別に格納する必要があります。 |
LOG_ARCHIVE_DEST_STATE_n: ダウンストリーム・データベースのLOG_ARCHIVE_DEST_nパラメータに対応するこの初期化パラメータをENABLEに設定します。
たとえば、ダウンストリーム・データベースにLOG_ARCHIVE_DEST_2初期化パラメータが設定されている場合、LOG_ARCHIVE_DEST_STATE_2パラメータを次のように設定します。
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_CONFIG: ソース・データベースとダウンストリーム・データベースのDB_UNIQUE_NAMEを含めるように、この初期化パラメータのDG_CONFIG属性を設定します。
たとえば、ソース・データベースのDB_UNIQUE_NAMEがdbs1で、ダウンストリーム・データベースのDB_UNIQUE_NAMEがdbs2の場合は、次のパラメータを指定します。
LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'
デフォルトで、LOG_ARCHIVE_CONFIGパラメータによって、データベースによるREDOの送受信が可能になります。
|
関連項目: これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』および『Oracle Data Guard概要および管理』を参照してください。 |
ダウンストリーム・データベースで、ソース・データベースとダウンストリーム・データベースのDB_UNIQUE_NAMEを含めるように、LOG_ARCHIVE_CONFIG初期化パラメータのDG_CONFIG属性を設定します。
たとえば、ソース・データベースのDB_UNIQUE_NAMEがdbs1で、ダウンストリーム・データベースのDB_UNIQUE_NAMEがdbs2の場合は、次のパラメータを指定します。
LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'
デフォルトで、LOG_ARCHIVE_CONFIGパラメータによって、データベースによるREDOの送受信が可能になります。
手順3または手順4で、データベース上でインスタンスを実行中に初期化パラメータをリセットした場合、データベースが再起動されたときに新しい値が保持されるように、それらのパラメータを初期化パラメータ・ファイルでもリセットする必要があります。
手順3または4で、インスタンスの実行中に初期化パラメータをリセットせず、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOログ・ファイルを送信するときには、ソース・データベースがオープンである必要があります。
これらの手順が完了したら、次のいずれかのタスクを実行できます。
アーカイブ・ログ・ダウンストリーム取得プロセスを構成します。この場合、次の項の手順を参照してください。
ダウンストリーム・データベースでリアルタイム・ダウンストリーム取得プロセス用のスタンバイREDOログ・ファイルを追加します。この場合、「リアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加」の手順を参照してください。
この項の例では、ダウンストリーム・データベースでスタンバイREDOログを追加します。スタンバイREDOログは、リアルタイム・ダウンストリーム取得プロセスを構成するために必要です。この例では、ソース・データベースはdbs1.example.com、ダウンストリーム・データベースはdbs2.example.comです。
リアルタイム・ダウンストリーム取得とアーカイブ・ログ・ダウンストリーム取得の違いの詳細は、「ソース・データベースに対してローカル取得またはダウンストリーム取得を構成するかどうかの決定」を参照してください。この項の手順は、リアルタイム・ダウンストリーム取得を構成している場合にのみ実行する必要があります。アーカイブ・ログ・ダウンストリーム取得を構成している場合、この項の手順は実行しないでください。
|
ヒント: Oracle Enterprise Manager Cloud Controlを使用して、リアルタイム・ダウンストリーム取得を構成できます。手順については、Oracle Enterprise Manager Cloud Controlのオンライン･ヘルプを参照してください。 |
ダウンストリーム・データベースでスタンバイREDOログを追加するには、次の手順を実行します。
「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」の手順を実行します。
ダウンストリーム・データベースで、次の初期化パラメータを設定して、ローカルに生成されるREDOデータのアーカイブを構成します。
LOG_ARCHIVE_DEST_n初期化パラメータで、ダウンストリーム・データベースを実行中のコンピュータ・システム上のディレクトリまたは高速リカバリ領域のいずれかになるよう、アーカイブ・ログの宛先を少なくとも1つ設定します。このパラメータの次の属性を次の方法で設定します。
LOCATION: ディスク・ディレクトリの有効なパス名を指定するか、または高速リカバリ領域を使用するためにUSE_DB_RECOVERY_FILE_DESTを指定します。この場所は、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別々に保持する必要があります。高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
VALID_FOR: (ONLINE_LOGFILE,PRIMARY_ROLE)または(ONLINE_LOGFILE,ALL_ROLES)のいずれかを指定します。
次に、リアルタイム・ダウンストリーム取得データベースでローカルに生成されるREDOデータのためのLOG_ARCHIVE_DEST_n設定の例を示します。
LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local_rl_dbs2 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'
リアルタイム・ダウンストリーム取得の構成では、アーカイブ・スタンバイREDOログ・ファイルとダウンストリーム・データベースで生成されるアーカイブ・オンラインREDOログ・ファイルは別々に保持する必要があります。これを行うには、VALID_FOR属性のREDOログ・タイプに、ALL_LOGFILESのかわりにONLINE_LOGFILEを指定します。
必要に応じて、LOG_ARCHIVE_DEST_n初期化パラメータの他の属性を指定できます。
この手順で以前に設定したLOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_n初期化パラメータを、ENABLEに設定します。
たとえば、LOG_ARCHIVE_DEST_1初期化パラメータが設定されている場合は、LOG_ARCHIVE_DEST_STATE_1パラメータを次のとおり設定します。
LOG_ARCHIVE_DEST_STATE_1=ENABLE
ダウンストリーム・データベースで、次の初期化パラメータを設定して、ソース・データベースからREDOデータを受信し、そのREDOデータをダウンストリーム・データベースのスタンバイREDOログに書き込むようにダウンストリーム・データベースを構成します。
LOG_ARCHIVE_DEST_n初期化パラメータで、ダウンストリーム・データベースを実行中のコンピュータ・システム上のディレクトリまたは高速リカバリ領域のいずれかになるよう、アーカイブ・ログの宛先を少なくとも1つ設定します。このパラメータの次の属性を次の方法で設定します。
LOCATION: ディスク・ディレクトリの有効なパス名を指定するか、または高速リカバリ領域を使用するためにUSE_DB_RECOVERY_FILE_DESTを指定します。この場所は、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別々に保持する必要があります。高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
VALID_FOR: (STANDBY_LOGFILE,PRIMARY_ROLE)または(STANDBY_LOGFILE,ALL_ROLES)を指定します。
次に、リアルタイム・ダウンストリーム取得データベースでソース・データベースから受信するREDOデータのためのLOG_ARCHIVE_DEST_n設定の例を示します。
LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbs1 VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'
必要に応じて、LOG_ARCHIVE_DEST_n初期化パラメータの他の属性を指定できます。
この手順で以前に設定したLOG_ARCHIVE_DEST_nパラメータに対応するLOG_ARCHIVE_DEST_STATE_n初期化パラメータを、ENABLEに設定します。
たとえば、ダウンストリーム・データベースにLOG_ARCHIVE_DEST_2初期化パラメータが設定されている場合、LOG_ARCHIVE_DEST_STATE_2パラメータを次のように設定します。
LOG_ARCHIVE_DEST_STATE_2=ENABLE
|
関連項目: これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』および『Oracle Data Guard概要および管理』を参照してください。 |
手順2または手順3で、データベース上でインスタンスを実行中に初期化パラメータをリセットした場合、データベースが再起動されたときに新しい値が保持されるように、それらのパラメータを関連する初期化パラメータ・ファイルでもリセットする必要があります。
Step ステップ2または3で、インスタンスの実行中には初期化パラメータをリセットしなかったが、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOデータを送信するときには、ソース・データベースがオープンである必要があります。
スタンバイREDOログ・ファイルを作成します。
|
注意: 次の手順では、スタンバイREDOログ・ファイルをダウンストリーム・データベースに追加する一般的な方法の概要を示します。スタンバイREDOログ・ファイルを追加するための特定の手順とSQL文は、環境によって異なります。たとえば、Oracle Real Application Clusters(Oracle RAC)環境では、異なる手順を使用します。スタンバイREDOログ・ファイルをデータベースに追加する手順の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
SQL*Plusで、管理ユーザーとしてソース・データベースdbs1.example.comに接続します。
SQL*Plusでのデータベースへの接続の詳細は、『Oracle Database管理者ガイド』を参照してください。
ソース・データベースで使用されるログ・ファイルのサイズを決定します。スタンバイ・ログ・ファイルのサイズは、ソース・データベースのログ・ファイルのサイズと同じ(またはそれ以上)にする必要があります。たとえば、ソース・データベースのログ・ファイルのサイズが500MBの場合、スタンバイ・ログ・ファイルのサイズは500MB以上にする必要があります。ソース・データベースでV$LOGビューを問い合せて、ソース・データベースのREDOログ・ファイルのサイズ(バイト単位)を確認できます。
たとえば、V$LOGビューを問い合せます。
SELECT BYTES FROM V$LOG;
ダウンストリーム・データベースで必要なスタンバイ・ログ・ファイル・グループの数を決定します。スタンバイ・ログ・ファイル・グループの数は、ソース・データベースのオンライン・ログ・ファイル・グループの数より1つ以上多くする必要があります。たとえば、ソース・データベースに2つのオンライン・ログ・ファイル・グループが存在する場合、ダウンストリーム・データベースには3つ以上のスタンバイ・ログ・ファイル・グループが必要です。ソース・データベースでV$LOGビューを問い合せて、ソース・データベースのオンライン・ログ・ファイル・グループの数を確認できます。
たとえば、V$LOGビューを問い合せます。
SELECT COUNT(GROUP#) FROM V$LOG;
SQL*Plusで、管理ユーザーとしてダウンストリーム・データベースdbs2.example.comに接続します。
SQL文ALTER DATABASE ADD STANDBY LOGFILEを使用して、スタンバイ・ログ・ファイル・グループをダウンストリーム・データベースに追加します。
たとえば、ソース・データベースに2つのオンラインREDOログ・ファイル・グループが存在し、そのソース・データベースで500MBのログ・ファイル・サイズが使用されていると想定します。この場合は、次の文を使用して、適切なスタンバイ・ログ・ファイル・グループを作成します。
ALTER DATABASE ADD STANDBY LOGFILE GROUP 3
('/oracle/dbs/slog3a.rdo', '/oracle/dbs/slog3b.rdo') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
('/oracle/dbs/slog4.rdo', '/oracle/dbs/slog4b.rdo') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
('/oracle/dbs/slog5.rdo', '/oracle/dbs/slog5b.rdo') SIZE 500M;
次の問合せを実行して、スタンバイ・ログ・ファイル・グループが正常に追加されたことを確認します。
SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;
出力は次のようになります。
GROUP# THREAD# SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
3 0 0 YES UNASSIGNED
4 0 0 YES UNASSIGNED
5 0 0 YES UNASSIGNED
ソース・データベースからのログ・ファイルが手順3でLOCATION属性に指定した場所に存在することを確認します。ディレクトリ内のファイルを確認するには、ソース・データベースのログ・ファイルを切り替える必要がある場合があります。
これらの手順が完了すると、リアルタイム・ダウンストリーム取得プロセスを構成できます。次の項の手順を参照してください。
