この章では、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レプリケーションを構成する前に、次の決定を行います。
レプリケーション環境を構成する前に、まず、レプリケーション環境に含めるデータベースの数、レプリケートするデータベース・オブジェクト、およびレプリケーション環境でのデータベースの変更の流れを決定します。最も一般的なタイプのレプリケーション環境は、次のとおりです。
一方のデータベースが読取り/書込み可能で、もう一方のデータベースが読取り専用である2データベース環境での一方向のレプリケーション
両方のデータベースが読取り/書込み可能である2データベース環境での双方向のレプリケーション
1つの読取り/書込み可能なハブ、および複数の読取り専用スポークを持つハブ・アンド・スポーク・レプリケーション
読取り/書込み可能なハブ、および1つ以上の読取り/書込み可能なスポークを持つハブ・アンド・スポーク・レプリケーション
複数の読取り/書込み可能なデータベースを持つn-wayレプリケーション
ほとんどの組織のレプリケーション要件は、これらの環境のいずれかによって満たされます。これらの一般的なタイプのレプリケーション環境の詳細は、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。
これらの一般的なレプリケーション環境で要件が満たされない場合は、Oracle Streamsを使用して、ほぼすべてのタイプのカスタム・レプリケーション環境を構成できます。たとえば、カスタム・レプリケーション環境では、データベースの変更を、宛先データベースに適用する前に複数の中間データベースを介して送信できます。
ローカル取得とは、ソース・データベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得とは、ソース・データベース以外のデータベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得を使用する主な理由は、ソース・データベースの負荷を削減して、パフォーマンスを向上させることです。
ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。次のいずれかのデータベースを取得データベースとして使用できます。
ソース・データベース(ローカル取得)
宛先データベース(ダウンストリーム取得)
第3のデータベース(ダウンストリーム取得)
図1-2に、取得データベースの役割を示します。
ソース・データベースまたは第3のデータベースを取得データベースとして使用すると、伝播によって、取得データベースから宛先データベースに変更が送信されます。宛先データベースを取得データベースとして使用すると、取得プロセスと適用プロセスで同じキューが使用されるため、データベース間でこの伝播を行う必要はありません。
ダウンストリーム取得プロセスを構成する場合は、構成するダウンストリーム取得プロセスのタイプを決定する必要があります。次のタイプを使用できます。
リアルタイム・ダウンストリーム取得プロセスの構成: REDO転送サービスでソース・データベースのログ・ライター・プロセス(LGWR)を使用して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 Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。
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 Database 2日でデータ・レプリケーションおよび統合ガイド』およびOracle Enterprise Managerのオンライン・ヘルプを参照してください。
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のStreamsレプリケーションの設定ウィザード。例は次のとおりです。
提供の 各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。
|
|
Oracle Enterprise ManagerのStreamsレプリケーションの設定ウィザード。例は次のとおりです。
提供の 各Oracle Streamsコンポーネントの個別の構成。例は次のとおりです。
|
|
提供の 各Oracle Streamsコンポーネントの個別の構成。 |
|
読取り/書込み可能なハブ、および1つ以上の読取り/書込み可能なスポークを持つハブ・アンド・スポーク・レプリケーション |
Oracle Enterprise Managerの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を使用してOracle Streams管理者を作成する手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
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
権限が必要です。また、ユーザー作成サブプログラム内のビューを問い合せる場合は、そのデータ・ディクショナリ・ビューに対する明示的な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を使用してOracle Streamsコンポーネント含むデータベースを管理する場合は、Oracle Streams管理者がDatabase Control管理者となるように構成します。これにより、Oracle Enterprise Managerジョブの実行に必要な権限など、Oracle Enterprise Managerで必要な追加の権限が付与されます。手順については、『Oracle Database 2日でデータベース管理者』を参照してください。
ローカル・データベースでアクションを実行する権限をリモートの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サーバーとの互換性を保つ必要があるリリースを指定します。互換レベルが異なるOracleサーバーと相互運用できます。 Oracle Database 11gリリース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、NESTED TABLEなど)および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を使用して、ログ・ファイルの転送およびダウンストリーム取得プロセスを構成できます。手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
次の手順を実行して、ソース・データベースの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
を指定するメリットは、ソース・データベースのパフォーマンスにほとんど影響を与えないことです。ソース・データベースでOracle Database 10gリリース1以上を実行しており、ダウンストリーム・データベースまたはネットワークのパフォーマンスが低い場合は、ソース・データベースのパフォーマンスに影響を及ぼさないように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を使用して、リアルタイム・ダウンストリーム取得を構成できます。手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。 |
ダウンストリーム・データベースでスタンバイ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
属性に指定した場所に存在することを確認します。ディレクトリ内のファイルを確認するには、ソース・データベースのログ・ファイルを切り替える必要がある場合があります。
これらの手順が完了すると、リアルタイム・ダウンストリーム取得プロセスを構成できます。次の項の手順を参照してください。