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管理者のユーザー名はstrmadmin
ですが、適切な権限を持つすべてのユーザーがOracle Streams管理者になることができます。この項の例では、Oracle Streams管理者のユーザー名としてstrmadmin
を使用します。
関連する各Oracle StreamsデータベースでOracle Streams管理者用に個別の表領域を作成します。この表領域には、スキーマ所有のバッファ・キューからオーバーフローしたすべてのメッセージを含む、Oracle Streams管理者スキーマで作成されたすべてのオブジェクトが格納されます。
たとえば、streams_tbs
という表領域を作成し、それをOracle Streams管理者に割り当てるには、管理ユーザーとしてログインし、次のSQL文を実行します。
CREATE TABLESPACE streams_tbs DATAFILE '/usr/oracle/dbs/streams_tbs.dbf' SIZE 25 M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED; ALTER USER strmadmin DEFAULT TABLESPACE streams_tbs QUOTA UNLIMITED ON streams_tbs;
CREATE
TABLESPACE
文のデータ・ファイルにファイル・システム上の有効なパスを指定します。
参照: 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管理者がDBA権限を所有している必要があります。管理ユーザーは、DBA権限をOracle Streams管理者に明示的に付与する必要があります。たとえば、次の文ではDBA権限がstrmadmin
というOracle Streams管理者に付与されます。
GRANT DBA TO strmadmin;
また、関連する各Oracle Streamsデータベース上のOracle Streams管理者に他の権限を付与できます。これらの権限を付与するには、DBMS_STREAMS_AUTH
パッケージのGRANT_ADMIN_PRIVILEGE
プロシージャを使用します。たとえば、次のプロシージャを実行すると、権限がstrmadmin
というOracle Streams管理者に付与されます。
exec DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE('STRMADMIN');
参照: Oracle Streams管理者を構成する方法は、『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タグを使用して変更の循環を回避できます。
参照:
|
Oracle Streamsレプリケーション環境を構成した後、適切かつ効率的に実行するには、この項のベスト・プラクティスに従います。この項の内容は次のとおりです。
Oracle Streamsでは、特定のデータベースからの変更または特定のデータベースへの変更を識別するために、データベースのグローバル名を使用します。たとえば、一般的に取得、伝播および適用のシステム生成ルールでは、ソース・データベースのグローバル名を指定します。また、Oracle Streams取得プロセスまたは同期取得によって取得された変更には、ソース・データベースの現行のグローバル名が自動的に含まれます。可能な場合、環境を構成した後はOracle Streamsレプリケーション環境内のデータベースのグローバル名は変更しません。また、データベース・リンク名が各接続先データベースのグローバル名と一致することを保証するには、GLOBAL_NAMES
初期化パラメータをTRUE
に設定する必要があります。
Oracle Streamsデータベースのグローバル名を変更する必要がある場合は、データベース上でのユーザーによる変更が不可能で、キューが空で、適用プロセスによって未解決の変更を適用する必要がないときに、一度に実行します。これらの要件を満たす場合、データベースのグローバル名を変更し、変更されたデータベースを参照するOracle Streams構成の一部を再作成できます。ソース・データベースのグローバル名が変更される場合、伝播、適用プロセスなどのすべてのキュー・サブスクライバを再作成する必要があります。
データ定義言語(DDL)変更をレプリケートする際、制約または索引に対してシステム生成名を許可しないでください。異なるデータベースのオブジェクト名が一致しないため、これらのデータベース・オブジェクトに対する変更は、接続先データベースで失敗する可能性が高いです。また、接続先データベースが異なる場合、STORAGE句によって問題が発生する場合もあります。Oracle Streams環境でDDLをレプリケートしないことを決定する場合、環境内の各データベースですべての表構造の変更を手動で実行する必要があります。
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
ディレクトリで使用可能です。
参照:
|
キューのサイズをチェックするために取得プロセスによって使用されるキューを監視する必要があります。キュー内のメッセージが1つ以上の宛先キューに伝播できない場合、取得プロセスまたは同期取得によって使用されるキュー内のメッセージ数は増加します。ソース・キューのサイズの増加は、Oracle Streamsレプリケーション環境に問題があることを示す場合が多くあります。メッセージを伝播できない一般的な理由は次のとおりです。
接続先データベースのいずれかが長期間停止している。
接続先データベースの適用プロセスが長期間無効化されている。
キューが、ネットワークの問題または伝播ジョブの問題のため、長期間メッセージを特定の宛先キューに配信できない伝播のソース・キューである。
取得プロセス・キューのサイズが増加すると、取得プロセスは、ディスクにオーバーフローするメッセージの数を最小化するフロー制御のために中断します。V$BUFFERED_QUEUES
動的パフォーマンス・ビューを問い合せて取得プロセス・キュー内のメッセージ数を監視できます。このビューには、メモリ内のメッセージ数およびディスクにオーバーフローしたメッセージ数が表示されます。
V$PERSISTENT_QUEUES
またはV$AQ
動的パフォーマンス・ビューを問い合せて同期取得キュー内のメッセージ数を監視できます。このビューには、永続キュー内の様々なメッセージ状態のメッセージの数が表示されます。
伝播はOracle Schedulerを使用して実装します。ジョブを連続して16回実行できない場合は、ジョブは「故障」としてマークされ、無効になります。ソース・キューのサイズを最小化するために伝播ジョブが正常に動作していることを確認するには、定期的に伝播ジョブをチェックします。
次の項には、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を使用して実行するバックアップでは、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接続先データベースのバックアップの次のベスト・プラクティスに従います。
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
をキュー表の名前に置換します。
次の手順を完了して、揮発性表で統計を収集することをお薦めします。
これらの表がいっぱいのときに、揮発性表でDBMS_STATS.GATHER_TABLE_STATS
プロシージャを手動で実行します。
揮発性表で統計が収集された直後に、これらの表でDBMS_STATS.LOCK_TABLE_STATS
プロシージャを実行します。
揮発性表で統計をロックすると、自動統計収集ジョブがこれらの表をスキップして、表が分析されません。
参照: オプティマイザ統計の管理の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
デフォルトでは、アラート・ログには、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 Real Application Clusters(Oracle RAC)データベース用です。
参照: Oracle StreamsがOracle RACと動作する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
すべてのインスタンスからのすべてのスレッドのアーカイブ・ログ・ファイルは、取得プロセスを実行するすべてのインスタンスで使用可能である必要があります。この要件は、ローカルおよびダウンストリーム取得プロセスの両方に関連します。
「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接続先データベースのグローバル名を変更する必要がある場合、グローバル名を変更する前に、各適用プロセスによって使用されるキューが空で、適用されていないトランザクションが存在しないことを確認します。グローバル名を変更した後、各適用プロセス・キューおよび各適用プロセスを削除して再作成します。
「故障した伝播の再起動」で説明する一般的なベスト・プラクティスは、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)))