15 Oracle Streamsレプリケーション・データベースのベスト・プラクティス

Oracle Streamsレプリケーション・データベースとは、Oracle Streamsレプリケーション環境のデータベースです。Oracle Streamsレプリケーション環境では、あるデータベースから別のデータベースへデータベースの変更をレプリケートするOracle Streamsクライアントを使用します。Oracle Streamsクライアントには、取得プロセス、同期取得、伝播および適用プロセスが含まれます。この章では、Oracle Streamsレプリケーション・データベースの一般的なベスト・プラクティスについて説明します。

この章の内容は次のとおりです。

• Oracle Streamsデータベース構成のベスト・プラクティス

• Oracle Streamsデータベースの操作のベスト・プラクティス

• Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス

Oracle Streamsデータベース構成のベスト・プラクティス

Oracle Streamsレプリケーション環境を適切かつ効率的に実行するために、環境を構成する際にこの項のベスト・プラクティスに従います。この項の内容は次のとおりです。

• Oracle Streamsクライアント(取得および適用プロセス)用の個別のキューの使用

• Oracle Streamsレプリケーション構成の自動化

関連項目: Oracle Streamsレプリケーションの準備のベスト・プラクティスについては、第1章「Oracle Streamsレプリケーションの準備」を参照してください。

Oracle Streamsクライアント(取得および適用プロセス)用の個別のキューの使用

各取得プロセス、各同期取得および各適用プロセス用に個別のキューを構成し、各キューに独自のキュー表があることを確認します。2つのデータベース間で双方向のレプリケーションを構成する場合、または単一のデータベースが複数の他のデータベースからメッセージを受信する場合に、個別のキューを使用することは特に重要です。

たとえば、db1というデータベースが取得プロセスを使用して他のデータベースに送信される変更を取得しており、db2というデータベースから変更を受信していると想定します。db2から受信される変更がdb1上で実行する適用プロセスによって適用されます。この例では、db1で取得プロセスおよび適用プロセス用に個別のキューを作成し、これらのキューが異なるキュー表を使用することを確認します。

次の例では、取得プロセスのキューを作成します。キュー名はcapture_queueで、このキューはキュー表qt_capture_queueを使用します。

BEGIN
  DBMS_STREAMS_ADM.SET_UP_QUEUE(
    queue_table => 'strmadmin.qt_capture_queue',
    queue_name  => 'strmadmin.capture_queue');
END;
/

次の例では、適用プロセスのキューを作成します。キュー名はapply_queueで、このキューはキュー表qt_apply_queueを使用します。

BEGIN
  DBMS_STREAMS_ADM.SET_UP_QUEUE(
    queue_table => 'strmadmin.qt_apply_queue',
    queue_name  => 'strmadmin.apply_queue');
END;
/

その後、db1で取得プロセスを構成する際に、キューstrmadmin.capture_queueを指定し、db1で適用プロセスを構成する際に、キューstrmadmin.apply_queueを指定します。必要に応じて、SET_UP_QUEUEプロシージャを使用すると、各キュー表用に個別の表領域および記憶域の仕様を構成するために、storage_clauseパラメータを指定できます。

「Oracle Streamsレプリケーション構成の自動化」の説明に従って構成を自動化すると、各Oracle Streamsクライアントは独自のキューを使用して自動的に構成されるようになります。

関連項目: 「ANYDATAキューの作成」 「取得プロセスの構成」 第7章「暗黙的適用の構成」

Oracle Streamsレプリケーション構成の自動化

可能な場合にOracle Streamsレプリケーション環境を作成するには、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用します。

• MAINTAIN_GLOBAL: 2つのデータベース間でデータベース・レベルの変更をレプリケートするOracle Streams環境が構成されます。

• MAINTAIN_SCHEMAS: 2つのデータベース間で、指定されたスキーマに対する変更をレプリケートするOracle Streams環境が構成されます。

• MAINTAIN_SIMPLE_TTS: 宛先データベースでソース・データベースからの単一の表領域がクローニングされ、Oracle Streamsを使用して両方のデータベースでこの表領域がメンテナンスされます。

• MAINTAIN_TABLES: 2つのデータベース間で、指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。

• MAINTAIN_TTS: 宛先データベースでソース・データベースからの表領域セットがクローニングされ、Oracle Streamsを使用して両方のデータベースでこれらの表領域がメンテナンスされます。

• PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP: 2つのデータベース間でデータベース・レベルの変更または指定された表に対する変更をレプリケートするOracle Streams環境が構成されます。Oracle Streamsレプリケーションの構成を完了するには、これらのプロシージャをともに使用し、インスタンス化の操作を手動で実行する必要があります。

これらのプロシージャによって複数のデータベースでOracle Streamsクライアントの構成全体が自動化されます。さらに、構成はOracle Streamsのベスト・プラクティスに従います。たとえば、可能な場合はこれらのプロシージャによってキュー・ツー・キュー伝播が作成されます。

これらのプロシージャが環境に適さない場合は、Oracle Streamsクライアント、ルール・セットおよびルールを作成するために、DBMS_STREAMS_ADMパッケージの次のプロシージャを使用します。

• ADD_TABLE_RULES

• ADD_SUBSET_RULES

• ADD_SCHEMA_RULES

• ADD_GLOBAL_RULES

• ADD_TABLE_PROPAGATION_RULES

• ADD_SUBSET_PROPAGATION_RULES

• ADD_SCHEMA_PROPAGATION_RULES

• ADD_GLOBAL_PROPAGATION_RULES

これらのプロシージャは、Oracle Streamsクライアントを構成するのに必要な手順の数を最小化します。また、存在しないオブジェクトのルールを作成することが可能なため、ルールに指定された各オブジェクトのスペルは注意して確認してください。

一般的にはお薦めしませんが、キュー内のすべてのメッセージを常に伝播または適用する場合、ルール・セットまたはルールなしで伝播または適用プロセスを使用できます。ただし、取得プロセスにはルールと1つ以上のルール・セット、同期取得にはポジティブ・ルール・セットが必要です。サポートされないオブジェクトに対する変更がフィルタ処理されるように、取得プロセスに対してネガティブ・ルール・セットを構成すると、ADD_GLOBAL_RULESプロシージャを使用して、データベース全体に対するデータ操作言語(DML)変更を取得プロセスで取得できます。また、ADD_GLOBAL_RULESプロシージャを使用して、データベースに対するすべてのデータ定義言語(DDL)変更を取得プロセスで取得することもできます。

伝播のルール・セットのルールは、取得プロセスまたは同期取得に指定されたルールと異なっていてもかまいません。たとえば、すべての取得された変更が宛先データベースに伝播されるように構成する場合は、たとえ取得プロセスまたは同期取得のADD_TABLE_RULESを使用して複数のルールを構成したとしても、伝播のADD_GLOBAL_PROPAGATION_RULESプロシージャを実行できます。同様に、適用プロセスのルール・セットのルールは、メッセージを取得して適用プロセスに伝播する取得プロセス、同期取得および伝播に指定されたルールと異なっていてもかまいません。

Oracle Streamsクライアントは、複数の表またはスキーマの変更を処理できます。パフォーマンスを最適化するために、これらの表またはスキーマのルールが単純であることを確認します。複雑なルールは、Oracle Streamsのパフォーマンスに影響します。たとえば、LIKE句を含む条件があるルールは複雑です。ルールを作成するためにDBMS_STREAMS_ADMパッケージのプロシージャを使用する場合は、常にルールは単純です。

Oracle Streamsレプリケーション環境に複数のソース・データベースを構成する際、変更の循環を回避する必要があります。変更の循環とは、変更が発生場所であるデータベースに再送されることです。Oracle Streamsタグを使用して変更の循環を回避できます。

関連項目: 「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」 「キュー・ツー・キュー伝播の使用」 変更の循環を回避するためのOracle Streamsタグの使用の詳細は、「レプリケーション環境のOracle Streamsタグ」を参照してください。 単純および複雑なルールの詳細は、『Oracle Streams概要および管理』を参照してください。

Oracle Streamsデータベースの操作のベスト・プラクティス

Oracle Streamsレプリケーション環境を構成した後、適切かつ効率的に実行するには、この項のベスト・プラクティスに従います。この項の内容は次のとおりです。

• Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠

• パフォーマンスの監視と必要に応じた調整

• サイズに対する取得プロセスのキューおよび同期取得のキューの監視

• バックアップのOracle Streamsのベスト・プラクティスへの準拠

• オプティマイザ統計の自動収集の調整

• Oracle Streams情報のアラート・ログの確認

• データベースでOracle Streams構成を削除するベスト・プラクティスへの準拠

Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠

Oracle Streamsでは、特定のデータベースからの変更または特定のデータベースへの変更を識別するために、データベースのグローバル名を使用します。たとえば、一般的に取得、伝播および適用のシステム生成ルールでは、ソース・データベースのグローバル名を指定します。また、Oracle Streams取得プロセスまたは同期取得によって取得された変更には、ソース・データベースの現行のグローバル名が自動的に含まれます。可能な場合、環境を構成した後はOracle Streamsレプリケーション環境内のデータベースのグローバル名は変更しません。また、データベース・リンク名が各宛先データベースのグローバル名と一致することを保証するには、GLOBAL_NAMES初期化パラメータをTRUEに設定する必要があります。

Oracle Streamsデータベースのグローバル名を変更する必要がある場合は、データベース上でのユーザーによる変更が不可能で、キューが空で、適用プロセスによって未解決の変更を適用する必要がないときに、一度に実行します。これらの要件を満たす場合、データベースのグローバル名を変更し、変更されたデータベースを参照するOracle Streams構成の一部を再作成できます。ソース・データベースのグローバル名が変更される場合、伝播、適用プロセスなどのすべてのキュー・サブスクライバを再作成する必要があります。

関連項目: 「ソース・データベースのDBIDまたはグローバル名の変更」

パフォーマンスの監視と必要に応じた調整

Oracle Database 11g リリース1(11.1)以上のデータベースでは、Oracle Streamsパフォーマンス・アドバイザによって、Oracle Streamsコンポーネントの実行状況に関する情報が提供されます。このアドバイザを使用すると、環境内の複数のOracle Streamsコンポーネントのパフォーマンスを監視して、必要に応じて調整を行い、パフォーマンスを向上させることができます。

UTL_SPADVパッケージでも、Oracle Streams環境のパフォーマンス統計が提供されます。このパッケージは、Oracle Streamsパフォーマンス・アドバイザを使用してパフォーマンス統計を収集します。このパッケージを使用すると、分析用にスプレッドシートにインポートできる形式で統計を出力することができます。

Oracle Database 11g リリース1(11.1)より前のリリースのデータベースでは、STRMMONを使用してOracle Streams環境のパフォーマンスを監視できます。このツールを使用して、データベース内のOracle Streamsアクティビティの概要を迅速に把握することができます。STRMMONは、情報を1行でレポートします。レポート間隔および表示の反復回数を構成できます。STRMMONは、Oracleホームのrdbms/demoディレクトリで使用可能です。

関連項目: Oracle Streamsパフォーマンス・アドバイザの詳細は、『Oracle Streams概要および管理』を参照してください。 UTL_SPADVパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

サイズに対する取得プロセスのキューおよび同期取得のキューの監視

キューのサイズをチェックするために取得プロセスによって使用されるキューを監視する必要があります。キュー内のメッセージが1つ以上の宛先キューに伝播できない場合、取得プロセスまたは同期取得によって使用されるキュー内のメッセージ数は増加します。ソース・キューのサイズの増加は、Oracle Streamsレプリケーション環境に問題があることを示す場合が多くあります。メッセージを伝播できない一般的な理由は次のとおりです。

• 宛先データベースのいずれかが長期間停止している。

• 宛先データベースの適用プロセスが長期間無効化されている。

• キューが、ネットワークの問題または伝播ジョブの問題のため、長期間メッセージを特定の宛先キューに配信できない伝播のソース・キューである。

取得プロセスのキューのサイズが増加すると、取得プロセスは、ディスクにオーバーフローするメッセージの数を最小化するフロー制御のために中断します。V$BUFFERED_QUEUES動的パフォーマンス・ビューを問い合せて取得プロセスのキュー内のメッセージ数を監視できます。このビューには、メモリ内のメッセージ数およびディスクにオーバーフローしたメッセージ数が表示されます。

V$PERSISTENT_QUEUESまたはV$AQ動的パフォーマンス・ビューを問い合せて同期取得のキュー内のメッセージ数を監視できます。このビューには、永続キュー内の様々なメッセージ状態のメッセージの数が表示されます。

伝播はOracle Schedulerを使用して実装します。ジョブを連続して16回実行できない場合は、ジョブは「故障」としてマークされ、強制終了されます。ソース・キューのサイズを最小化するために伝播ジョブが正常に動作していることを確認するには、定期的に伝播ジョブをチェックします。

関連項目: 「故障した伝播の再起動」

バックアップのOracle Streamsのベスト・プラクティスへの準拠

次の項には、Oracle Streamsレプリケーション環境内のソース・データベースおよび宛先データベースをバックアップするベスト・プラクティスに関する情報が含まれます。単一のデータベースがソース・データベースおよび宛先データベースの両方である場合があります。

Oracle Streamsソース・データベースのバックアップのベスト・プラクティス

ソース・データベースとは、取得プロセスによって取得される変更がREDOログで生成されるデータベース、またはOracle Streams同期取得が構成されるデータベースです。次のOracle Streamsソース・データベースのバックアップのベスト・プラクティスに従います。

• ソース・データベースに対する変更を取得する取得プロセスがバックアップ文を取得しないことを確認するために、オンライン・バックアップSQL文を実行するセッションでOracle Streamsタグを使用します。オンライン・バックアップ文では、ALTER TABLESPACEまたはALTER DATABASE文のBEGIN BACKUPおよびEND BACKUP句が使用されます。Oracle Streamsセッション・タグを設定するには、DBMS_STREAMS.SET_TAGプロシージャを使用します。

  
  

  注意: Recovery Manager(RMAN)を使用して実行するバックアップでは、Oracle Streamsセッション・タグを設定する必要はありません。

  
  
  
  

  関連項目: 第10章「Oracle Streamsタグ」

  
  

• 取得プロセスで必要なアーカイブ・ログを削除する可能性があるアーカイブ・ログの自動バックアップは許可しないでください。取得プロセスによるすべての必要なアーカイブ・ログ・ファイルの処理が完了するまで、それらのファイルが予期された場所にあり、オンラインで使用可能であることはOracle Streams環境では特に重要です。取得プロセスで必要なログが使用不可能な場合、取得プロセスは異常終了します。

  データベース内の必要な各アーカイブREDOログを表示するには、次の問合せを実行します。

  COLUMN CONSUMER_NAME HEADING 'Capture|Process|Name' FORMAT A15
  COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A10
  COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 99999
  COLUMN NAME HEADING 'Required|Archived Redo Log|File Name' FORMAT A40
   
  SELECT r.CONSUMER_NAME,
         r.SOURCE_DATABASE,
         r.SEQUENCE#, 
         r.NAME 
    FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
    WHERE r.CONSUMER_NAME =  c.CAPTURE_NAME AND
          r.NEXT_SCN      >= c.REQUIRED_CHECKPOINT_SCN;
  

• すべてのスレッドからのすべてのアーカイブ・ログ・ファイルが使用可能であることを確認します。データベース・リカバリはこれらのログの可用性に応じて異なるため、ログが欠落すると、不完全リカバリになります。

• ソース・データベースで不完全リカバリ(Point-in-Timeリカバリ)が発生する状況では、「単一ソース環境のソースにおけるPoint-in-Timeリカバリの実行」または「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順に従います。

Oracle Streams宛先データベースのバックアップのベスト・プラクティス

Oracle Streamsレプリケーション環境では、宛先データベースは、適用プロセスが変更を適用するデータベースです。Oracle Streams宛先データベースのバックアップに関する次のベスト・プラクティスに従います。

• commit_serialization適用プロセス・パラメータがFULLに設定されていることを確認します。

• 宛先データベースで不完全リカバリ(Point-in-Timeリカバリ)が発生する状況では、「宛先データベースにおけるPoint-in-Timeリカバリの実行」の手順に従います。

オプティマイザ統計の自動収集の調整

デフォルトでは毎晩、オプティマイザは統計が古くなった表に関する統計を自動的に収集します。Oracle Streamsキュー表などの揮発性表の場合、これらの表が完全ロード期間を表すデータを所有していないときに、統計収集ジョブが動作する可能性があります。

DBMS_AQADM.CREATE_QUEUE_TABLEまたはDBMS_STREAMS_ADM.SETUP_QUEUEプロシージャを使用して、これらの揮発性キュー表を作成します。これらのプロシージャを実行する際にキュー表の名前を指定します。キュー表が作成され、その表が揮発性である場合は、キュー表に加えて次の表が作成されます。

• AQ$_queue_table_name_I

• AQ$_queue_table_name_H

• AQ$_queue_table_name_T

• AQ$_queue_table_name_P

• AQ$_queue_table_name_D

• AQ$_queue_table_name_C

queue_table_name をキュー表の名前に置換します。

次の手順を完了して、揮発性表で統計を収集することをお薦めします。

1. これらの表が一杯のときに、揮発性表でDBMS_STATS.GATHER_TABLE_STATSプロシージャを手動で実行します。

2. 揮発性表で統計が収集された直後に、これらの表でDBMS_STATS.LOCK_TABLE_STATSプロシージャを実行します。

揮発性表で統計をロックすると、自動統計収集ジョブがこれらの表をスキップして、表が分析されません。

関連項目: オプティマイザ統計の管理の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

Oracle Streams情報のアラート・ログの確認

デフォルトでは、アラート・ログには、Oracle Streamsの取得プロセスおよび適用プロセスが停止した理由に関する情報が含まれます。また、Oracle Streamsの取得プロセスおよび適用プロセスは、アラート・ログに長時間実行トランザクションおよび大規模なトランザクションをレポートします。

長時間実行トランザクションとは、長期間(20分)アクティビティがない(新しい変更レコード、ロールバック、コミットがない)オープン・トランザクションです。大規模なトランザクションとは、大量の変更レコードがあるオープン・トランザクションです。アラート・ログでは、長時間実行トランザクションまたは大規模なトランザクションが20分ごとに確認されたかどうかをレポートします。各20分間で1つのトランザクションのみがレポートされるため、すべてのそのようなトランザクションがレポートされるわけではありません。コミットまたはロールバックが受け入れられると、この情報はアラート・ログにもレポートされます。

長時間実行トランザクションについて次のビューを使用できます。

• V$STREAMS_TRANSACTION動的パフォーマンス・ビューによって、Oracle Streamsの取得プロセスおよび適用プロセスによって処理中の長時間実行トランザクションを監視できます。

• DBA_APPLY_SPILL_TXNおよびV$STREAMS_APPLY_READERビューによって、適用プロセスでオーバーフローしたトランザクションおよびメッセージの数を監視できます。

注意: V$STREAMS_TRANSACTIONビューは、同期取得には関連していません。

関連項目: アラート・ログ内のOracle Streamsの情報の詳細は、『Oracle Streams概要および管理』を参照してください。

データベースでOracle Streams構成を削除するベスト・プラクティスへの準拠

データベースでOracle Streams構成を完全に削除するには、次の手順を実行します。

1. SQL*Plusで、管理ユーザーとしてデータベースに接続します。

   SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。

2. DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATIONプロシージャを実行します。

3. 可能な場合は、Oracle Streams管理者を削除します。

Oracle Real Application ClustersおよびOracle Streamsのベスト・プラクティス

次のベスト・プラクティスは、Oracle Streamsレプリケーション環境のOracle Real Application Clusters(Oracle RAC)データベース用です。

• すべてのスレッドのアーカイブ・ログ・ファイルの取得プロセスでの使用可能化

• Oracle RACデータベースのグローバル名のベスト・プラクティスへの準拠

• 伝播を構成および管理するベスト・プラクティスへの準拠

• キュー所有権のベスト・プラクティスへの準拠

関連項目: Oracle StreamsがOracle RACと動作する方法の詳細は、『Oracle Streams概要および管理』を参照してください。

すべてのスレッドのアーカイブ・ログ・ファイルの取得プロセスでの使用可能化

すべてのインスタンスからのすべてのスレッドのアーカイブ・ログ・ファイルは、取得プロセスを実行するすべてのインスタンスで使用可能である必要があります。この要件は、ローカルおよびダウンストリーム取得プロセスの両方に関連します。

Oracle RACデータベースのグローバル名のベスト・プラクティスへの準拠

「Oracle Streamsデータベースのグローバル名のベスト・プラクティスへの準拠」で説明されている一般的なベスト・プラクティスは、Oracle Streams環境内のOracle Real Application Clusters(Oracle RAC)データベースにも適用します。また、Oracle RAC宛先データベースのグローバル名が、データベースのDB_NAME.DB_DOMAIN に一致しない場合、SERVICE_NAMES初期化パラメータによって指定されたデータベースのサービスのリストにデータベースのグローバル名が含まれます。

tnsnames.oraファイルで、接続記述子のCONNECT_DATA句では、SERVICE_NAMEに宛先データベースのグローバル名を指定することを確認します。また、CONNECT_DATA句には、INSTANCE_NAMEパラメータを含まないことを確認します。

Oracle Streams伝播を含むOracle RACデータベースのグローバル名を変更する場合、すべての伝播を削除して再作成します。作成時にqueue_to_queueパラメータをTRUEに設定して、新しい伝播がキュー・ツー・キュー伝播であることを確認します。

Oracle RAC宛先データベースのグローバル名を変更する必要がある場合、グローバル名を変更する前に、各適用プロセスによって使用されるキューが空で、適用されていないトランザクションが存在しないことを確認します。グローバル名を変更した後、各適用プロセスのキューおよび各適用プロセスを削除して再作成します。

関連項目: tnsnames.oraファイルのSERVICE_NAMEパラメータの詳細は、「キュー所有権のベスト・プラクティスへの準拠」を参照してください。

伝播を構成および管理するベスト・プラクティスへの準拠

「故障した伝播の再起動」で説明する一般的なベスト・プラクティスは、Oracle Streams環境のOracle Real Application Clusters(Oracle RAC)データベースにも適用します。伝播を起動および停止するには、DBMS_PROPAGATION_ADMパッケージのプロシージャSTART_PROPAGATIONおよびSTOP_PROPAGATIONを使用します。これらのプロシージャでは、自動的にキュー・ツー・キュー伝播を処理します。

また、Oracle RACデータベースでは、サービスは各バッファ・キューに対して作成されます。常に、このサービスは、宛先キューの所有者のインスタンス上で動作し、インスタンス起動、インスタンス停止などを含むキュー所有権の切り替え時にこのキューの所有権に従います。このサービスは、キュー・ツー・キュー伝播によって使用されます。キュー・ツー・キュー伝播のサービス名を判断するには、DBA_SERVICESデータ・ディクショナリ・ビューのNETWORK_NAME列を問い合せます。Oracle RACインスタンスを実行しており、Oracle Database 10g リリース2より前に作成されたキューを所有している場合、自動サービス生成およびキュー・ツー・キュー伝播を利用するには、これらのキューを削除して再作成します。これらのキューが空で、新しいメッセージがこれらのキューにエンキューされていない場合は、これらのキューを再作成することを確認します。

関連項目: 「キュー・ツー・キュー伝播の使用」

キュー所有権のベスト・プラクティスへの準拠

すべてのOracle Streams処理は、Oracle Streamsクライアントによって使用されるキューの所有するインスタンスで行われます。データベース内の各ANYDATAキューの所有するインスタンスを判断するには、次の問合せを実行します。

SELECT q.OWNER, q.NAME, t.QUEUE_TABLE, t.OWNER_INSTANCE
   FROM DBA_QUEUES q, DBA_QUEUE_TABLES t
   WHERE t.OBJECT_TYPE = 'SYS.ANYDATA' AND
         q.QUEUE_TABLE = t.QUEUE_TABLE AND
         q.OWNER = t.OWNER;

Oracle StreamsがOracle Real Application Clusters(Oracle RAC)環境で構成されている場合、各キュー表には所有するインスタンスがあります。また、各キュー表内のすべてのキューは、同じインスタンスによって所有されます。次のOracle Streamsクライアントでは、作業の実行に、関連するキューの所有するインスタンスを使用します。

• 各取得プロセスは、そのキューの所有するインスタンスで実行されます。

• 各伝播は、伝播のソース・キューの所有するインスタンスで実行されます。

• 各伝播は、伝播の宛先キューの所有するインスタンスに接続する必要があります。

• 各適用プロセスは、そのキューの所有するインスタンスで実行されます。

DBMS_AQADM.ALTER_QUEUE_TABLEプロシージャを実行して、primary_instanceおよびsecondary_instanceパラメータを設定すると、インスタンスが使用可能である場合は、特定のインスタンス上に存在するようにキューの所有権を構成できます。キュー表のプライマリ・インスタンスを特定のインスタンスに設定すると、インスタンスが動作しているときは、常に、キューの所有権は指定されたインスタンスに戻ります。

取得プロセスおよび適用プロセスは、自動的にキューの所有権に従います。プロセスの動作中に所有権が変わる場合、プロセスは現在のインスタンス上で停止し、新しい所有者のインスタンス上で再起動します。

キュー・ツー・キュー伝播は、宛先キューとして識別された特定のキューにのみメッセージを送信します。また、宛先データベースの接続記述子のソース・データベース・リンクでは、宛先データベースに接続する適切なサービスを指定する必要があります。接続記述子のCONNECT_DATA句では、SERVICE_NAMEに宛先データベースのグローバル名を指定する必要があります。

たとえば、グローバル名がdb.mycompany.comであるデータベースのtnsnames.oraファイルを検討します。最初のインスタンスの別名はdb1で、2番目のインスタンスの別名はdb2であると想定します。このデータベースのtnsnames.oraファイルには、次のエントリが含まれる場合があります。

db.mycompany.com= 
 (description= 
  (load_balance=on)
   (address=(protocol=tcp)(host=node1-vip)(port=1521))
   (address=(protocol=tcp)(host=node2-vip)(port=1521))
  (connect_data=
     (service_name=db.mycompany.com)))
 
db1.mycompany.com=
 (description=
  (address=(protocol=tcp)(host=node1-vip)(port=1521))
  (connect_data= 
    (service_name=db.mycompany.com)
    (instance_name=db1)))
 
db2.mycompany.com= 
 (description= 
  (address=(protocol=tcp)(host=node2-vip)(port=1521))
  (connect_data= 
    (service_name=db.mycompany.com)
    (instance_name=db2)))