3 XStream Outの概念
XStream Outに関連する概念について理解します。
- XStream Outの概要
XStream Outでは、OracleデータベースのREDOログからトランザクションを取得して、クライアント・アプリケーションに効率よく送信できます。 - 取得プロセス
取得プロセスに関連する概念について理解します。 - アウトバウンド・サーバー
XStream Outでは、アウトバウンド・サーバーからクライアント・アプリケーションにデータベース変更が送信されます。 - LCRの位置およびXStream Out
XStream Outのアウトバウンド・サーバーでは、取得プロセスで取得したLCRがクライアント・アプリケーションにストリームされます。LCRの位置により、トランザクション内のLCRのストリームにおける配置が識別されます。 - XStream Outと分散トランザクション
XStream Outと分散トランザクションに関する考慮事項があります。 - XStream Outとセキュリティ
クライアント・アプリケーションとXStreamコンポーネントに関連するセキュリティ、および取得ユーザーと接続ユーザーに必要な権限について理解します。 - XStream Outと他のOracle Databaseコンポーネント
XStream Outは、他のOracle Databaseコンポーネントと連携できます。
関連項目:
親トピック: XStream Out
3.1 XStream Outの概要
XStream OutはOracleデータベースのREDOログからトランザクションを取得し、それらをクライアント・アプリケーションに効率的に送信できます。
XStream Outは、クライアント・アプリケーションにこれらの変更をストリームするためのトランザクション・ベースのインタフェースを提供します。クライアント・アプリケーションは、他のシステム(Oracle以外のデータベースやファイル・システムなどのOracle以外のシステムを含む)と対話できます。
XStream Out構成の取得プロセスでは、データベースに対する変更を取得し、その変更をアウトバウンド・サーバーに送信します。この項では、取得プロセスおよびアウトバウンド・サーバーについて詳しく説明しています。
XStream OutにはOCIインタフェースとJavaインタフェースの両方があり、LOB、LONG
、LONG
RAW
、XMLType
など、Oracle Databaseでサポートされているデータ型のほとんどがサポートされます。
3.2 取得プロセス
取得プロセスに関連する概念について理解します。
- 取得プロセスの概要
A 取得プロセスはオプションのOracleバックグラウンド・プロセスであり、データベースのREDOログをスキャンしてデータベース・オブジェクトに対するDML変更とDDL変更を取得します。 - 取得プロセスで取得されるデータ型
取得プロセスでは、ほとんどのデータ型の列に対する変更を取得できます。 - 取得プロセスで取得されるDML変更のタイプ
取得プロセスでは様々なタイプのDML変更を取得できます。 - ローカル取得とダウンストリーム取得
取得プロセスは、ソース・データベースでローカルに実行されるように構成することも、ダウンストリーム・データベースでリモートに実行されるように構成することもできます。 - 取得プロセスとRESTRICTED SESSION
制限付きセッションの有効化と無効化は、取得プロセスに影響します。 - 取得プロセスのサブコンポーネント
取得プロセスのサブコンポーネントには、1つのリーダー・サーバー、1つ以上のプリペアラ・サーバーおよび1つのビルダー・サーバーがあります。 - 取得プロセスの状態
取得プロセスの状態は、取得プロセスが現在行っている処理を表します。 - 取得プロセス・パラメータ
取得プロセス・パラメータは、取得プロセスの動作を制御します。 - 取得プロセスのチェックポイントとXStream Out
チェックポイントは取得プロセスの現在の状態に関する情報です。この情報は、取得プロセスを実行しているデータベースのデータ・ディクショナリに永続的に格納されます。 - 取得プロセスに関連するSCN値
取得プロセスには固有のシステム変更番号(SCN)値が重要となります。
親トピック: XStream Outの概念
3.2.1 取得プロセスの概要
取得プロセスはオプションのOracleバックグラウンド・プロセスであり、データベースのREDOログをスキャンし、データベース・オブジェクトに対するDML変更とDDL変更を取得します。
REDOログの主要な機能は、データベースに対して行われた変更をすべて記録することです。取得プロセスでは、REDOログからデータベース変更が取得され、変更が生成されたデータベースは、取得プロセスのソース・データベースと呼ばれます。
取得プロセスはデータベースの変更を取得すると、論理変更レコード(LCR).と呼ばれる特殊なメッセージ・フォーマットに変換しますXStream Out構成の取得プロセスでは、アウトバウンド・サーバーにこれらのLCRが送信されます。
図3-1では取得プロセスを示しています。
取得プロセスは、ソース・データベースまたはリモート・データベース上で実行されます。取得プロセスをソース・データベース上で実行する場合、取得プロセスはローカル取得プロセスです。
別のサーバーで取得プロセスを実行して、ソース・データベースに対する変更を取得することもできます。取得プロセスがリモート・データベース上で実行される場合、取得プロセスはダウンストリーム取得プロセスと呼ばれ、そのリモート・データベースはダウンストリーム・データベースと呼ばれます。ログ・ファイルは、リモート・データベースおよびソース・データベースに書き込まれます。この構成では、ソース・ログ・ファイルがダウンストリーム取得データベースで使用可能である必要があります。リモート・データベースでの取得プロセスによってソース・データベースからログが取り出され、ローカルでステージングされます。この構成は、本番データベースの変更取得処理の負荷を別のリモート・データベースにオフロードする場合に役立つことがあります。
親トピック: 取得プロセス
3.2.2 取得プロセスによって取得されるデータ型
取得プロセスはほとんどのデータ型の列に加えられた変更を取得できます。
表に対するDML変更による行の変更を取得するとき、取得プロセスは、次のデータ型の列に対して行われる変更を取得できます。
-
VARCHAR2
-
NVARCHAR2
-
NUMBER
-
FLOAT
-
LONG
-
DATE
-
BINARY_FLOAT
-
BINARY_DOUBLE
-
TIMESTAMP
-
TIME
WITH
TIME
ZONE
-
TIMESTAMP
WITH
LOCAL
TIME
ZONE
-
INTERVAL
YEAR
TO
MONTH
-
INTERVAL
DAY
TO
SECOND
-
RAW
-
LONG
RAW
-
UROWID
-
CHAR
-
NCHAR
-
BASICFILE
またはSECUREFILE
記憶域を持つCLOB
-
BASICFILE
またはSECUREFILE
記憶域を持つNCLOB
-
BASICFILE
またはSECUREFILE
記憶域を持つBLOB
-
CLOB
、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType
-
オブジェクト型
-
可変長配列
-
REF
データ型 -
次のOracle提供の型:
ANYDATA
、SDO_GEOMETRY
、メディア・タイプ -
BFILE
XStreamがオブジェクト・タイプのデータをレプリケートする場合、レプリケーションは一方向である必要があり、すべてのレプリケーション・サイトで、オブジェクト・タイプの属性の名前とデータ型が一致している必要があります。属性の名前とデータ型は、オブジェクト型を作成するときに設定します。たとえば、次のようなオブジェクト型の場合を考えます。
CREATE TYPE cust_address_typ AS OBJECT (street_address VARCHAR2(40), postal_code VARCHAR2(10), city VARCHAR2(30), state_province VARCHAR2(10), country_id CHAR(2)); /
すべてのレプリケーション・サイトで、street_address
はVARCHAR2(40)
、postal_code
はVARCHAR2(10)
、city
はVARCHAR2(30)
などのようにする必要があります。
ノート:
-
COMPATIBLE
初期化パラメータを12.0.0
に、MAX_STRING_SIZE
初期化パラメータをEXTENDED
に設定している場合、Oracle Database 12cではVARCHAR2
、NVARCHAR2
およびRAW
の各データ型の最大サイズが大きくなりました。 -
CLOB
として格納されるXMLType
は、Oracle Database 12cリリース1 (12.1)からは非推奨になりました。 -
BFILE
の場合、データ型構造のみがレプリケートされ、ファイル・システムに存在するBFILE
のコンテンツはレプリケートされません。
- IDキーLCR
IDキーLCRは特別なタイプの行LCRです。IDキーLCRにより、XStreamクライアント・アプリケーションで、サポートされていないデータ型を含む行に対する変更の処理が可能になります。 - IDキーLCRのデモ
IDキーLCRを処理するサンプルのクライアント・アプリケーションを作成するデモが用意されています。
関連項目:
データ型の詳細は、Oracle Database SQL言語リファレンスを参照
親トピック: 取得プロセス
3.2.2.1 IDキーLCR
IDキーLCRは特別なタイプの行LCRです。IDキーLCRにより、XStreamクライアント・アプリケーションで、サポートされていないデータ型を含む行に対する変更の処理が可能になります。
XStream Outでは行LCRの次のデータ型は完全にはサポートされていません。
-
ROWID
-
ネストした表
-
Oracle提供型:
ANYTYPE
、ANYDATASET
、URI型、SDO_TOPO_GEOMETRY
、SDO_GEORASTER
およびExpression
これらのデータ型の制限事項は、通常の(ヒープ構成)表および索引構成表の両方に適用されます。
IDキーLCRには、行の変更に関するすべての列が含まれるわけではありません。かわりに、変更される行の行ID、表内で行を識別するためのキー列のグループ、およびXStream Outでサポートされている表のスカラー列のデータが含まれています。IDキーLCRには、サポートされていないデータ型の列のデータは含まれません。
XStream OutではCAPTURE_IDKEY_OBJECTS
取得プロセス・パラメータをY
に設定することによって、完全にはサポートされていない表の変更を取得できます。XStreamクライアント・アプリケーションでは、次の方法でIDキーLCRを使用できます。
-
サポートされていない列のデータがアプリケーションで必要ではない場合、アプリケーションでは、通常どおり、IDキーLCR内のサポートされている列の値を処理できます。
-
サポートされていない列のデータがアプリケーションで必要な場合、アプリケーションでは、IDキーLCRの情報を使用してデータベース内の適切な行を問い合せ、その行のサポートされていないデータを使用できます。
DBA_XSTREAM_OUT_SUPPORT_MODE
ビューを使用して、IDキーLCRによってサポートされるローカル表のリストを表示できます。このビューでは、SUPPORT_MODE
列に、表に対する次のタイプのXStream Outのサポートが示されます。
-
(IDキーLCRを使用せずに)XStream Outで完全にサポートされる表の場合、
FULL
。 -
IDキーLCRを使用することでのみサポートされている表の場合、
ID
KEY
-
XStream Outでサポートされていない表の場合、
NONE
DBA_XSTREAM_OUT_SUPPORT_MODE
ビューにNONE
と表示される表では、IDキーLCRを使用しても、行に対する変更を処理できません。
たとえば、次の問合せを実行して、データベース内のすべての表に対するXStream Outのサポートを表示します。
COLUMN OWNER FORMAT A30 COLUMN OBJECT_NAME FORMAT A30 COLUMN SUPPORT_MODE FORMAT A12 SELECT OWNER, OBJECT_NAME, SUPPORT_MODE FROM DBA_XSTREAM_OUT_SUPPORT_MODE ORDER BY OBJECT_NAME;
出力は次のようになります。
OWNER OBJECT_NAME SUPPORT_MODE ------------------------------ ------------------------------ ------------ . . . IX ORDERS_QUEUETABLE NONE OE ORDER_ITEMS FULL SH PLAN_TABLE FULL PM PRINT_MEDIA ID KEY . . .
親トピック: 取得プロセスで取得されるデータ型
3.2.2.2 IDキーLCRのデモ
IDキーLCRを処理するサンプル・クライアント・アプリケーションを作成するデモが使用可能です。
具体的には、クライアント・アプリケーションでは、XStreamアウトバウンド・サーバーに連結して、アウトバウンド・サーバーからのLCRを待機します。クライアント・アプリケーションでIDキーLCRを受信すると、IDキーLCRのROWIDを使用して、適切なソース・データベース表を問い合せることができます。
このデモは、OCIとJavaの両方のコードで使用可能であり、次の場所にあります。
$ORACLE_HOME/rdbms/demo/xstream/idkey
親トピック: 取得プロセスで取得されるデータ型
3.2.3 取得プロセスによって取得されるDML変更のタイプ
取得プロセスでは、様々なタイプのDML変更を取得できます。
特定の表に対して行われたDML変更が取得されるように指定した場合、取得プロセスでは、これらの表に対して行われた次のタイプのDML変更が取得されます。
-
INSERT
-
UPDATE
-
DELETE
-
MERGE
-
ピース単位の操作
取得プロセスによって、MERGE
の変更がそれぞれINSERT
またはUPDATE
の変更に変換されます。MERGE
は、行LCRでは無効なコマンド・タイプです。
親トピック: 取得プロセス
3.2.4 ローカル取得およびダウンストリーム取得
取得プロセスは、ソース・データベースでローカルに実行されるか、またはダウンストリーム・データベースで実行されるように構成できます。
単一のデータベースに、ローカルの変更を取得する1つ以上の取得プロセスおよびリモート・ソース・データベースの変更を取得する他の取得プロセスを含めることができます。つまり、単一のデータベースを構成することによって、ローカル取得およびダウンストリーム取得の両方を実行できます。
- ローカル取得
ローカル取得とは、ソース・データベースで取得プロセスが実行されることを意味します。 - ダウンストリーム取得
ダウンストリーム取得とは、ソース・データベース以外のデータベースで取得プロセスが実行されることを意味します。
親トピック: 取得プロセス
3.2.4.1 ローカル取得
ローカル取得とは、ソース・データベース上で取得プロセスが実行されることを意味します。
図3-1に、ローカル取得を使用するデータベースを示します。
- すべての変更取得アクションを実行するソース・データベース
ローカル取得では、取得アクションがソース・データベースで実行されます。 - ローカル取得の利点
ローカル取得にはいくつかの利点があります。
親トピック: ローカル取得およびダウンストリーム取得
3.2.4.1.1 ソース・データベースによるすべての変更取得アクションの実行
ローカル取得では、ソース・データベースで取得アクションが実行されます。
ローカル取得を構成すると、ソース・データベースで次のアクションが実行されます。
-
DBMS_CAPTURE_ADM.BUILD
プロシージャが実行され、データ・ディクショナリがREDOログに抽出(構築)されます。 -
ソース・データベースでのサプリメンタル・ロギングによって、REDOログに追加情報が記録されます。この情報は、取得された変更がXStreamクライアント・アプリケーションで処理されるときに必要な場合があります。サプリメンタル・ロギングの構成(必要な場合)を参照してください。
-
データベースで取得プロセスが初めて起動される場合、Oracle Databaseでは、REDOログ内の抽出されたデータ・ディクショナリ情報を使用して、LogMinerデータ・ディクショナリが作成されます。LogMinerデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリとは別のデータ・ディクショナリです。後続の取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。
-
取得プロセスで、LogMinerを使用してREDOログの変更がスキャンされます。
-
ルール・エンジンにより、1つ以上の取得プロセスのルール・セットのルールに基づいて変更が評価されます。
-
取得プロセスで、ルール・セットのルールを満たす変更がローカルの
ANYDATA
キューにエンキューされます。 -
取得された変更が他のデータベース上の1つ以上のアウトバウンド・サーバーと共有されている場合、1つ以上の伝播によって、これらの変更がソース・データベースから他のデータベースに伝播されます。
親トピック: ローカル取得
3.2.4.1.2 ローカル取得のメリット
ローカル取得には、いくつかの利点があります。
ローカル取得を使用するメリットは次のとおりです。
-
ダウンストリーム取得を使用する場合より、取得プロセスを簡単に構成および管理できます。ローカル取得を使用すると、ダウンストリーム・データベースにコピーされるようにREDOデータを構成する必要がなくなり、取得した変更が行われたデータベースでローカルに取得プロセスを管理できます。
-
ローカル取得プロセスでは、データベースによってオンラインREDOログの変更がアーカイブREDOログ・ファイルに書き込まれる前に、これらの変更をスキャンできます。アーカイブ・ログ・ダウンストリーム取得プロセスを使用すると、ダウンストリーム・データベースへのアーカイブREDOログ・ファイルのコピーは、ソース・データベースによる変更の書込みが終了した後に行われるため、ダウンストリーム・データベースへのREDOログ・ファイルのコピーには時間がかかります。ただし、リアルタイム・ダウンストリーム取得プロセスは、ソース・データベースから送信されたオンラインREDOログの変更を取得できます。
-
REDOデータがダウンストリーム・データベースにコピーされるわけではないため、ネットワークを介して送信されるデータの量が低減されます。取得されたLCRは、他のデータベースに伝播される場合でも、データベースに対する変更全体のサブセットであることがあり、伝播のルール・セットのルールを満たすLCRのみが伝播されます。
-
REDOデータにアクセスできるのはソース(ローカル)データベースのみのため、セキュリティを向上できます。たとえば、hrスキーマの変更のみを取得プロセスで取得する場合にローカル取得を使用すると、REDOログにアクセスし、hrスキーマに対する変更を取得プロセスのキューにエンキューできるのはソース・データベースのみです。一方、ダウンストリーム取得を使用すると、REDOデータがダウンストリーム・データベースにコピーされ、REDOデータに、特定のオブジェクトやスキーマに対する変更のみではなく、データベースに対するすべての変更が含まれます。
親トピック: ローカル取得
3.2.4.2 ダウンストリーム取得
ダウンストリーム取得とは、ソース・データベース以外のデータベース上で取得プロセスが実行されることを意味します。
構成可能なダウンストリーム取得には、リアルタイム・ダウンストリーム取得およびアーカイブ・ログ・ダウンストリーム取得の2つのタイプがあります。downstream_real_time_mine
取得プロセス・パラメータによって、ダウンストリーム取得プロセスでリアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれを実行するかが制御されます。ダウンストリーム・データベースには、1つのリアルタイム・ダウンストリーム取得プロセスと1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスが共存できます。ダウンストリーム取得では、ソース・データベースのREDOログ・ファイルがダウンストリーム・データベースで使用可能である必要があります。
ノート:
-
このマニュアルでは、「ダウンストリーム取得プロセス」とは、リアルタイム・ダウンストリーム取得プロセスとアーカイブ・ログ・ダウンストリーム取得プロセスの両方のことを示します。必要に応じて、これら2つのタイプのダウンストリーム取得プロセスを区別しています。
-
ダウンストリーム取得プロセスでは、単一のソース・データベースからの変更のみを取得できます。ただし、単一のダウンストリーム・データベースで複数のダウンストリーム取得プロセスを使用すると、単一のソース・データベースまたは複数のソース・データベースから変更を取得することができます。
-
XStream Outのダウンストリーム取得を構成するには、ソース・データベースがOracle Database 10gリリース2 (10.2)以降である必要があり、取得データベースがOracle Database 11gリリース2 (11.2.0.3)以降である必要があります。
- リアルタイム・ダウンストリーム取得
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。 - アーカイブ・ログ・ダウンストリーム取得
リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、1つのダウンストリーム・データベースで複数のソース・データベースからダウンストリーム取得プロセスを実行できるというメリットがあります。 - 変更取得アクションのほとんどを実行するダウンストリーム・データベース
ダウンストリーム取得では、ほとんどの取得アクションがダウンストリーム・データベースで実行されます。 - ダウンストリーム取得の利点
ダウンストリーム取得にはいくつかの利点があります。 - ダウンストリーム・データベースからソース・データベースへのオプションのデータベース・リンク
ダウンストリーム取得プロセスを作成または変更する際に、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用するように指定できます。 - XStream Outでのダウンストリーム取得の操作要件
ダウンストリーム取得には、いくつかの操作要件があります。
親トピック: ローカル取得およびダウンストリーム取得
3.2.4.2.1 リアルタイム・ダウンストリーム取得
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。
リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。
リアルタイム・ダウンストリーム取得構成は、次のように機能します。
-
REDO転送サービスがREDOデータをダウンストリーム・データベースに同期または非同期に送信します。同時に、ログ・ライター・プロセス(LGWR)は、REDOデータをソース・データベースのオンラインREDOログに記録します。
-
ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)が、ネットワークを介してREDOデータを受信し、スタンバイREDOログにREDOデータを格納します。
-
ソース・データベースでログ・スイッチが発生すると、ダウンストリーム・データベースでもログ・スイッチが発生し、ダウンストリーム・データベースの
ARCH
n
プロセスによって、現行のスタンバイREDOログ・ファイルがアーカイブされます。 -
リアルタイム・ダウンストリーム取得プロセスは、可能な場合は常にスタンバイREDOログからの変更を取得し、必要に応じてアーカイブ済スタンバイREDOログ・ファイルからの変更を取得します。取得プロセスは、遅延が発生すると、アーカイブ済スタンバイREDOログ・ファイルの変更を取得できるようになります。遅延が解消されたら、スタンバイREDOログからの変更の取得を再開します。
ノート:
同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。
親トピック: ダウンストリーム取得
3.2.4.2.2 アーカイブ・ログ・ダウンストリーム取得
リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、1つのダウンストリーム・データベースで複数のソース・データベースからダウンストリーム取得プロセスを実行できるというメリットがあります。
アーカイブ・ログ・ダウンストリーム取得構成では、ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイルの変更が取得されます。アーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーするには、REDO転送サービス、DBMS_FILE_TRANSFER
パッケージ、ファイル転送プロトコル(FTP)などのメカニズムを使用します。
REDOログ・ファイルを複数のソース・データベースから単一のダウンストリーム・データベースにコピーし、それらのREDOログ・ファイル内の変更を複数のアーカイブ・ログ・ダウンストリーム取得プロセスで取得するように構成できます。
関連項目:
REDO転送サービスの詳細は、Oracle Data Guard概要および管理を参照
親トピック: ダウンストリーム取得
3.2.4.2.3 ダウンストリーム・データベースによるほとんどの変更取得アクションの実行
ダウンストリーム取得では、ダウンストリーム・データベースでほとんどの取得アクションが実行されます。
リアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれかを構成すると、ダウンストリーム・データベースで次のアクションが実行されます。
-
ダウンストリーム・データベースでダウンストリーム取得プロセスが初めて起動される場合、Oracle Databaseでは、ソース・データベースのREDOデータのデータ・ディクショナリ情報を使用して、ダウンストリーム・データベースにLogMinerデータ・ディクショナリが作成されます。ソース・データベースで
DBMS_CAPTURE_ADM.BUILD
プロシージャが実行され、ソース・データベースのREDOログにソース・データ・ディクショナリ情報が抽出されます。次に、REDOデータがソース・データベースからダウンストリーム・データベースにコピーされます。同じソース・データベースに対する後続のダウンストリーム取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。また、リアルタイム・ダウンストリーム取得プロセスでは、1つのLogMinerデータ・ディクショナリを1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスと共有できます。 -
取得プロセスで、LogMinerを使用してソース・データベースのREDOデータの変更がスキャンされます。
-
ルール・エンジンでは、1つ以上の取得プロセス・ルール・セットに含まれるルールに基づいて変更が評価されます。
-
取得プロセスで、ルール・セットのルールを満たす変更がローカルの
ANYDATA
キューにエンキューされます。この変更は、取得プロセスによってLCRにフォーマットされます。
ダウンストリーム取得を構成すると、ソース・データベースで次のアクションが実行されます。
-
ソース・データベースで
DBMS_CAPTURE_ADM.BUILD
プロシージャが実行され、データ・ディクショナリがREDOログに抽出されます。 -
ソース・データベースでのサプリメンタル・ロギングによって、適用に必要となる可能性がある追加情報がREDOログに記録されます。必要な場合のサプリメンタル・ロギングの構成を参照してください。
また、ソース・データベースを実行しているコンピュータ・システムから、ダウンストリーム・データベースを実行しているコンピュータ・システムにREDOデータをコピーする必要があります。リアルタイム・ダウンストリーム取得構成では、REDO転送サービスがREDOデータをダウンストリーム・データベースに送信します。通常、アーカイブ・ログ・ダウンストリーム取得構成では、REDO転送サービスがアーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーします。
親トピック: ダウンストリーム取得
3.2.4.2.4 ダウンストリーム取得のメリット
ダウンストリーム取得には、いくつかの利点があります。
ダウンストリーム取得を使用するメリットは次のとおりです。
-
必要なほとんどの作業がダウンストリーム・データベースで実行されるため、ソース・データベースで、変更の取得に使用されるリソースが少なくなります。
-
複数のソース・データベースで行われた変更を取得する場合、複数のソース・データベースに対する複数のアーカイブ・ログ・ダウンストリーム取得プロセスを1つのダウンストリーム・データベースで実行することによって、取得プロセスを簡単に管理できます。つまり、1つのダウンストリーム・データベースが、複数のソースからの変更を取得するための中心の場所として機能します。このような構成では、アーカイブ・ログ・ダウンストリーム取得プロセスに加えて、1つのリアルタイム・ダウンストリーム取得プロセスもダウンストリーム・データベースで実行できます。
-
REDOデータを1つ以上のダウンストリーム・データベースにコピーすることによって、データ損失に対する保護が強化されます。たとえば、状況によっては、ダウンストリーム・データベースのREDOログ・ファイルをソース・データベースのリカバリに使用できます。
-
1つ以上のダウンストリーム・データベースに、単一のソース・データベースから変更を取得する複数の取得プロセスを構成できるため、柔軟性およびスケーラビリティが向上します。
親トピック: ダウンストリーム取得
3.2.4.2.5 ダウンストリーム・データベースからソース・データベースへのオプションのデータベース・リンク
ダウンストリーム取得プロセスを作成または変更する場合は、オプションで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが使用されるように指定できます。
このデータベース・リンクには、ソース・データベースのグローバル名と同じ名前を付ける必要があります。このようなデータベース・リンクを使用すると、ダウンストリーム取得プロセスを簡単に作成および管理できます。ダウンストリーム取得プロセスでデータベース・リンクが使用されるように指定するには、ダウンストリーム取得プロセスでCREATE_CAPTURE
またはALTER_CAPTURE
プロシージャを実行する際に、use_database_link
パラメータをTRUE
に設定します。データベース・リンクの名前は、ソース・データベースのグローバル名と一致している必要があります。
ダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクを使用すると、取得プロセスがソース・データベースに接続され、次の管理アクションが自動的に実行されます。
-
特定の状況では、ソース・データベースで
DBMS_CAPTURE_ADM.BUILD
プロシージャが実行され、取得プロセスの作成時にソース・データベースのデータ・ディクショナリがREDOログに抽出されます。 -
取得プロセスの作成時に先頭システム変更番号(SCN)を指定しなかった場合は、ダウンストリーム取得プロセスの先頭SCNが取得されます。取得プロセスを作成するには、先頭SCNが必要です。
ダウンストリーム取得プロセスでデータベース・リンクを使用していない場合は、これらのアクションを手動で実行する必要があります。
ノート:
ダウンストリーム取得プロセスの作成時、CREATE_CAPTURE
プロシージャのfirst_scn
パラメータがNULL
に設定されている場合は、use_database_linkパラメータをTRUE
に設定する必要があります。そうでない場合は、エラーが発生します。
親トピック: ダウンストリーム取得
3.2.4.2.6 XStream Outでのダウンストリーム取得の操作要件
いくつかの操作上の要件がダウンストリーム取得に適用されます。
ダウンストリーム取得を使用する場合の操作要件は次のとおりです。
-
ソース・データベースでOracle Database 10gリリース2 (10.2)以上を実行している必要があります。
-
XStream Outダウンストリーム取得データベースでOracle Database 11gリリース2 (11.2.0.3)以降を実行している必要があります。また、ソース・データベースでOracle Database 10gリリース2 (10.2)以降を実行している必要があります。
-
ソース・サイトおよびダウンストリーム取得サイトのオペレーティング・システムは同じである必要があります。ただし、オペレーティング・システムのリリースが同じである必要はありません。また、ダウンストリーム・サイトでは、ソース・サイトと異なるディレクトリ構造を使用できます。
-
ソース・サイトおよびダウンストリーム取得サイトのハードウェア・アーキテクチャが同じである必要があります。たとえば、ダウンストリーム取得構成では、ソース・データベースが64ビットのSunシステム上に構成されている場合、ダウンストリーム・データベースが64ビットのSunシステム上に構成されている必要があります。CPUの数、メモリー・サイズ、記憶域構成などのその他のハードウェア要素は、ソース・サイトとダウンストリーム・サイトで同じである必要はありません。
親トピック: ダウンストリーム取得
3.2.5 取得プロセスおよびRESTRICTED SESSION
制限付きセッションの有効化および無効化は、取得プロセスに影響します。
システム起動時にSTARTUP
RESTRICT
文を発行して制限付きセッションを有効にした場合、取得プロセスは、データベースの停止時に実行中であった場合でも、起動されません。ALTER
SYSTEM
文を使用して制限付きセッションを無効にすると、データベースの停止時に実行されたいた各取得プロセスが起動されます。
SQL文ALTER
SYSTEM
のENABLE
RESTRICTED
SESSION
句によって実行中のデータベースで制限付きセッションを有効にしても、実行中の取得プロセスには影響がありません。これらの取得プロセスは引き続き実行され、変更の取得が行われます。停止している取得プロセスを制限付きセッションで起動しても、この取得プロセスは、制限付きセッションを無効にするまで実際には起動されません。
親トピック: 取得プロセス
3.2.6 取得プロセスのサブコンポーネント
取得プロセスのサブコンポーネントは、リーダー・サーバー、1つ以上のプリペアラ・サーバーおよびビルダー・サーバーです。
取得プロセスはオプションのOracleバックグラウンド・プロセスであり、プロセス名はCP
nn
(nn
は文字または数字)です。取得プロセスは、LogMinerのインフラストラクチャを使用してREDOログから変更を取得します。LogMinerは、XStreamによって自動的に構成されます。取得プロセスの作成、変更、起動、停止および削除を行うことができます。また、取得プロセスで取得される変更を制御する取得プロセスのルールを定義できます。
parallelism
取得プロセス・パラメータにより、取得プロセスの並列性が制御されます。取得プロセスの並列性が0(ゼロ、XStream Outのデフォルト)である場合は、取得プロセスでは、サブコンポーネントを使用してその作業を実行しません。かわりに、CP
nn
プロセスによって、データベース変更を取得するために必要なすべてのタスクが実行されます。
取得プロセスの並列性が0より大きい場合は、取得プロセスでは、基礎となるLogMinerプロセス名MS
nn
を使用します。ここで、nn
には文字および数字が含まれることがあります。取得プロセスの並列性が0(ゼロ)の場合、取得プロセスでは、このプロセスを使用しません。
取得プロセスの並列性が0を超えている場合、取得プロセスは、次のサブコンポーネントで構成されます。
-
1つのリーダー・サーバー。REDOログを読み取って複数の領域に分割します。
-
1つ以上のプリペアラ・サーバー。リーダー・サーバーによって定義された領域をパラレルでスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。事前フィルタ処理では、変更に関する部分的な情報(変更のスキーマ名やオブジェクト名など)が評価のためにルール・エンジンに送信され、評価の結果が受信されます。parallelism取得プロセス・パラメータを使用してプリペアラ・サーバーの数を制御できます。
-
1つのビルダー・サーバー。プリペアラ・サーバーからのREDOレコードをマージします。これらのREDOレコードには、部分評価の実行中に
TRUE
と評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号(SCN)の順序を保持し、マージされたREDOログ・レコードを取得プロセスに渡します。 -
取得プロセス(
CP
nn
)。マージされたREDOレコードをビルダー・サーバーから受信すると、各変更に対して次のアクションを実行します。-
変更をLCR形式でフォーマットします
-
プリペアラ・サーバーによって実行された部分評価で、LCRの変更に対する結果が生成されていない場合は、LCRを完全評価のためにルール・エンジンに送信します。
-
LCRの完全評価が実行された場合は、その結果を受信します
-
LCRが取得プロセスのネガティブ・ルール・セットのルールを満たすか、ポジティブ・ルール・セットのルールを満たさない場合は、LCRを廃棄します。
-
LCRが取得プロセスのポジティブ・ルール・セット内のルールを満たしている場合、LCRが取得プロセスに関連付けられているキューにエンキューされます。
-
リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーはそれぞれが1つのプロセスである。
親トピック: 取得プロセス
3.2.7 取得プロセスの状態
取得プロセスの状態は、取得プロセスが現在行っている処理を示します。
取得プロセスの状態は、V$XSTREAM_CAPTURE
動的パフォーマンス・ビューのSTATE
列を問い合せることによって表示できます。
関連項目:
親トピック: 取得プロセス
3.2.8 取得プロセス・パラメータ
取得プロセス・パラメータによって、取得プロセスの動作が制御されます。
たとえば、parallelism取得プロセス・パラメータによって、取得プロセスで使用されるプリペアラ・サーバーの数が制御され、time_limit
取得プロセス・パラメータによって、取得プロセスが自動的に停止されるまでの実行時間が指定されます。DBMS_CAPTURE_ADM.SET_PARAMETER
プロシージャを使用して取得プロセス・パラメータを設定します。作成後の取得プロセスは、最初に起動する前に環境に合わせて取得プロセス・パラメータを設定できるように無効になっています。
親トピック: 取得プロセス
3.2.9 取得プロセスのチェックポイントおよびXStream Out
チェックポイントは、取得プロセスの現在の状態に関する情報です。この情報は、取得プロセスを実行しているデータベースのデータ・ディクショナリに永続的に格納されます。
取得プロセスでは、チェックポイント間隔と呼ばれる定期的な間隔でチェックポイントの記録が試行されます。
- 必須チェックポイントSCN
取得プロセスでREDOデータが必要となる最小のチェックポイントに対応するシステム変更番号(SCN)は、必須チェックポイントSCNと呼ばれます。 - 最大チェックポイントSCN
取得プロセスで記録された最後の物理チェックポイントに対応するSCNは、最大チェックポイントSCNと呼ばれます。 - チェックポイント保存時間
チェックポイント保存時間とは、チェックポイントが自動的に消去されるまで取得プロセスによって保持される時間(日数)です。
親トピック: 取得プロセス
3.2.9.1 必須チェックポイントSCN
取得プロセスでREDOデータが必要となる最小のチェックポイントに対応するシステム変更番号(SCN)は、必須チェックポイントSCNと呼ばれます。
必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが、取得プロセスで使用可能である必要があります。取得プロセスを停止して再起動すると、REDOログのスキャンは、必須チェックポイントSCNに対応するSCNから開始されます。必須チェックポイントSCNは、データベースが予期せず停止した場合のリカバリで重要となります。また、取得プロセス用に先頭SCNをリセットする場合は、取得プロセスの必須チェックポイントSCN以下の値に設定する必要があります。取得プロセスの必須チェックポイントSCNを確認するには、ALL_CAPTURE
データ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN
列を問い合せます。
Parent topic: 取得プロセスのチェックポイントおよびXStream Out
3.2.9.2 最大チェックポイントSCN
取得プロセスによって記録された最後のチェックポイントに対応するSCNは、最大チェックポイントSCNと呼ばれます。
最大チェックポイントSCNは、取得プロセスの必須チェックポイントSCNより小さいことも大きいこともあります。取得プロセスが新規であり、物理的なチェックポイントがまだ記録されていない場合、最大チェックポイントSCNは0(ゼロ)のこともあります。
Parent topic: 取得プロセスのチェックポイントおよびXStream Out
3.2.9.3 チェックポイント保存時間
チェックポイント保存時間とは、チェックポイントが自動的に消去されるまで取得プロセスによって保持される時間(日数)のことです。
取得プロセスでは、取得プロセスの必須チェックポイントSCNが含まれているアーカイブREDOログ・ファイルのFIRST_TIME
から、チェックポイントに対応するアーカイブREDOログ・ファイルのNEXT_TIME
を差し引くことによって、チェックポイントの経過時間が定期的に計算されます。計算された値がチェックポイント保存時間より大きい場合、先頭SCN値を進めることによってチェックポイントが自動的に消去されます。計算された値がチェックポイント保存時間より小さい場合、チェックポイントは保持されます。
DBMS_CAPTURE_ADM
パッケージのALTER_CAPTURE
プロシージャを使用して、取得プロセスのチェックポイント保存時間を設定できます。DBA_REGISTERED_ARCHIVED_LOG
ビューにはアーカイブREDOログ・ファイルのFIRST_TIME
およびNEXT_TIME
が表示され、ALL_CAPTURE
ビューのREQUIRED_CHECKPOINT_SCN
列には取得プロセスの必須チェックポイントSCNが表示されます。
Parent topic: 取得プロセスのチェックポイントおよびXStream Out
3.2.10 取得プロセスに関連するSCN値
特定のシステム変更番号(SCN)値は、取得プロセスにとって重要です。
1つ以上の取得プロセスのシステム変更番号を表示するには、ALL_CAPTURE
データ・ディクショナリ・ビューを問い合せます。
- 取得済SCNと適用済SCN
取得済SCNは、取得プロセスでスキャンされたREDOログの最新の変更に対応するSCNです。取得プロセスの適用済SCNは、関連するアウトバウンド・サーバーで最後に処理されたLCRのSCNです。 - 先頭SCNと開始SCN
取得プロセスでは先頭SCNと開始SCNが重要です。
親トピック: 取得プロセス
3.2.10.1 取得済SCNおよび適用済SCN
取得済SCNは、取得プロセスによってスキャンされたREDOログの最新の変更に対応するSCNです。取得プロセスの適用済SCNは、関連するアウトバウンド・サーバーによって最後に処理されたLCRのSCNです。
適用済SCNより小さいすべてのLCRは、取得プロセスによって取得された変更を処理するすべてのアウトバウンド・サーバーで処理されています。取得プロセスの適用済SCNは、取得プロセスで取得された変更を処理するアウトバウンド・サーバーの最低水位標SCNと等価です。
親トピック: 取得プロセスに関連するSCN値
3.2.10.2 先頭SCNおよび開始SCN
取得プロセスでは先頭SCNと開始SCNが重要です。
- 先頭SCN
先頭SCNは、取得プロセスで変更を取得できる、REDOログ内の最小SCNです。 - 開始SCN
開始SCNは、取得プロセスで変更の取得を開始するSCNです。 - 先頭SCN以上であることが必要な開始SCN
取得プロセスの作成時または変更時に開始SCNを指定する場合は、取得プロセスの先頭SCN以上のSCNを指定する必要があります。
親トピック: 取得プロセスに関連するSCN値
3.2.10.2.1 先頭SCN
先頭SCNは、取得プロセスで変更を取得できる、REDOログ内の最小SCNです。
取得プロセスの作成時に先頭SCNを指定する場合、データベースは、指定したSCN以上のREDOデータにアクセスできる必要があります。
DBMS_CAPTURE_ADM.BUILD
プロシージャは、ソース・データベースのデータ・ディクショナリをREDOログに抽出します。取得プロセスを作成する際、REDOログのこのデータ・ディクショナリ・ビルドに対応する先頭SCNを指定できます。特に、作成中の取得プロセスの先頭SCNは、次の問合せで返される任意の値に設定できます。
COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999 COLUMN NAME HEADING 'Log File Name' FORMAT A50 SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES';
NAME
列に対して返される値は、先頭SCNに相当するSCNが含まれるREDOログ・ファイルの名前です。このREDOログ・ファイルおよびすべての後続のREDOログ・ファイルは、取得プロセスで使用可能であることが必要です。この問合せでFIRST_CHANGE#
に対して複数の異なる値が返される場合、DBMS_CAPTURE_ADM.BUILD
プロシージャがソース・データベースに対して2回以上実行されています。この場合、作成する取得プロセスに最も適した先頭SCN値を選択します。
場合によっては、取得プロセスの作成時に、DBMS_CAPTURE_ADM.BUILD
プロシージャが自動的に実行されます。このとき、取得プロセスの先頭SCNは、このデータ・ディクショナリ・ビルドに対応します。
親トピック: 先頭SCNおよび開始SCN
3.2.10.2.2 開始SCN
開始SCNは、取得プロセスが変更の取得を開始するSCNです。
開始SCNは、取得プロセスが変更の取得を開始するSCNです。取得プロセスの作成時に先頭SCNとは別に開始SCNを指定するか、または取得プロセスを変更して開始SCNを設定できます。取得プロセスの通常の操作については開始SCNを変更する必要はありません。取得プロセスから変更を受け取るいずれかの接続先データベースでPoint-in-Timeリカバリを実行する必要がある場合、通常は取得プロセスの開始SCNをリセットします。このような場合は、取得プロセスを使用して、Point-in-Timeリカバリの後にソース・データベースで行われた変更を取得することができます。
ノート:
開始SCNを設定する前に、既存の取得プロセスを停止する必要があります。
親トピック: 先頭SCNおよび開始SCN
3.2.10.2.3 開始SCNが先頭SCN以上である必要性
取得プロセスの作成または変更時に開始SCNを指定する場合、指定する開始SCNは、取得プロセスの先頭SCN以上である必要があります。
取得プロセスでは、REDOログ・レコードが開始SCNより小さいSCN値を含む場合でも、先頭SCNより大きいSCN値を含む(スキャン済でない)REDOログ・レコードが常にスキャンされます。そのため、先頭SCNより大きい開始SCNを指定すると、取得プロセスは、開始SCNより小さい番号のSCNが含まれるために変更を取得できないREDOログ・レコードをスキャンする場合があります。
開始SCNより前のREDOログ・レコードのスキャンには時間がかかる場合があるため、可能であれば回避する必要があります。そのため、取得プロセスの作成時には、先頭SCNと開始SCNの差をできるかぎり小さくして、取得プロセスの初期起動時間を最小限に抑えることをお薦めします。
ノート:
取得プロセスを起動または再起動する場合、開始SCNよりFIRST_CHANGE#
値の小さいREDOログ・ファイルをスキャンする必要がある場合があります。取得プロセスがスキャンする前に必要なREDOログ・ファイルを削除すると、取得プロセスが強制終了されます。先頭SCN、開始SCNおよび必須チェックポイントSCNを判別するには、ALL_CAPTURE
データ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイントSCNが含まれるREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが必要です。
親トピック: 先頭SCNおよび開始SCN
3.3 アウトバウンド・サーバー
XStream Outでは、アウトバウンド・サーバーから、データベース変更をクライアント・アプリケーションに送信します。
- アウトバウンド・サーバーの概要
アウトバウンド・サーバーは、データベース変更をクライアント・アプリケーションに送信するオプションのOracleバックグラウンド・プロセスです。 - アウトバウンド・サーバーでサポートされているデータ型
アウトバウンド・サーバーでは、取得プロセスでサポートされているすべてのデータ型がサポートされます。 - アウトバウンド・サーバーの適用ユーザー
アウトバウンド・サーバーの適用ユーザーとは、アウトバウンド・サーバーの取得プロセスからLCRを受信するユーザーです。 - アウトバウンド・サーバーとRESTRICTED SESSION
制限付きセッションの有効化と無効化は、アウトバウンド・サーバーに影響します。 - アウトバウンド・サーバーのサブコンポーネント
アウトバウンド・サーバーは、リーダー・サーバー、コーディネータ・プロセスおよび適用サーバーで構成されます。 - アウトバウンド・サーバーに関する考慮事項
XStreamのアウトバウンド・サーバーにはいくつかの考慮事項があります。 - アウトバウンド・サーバーと適用パラメータ
適用パラメータは、アウトバウンド・サーバーの動作を制御します。
親トピック: XStream Outの概念
3.3.1 アウトバウンド・サーバーの概要
アウトバウンド・サーバーは、データベース変更をクライアント・アプリケーションに送信するオプションのOracleバックグラウンド・プロセスです。
具体的には、クライアント・アプリケーションがアウトバウンド・サーバーに連結し、LCRからデータベース変更を抽出できます。クライアント・アプリケーションは、OCIまたはJavaインタフェースを使用して、アウトバウンド・サーバーに連結します。
1つのクライアント・アプリケーションで複数のセッションを作成できます。各セッションは1つのアウトバウンド・サーバーにのみ連結でき、各アウトバウンド・サーバーは一度に1つのセッションのみを処理できます。ただし、クライアント・アプリケーションのセッションは、それぞれ異なるアウトバウンド・サーバーまたはインバウンド・サーバーに接続できます。
変更取得は、アウトバウンド・サーバーと同じデータベースまたは別のデータベースで実行できます。アウトバウンド・サーバーが含まれているものとは異なるデータベースで変更取得が実行された場合、伝播により、変更取得データベースからアウトバウンド・サーバー・データベースに変更が送信されます。ダウンストリーム取得も、ソース・データベースの負荷を軽減するためにサポートされているモードです。
アウトバウンド・サーバーとその取得プロセスの両方が有効である場合、データの変更は行LCRおよびDDL LCRにカプセル化され、アウトバウンド・サーバーに送信されます。アウトバウンド・サーバーでは、様々なフォーマット(OCIおよびJavaなど)でLCRを公開できます。クライアント・アプリケーションでアウトバウンド・サーバーから渡されたLCRを処理するか、ループを使用してアウトバウンド・サーバーからのLCRを待機できます。
アウトバウンド・サーバーでは、LOB、LONG
、LONG
RAW
、XMLType
のデータをクライアント・アプリケーションにチャンクで送信します。いくつかのチャンクは、LOB、LONG
、LONG
RAW
またはXMLType
データ型の単一の列値で構成されます。
図3-4は、アウトバウンド・サーバーの構成を示しています。
クライアント・アプリケーションは、必要に応じて、アウトバウンド・サーバーから連結解除できます。クライアント・アプリケーションが再接続されると、アウトバウンド・サーバーでは、連結解除されたときにクライアント・アプリケーションが対象としていた、LCRのストリーム内の位置が自動的に判別されます。アウトバウンド・サーバーでは、この時点からLCRの送信が開始されます。
関連項目:
取得プロセスの詳細は、取得プロセスを参照
親トピック: アウトバウンド・サーバー
3.3.2 アウトバウンド・サーバーでサポートされるデータ型
アウトバウンド・サーバーでは、取得プロセスでサポートされているすべてのデータ型がサポートされます。
アウトバウンド・サーバーでは、これらのデータ型の列に対する変更が含まれているLCRをXStreamクライアント・アプリケーションに送信できます。
関連項目:
親トピック: アウトバウンド・サーバー
3.3.3 アウトバウンド・サーバーの適用ユーザー
アウトバウンド・サーバーの適用ユーザーは、アウトバウンド・サーバーの取得プロセスからのLCRを受信するユーザーです。
アウトバウンド・サーバーの適用ユーザーは、アウトバウンド・サーバーの取得プロセスの取得ユーザーと一致する必要があります。
関連項目:
親トピック: アウトバウンド・サーバー
3.3.4 アウトバウンド・サーバーおよびRESTRICTED SESSION
制限付きセッションの有効化および無効化は、アウトバウンド・サーバーに影響します。
システム起動時にSTARTUP
RESTRICT
文を発行して制限付きセッションを有効にすると、アウトバウンド・サーバーは、データベースの停止時に実行中であった場合でも、起動されません。制限付きセッションを無効にした場合、停止されなかった各アウトバウンド・サーバーが起動されます。
SQL文ALTER
SYSTEM
ENABLE
RESTRICTED
SESSION
によって実行中のデータベースで制限付きセッションを有効にしても、実行中のアウトバウンド・サーバーには影響がありません。これらのアウトバウンド・サーバーは引き続き実行され、XStreamクライアント・アプリケーションにLCRを送信します。停止されたアウトバウンド・サーバーが制限付きセッションで起動された場合は、制限付きセッションが無効化されるまで、アウトバウンド・サーバーは実際に起動しません。
親トピック: アウトバウンド・サーバー
3.3.5 アウトバウンド・サーバーのサブコンポーネント
アウトバウンド・サーバーは、リーダー・サーバー、コーディネータ・プロセス、適用サーバーで構成されます。
-
リーダー・サーバー。アウトバウンド・サーバーの取得プロセスからのLCRを受信します。リーダー・サーバーは、LCR間の依存性を計算してLCRをトランザクションにアセンブルするプロセスです。その後、リーダー・サーバーは、アセンブルしたトランザクションをコーディネータ・プロセスに返します。
アウトバウンド・サーバーのリーダー・サーバーの状態は、
V$XSTREAM_APPLY_READER
動的パフォーマンス・ビューを問い合せることによって表示できます。 -
リーダー・サーバーからトランザクションを取得して適用サーバーに渡すコーディネータ・プロセス。コーディネータ・プロセス名は
AP
nn
(nn
は文字および数字)です。コーディネータ・プロセスはOracleバックグラウンド・プロセスです。コーディネータ・プロセスの状態は、
V$XSTREAM_APPLY_COORDINATOR
動的パフォーマンス・ビューを問い合せることによって表示できます。 -
適用サーバー。XStreamクライアント・アプリケーションにLCRを送信します。適用サーバーはプロセスです。適用サーバーでエラーが検出された場合は、
ALL_APPLY
ビューにエラーの情報が記録されます。アウトバウンド・サーバーの適用サーバーの状態は、
V$XSTREAM_APPLY_SERVER
動的パフォーマンス・ビューを問い合せることによって表示できます。
リーダー・サーバーおよび適用サーバー・プロセス名はAS
nn
であり、nn
には文字および数字を含めることができます。
関連項目:
-
V$XSTREAM_APPLY_READER
動的パフォーマンス・ビューの詳細は、Oracle Databaseリファレンスを参照 -
V$XSTREAM_APPLY_COORDINATOR
動的パフォーマンス・ビューの詳細は、Oracle Databaseリファレンスを参照 -
V$XSTREAM_APPLY_SERVER
動的パフォーマンス・ビューの詳細は、Oracle Databaseリファレンスを参照
親トピック: アウトバウンド・サーバー
3.3.6 アウトバウンド・サーバーの考慮事項
アウトバウンド・サーバーに関するいくつかの考慮事項があります。
アウトバウンド・サーバーに関する考慮事項は次のとおりです。
-
アウトバウンド・サーバーで処理されるLCRは、取得プロセスで取得されたLCRである必要があります。アウトバウンド・サーバーでは、アプリケーションによって作成されたLCRはサポートされません。
-
単一のアウトバウンド・サーバーは、単一のソース・データベースから取得したLCRのみを処理できます。ソース・データベースは、LCRにカプセル化された変更がREDOログで生成されたデータベースです。
-
取得プロセスによって取得された変更のソース・データベースは、それらの変更がアウトバウンド・サーバーによって処理されるには、10.2.0以上の互換性レベルになっている必要があります。
-
アウトバウンド・サーバーの取得プロセスは、Oracle Database 11gリリース2 (11.2)以降のデータベースで実行されている必要があります。
-
1つの取得プロセスでアウトバウンド・サーバーと適用プロセスの両方の変更を取得することはできません。ただし、1つの取得プロセスで、複数のアウトバウンド・サーバー用の変更を取得できます。
-
取得プロセスおよびストリームのアウトバウンド・サーバーが別のデータベースで実行されている場合、ストリームの自動分割およびマージが可能です。ただし、取得プロセスおよびストリームのアウトバウンド・サーバーが同一データベースで実行されている場合、ストリームの自動分割およびマージはできません。
-
アウトバウンド・サーバーのLCRは、処理されずに一定の期間バッファリングされたキューに入っている場合、トランザクション内のLCR数が多い場合、あるいはすべてのLCRを保持するための領域がメモリー内に十分にない場合、メモリーからハード・ディスクにオーバーフローできます。アウトバウンド・サーバーは、メモリーからオーバーフローするLCRが最小の場合に、最高のパフォーマンスを発揮します。
txn_age_spill_threshold
およびtxn_lcr_spill_threshold
適用パラメータを使用して、オーバーフローしたLCRに関するアウトバウンド・サーバーの動作を制御できます。 -
インスタンス化SCNは、アウトバウンド・サーバーによって処理されるデータベース・オブジェクトには不要です。インスタンス化SCNをデータベース・オブジェクトに対して設定すると、アウトバウンド・サーバーでは、インスタンス化SCN値より大きいSCN値を持つデータベース・オブジェクトのLCRのみが送信されます。データベース・オブジェクトにインスタンス化SCNセットが含まれない場合、アウトバウンド・サーバーでは、インスタンス化SCNのチェックがスキップされ、そのデータベース・オブジェクトのすべてのLCRが送信されます。いずれの場合も、アウトバウンド・サーバーでは、そのルール・セットを満たすLCRのみが送信されます。
関連項目:
適用パラメータの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照
親トピック: アウトバウンド・サーバー
3.3.7 アウトバウンド・サーバーおよび適用パラメータ
適用パラメータでは、アウトバウンド・サーバーの動作を制御します。
アウトバウンド・サーバーでは、次の適用パラメータを使用できます。
-
apply_sequence_nextval
-
disable_on_limit
-
grouptransops
-
ignore_transaction
-
max_sga_size
-
maximum_scn
-
startup_seconds
-
time_limit
-
trace_level
-
transaction_limit
-
txn_age_spill_threshold
-
txn_lcr_spill_threshold
-
write_alert_log
3.4 LCRの位置とXStream Out
XStream Outアウトバウンド・サーバーは、取得プロセスによって取得されたLCRをクライアント・アプリケーションにストリームします。LCRの位置により、トランザクション内のLCRのストリームにおける配置が識別されます。
- XStream Outでの位置に関連する追加のLCR属性
取得プロセスで取得されたLCRには、LCRの位置に関する追加情報が含まれています。 - XStream Outでの処理済最低位置と再起動性
処理済最低位置は、その位置より下ですべてのトランザクションがクライアント・アプリケーションによって処理されたことを示します。 - ストリーミング・ネットワーク送信
アウトバウンド・サーバーは、ネットワーク・レイテンシを最小限に抑えるために、時間ベースの確認応答を使用してクライアント・アプリケーションにLCRをストリームします。たとえば、アウトバウンド・サーバーは30秒ごとに確認応答を送信する場合があります。
関連項目:
親トピック: XStream Outの概念
3.4.1 XStream Outでの位置に関連する追加のLCR属性
取得プロセスによって取得されたLCRに、LCR位置に関連する追加情報があります。
取得プロセスによって取得されたLCRには、LCR位置に関連する次の追加の属性が含まれています。
-
scn_from_position
属性。LCRのSCNが含まれています。 -
commit_scn_from_position
属性。LCRが属するトランザクションのコミットSCNが含まれています。
ノート:
scn_from_position
およびcommit_scn_from_position
属性は、明示的に取得された行LCRでは存在しません。
3.4.2 XStream Outの処理済最低位置および再起動可能性
処理済最低位置は、その位置未満のすべてのトランザクションがクライアント・アプリケーションで処理された位置を示します。
アウトバウンド・サーバーまたはクライアント・アプリケーションが異常終了した場合、この2つの間の接続は自動的に切断されます。この場合、クライアント・アプリケーションでは、すべての未完了のトランザクションをロールバックする必要があります。
クライアント・アプリケーションでは、クライアント・アプリケーションまたはアウトバウンド・サーバー(あるいはその両方)の再起動後に適切にリカバリするには、処理済最低位置を保持する必要があります。処理済最低位置は、クライアント・アプリケーションでその値以下のすべてのLCRが処理されたことを示します。クライアント・アプリケーションでは、使用するトランザクションごとに処理済最低位置を更新できます。
クライアント・アプリケーションがアウトバウンド・サーバーに連結すると、処理済最低位置に関連する次の状態が発生する可能性があります。
-
クライアント・アプリケーションでは、アウトバウンド・サーバーの処理済最低位置以上の処理済最低位置をアウトバウンド・サーバーに渡すことができます。この場合、アウトバウンド・サーバーでは、クライアント・アプリケーションの処理済最低位置よりも大きい位置を持つ最初のLCRから、LCRのストリーミングを再開します。
-
クライアント・アプリケーションでは、アウトバウンド・サーバーの処理済最低位置未満の処理済最低位置をアウトバウンド・サーバーに渡すことができます。この場合、アウトバウンド・サーバーでエラーが発生します。
-
クライアント・アプリケーションでは、
NULL
をアウトバウンド・サーバーに渡すことができます。この場合、アウトバウンド・サーバーでは、処理済最低位置が自動的に判別され、その処理済最低位置よりも大きい位置を持つLCRから、LCRのストリーミングが開始されます。これが発生した場合、クライアント・アプリケーションでは、クライアント・アプリケーションの処理済最低位置以下の位置を持つ各LCRを抑制または破棄する必要があります。
関連項目:
親トピック: LCRの位置とXStream Out
3.4.3 ネットワーク伝達ストリーム
ネットワーク待機時間を最小にするために、アウトバウンド・サーバーでは、時間ベースの確認を使用してクライアント・アプリケーションにLCRをストリームします。たとえば、アウトバウンド・サーバーでは30秒ごとに確認を送信することがあります。
このストリーミング・プロトコルでは、使用可能なネットワーク帯域幅を完全に利用します。パフォーマンスは、送信者と受信者を分離するWide Area Network(WAN)の存在による影響を受けません。アウトバウンド・サーバーにより、基盤のOracle Replicationインフラストラクチャが拡張されます。アウトバウンド・サーバーでは、ストリーミング・パフォーマンス・レートが維持されます。
OCIを使用する場合、OCIクライアント・アプリケーションを介してOCI_ATTR_XSTREAM_ACK_INTERVAL
属性を設定することで、間隔の期間を制御できます。デフォルトは30秒です。
Javaを使用する場合、XStreamOut
クラスのattach
メソッドでbatchInterval
パラメータを設定することで、間隔の期間を制御できます。クライアント・アプリケーションでは、attach
メソッドを呼び出す際に、この間隔を指定できます。
間隔が大きい場合、アウトバウンド・サーバーでは各確認間隔に、より多くのLCRをストリーム・アウトできます。ただし、間隔が長くなると、クライアント・アプリケーションからアウトバウンド・サーバーに処理済最低位置を送信できる頻度が低くなります。そのため、間隔が長いと、アウトバウンド・サーバーで保持されている処理済最低位置が最新のものではない可能性があります。この場合、アウトバウンド・サーバーの再起動時に、クライアント・アプリケーションで保持されている処理済最低位置に対応するLCRよりも前の位置にあるLCRの処理を開始する必要があります。このため、より多くのLCRが再送信される可能性があり、クライアント・アプリケーションでは適用済のLCRを破棄する必要があります。
親トピック: LCRの位置とXStream Out
3.5 XStream Outおよび分散トランザクション
XStream Outと分散トランザクションの考慮事項を示します。
次のいずれかの方法を使用して分散トランザクションを実行できます。
-
データベース・リンクを使用した調整方法により複数のデータベース内の表を変更します。
-
DBMS_XA
提供のPL/SQLパッケージ、あるいはOCIまたはJDBCライブラリによって公開されているXAインタフェースを使用します。XAインタフェースによって、X/Open分散トランザクション処理(DTP)アーキテクチャが実装されます。
XStream Out構成では、前述の方法のいずれかを使用して分散トランザクション中にソース・データベースに加えられた変更は、XStreamアウトバウンド・サーバーにストリームされます。アウトバウンド・サーバーでは、トランザクションのコミット後、トランザクション内の変更をXStreamクライアント・アプリケーションに送信します。
ただし、分散トランザクションの状態はレプリケートも送信もされません。クライアント・アプリケーションは、このようなトランザクションのインダウト状態または準備済状態を継承しません。また、XStreamでは、ソース・データベースでXAトランザクションのために使用されるものと同じグローバル・トランザクション識別子を使用した変更はレプリケートも送信もしません。
XAトランザクションは次の2つの方法で実行できます。
-
密結合(異なるXAブランチがロックを共有する)
-
疎結合(異なるXAブランチがロックを共有しない)
XStreamでは、疎結合のXAブランチによって行われる変更のレプリケーションは、COMPATIBLE
初期化パラメータの値に関係なくサポートされます。XStreamでは、Oracle RACソース・データベースで密結合のブランチによって行われる変更のレプリケーションについては、COMPATIBLE
初期化パラメータが11.2.0.0
以上に設定されている場合にのみサポートされます。
関連項目:
-
分散トランザクションの詳細は、Oracle Database管理者ガイドを参照
-
Oracle XAの詳細は、Oracle Database開発ガイドを参照
親トピック: XStream Outの概念
3.6 XStream Outとセキュリティ
クライアント・アプリケーションおよびXStreamコンポーネントに関連するセキュリティに加え、取得ユーザーおよび接続ユーザーに必要な権限について理解します。
- XStream Outのクライアント・アプリケーションとセキュリティ
XStream Outではクライアント・アプリケーションにLCRの受信を許可しているため、クライアント・アプリケーションのセキュリティについて考慮する必要があります。 - XStream Outのコンポーネントレベルのセキュリティ
XStream Out構成のコンポーネントはいずれも、同じXStream管理者として実行されます。このユーザーは、権限レベルの高い信頼できるユーザーの場合もあれば、特定のタスクの実行に必要な権限のみを持つ信頼できないユーザーの場合もあります。 - 取得プロセスの取得ユーザーに必要な権限
変更は、取得プロセスの取得ユーザーのセキュリティ・ドメイン内で取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。取得ユーザーは、これらのアクションの実行に必要な権限を持っている必要があります。 - アウトバウンド・サーバーの接続ユーザーに必要な権限
アウトバウンド・サーバーは、その接続ユーザーのセキュリティ・ドメイン内でXStreamクライアント・アプリケーションにLCRを送信します。
親トピック: XStream Outの概念
3.6.1 XStream Outクライアント・アプリケーションおよびセキュリティ
XStream Outではクライアント・アプリケーションでLCRを受信できるため、クライアント・アプリケーションのセキュリティの考慮事項があります。
XStream Outアプリケーションでは、LCRを受信した後、LCRのコンテンツをファイルに保存するか、SQL文を生成してOracle以外のデータベース上でLCRを実行できます。
JavaおよびOCIクライアント・アプリケーションでは、Oracleデータベースで作成されたXStreamアウトバウンド・サーバーに連結する前に、Oracleデータベースに接続する必要があります。接続ユーザーはアウトバウンド・サーバー用に構成されたconnect_user
と同じである必要があります。そうでない場合は、エラーが発生します。XStreamでは、アウトバウンド・サーバーへの接続ユーザーが信頼できると想定されません。
XStreamOut
クラスのXStream attach
メソッドでクライアント・アプリケーションによって作成されたOracle JDBC接続インスタンスをXStreamで受け入れるため、XStream JavaレイヤーAPIは、Oracle JDBCセキュリティに依存しています。接続したユーザーはXStreamユーザーとして検証されます。
関連項目:
-
XStreamのOCIインタフェースの詳細は、Oracle Call Interfaceプログラマーズ・ガイドを参照
-
XStreamのJavaインタフェースの詳細は、Oracle Database XStream Java APIリファレンスを参照
親トピック: XStream Outとセキュリティ
3.6.2 XStream Outのコンポーネント・レベルのセキュリティ
XStream Out構成のすべてのコンポーネントは同じXStream管理者として実行されます。このユーザーは高いレベルの権限を備えた信頼できるユーザーにすることも、特定のタスクの実行に必要な権限のみを備えた信頼されないユーザーにすることもできます。
XStream管理者のセキュリティ・モデルでは、このユーザーがXStream構成を監視するために問合せ可能なデータ・ディクショナリ・ビューも決定します。信頼できる管理者はDBA_
ビューでXStreamを監視できます。信頼されない管理者はALL_
ビューでXStreamを監視できます。
DBMS_XSTREAM_AUTH
パッケージのGRANT_ADMIN_PRIVILEGE
プロシージャを使用してXStream管理者を作成します。この手順を実行してXStream OutのXStream管理者を作成した場合、privilege_type
パラメータにより、ユーザーに付与される権限のタイプが決定されます。
-
XStream管理者がデータベースでXStream Out構成のみを管理する場合、
privilege_type
パラメータにCAPTURE
を指定します。 -
XStream管理者がデータベース上のXStream OutとXStream In構成の両方を管理する場合、
privilege_type
パラメータに*
を指定します。
GRANT_ADMIN_PRIVILEGE
プロシージャにより、XStream OutまたはXStream In構成のコンポーネントを実行するために必要な、Oracle提供のビューとパッケージに対する権限が付与されます。このプロシージャは、ユーザーが所有しているデータベース・オブジェクトに対する権限を付与しません。このような権限が必要な場合は、個別に付与する必要があります。
関連項目:
XStream管理者の構成の詳細は、すべてのデータベースでのXStream管理者の構成を参照
親トピック: XStream Outとセキュリティ
3.6.3 取得プロセスの取得ユーザーに必要な権限
変更は、取得プロセスの取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。取得ユーザーは、これらのアクションの実行に必要な権限を持っている必要があります。
取得ユーザーには次の権限が必要です。
-
取得プロセスで使用するルール・セットの
EXECUTE
権限 -
ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションの
EXECUTE
権限 -
LCRを取得プロセス・キューにエンキューする権限
1つの取得プロセスは1ユーザーにしか関連付けできませんが、1ユーザーは複数の取得プロセスに関連付けることができます。
GRANT_ADMIN_PRIVILEGE
プロシージャでprivilege_type
パラメータにCAPTURE
を指定することで、DBMS_XSTREAM_AUTH
パッケージで取得ユーザーに権限を付与します。
関連項目:
-
GRANT_ADMIN_PRIVILEGE
プロシージャの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照
親トピック: XStream Outとセキュリティ
3.6.4 アウトバウンド・サーバーの接続ユーザーに必要な権限
アウトバウンド・サーバーは接続ユーザーのセキュリティ・ドメイン内で、XStreamクライアント・アプリケーションにLCRを送信します。
接続ユーザーは、アウトバウンド・サーバーのルール・セットを満たしているLCRをXStreamクライアント・アプリケーションに送信します。また、接続ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベース変換をすべて実行します。
接続ユーザーには次の権限が必要です。
-
アウトバウンド・サーバーで使用されるルール・セットに対する
EXECUTE
権限 -
ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションの
EXECUTE
権限
アウトバウンド・サーバーは1人のユーザーにのみ関連付けることができますが、1人のユーザーを多数のアウトバウンド・サーバーに関連付けることができます。
関連項目:
-
XStreamの構成および管理のセキュリティ要件の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスの
DBMS_XSTREAM_ADM
パッケージの「セキュリティ・モデル」を参照 -
XStreamのOCIインタフェースの詳細は、Oracle Call Interfaceプログラマーズ・ガイドを参照
親トピック: XStream Outとセキュリティ
3.7 XStream Outと他のOracle Databaseコンポーネント
XStream Outは、他のOracle Databaseコンポーネントと連携して動作できます。
- XStream OutとOracle Real Application Clusters
XStream Outは、Oracle Real Application Clusters (Oracle RAC)と連携できます。 - XStream Outと透過的データ暗号化
XStream Outは、透過的データ暗号化と連携できます。 - XStream Outとフラッシュバック・データ・アーカイブ
XStream Outは、フラッシュバック・データ・アーカイブの表をサポートします。 - XStream OutとRecovery Manager
RMANの削除ポリシーが取得プロセスに影響する可能性があります。 - XStream Outと分散トランザクション
XStream Outは分散トランザクションをサポートします。 - XStream Outとマルチテナント環境
マルチテナント環境では、移植可能な一連のスキーマ、オブジェクト、および論理的に個別のデータベースとしてアプリケーションに表示される関連する構造をデータベースに含めることができます。
親トピック: XStream Outの概念
3.7.1 XStream OutおよびOracle Real Application Clusters
XStream OutはOracle Real Application Clusters (Oracle RAC)と連携して動作できます。
- 取得プロセスとOracle Real Application Clusters
取得プロセスは、Oracle Real Application Clusters (Oracle RAC)環境で変更を取得できます。 - キューとOracle Real Application Clusters
Oracle Real Application Clusters (Oracle RAC)環境でキューを構成できます。 - 伝播とOracle Real Application Clusters
伝播では、Oracle Real Application Clusters (Oracle RAC)環境のキュー間でLCRを伝播できます。あるインスタンスで実行されている伝播ジョブは、そのインスタンスが所有するすべてのキューから宛先キューに論理変更レコード(LCR)を伝播します。 - アウトバウンド・サーバーとOracle Real Application Clusters
DBMS_CAPTURE_ADM.SET_PARAMETER
プロシージャでuse_rac_service
をY
に設定した場合は、Oracle Real Application Clusters (Oracle RAC)環境でアウトバウンド・サーバーを構成できます。
3.7.1.1 取得プロセスおよびOracle Real Application Clusters
取得プロセスは、Oracle Real Application Clusters(Oracle RAC)環境での変更を取得できます。
同じ環境で1つ以上の取得プロセスとOracle RACを使用する場合は、取得プロセスによって取得される変更を含むすべてのアーカイブ・ログは、Oracle RAC環境のすべてのインスタンスで使用可能である必要があります。Oracle RAC環境では、取得プロセスによってすべてのインスタンスによる変更が読み取られます。同一取得プロセスを使用している複数のアウトバウンド・サーバー・プロセスは、取得プロセスと同一のOracle RACインスタンスで実行される必要があります。
プロシージャDBMS_CAPTURE_ADM.SET_PARAMETER
でパラメータuse_rac_service
をY
に設定することによって、取得プロセスがそのキューと同じOracle RACインスタンスで実行されるようにしてください。
取得プロセス・パラメータuse_rac_service
の値がY
に設定されている場合、各取得プロセスは、起動プロシージャまたは停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATA
キューの所有者インスタンスで起動および停止されます。また、現行の所有者インスタンスが使用不可能になった場合、取得プロセスは別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。
取得プロセス・パラメータuse_rac_service
の値がN
に設定されている場合、取得プロセスはクライアント・アプリケーションが接続するインスタンスで起動されます。取得プロセスの停止は、取得プロセスが開始されたのと同じインスタンスで実行する必要があります。
取得プロセスによって使用されるキューを含むキュー表の所有者インスタンスが使用不可能になった場合、キュー所有権がクラスタ内の別のインスタンスに自動的に移動します。さらに、所有者インスタンスが使用不可能になったときに取得プロセスが有効であった場合、取得プロセスは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用不可能になったときに取得プロセスが無効であった場合、取得プロセスは新しい所有者インスタンスでも無効のままです。
LogMinerではLOG_ARCHIVE_DEST_
n
初期化パラメータがサポートされており、取得プロセスでは、LogMinerを使用してREDOログから変更が取得されます。1つの宛先からアーカイブ・ログ・ファイルにアクセスできない場合は、ローカル取得プロセスで、アクセス可能な別の宛先からアーカイブ・ログ・ファイルを読み取ることができます。Oracle RACデータベースでは、この機能を使用して、インスタンス間アーカイブ(CIA)を使用することもできます。CIAでは、各インスタンスによってファイルがすべてのインスタンスにアーカイブされます。この方法では、アーカイブ・ログ・ファイルの欠落による差異を検出したり、解決することはできません。このため、この方法は、既存の方法を補完して、アーカイブ・ファイルをすべてのインスタンスで共有可能にする場合にのみ使用できます。
ダウンストリーム取得プロセス環境では、ソース・データベースは、単一インスタンス・データベースまたは複数インスタンスのOracle RACデータベースです。ダウンストリーム・データベースは、ソース・データベースが単一インスタンスか複数インスタンスかに関係なく、単一インスタンスのデータベースまたは複数インスタンスのOracle RACデータベースとして構成できます。
関連項目:
-
ALL_QUEUE_TABLES
データ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照 -
インスタンス間で共有されるアーカイブ・ログの構成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照
3.7.1.2 キューとOracle Real Application Clusters
Oracle Real Application Clusters (Oracle RAC)環境でキューを構成できます。
Oracle RAC環境では、キューのバッファを使用できるのは所有者インスタンスのみですが、別のインスタンスは、別のキューのバッファを使用できます。バッファ・キューは、キューに関連付けられたシステム・グローバル領域(SGA)メモリーです。
取得プロセス・パラメータuse_rac_service
をY
に設定し、キュー表の所有権、または特定のキュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスを指定します。
XStream Outのプロセスおよびジョブでは、キュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの指定がサポートされます。use_rac_service
がY
に設定されている場合は、キュー表の指定を使用でき、プライマリ・インスタンスが使用できなくなると、セカンダリ・インスタンスがキュー表の所有権を引き継ぎます。プライマリ・インスタンスが再び使用可能になると、キューの所有権がプライマリ・インスタンスに戻ります。
伝播で宛先キューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。宛先キューを含むキュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの両方が使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。この場合、プライマリ・インスタンスまたはセカンダリ・インスタンスが再度使用可能になると、所有権は使用可能になったインスタンスに戻ります。
プライマリ・インスタンスおよびセカンダリ・インスタンスの指定は、DBMS_AQADM
パッケージのALTER_QUEUE_TABLE
プロシージャを使用して設定できます。ALL_QUEUE_TABLES
データ・ディクショナリ・ビューには、キュー表の所有者インスタンスに関する情報が含まれています。キュー表は、複数のキューを含むことがあります。この場合、キュー表内の各キューはキュー表と同じ所有者インスタンスを持ちます。
ALL_QUEUES
データ・ディクショナリ・ビューのNETWORK_NAME
列には、キュー・サービスのネットワーク名が含まれています。キューのサービスは、いかなる方法でも管理しないでください。これらのサービスはOracleによって自動的に管理されます。
関連項目:
-
ALL_QUEUE_TABLES
データ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照 -
キューおよびOracle RACの詳細は、Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイドを参照
-
ALTER_QUEUE_TABLE
プロシージャの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照
3.7.1.3 伝播およびOracle Real Application Clusters
伝播により、Oracle Real Application Clusters (Oracle RAC)環境で、あるキューから別のキューにLCRを伝播できます。インスタンスで実行中の伝播ジョブにより、そのインスタンスが所有している任意のキューから宛先キューに論理変更レコード(LCR)が伝播されます。
この項の情報は、伝播を含むXStream構成のみに適用されます。通常のXStream構成では、アウトバウンド・サーバーとその取得プロセスは同じデータベース上で構成され、伝播は必要ありません。この項の情報は、伝播を含まない構成には適用されません。ただし、あるデータベース上に取得プロセス、別のデータベース上にアウトバウンド・サーバーを構成することも可能です。この場合、伝播により、取得プロセスのキューからアウトバウンド・サーバーのキューにLCRが送信されます。
Oracle RAC環境でLCRを伝播するには、その前にプロシージャDBMS_CAPTURE_ADM.SET_PARAMETER
のuse_rac_service
をY
に設定する必要があります。
Oracle RACデータベースへの伝播は、データベース・リンクを介して行われます。データベース・リンクは、LCRを受信予定のキューを所有している宛先インスタンスに接続するように構成する必要があります。
バッファ宛先キューへのキュー・ツー・キュー伝播は、サービスを使用してOracle RAC環境での透過的フェイルオーバーを提供します。つまり、キュー・ツー・キュー伝播の伝播ジョブは、宛先キューを所有するインスタンスに自動的に接続します。キュー・ツー・キュー伝播で使用されるサービスは、常に宛先キューの所有者インスタンスで実行されます。このサービスは、Oracle RACデータベース内のバッファ・キュー用にのみ作成されます。Oracle RACデータベースにバッファリングされたメッセージ機能を使用する予定の場合は、任意のインスタンスでLCRをバッファ・キューにエンキューできます。キューを所有していないインスタンスにLCRがエンキューされた場合、LCRは正しいインスタンスに送信されますが、キューを所有しているインスタンスにLCRをエンキューする方がより効率的です。このサービスを使用すると、LCRをバッファ・キューにエンキューする前にキューの所有者インスタンスに接続できます。
キュー・サービスはキューの所有者インスタンスで常に実行しているため、Oracle RACインスタンスが失敗すると、透過的フェイルオーバーが行われます。複数のキュー・ツー・キュー伝播が1つのデータベース・リンクを使用する場合、LCRを適切な宛先キューに伝播するように各伝播の接続記述が自動的に変わります。
ノート:
Oracle RAC環境でキューに取得LCRが含まれているか、今後含まれる場合、キュー・ツー・キュー伝播を使用してOracle RACの宛先データベースにLCRを伝播してください。
3.7.1.4 アウトバウンド・サーバーとOracle Real Application Clusters
プロシージャDBMS_CAPTURE_ADM.SET_PARAMETER
のuse_rac_service
をY
に設定した場合、Oracle Real Application Clusters (Oracle RAC)環境でアウトバウンド・サーバーを構成できます。
各アウトバウンド・サーバーは、起動プロシージャまたは停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATA
キューの所有者インスタンスで起動および停止されます。コーディネータ・プロセス、対応する適用リーダー・サーバーおよび適用サーバーは、単一インスタンスで実行されます。同一取得プロセスを使用している複数のXStream Outプロセスは、取得プロセスと同一のOracle RACインスタンスで実行される必要があります。
アウトバウンド・サーバーで使用されるキューが含まれているキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに譲渡されます。また、現行の所有者インスタンスが使用不可能になった場合、アウトバウンド・サーバーは、別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。さらに、所有者インスタンスが使用できなくなったときにアウトバウンド・サーバーが有効化されている場合、アウトバウンド・サーバーは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用できなくなったときにアウトバウンド・サーバーが無効になっていた場合、アウトバウンド・サーバーは新しい所有者インスタンスで無効のままです。
関連項目:
-
ALL_QUEUE_TABLES
データ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照
3.7.2 XStream Outおよび透過的データ暗号化
XStream Outは、透過的データ暗号化と連携して動作できます。
- 取得プロセスと透過的データ暗号化
取得プロセスでは、透過的データ暗号化を使用して暗号化された列に対する変更を取得できます。 - 伝播と透過的データ暗号化
伝播では、透過的データ暗号化を使用して暗号化された列に対する変更を含んでいる行論理変更レコード(行LCR)を伝播できます。 - アウトバウンド・サーバーと透過的データ暗号化
アウトバウンド・サーバーは、透過的データ暗号化を使用して暗号化された列を含む暗黙的に取得された行論理変更レコード(行LCR)を処理できます。
関連項目:
透過的データ暗号化の詳細は、Oracle Database Advanced Securityガイドを参照
3.7.2.1 取得プロセスおよび透過的データ暗号化
取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。
ローカル取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。ダウンストリーム取得プロセスでは、ダウンストリーム・データベースが暗号化キーストア(認証および署名証明書のコンテナ)をソース・データベースと共有している場合にのみ、暗号化されている列に対する変更を取得できます。キーストアは、ネットワーク・ファイル・システム(NFS)を介して共有するか、または1つのコンピュータ・システムから別のコンピュータ・システムに手動でコピーできます。キーストアがダウンストリーム・データベースと共有されている場合は、ダウンストリーム・データベースのsqlnet.ora
ファイルのENCRYPTION_WALLET_LOCATION
パラメータにキーストアの場所が指定されていることを確認してください。
ダウンストリーム・データベースにキーストアをコピーする場合は、ソース・データベースのキーストアが変更されるたびに、ソース・データベースからダウンストリーム・データベースにキーストアをコピーしてください。ダウンストリーム・データベースのキーストアに対して、レプリケートされた表の暗号化キーの変更などの操作は実行しないでください。
ローカル取得プロセスまたはダウンストリーム取得プロセスによって取得された行論理変更レコード(行LCR)内の暗号化された列は、行LCRがバッファ・キューにステージングされると復号化されます。
ノート:
取得プロセスによって使用されるREDOログが互換性レベル11.0.0以上のデータベースで生成されている場合、取得プロセスでは、暗号化された列のみがサポートされます。互換性レベルは、COMPATIBLE
初期化パラメータによって制御されます。
ノート:
SQLNET.ENCRYPTION_WALLET_LOCATION sqlnet.ora
パラメータはOracle Database 19cでは非推奨です。
SQLNET.ENCRYPTION_WALLET_LOCATION
パラメータは、透過的データ暗号化(TDE)のソフトウェア・キーストアの場所を定義します。ソフトウェア・キーストアの場所を構成するには、SQLNET.ENCRYPTION_WALLET_LOCATION
を設定するかわりに、WALLET_ROOT
初期化パラメータおよびTDE_CONFIGURATION
動的初期化パラメータを設定することをお薦めします。
関連項目:
親トピック: XStream Outおよび透過的データ暗号化
3.7.2.2 伝播と透過的データ暗号化
伝播では、透過的データ暗号化を使用して暗号化された列に対する変更を含む行論理変更レコード(行LCR)を伝播できます。
この項の情報は、伝播が組み込まれたXStream構成のみに該当します。標準のXStream構成では、アウトバウンド・サーバーとその取得プロセスが同じデータベース上で構成されるため、伝播は不要です。この項の情報は、伝播が組み込まれていない構成には該当しません。ただし、取得プロセスとアウトバウンド・サーバーが別々のデータベースで構成される可能性があります。この場合、伝播によって取得プロセスのキューからアウトバウンド・サーバーのキューにLCRが送信されます。
伝播によって、暗号化された列とともに行LCRが伝播されると、行LCRがネットワーク上を転送される間に、暗号化された列が復号化されます。必要に応じて、Oracle Advanced Securityの機能を使用して、ネットワーク上でのデータ転送を暗号化できます。
関連項目:
ネットワーク・データの暗号化の構成の詳細は、Oracle Databaseセキュリティ・ガイドを参照
親トピック: XStream Outおよび透過的データ暗号化
3.7.2.3 アウトバウンド・サーバーおよび透過的データ暗号化
アウトバウンド・サーバーでは、透過的データ暗号化を使用して暗号化された列を含む、暗黙的に取得された行論理変更レコード(行LCR)を処理できます。
暗号化された列は、それらの暗号化列を含む行LCRがアウトバウンド・サーバーによって処理されると復号化されます。復号化された列が含まれたこれらの行LCRが、XStreamクライアント・アプリケーションに送信されます。
暗号化された列を含む行LCRがバッファ・キューに格納されると、それらの列は復号化されます。行LCRがディスクにオーバーフローした場合、その行LCRがディスクに格納されている間、XStreamで暗号化された列が透過的に暗号化されます。
ノート:
XStream Outで列を透過的に暗号化するには、ローカル・データベース上のキーストアに暗号化のマスター・キーが格納されており、キーストアがオープンしている必要があります。次の文を実行すると、マスター・キーが設定され、キーストアがオープンします。
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY key-password; ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY key-password;
列が暗号化されているすべてのインスタンスで同じキーストアが使用可能でオープンしている必要があるため、必ず、キーストアをダウンストリーム取得データベースにコピーしてください。ダウンストリーム取得の場合は、ダウンストリーム・インスタンスで前述のコマンドを実行する必要もあります。
関連項目:
親トピック: XStream Outおよび透過的データ暗号化
3.7.3 XStream Outおよびフラッシュバック・データ・アーカイブ
XStream Outでは、フラッシュバック・データ・アーカイブ内の表がサポートされます。
取得プロセスは、これらの表に対して行われたデータ操作言語(DML)およびデータ定義言語(DDL)の変更を取得できます。アウトバウンド・サーバーでは、取得されたLCRを処理できます。
XStream Outでは次のDDL文もサポートされています。
-
CREATE
FLASHBACK
ARCHIVE
-
ALTER
FLASHBACK
ARCHIVE
-
DROP
FLASHBACK
ARCHIVE
-
FLASHBACK
ARCHIVE
句を指定したCREATE
TABLE
-
FLASHBACK
ARCHIVE
句を指定したALTER
TABLE
ノート:
XStream Outでは、フラッシュバック・データ・アーカイブによって使用される内部表に対する変更は取得されません。
関連項目:
-
フラッシュバック・データ・アーカイブの詳細は、Oracle Database開発ガイドを参照
3.7.4 XStream OutおよびRecovery Manager
RMANの削除方針は、取得プロセスに影響する可能性があります。
RMANの一部の削除ポリシーおよびコマンドでは、アーカイブREDOログ・ファイルが削除されます。RMANのこれらのポリシーまたはコマンドのいずれかを、1つ以上の取得プロセスに対してREDOログ・ファイルを生成するデータベースで使用する場合は、そのRMANのコマンドが取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しないことを確認してください。
- RMANとローカル取得プロセス
ローカル取得プロセスを構成した場合、高速リカバリ領域に余裕があるかぎり、RMANはローカル取得プロセスに必要なアーカイブREDOログ・ファイルを削除しません。 - RMANとダウンストリーム取得プロセス
ソース・データベースで行われたデータベース変更をダウンストリーム取得プロセスで取得する場合は、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム取得プロセス・データベースに移管されるまで、RMANの削除ポリシーまたはコマンドがそのアーカイブREDOログ・ファイルを削除しないことを確認してください。
関連項目:
-
取得プロセスで必要なアーカイブREDOログ・ファイルが欠落しているかどうかを確認する方法、およびこの問題を解決する方法の詳細は、取得プロセスで必要なREDOログ・ファイルがないを参照
-
RMANの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドおよびOracle Databaseバックアップおよびリカバリ・リファレンスを参照
3.7.4.1 RMANおよびローカル取得プロセス
ローカル取得プロセスが構成されるとき、高速リカバリ領域に余裕があれば、RMANはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。
具体的には、RMANは、ローカル取得プロセスの必須チェックポイントSCN以上のシステム変更番号(SCN)値の変更を含むアーカイブREDOログ・ファイルを削除しません。これは、RMANのすべての削除ポリシーおよびDELETE
コマンド(DELETE
ARCHIVELOG
およびDELETE
OBSOLETE
を含む)におけるRMANのデフォルトの動作です。
高速リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合、RMANは1つ以上のアーカイブREDOログ・ファイルを自動的に削除します。RMANが自動的に削除したアーカイブREDOログ・ファイルがローカル取得プロセスで必要なものであれば、Oracle Databaseによってアラート・ログに警告が書き込まれます。
アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成される場合は、RMANの次の削除ポリシーをお薦めします。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;
この削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでにinteger
回バックアップされる必要があります。
アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成されない場合は、推奨される特定の削除ポリシーはありません。デフォルトでは、RMANはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。
3.7.4.2 RMANおよびダウンストリーム取得プロセス
ダウンストリーム取得プロセスが、ソース・データベースで行われたデータベースの変更を取得する場合、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム取得プロセス・データベースに移動されるまで、RMANの削除ポリシーまたはコマンドがそのアーカイブREDOログ・ファイルを削除しないことを確認してください。
アーカイブREDOログ・ファイルを削除するRMANの特定の削除ポリシーおよびコマンドの考慮事項を次に示します。
-
RMANコマンド
CONFIGURE
ARCHIVELOG
DELETION
POLICY
は、高速リカバリ領域内のアーカイブREDOログ・ファイルが削除対象となるタイミングを決定する削除ポリシーを設定します。また、この削除ポリシーは、RMANのすべてのDELETE
コマンド(DELETE
ARCHIVELOG
およびDELETE
OBSOLETE
を含む)に適用されます。次の設定は、ソース・データベースでの動作を決定します。
-
TO
SHIPPED
TO
STANDBY
を設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動されるまで、ログ・ファイルを削除しません。これらのログ・ファイルは、ダウンストリーム取得プロセスで処理された場合もあれば、処理されなかった場合もあります。自動削除が発生するのは、高速リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合です。 -
TO
APPLIED
ON
STANDBY
を設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動され、ソース・データベースがそのログ・ファイルを適用済とマークするまで、ログ・ファイルを削除しません。ソース・データベースがログ・ファイルを適用済とマークするのは、ソース・データベースのすべてのダウンストリーム取得プロセスの最小必須チェックポイントSCNがログ・ファイル内の最大SCNより大きくなった場合です。 -
BACKED
UP
integer
TIMES
TO
DEVICE
TYPE
に設定された削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでに、そのログ・ファイルはinteger
回バックアップされる必要があります。ログ・ファイルは、そのファイルを必要とするダウンストリーム取得プロセスで処理されていない場合であっても削除できます。 -
TO
NONE
を設定した削除ポリシーは、高速リカバリ領域に余裕がなくなった場合に、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセスで処理されていなくても、そのログ・ファイルを削除できることを意味します。
-
-
RMANコマンド
DELETE
ARCHIVELOG
は、次の条件をすべて満たすアーカイブREDOログ・ファイルを削除します。-
ログ・ファイルが、
DELETE
ARCHIVELOG
コマンドで指定した条件を満たしている。 -
CONFIGURE
ARCHIVELOG
DELETION
POLICY
に従ってログ・ファイルを削除できる。たとえば、ポリシーにTO
SHIPPED
TO
STANDBY
を設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。
この動作は、データベースがマウントまたはオープンされたときに適用されます。
アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、RMANによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。
-
-
RMANコマンド
DELETE
OBSOLETE
は、次の条件をすべて満たすアーカイブREDOログ・ファイルを完全に削除します。-
ログ・ファイルが、保存ポリシーに従って不要になっている。
-
CONFIGURE
ARCHIVELOG
DELETION
POLICY
に従ってログ・ファイルを削除できる。たとえば、ポリシーにTO
SHIPPED
TO
STANDBY
を設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。
この動作は、データベースがマウントまたはオープンされたときに適用されます。
-
-
RMANコマンド
BACKUP
ARCHIVELOG
ALL
DELETE
INPUT
は、アーカイブREDOログ・ファイルをコピーし、バックアップの完了後に元のファイルを削除します。このコマンドでは、次の条件が満たされている場合、ログ・ファイルがダウンストリーム取得プロセス・データベースに移動されるまで、そのログ・ファイルは削除されません。-
データベースがマウントまたはオープンされている。
-
ログ・ファイルが、ダウンストリーム取得プロセスで必要である。
-
削除ポリシーに
TO
SHIPPED
TO
STANDBY
を設定している。
アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、RMANによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。
-
ダウンストリーム取得プロセスの場合、ソース・データベースにおけるRMANの削除ポリシーを次のいずれかにすることをお薦めします。
-
アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成される場合、削除ポリシーを次のように設定します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;
-
アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成されない場合、削除ポリシーを次のように設定します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;
ノート:
ダウンストリーム取得プロセス・データベースでは、ソース・データベースから移動されたアーカイブREDOログ・ファイルは、RMANで管理されません。
3.7.5 XStreamおよび分散トランザクション
XStream Outでは分散トランザクションがサポートされます。
次のいずれかの方法を使用して分散トランザクションを実行できます。
-
データベース・リンクを使用した調整方法により複数のデータベース内の表を変更します。
-
DBMS_XA
提供のPL/SQLパッケージ、あるいはOCIまたはJDBCライブラリによって公開されているXAインタフェースを使用します。XAインタフェースによって、X/Open分散トランザクション処理(DTP)アーキテクチャが実装されます。
取得プロセスではこれらの2つの方法のいずれかを使用して分散トランザクション中にソース・データベースに対する変更を取得し、アウトバウンド・サーバーに変更を送信します。アウトバウンド・サーバーでは、トランザクションのコミット後、トランザクション内の変更をクライアント・アプリケーションに送信します。
ただし、分散トランザクションの状態は送信されません。クライアント・アプリケーションでは、このようなトランザクションのインダウト状態または準備済状態が継承されません。また、アウトバウンド・サーバーでは、ソース・データベースでXAトランザクションのために使用されるものと同じグローバル・トランザクション識別子を使用した変更の送信も行われません。
XAトランザクションは次の2つの方法で実行できます。
-
密結合(異なるXAブランチがロックを共有する)
-
疎結合(異なるXAブランチがロックを共有しない)
XStream Outでは、疎結合のXAブランチによって行われる変更は、COMPATIBLE
初期化パラメータの値に関係なくサポートされます。XStream Outでは、Oracle RACソース・データベースで密結合のブランチによって行われる変更のレプリケーションについては、COMPATIBLE
初期化パラメータが11.2.0.0
以上に設定されている場合にのみサポートされます。
関連項目:
-
分散トランザクションの詳細は、Oracle Database管理者ガイドを参照
-
Oracle XAの詳細は、Oracle Database開発ガイドを参照
3.7.6 XStream Outとマルチテナント環境
マルチテナント環境では、移植可能な一連のスキーマ、オブジェクトおよび関連構造をデータベースに含めることができ、アプリケーションには論理的に別のデータベースのように見えます。
この自己完結型コレクションは、プラガブル・データベース(PDB)と呼ばれます。1つのマルチテナント・コンテナ・データベース(CDB)には複数のPDBが格納されます。CDBでのXStream Outの機能は非CDBでの機能とほとんど同じです。
CDBには、アプリケーション・コンテナを含めることもできます。アプリケーション・コンテナは、アプリケーション・ルートとそれに関連付けられたすべてのアプリケーションPDBから構成されるCDBのオプション・コンポーネントです。アプリケーション・コンテナには、1つ以上のアプリケーションのデータが格納されています。アプリケーション・コンテナは、アプリケーションのメタデータおよび共通データを共有します。CDBでは、CDBルート、各PDB、各アプリケーション・ルートおよび各アプリケーションPDBのどれもがコンテナです。
CDBと非CDBでのXStream Outの動作の主な違いは次のとおりです。
-
XStream OutはCDBルートでのみ構成する必要があります。
-
XStream Outでは、CDB内のすべてのコンテナに対する変更を表示できます。
-
XStream Out取得ルールにより、LCRをクライアント・アプリケーションに必要なものに制限できます。システムで生成された取得ルールにより、
DBMS_XSTREAM_ADM
パッケージのADD_OUTBOUND
およびCREATE_OUTBOUND
プロシージャに渡されたパラメータに基づいて適切なLCRが選択されます。XStream Outコンポーネントで使用されるルールをより詳細に制御するために、同じパッケージ内のADD_*_RULES
プロシージャを使用できます。 -
XStream Outタスクを実行するユーザーは、共通ユーザーである必要があります。
XStream環境での切断および接続操作
XStream Out関連のPDB、アプリケーション・ルートまたはアプリケーションPDBがそのCDBから切断され、別のCDBに接続された場合、いずれの取得プロセスおよびアウトバウンド・サーバーもコンテナの一部とみなされません。もう一方のCDBで取得プロセスおよびアウトバウンド・サーバーを再度構成する必要があります。
アウトバウンド・サーバーが取得プロセスとは異なるデータベースで構成されている場合、切断および接続操作には、追加の考慮事項があります。
この例では、次のことを想定しています。
-
CDB1
という名前のCDBにPDBPDB1
が含まれている。 -
取得プロセスが
CDB1
で構成されており、PDB1
からCDB2
という名前のCDB内のアウトバウンド・サーバーにLCRを送信する。 -
PDB1
をCDB1
から切断してから、CDB3
という名前のCDBに接続する。
PDB1
からCDB2
内のアウトバウンド・サーバーにLCRを配信しつづけるには、LCRを取得してCDB2
に送信する新しい取得プロセスをCDB3
で構成する必要があります。
データベースBのアウトバウンド・サーバーで使用されるルールを変更して、CDB1
のルートへの参照をCDB3
のルートに変更する必要があります。また、CDB3
でPDB1
に別の名前を指定した場合、新しいPDBの名前を反映するようにルールを変更する必要があります。
XStream環境でのアプリケーション・コンテナ
CDBに1つ以上のアプリケーション・コンテナが含まれている場合、XStream OutはCDBルートで構成する必要があり、XStream Outでは、アプリケーション・ルートおよびアプリケーションPDBを含む、CDB内の任意のコンテナで行われた変更を取得できます。アプリケーション・コンテナ内で取得された変更は、PDB、アプリケーション・ルートおよびアプリケーションPDBを含む、任意の型のコンテナに送信できます。
1つのアプリケーション・ルートから別のアプリケーション・ルートに変更をレプリケートする場合は、XStreamではALTER PLUGGABLE DATABASE APPLICATION
文をレプリケートできます。エラーを回避するには、文を適用するターゲット・アプリケーション・ルートで同じアプリケーションがソース・アプリケーション・ルートとしてインストールされている必要があり、またアプリケーション名が両方のアプリケーション・ルートで同一である必要があります。
アプリケーション・ルートからアプリケーション・ルートではないコンテナに変更をレプリケートする際にエラーが発生しないようにするには、ALTER PLUGGABLE DATABASE APPLICATION
文がレプリケートされないようにする必要があります。
XStream OCI APIを使用する場合、ALTER PLUGGABLE DATABASE APPLICATION
文がOCIXStreamOutAttach
関数およびOCILCRHeaderGet
関数を使用してレプリケートされるかどうかを制御できます。XStream Java APIを使用する場合、XStreamOut.attach
メソッドでmode
パラメータを使用して、この動作を制御できます。