8 XStream Inの概念
XStream Inに関連する概念について理解します。
- XStream Inの概要
XStream Inにより、リモート・クライアント・アプリケーションは、Oracle以外のデータベースやファイルシステムなどの他のシステムからOracleデータベースに情報を送信できるようになります。 - インバウンド・サーバー
インバウンド・サーバーでは、XStream Inを使用してクライアント・アプリケーションからデータベースの変更を取得します。 - LCRの位置およびXStream In
クライアント・アプリケーションはLCRをXStream Inインバウンド・サーバーにストリームします。 - XStream Inとパフォーマンス上の考慮点
XStream Inおよびパフォーマンスの考慮事項を示します。 - XStream Inおよびセキュリティ
クライアント・アプリケーションおよびXStreamコンポーネントに関連するセキュリティ、インバウンド・サーバーの適用ユーザーに必要な権限について説明します。 - XStream Inと他のOracle Databaseコンポーネント
XStream Inは、他のOracle Databaseコンポーネントと連携して動作できます。
親トピック: XStream In
8.1 XStream Inの概要
XStreamによって、リモート・クライアント・アプリケーションはOracle以外のデータベースやファイルシステムなどの別のシステムからOracleデータベースに情報を送信できます。
XStream Inでは、クライアント・アプリケーションからOracleデータベースに情報を送信するための効率的なトランザクション・ベースのインタフェースを提供します。XStream Inでは、データ・レプリケーション、監査、変更データの取得などのいくつかの方法でOracle Databaseに移入される情報を利用できます。XStream Inでは、OCIインタフェースとJavaインタフェースの両方をサポートしています。
Oracleデータベースに対するDML変更を直接行うOCIクライアント・アプリケーションと比べて、XStream Inの方が、Oracleデータベースに対するほぼリアルタイムのトランザクション・ベースの異機種DML変更にとって効率的です。
XStream Inでは、Oracle Replicationの次の機能が使用されます。
-
DML変更の高パフォーマンスの処理(オプションで並列処理を使用)
-
SQL生成、競合検出と解決、エラー処理および適用ハンドラを使用した処理のカスタマイズなどの適用プロセス機能
-
ネットワークのラウンド・トリップが最小限である情報のネットワーク伝達ストリーム
-
ルール、ルール・セットおよびルールベースの変換
カスタム・ルールベースの変換がインバウンド・サーバーで使用されるルールで指定されている場合、変換関数をコールするユーザーは、インバウンド・サーバーの適用ユーザーです。
XStream Inでは、LOB、LONG
、LONG
RAW
およびXMLType
など、Oracle Replicationでサポートされているすべてのデータ型がサポートされています。クライアント・アプリケーションから、LOBおよびXMLType
データがチャンクでインバウンド・サーバーに送信されます。いくつかのチャンクは、LOB、LONG
、LONG
RAW
またはXMLType
データ型の単一の列値で構成されます。
8.2 インバウンド・サーバー
XStream Inでは、インバウンド・サーバーが、クライアント・アプリケーションからデータベースの変更を受信します。
- インバウンド・サーバーの概要
インバウンド・サーバーは、クライアント・アプリケーションからLCRを受信するオプションのOracleバックグラウンド・プロセスです。 - インバウンド・サーバーによって適用されるデータ型
インバウンド・サーバーはほとんどのデータ型をサポートします。 - インバウンド・サーバーのLCR処理オプション
インバウンド・サーバーは、LCRを直接適用するか、または処理のために適用ハンドラにLCRを送信できます。LCR処理のオプションは、インバウンド・サーバーによって受信されたLCRが、行LCRまたはDDL LCRのいずれかによって異なります。 - インバウンド・サーバーおよびRESTRICTED SESSION
制限付きのセッションの有効化および無効化はインバウンド・サーバーに影響を与えます。 - インバウンド・サーバー・コンポーネント
インバウンド・サーバーは次のサブコンポーネントで構成されます。リーダー・サーバー、コーディネータ・プロセス、および1つ以上の適用サーバーです。 - インバウンド・サーバーの考慮事項
インバウンド・サーバーにはいくつかの考慮事項があります。 - インバウンド・サーバーのエラー・キュー
エラー・キューにはデータベースの現在の適用エラーがすべて含まれます。データベース内に複数のインバウンド・サーバーがある場合、エラー・キューには各インバウンド・サーバーの適用エラーが含まれています。
親トピック: XStream Inの概念
8.2.1 インバウンド・サーバーの概要
インバウンド・サーバーは、クライアント・アプリケーションからLCRを受信するオプションのOracleバックグラウンド・プロセスです。
具体的には、クライアント・アプリケーションによってインバウンド・サーバーに連結し、LCRにカプセル化された行変更、DDL変更およびプロシージャ・コールを送信できます。
外部クライアント・アプリケーションは、OCIまたはJavaインタフェースを使用してインバウンド・サーバーに接続します。接続の確立後、クライアント・アプリケーションは、LCRをストリームすることによりインバウンド・サーバーの取得エージェントとして機能します。
1つのクライアント・アプリケーションで複数のセッションを作成できます。各セッションは1つのインバウンド・サーバーにのみ連結でき、各インバウンド・サーバーは一度に1つのセッションのみを処理できます。ただし、クライアント・アプリケーションのセッションは、それぞれ異なるインバウンド・サーバーまたはアウトバウンド・サーバーに接続できます。クライアント・アプリケーションは、必要に応じて、インバウンド・サーバーから連結解除できます。
図8-1では、インバウンド・サーバーの構成を示しています。
ノート:
インバウンド・サーバーでは、図8-1に示されていないキューが使用されます。インバウンド・サーバーのキューは、エラー・トランザクションを格納する目的でのみ使用されます。
親トピック: インバウンド・サーバー
8.2.2 インバウンド・サーバーによって適用されるデータ型
インバウンド・サーバーは、ほとんどのデータ型をサポートしています。
表に対するDML変更から生じる行LCRの適用時に、インバウンド・サーバーでは、次のデータ型の列に加えられた変更が適用されます。
-
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)
などのようにする必要があります。
ノート:
-
Oracle Database 12cでは、
COMPATIBLE
初期化パラメータが12.0.0
に設定されていて、MAX_STRING_SIZE
初期化パラメータがEXTENDED
に設定されている場合、VARCHAR2
、NVARCHAR2
およびRAW
の各データ・タイプの最大サイズが増大しています。 -
CLOB
として格納されるXMLType
は、Oracle Database 12cリリース1 (12.1)からは非推奨になりました。 -
BFILE
の場合、データ型構造のみがレプリケートされ、ファイル・システムに存在するBFILE
のコンテンツはレプリケートされません。
関連項目:
データ型の詳細は、Oracle Database SQL言語リファレンスを参照
親トピック: インバウンド・サーバー
8.2.3 インバウンド・サーバーのLCR処理オプション
インバウンド・サーバーは、LCRを直接適用するか、適用ハンドラにLCRを送信して処理させることができます。LCR処理のオプションは、インバウンド・サーバーによって受信されたLCRが、行LCRまたはDDL LCRのいずれかによって異なります。
デフォルトでは、インバウンド・サーバーでは、LCRが直接適用されます。インバウンド・サーバーでは、LCRで識別されたデータベース・オブジェクトに対してLCR内の変更が実行されます。インバウンド・サーバーでは、LCR内の変更が正常に適用されるか、競合ハンドラまたはエラー・ハンドラと呼ばれるユーザー指定プロシージャを使用してエラーの解決が試行されます(競合または適用エラーが発生した場合)。
競合ハンドラが競合を解消できる場合は、競合ハンドラがLCRを適用するか、LCR内の変更を廃棄します。エラー・ハンドラがエラーを解決できる場合は、エラー・ハンドラが必要に応じてLCRを適用します。エラー・ハンドラは、適用前にLCRを変更することでエラーを解決できる場合があります。競合ハンドラまたはエラー・ハンドラでエラーを解決できない場合、インバウンド・サーバーでは、トランザクションとトランザクションに関連付けられたすべてのLCRがエラー・キューに入れられます。
LCRを直接適用するかわりに、適用ハンドラを使用し、カスタマイズした方法でLCRを処理することもできます。適用ハンドラを使用した場合、インバウンド・サーバーは処理のためにLCRをSQL文のコレクションに渡すか、またはユーザー定義のPL/SQLプロシージャに渡します。適用ハンドラでは、カスタマイズされた方法でLCRを処理できます。
適用ハンドラにはいくつかのタイプがあります。この項では、適用ハンドラを次のカテゴリに分けて説明します。
表8-1 適用ハンドラの特性
カテゴリ | 説明 |
---|---|
メカニズム |
適用ハンドラがLCRの処理に使用する手段のことです。適用ハンドラに使用されるメカニズムは、SQL文、またはユーザー定義のPL/SQLプロシージャです。 |
LCRのタイプ |
適用ハンドラによって処理されるLCRのタイプです。LCRタイプは、行LCR、DDL LCRまたはトランザクション制御ディレクティブです。 |
スコープ |
適用ハンドラに設定されたレベルのことです。有効範囲は、1つの表に対する1つの操作か、またはすべてのデータベースに対するすべての操作のいずれかになります。 |
各インバウンド・サーバーへの割当て数 |
各インバウンド・サーバーで許可される特定のタイプの適用ハンドラの数。割当て数は1つまたは複数のいずれかになります。 |
- プロシージャDMLハンドラ
プロシージャDMLハンドラでは、PL/SQLプロシージャを使用して行LCRを処理します。 - エラー・ハンドラ
エラー・ハンドラは、プロシージャDMLハンドラに似ています。ただしエラー・ハンドラは、特定の表に対して特定の操作を行うための行LCRをインバウンド・サーバーが適用する際、適用エラーが発生した場合にのみ呼び出されます。 - DDLハンドラ
DDLハンドラでは、PL/SQLプロシージャを使用してDDL LCRを処理します。 - プリコミット・ハンドラ
プリコミット・ハンドラはPL/SQLプロシージャを使用して、行LCRが含まれるトランザクションのコミット・ディレクティブを処理します。
親トピック: インバウンド・サーバー
8.2.3.1 プロシージャDMLハンドラ
プロシージャDMLハンドラでは、PL/SQLプロシージャを使用して行LCRを処理します。
プロシージャDMLハンドラの特性は次のとおりです。
-
メカニズム: ユーザー定義のPL/SQLプロシージャ
-
LCRのタイプ: 行LCR
-
有効範囲: 1つの表に対する1つの操作
-
各インバウンド・サーバーへの割当て数: 複数(ただし、同じ表に対する同じ操作については1つのみ指定可能)
プロシージャDMLハンドラは、インバウンド・サーバーに関連付けられている表ごとに個別に設定できます。処理できる操作(行LCR内の操作)は次のとおりです。
-
INSERT
-
UPDATE
-
DELETE
-
LOB_UPDATE
プロシージャDMLハンドラは、特定の表に対する特定の操作を実行する行LCRをインバウンド・サーバーで受信したときに呼び出されます。そのため、たとえばhr.employees
表でINSERT
操作を処理するためのプロシージャDMLハンドラを1つ設定し、それとは別に、UPDATE
操作を処理するためのプロシージャDMLハンドラをもう1つ設定することなどが可能です。また、hr.employees
表にあるこれら各タイプの操作に、同じプロシージャDMLハンドラを使用することもできます。
PL/SQLプロシージャでは、行LCRの処理を自由にカスタマイズして実行できます。たとえば、ソース・データベースの特定の表に対して挿入が行われるたびに、宛先データベースの複数の表に対して挿入が実行されるようにする場合は、その表に対するINSERT
操作を処理するためのPL/SQLプロシージャをユーザー定義で作成すれば解決できます。プロシージャDMLハンドラでは、行LCR内の列値を修正できます。
親トピック: インバウンド・サーバーのLCR処理オプション
8.2.3.2 エラー・ハンドラ
エラー・ハンドラは、プロシージャDMLハンドラに似ています。ただしエラー・ハンドラは、特定の表に対して特定の操作を行うための行LCRをインバウンド・サーバーが適用する際、適用エラーが発生した場合にのみ呼び出されます。
エラー・ハンドラの特性は次のとおりです。
-
メカニズム: ユーザー定義のPL/SQLプロシージャ
-
LCRのタイプ: 行LCR
-
有効範囲: 1つの表に対する1つの操作
-
各インバウンド・サーバーへの割当て数: 複数(ただし、同じ表に対する同じ操作については1つのみ指定可能)
関連項目:
プロシージャDMLハンドラ親トピック: インバウンド・サーバーのLCR処理オプション
8.2.3.3 DDLハンドラ
DDLハンドラでは、PL/SQLプロシージャを使用してDDL LCRを処理します。
DDLハンドラの特性は次のとおりです。
-
メカニズム: ユーザー定義のPL/SQLプロシージャ
-
LCRのタイプ: DDL LCR
-
スコープ: インバウンド・サーバーで受信したすべてのDDL LCR
-
各インバウンド・サーバーへの割当て数: 1
ユーザー定義のPL/SQLプロシージャでは、DDL LCRの処理を自由にカスタマイズして実行できます。たとえば、DDL変更を適用の前に記録する場合、DDL操作の処理に使用するプロシージャを独自に作成することでこのことを実現できます。
親トピック: インバウンド・サーバーのLCR処理オプション
8.2.3.4 プリコミット・ハンドラ
プリコミット・ハンドラでは、行LCRが含まれているトランザクションのコミット・ディレクティブを処理するためにPL/SQLプロシージャを使用します。
プリコミット・ハンドラの特性は次のとおりです。
-
メカニズム: ユーザー定義のPL/SQLプロシージャ
-
LCRのタイプ: 行LCRが含まれているトランザクションのコミット・ディレクティブ
-
スコープ: インバウンド・サーバーで受信したコミット・ディレクティブが含まれているすべての行LCR
-
各インバウンド・サーバーへの割当て数: 1
プリコミット・ハンドラを使用して、LCRのコミット・ディレクティブを監査できます。コミット・ディレクティブは、COMMIT
を含むトランザクション制御ディレクティブです。プリコミット・ハンドラは、トランザクションのコミット情報を受信し、カスタマイズした方法でコミット情報を処理できるユーザー定義のPL/SQLプロシージャです。プリコミット・ハンドラはプロシージャDMLハンドラと連携します。
たとえば、プリコミット・ハンドラで1トランザクション分のデータをキャッシュすることで、パフォーマンスが改善される場合があります。このデータには、カーソル、一時LOB、メッセージのデータなどが含まれます。プリコミット・ハンドラは、トランザクションが完了すると、ハンドラでキャッシュしたオブジェクトを解放または実行できます。
親トピック: インバウンド・サーバーのLCR処理オプション
8.2.4 インバウンド・サーバーおよびRESTRICTED SESSION
制限付きセッションの有効化および無効化は、インバウンド・サーバーに影響します。
システム起動時にSTARTUP
RESTRICT
文を発行して制限付きセッションを有効にすると、インバウンド・サーバーは、データベースの停止時に実行中であった場合でも、起動されません。制限付きセッションを無効にした場合、停止されなかった各インバウンド・サーバーが起動されます。
SQL文ALTER
SYSTEM
ENABLE
RESTRICTED
SESSION
によって実行中のデータベースで制限付きセッションを有効にしても、実行中のインバウンド・サーバーには影響がありません。これらのインバウンド・サーバーは引き続き実行され、XStreamクライアント・アプリケーションにLCRを送信します。停止されたインバウンド・サーバーが制限付きセッションで起動された場合は、制限付きセッションが無効化されるまで、インバウンド・サーバーは実際に起動しません。
親トピック: インバウンド・サーバー
8.2.5 インバウンド・サーバー・コンポーネント
インバウンド・サーバーは、サブコンポーネント(リーダー・サーバー、コーディネータ・プロセス、および1つ以上の適用サーバー)で構成されます。
インバウンド・サーバーは、次のサブコンポーネントで構成されます。
-
リーダー・サーバー。XStreamクライアント・アプリケーションからLCRを受信します。リーダー・サーバーは、論理変更レコード(LCR)間の依存性を計算してLCRをトランザクションにアセンブルするプロセスです。その後、リーダー・サーバーは、アセンブルしたトランザクションをコーディネータ・プロセスに返します。
インバウンド・サーバーのリーダー・サーバーの状態は、
V$XSTREAM_APPLY_READER
動的パフォーマンス・ビューを問い合せることによって表示できます。 -
リーダー・サーバーからトランザクションを取得して適用サーバーに渡すコーディネータ・プロセス。コーディネータ・プロセス名は
AP
nn
(nn
は文字および数字)です。コーディネータ・プロセスはOracleバックグラウンド・プロセスです。コーディネータ・プロセスの状態は、
V$XSTREAM_APPLY_COORDINATOR
動的パフォーマンス・ビューを問い合せることによって表示できます。 -
1つ以上の適用サーバー。LCRをDML文またはDDL文としてデータベース・オブジェクトに適用するか、LCRを適切な適用ハンドラに渡します。適用サーバーは、
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION
プロシージャで指定されたキューの永続キュー部分にLCRをエンキューすることもできます。各適用サーバーはプロセスです。エラーが発生すると、適用サーバーはユーザー指定の競合ハンドラまたはエラー・ハンドラを使用してエラーの解決を試みる。エラーを解決できない場合、適用サーバーはトランザクションをロールバックし、すべてのLCRを含めてトランザクション全体をエラー・キューに置きます。適用サーバーが完了済トランザクションをコミットした場合、そのトランザクションは適用される。トランザクションをエラー・キューに配置してコミットした場合にも、トランザクションは適用される。
インバウンド・サーバーの各適用サーバーの状態は、
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リファレンスを参照
親トピック: インバウンド・サーバー
8.2.6 インバウンド・サーバーの考慮事項
インバウンド・サーバーに関するいくつかの考慮事項があります。
XStreamインバウンド・サーバーに関する考慮事項は次のとおりです。
-
DBMS_DDL
パッケージのSET_TRIGGER_FIRING_PROPERTY
プロシージャを使用すると、DMLまたはDDLトリガーの起動プロパティを制御できます。このプロシージャでは、トリガーを常に起動するか、1回起動するか、またはインバウンド・サーバーによって変更が行われる場合にのみ起動するかを指定できます。トリガーが1回起動するように設定されている場合、ユーザー・プロセスによる変更に対して起動しますが、インバウンド・サーバーによる変更に対して起動されません。トリガーの起動プロパティは、適用プロセスとインバウンド・サーバーで同様に動作します。 -
クライアント・アプリケーションによってインバウンド・サーバーに送信されたLCRではトランザクションID値が指定されていない可能性があるため、インバウンド・サーバーでは、
ignore_transaction
適用パラメータの設定は無視されます。 -
クライアント・アプリケーションによってインバウンド・サーバーに送信されたLCRではSCN値が指定されていない可能性があるため、インバウンド・サーバーでは、
maximum_scn
適用パラメータの設定は無視されます。関連項目:
適用パラメータの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照
親トピック: インバウンド・サーバー
8.2.7 インバウンド・サーバーのエラー・キュー
エラー・キューには、1つのデータベースの現在の適用エラーがすべて格納されます。データベース内に複数のインバウンド・サーバーがある場合、エラー・キューには各インバウンド・サーバーの適用エラーが含まれています。
信頼できるユーザーは、DBA_APPLY_ERROR
データ・ディクショナリ・ビューを問い合せるか、Oracle Enterprise Manager Cloud Controlを使用して、適用エラーを表示できます。DBA_APPLY_ERROR
データ・ディクショナリ・ビューを使用すると、信頼できるユーザーは、他のユーザーの適用エラーに関する情報を確認できます。信頼されないユーザーは、ALL_APPLY_ERROR
データ・ディクショナリ・ビューを問い合せることで、適用エラーを表示できます。このビューでは、信頼されないユーザーの適用エラーのみが示されます。
また、信頼できるユーザーは、DBA_APPLY_ERROR_MESSAGES
データ・ディクショナリ・ビューを問い合せることで、適用エラーのさらに詳細な情報を表示できます。信頼されないユーザーは、ALL_APPLY_ERROR_MESSAGES
データ・ディクショナリ・ビューを問い合せることで、適用エラーのさらに詳細な情報を表示できます。これらのビューには、エラー・トランザクションでエラーの原因となった行に関する情報が含まれます。
エラー・キューには、データベースで実行中のインバウンド・サーバーによって正常に適用できなかったトランザクションに関する情報が格納されます。トランザクションには、多くのLCRが含まれることがあります。未処理のエラーが適用時に発生すると、インバウンド・サーバーでは、インバウンド・サーバーのルール・セットを満たすトランザクション内のすべてのLCRをエラー・キューに自動的に移動します。
エラーの原因となった状態を修正し、エラー・トランザクションを再実行できます。たとえば、表の1行を変更して、エラーの原因となった状態を修正できる場合もあります。
エラーの原因となった条件を訂正した後、EXECUTE_ERROR
またはEXECUTE_ALL_ERRORS
プロシージャを使用してエラー・キュー内のトランザクションを再実行するか、またはDELETE_ERROR
やDELETE_ALL_ERRORS
プロシージャを使用してエラー・キューからトランザクションを削除できます。これらのプロシージャは、DBMS_APPLY_ADM
パッケージに含まれています。
エラー・キュー内のトランザクションを再実行する場合は、そのトランザクションを実行するユーザーとして、最初にエラー・キューにエラーを置いたユーザーまたはトランザクションを再実行するユーザーを指定できます。また、エラー・キュー内のトランザクションを再実行する場合は、インバウンド・サーバーの現行のタグが使用されます。
再実行されるトランザクションでは、関連する適用ハンドラと競合解消ハンドラが使用されます。たとえば、エラーの解決策として、エラー・キュー内の行LCRが実行前に変更されるようにするには、エラーの原因となった行LCRをエラー・キュー内で処理するようにプロシージャDMLハンドラを構成します。つまり、DMLハンドラに行LCRを修正させることで、同じエラーの繰返しを回避できます。行LCRを含んだエラーが再実行されると、その行LCRはDMLハンドラに渡されます。たとえば、プロシージャDMLハンドラは、行LCRの1つ以上の列を変更することで同じエラーの繰返しを回避できます。
親トピック: インバウンド・サーバー
8.3 LCRの位置とXStream In
クライアント・アプリケーションはLCRをXStream Inインバウンド・サーバーにストリームします。
この項では、インバウンド・サーバーのLCRの位置に関連する概念について説明します。
各位置は、バイトの比較がサポートされているフォーマット(16進エンコーディングなど)でエンコードする必要があります。位置は、XStream Inインタフェースを使用してクライアント・アプリケーションから送信されるトランザクション・ストリームの全順序にとって不可欠です。
インバウンド・サーバーでは、次の位置が重要です。
-
適用最低位置。この値以下のLCRが適用されていることを示します。
LCRは、実行されたか、適用ハンドラに送信されたか、またはエラー・キューに移動された場合、インバウンド・サーバーによって適用されます。
-
オーバーフロー位置。位置がこの値以下のLCRが適用されているか、メモリーからハード・ディスクにオーバーフローしたことを示します。
-
適用最高位置。LCRの最高位置が適用されていることを示します。
インバウンド・サーバーの
commit_serialization
適用パラメータがDEPENDENT_TRANSACTIONS
に設定されている場合、高位のコミット位置のLCRは、下位のコミット位置のLCRの前に適用される場合があります。これが発生すると、適用最高位置は、適用最低位置とは異なります。 -
処理済最低位置は、適用最低位置またはオーバーフロー位置の高い方の値です。
処理済最低位置は、その位置以降、インバウンド・サーバーでLCRが必要とされないことを示します。この位置は、取得プロセスで取得された変更を適用するOracle適用プロセスの最も古いSCNに対応します。
処理済最低位置は、この位置以下のLCRがインバウンド・サーバーで処理済であることを示します。クライアントがインバウンド・サーバーに再連結されると、インバウンド・サーバーでは、処理済最低位置以下の位置のLCRがすべて破棄されるため、処理済最低位置より大きい位置のLCRのみを送信する必要があります。
クライアント・アプリケーションが異常停止した場合は、クライアント・アプリケーションとインバウンド・サーバー間の接続は自動的に切断されます。再起動時、クライアント・アプリケーションで処理済最低位置がインバウンド・サーバーから取り出され、この処理済最低位置から変更を取り出すように取得エージェントに指示が出されます。
XStream Inインタフェースを使用してクライアント・アプリケーションのリカバリ時間を制限するため、クライアント・アプリケーションから空のトランザクションなどのアクティビティを定期的にインバウンド・サーバーに送信できます。行LCRにはコミット・トランザクション制御ディレクティブを含めることができます。サーバーに送信するLCRが存在しない場合、インバウンド・サーバーの処理済最低位置を進めるように、コミット・ディレクティブが含まれた行LCRをクライアント・アプリケーションから送信できます。このアクティビティは、インバウンド・サーバーの処理済最低位置を進めるように承認する役割を果たします。
位置3の後、インバウンド・サーバーに送信する、関連する変更はありません。クライアント・アプリケーションで位置101までのすべての変更が処理されて、インバウンド・サーバーが再起動した場合、再起動後、クライアント・アプリケーションは、位置4以降の外部データベースのすべての変更を再確認する必要があります。インバウンド・サーバーの処理済最低位置が3であるため、再確認が必要になります。
そうではなく、hr.employees
表に対する関連する変更がない場合でも、クライアント・アプリケーションからコミットをインバウンド・サーバーに定期的に送信するものと想定してください。
位置 | 変更 | クライアント・アプリケーションのアクティビティ |
---|---|---|
1 |
|
インバウンド・サーバーに変更が含まれた行LCRを送信する |
2 |
|
なし |
3 |
コミット |
コミット・ディレクティブが含まれた行LCRをインバウンド・サーバーに送信する |
4 |
|
なし |
5 |
|
なし |
6 |
コミット |
なし |
7 |
コミット |
なし |
... |
... (外部データ・ソースでのアクティビティ。ただし、 |
それぞれにコミット・ディレクティブが含まれた複数の行LCRをインバウンド・サーバーに送信する |
100 |
|
なし |
101 |
コミット |
コミット・ディレクティブが含まれた行LCRをインバウンド・サーバーに送信する |
この場合、インバウンド・サーバーでは、クライアント・アプリケーションによって送信された行LCRのすべてを処理したら、処理済最低位置を101に進めます。インバウンド・サーバーが再起動すると、処理済最低位置は101になり、クライアント・アプリケーションは、位置3までのすべての変更を確認する必要はありません。
サンプルXStreamクライアント・アプリケーションのサンプル・アプリケーションでは、コミット・ディレクティブが含まれた行LCRをインバウンド・サーバーに送信するコードが含まれています。これらのコミット・ディレクティブは、「ping LCR」と呼ばれる場合があります。サンプルXStreamクライアント・アプリケーションで「ping」という単語を検索して、このコードが含まれているアプリケーションの部品を検索します。
例8-1 インバウンド・サーバーの処理済最低位置の進行
クライアント・アプリケーションと外部データ・ソースについて考えてみます。クライアント・アプリケーションでは、hr.employees
表に対する変更をインバウンド・サーバーに処理のために送信しますが、外部データ・ソースには、他の多くの表(oe.orders
表など)が含まれています。
次の変更が外部のデータ・ソースに対して実行されるものとします。
位置 | 変更 | クライアント・アプリケーション・アクティビティ |
---|---|---|
1 |
|
インバウンド・サーバーに変更を含む行LCRを送信します |
2 |
|
なし |
3 |
コミット |
コミット・ディレクティブを含む行LCRをインバウンド・サーバーに送信します |
4 |
|
なし |
5 |
|
なし |
6 |
コミット |
なし |
7 |
コミット |
なし |
... |
...(外部データ・ソースでのアクティビティ、ただし |
なし |
100 |
|
なし |
101 |
コミット |
なし |
クライアント・アプリケーションは、外部データ・ソースから変更を取得し、適切なLCRを生成し、LCRをインバウンド・サーバーに送信します。そのため、インバウンド・サーバーでは、次のLCRを受信します。
-
位置1の行LCR
-
位置3の行LCR
親トピック: XStream Inの概念
8.4 XStream Inおよびパフォーマンスの考慮事項
XStream Inおよびパフォーマンスの考慮事項を示します。
- 大規模トランザクションのためのXStream Inのパフォーマンスの最適化
トランザクションが小さい場合は、インバウンド・サーバーがソースからトランザクションのコミットLCRを受信するまで、XStream Inは論理変更レコード(LCR)の適用を開始しません。パフォーマンスを最適化するため、インバウンド・サーバーはコミットLCRを受信する前に、即時適用を使用して大規模なトランザクションの適用を開始できます。 - トランザクション・トラッキングでの潜在的なボトルネックの回避
XStreamでは、データベースに適用されている変更を追跡し、インバウンド・サーバーの再起動時にトランザクションが再適用されないようにします。 - トランザクション適用スケジューリングの最適化
ターゲット表の制約がソース表での制約と一致する場合は、インバウンド・サーバーのcompute_lcr_dep_on_arrival
適用パラメータをY
に設定して、依存性の計算を最適化できます。
親トピック: XStream Inの概念
8.4.1 大規模トランザクションにおけるXStream Inのパフォーマンスの最適化
少量のトランザクションの場合、XStream Inは、インバウンド・サーバーがソースからトランザクションのコミットLCRを受信するまで論理変更レコード(LCR)の適用を開始しません。パフォーマンスを最適化するため、インバウンド・サーバーはコミットLCRを受信する前に、即時適用を使用して大規模なトランザクションの適用を開始できます。
eager_size
適用パラメータでは、即時適用の開始前にインバウンド・サーバーで受信するLCRの最小数を制御します。トランザクション内のLCR数がeager_size
適用パラメータの値を超過すると、インバウンド・サーバーでLCRの適用が開始されます。このパラメータに対するデフォルト値は9500です。パラメータ値を変更して、ご使用の環境でXStream Inのパフォーマンスを最適化できます。
大規模なトランザクションでは、LCRを適用するために追加の適用サーバーが必要になる場合があります。トランザクションに対して即時適用が開始した後に、インバウンド・サーバーでは、LCRを適用するための追加の適用サーバーを自動的に作成できます。max_parallelism
適用パラメータでは、インバウンド・サーバーの適用サーバーの最大数を制御します。
インバウンド・サーバーで自動的に追加の適用サーバーが作成され、その一部が一定期間アイドルになった場合、XStream Inでは、それらは不要になったと判断され、自動的に削除されます。ただし、適用サーバーの数は、parallelism
適用パラメータで指定された値を下回ることはありません。これらの適用サーバーのすべての統計は、適用サーバー0(ゼロ)として集計されます。
インバウンド・サーバーで大規模なトランザクション用に即時適用を使用する場合、eager_size
適用パラメータの値は、txn_lcr_spill_threshold
適用パラメータの値より小さい値にする必要があります。txn_lcr_spill_threshold
の値がeager_size
よりも小さい場合、即時適用が開始される前にトランザクションがディスクにオーバーフローし、インバウンド・サーバーでは、ディスクにオーバーフローしたトランザクションに対して即時適用を使用できません。
8.4.2 トランザクション・トラッキングでの潜在的なボトルネックの回避
XStreamでは、データベースに適用されている変更を追跡し、インバウンド・サーバーの再起動時にトランザクションが再適用されないようにします。
optimize_progress_table
適用パラメータがTRUE
(デフォルト)に設定されている場合、XStream Inでは、REDOログ内の進捗が追跡されます。REDOログを使用すると、進捗表のDML変更による潜在的なボトルネックと競合が回避されます。
optimize_progress_table
パラメータがFALSE
に設定されている場合、XStream Inでは、トラッキング用の表が使用されます。ボリュームの大きい環境では、この表は、潜在的なボトルネックとなる可能性があります。
REDOログで適用トラッキングを行うには、その前に、適用データベースがアーカイブ・ログ・モードになっている必要があります。optimize_progress_table
パラメータがTRUE
に設定されているが、適用データベースがアーカイブ・ログ・モードになっていない場合、optimize_progress_table
の設定は無視され、XStream Inでは、トラッキング用の表が使用されます。
8.4.3 トランザクション適用スケジューリングの最適化
ターゲット表の制約がソース表での制約と一致する場合は、インバウンド・サーバーのcompute_lcr_dep_on_arrival
適用パラメータをY
に設定して、依存性の計算を最適化できます。
制約が一致していない場合は、この適用パラメータをN
(デフォルト)に設定します。
この適用パラメータがY
に設定されている場合、トランザクションのLCRの受信時に依存性が計算されます。この適用パラメータがN
に設定されている場合、依存性は、コミットされたトランザクションのすべてのLCRを受信した後にのみ計算されます。
compute_lcr_dep_on_arrival
適用パラメータの設定に関係なく、キー列のビフォア・イメージが、インバウンド・サーバーで受信したLCRで使用可能である必要があります。キー列には、主キー列、外部キー列、一意制約列が含まれます。インバウンド・サーバーでXStream Out構成の取得プロセスによって取得された変更を適用するXStream構成では、サプリメンタル・ロギングによって、必要な情報がLCRにあることが保証されます。
8.5 XStream Inとセキュリティ
クライアント・アプリケーションおよびXStreamコンポーネントに関連するセキュリティに加え、インバウンド・サーバーの適用ユーザーに必要な権限について理解します。
- XStream Inクライアント・アプリケーションとセキュリティ
XStream Inを使用すると、アプリケーションがLCRをインバウンド・サーバーに送信でき、インバウンド・サーバーは、LCRのデータベース変更をデータベースに適用できます。 - XStream Inコンポーネントレベルのセキュリティ
XStream In構成のすべてのコンポーネントは同じユーザーとして実行されます。このユーザーは、インバウンド・サーバーの適用ユーザーです。このユーザーは高いレベルの権限を持つ信頼できるユーザーである場合と、特定のタスクの実行に必要な権限のみを持つ信頼できないユーザーの場合があります。 - インバウンド・サーバーの適用ユーザーに必要な権限
インバウンド・サーバーは、その適用ユーザーのセキュリティ・ドメイン内のLCRを適用します。
親トピック: XStream Inの概念
8.5.1 XStream Inクライアント・アプリケーションおよびセキュリティ
XStream Inにより、アプリケーションからLCRをインバウンド・サーバーに送信でき、インバウンド・サーバーは、LCRに含まれているデータベース変更をデータベースに適用できます。
JavaおよびOCIクライアント・アプリケーションでは、Oracleデータベースで作成されたXStreamインバウンド・サーバーに連結する前に、Oracleデータベースに接続する必要があります。接続ユーザーは、インバウンド・サーバーに対して構成された適用ユーザーと同じである必要があります。そうでない場合は、エラーが発生します。
XStreamIn
クラスのXStream attach
メソッドでクライアント・アプリケーションによって作成されたOracle JDBC接続インスタンスをXStreamで受け入れるため、XStream JavaレイヤーAPIは、Oracle JDBCセキュリティに依存しています。接続ユーザーはXStreamユーザーとして検証されます。
関連項目:
-
XStreamのOCIインタフェースの詳細は、Oracle Call Interfaceプログラマーズ・ガイドを参照
-
XStreamのJavaインタフェースの詳細は、Oracle Database XStream Java APIリファレンスを参照
親トピック: XStream Inとセキュリティ
8.5.2 XStream Inコンポーネント・レベルのセキュリティ
XStream In構成のすべてのコンポーネントは同じユーザーとして実行されます。このユーザーは、インバウンド・サーバーの適用ユーザーです。このユーザーは高いレベルの権限を備えた信頼できるユーザーにすることも、特定のタスクの実行に必要な権限のみを備えた信頼されないユーザーにすることもできます。
XStream管理者のセキュリティ・モデルでは、このユーザーがXStream構成を監視するために問合せ可能なデータ・ディクショナリ・ビューも決定されます。信頼できる管理者は、DBA_
ビューでXStreamを監視できます。信頼されない管理者は、ALL_
ビューでXStreamを監視できます。
DBMS_XSTREAM_AUTH
パッケージのGRANT_ADMIN_PRIVILEGE
プロシージャを使用して、XStream管理者を作成します。この手順を実行してXStream InのXStream管理者を作成した場合、privilege_type
パラメータにより、ユーザーに付与される権限のタイプが決定されます。
-
XStream管理者がデータベースでXStream In構成のみを管理する場合、
privilege_type
パラメータにAPPLY
を指定します。 -
XStream管理者がデータベースでXStream OutとXStream Inの両方の構成を管理する場合、
privilege_type
パラメータに*
を指定します。
GRANT_ADMIN_PRIVILEGE
プロシージャにより、XStream InまたはXStream Out構成のコンポーネントを実行するために必要な、Oracle提供のビューとパッケージに対する権限が付与されます。このプロシージャでは、ユーザーが所有しているデータベース・オブジェクトに対する権限は付与されません。そのような権限が必要な場合は、それらを個別に付与する必要があります。
関連項目:
XStream管理者の構成の詳細は、XStream管理者の構成を参照
親トピック: XStream Inとセキュリティ
8.5.3 インバウンド・サーバーの適用ユーザーに必要な権限
インバウンド・サーバーでは、その適用ユーザーのセキュリティ・ドメインでLCRが適用されます。
インバウンド・サーバーでは、XStreamクライアント・アプリケーションからLCRを受信し、インバウンド・サーバーのルール・セットを満たすLCRが適用されます。適用ユーザーは、LCRをデータベース・オブジェクトに直接適用できます。また、適用ユーザーは、これらのルール・セット内のルールで指定されたすべてのカスタム・ルールベース変換を実行します。適用ユーザーは、ユーザー定義の適用ハンドラも実行します。XStream Inでは、インバウンド・サーバーの適用ユーザーが信頼できると想定されません。
適用ユーザーは、次の権限を含む、変更の適用に必要な権限を持っている必要があります。
-
(インバウンド・サーバーで他のスキーマ内の表に対するDML変更を受信したときに)他のスキーマ内の表に対するデータ操作言語(DML)変更を適用するために必要な権限
-
(インバウンド・サーバーでDDL変更を受信したときに)データベースに対するデータ定義言語(DDL)変更を適用するために必要な権限
-
インバウンド・サーバーで使用されるルール・セットに対する
EXECUTE
権限 -
ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションの
EXECUTE
権限 -
すべての適用ハンドラの
EXECUTE
権限
インバウンド・サーバーは1人のユーザーにのみ関連付けることができますが、1人のユーザーを多数のインバウンド・サーバーに関連付けることができます。
GRANT_ADMIN_PRIVILEGE
プロシージャでprivilege_type
パラメータにAPPLY
を指定することで、DBMS_XSTREAM_AUTH
パッケージで適用ユーザーに権限を付与します。
関連項目:
-
GRANT_ADMIN_PRIVILEGE
プロシージャの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照
親トピック: XStream Inとセキュリティ
8.6 XStream Inと他のOracle Databaseコンポーネント
XStream Inは、他のOracle Databaseコンポーネントと連携して動作できます。
- XStream InおよびOracle Real Application Clusters
Oracle Real Application Clusters (Oracle RAC)環境で変更を適用するインバウンド・サーバーを構成できます。 - XStream Inおよびフラッシュバック・データ・アーカイブ
インバウンド・サーバーは、論理変更レコード(LCR)にカプセル化された変更を、フラッシュバック・データ・アーカイブの表に適用できます。 - XStream Inおよびトランスポータブル表領域
トランスポータブル表領域を使用して、XStreamレプリケーション環境に関係しているデータベースにデータをインポートできます。 - XStream Inおよびマルチテナント環境
マルチテナント環境では、アプリケーションが論理的に別のデータベースと認識するOracleデータベースに、移植可能な一連のスキーマ、オブジェクトおよび関連構造を格納できます。
親トピック: XStream Inの概念
8.6.1 XStream InおよびOracle Real Application Clusters
Oracle Real Application Clusters (Oracle RAC)環境での変更を適用するようにインバウンド・サーバーを構成できます。
インバウンド・サーバーは、接続したOracle RACインスタンスで実行されます。このインスタンスに障害が発生した場合、残っているインスタンスに接続し、インバウンド・サーバーを再び起動できます。
8.6.2 XStream Inおよびフラッシュバック・データ・アーカイブ
インバウンド・サーバーでは、論理変更レコード(LCR)にカプセル化された変更をフラッシュバック・データ・アーカイブの表に適用できます。
インバウンド・サーバーでは、次のDDL文もサポートされています。
-
CREATE
FLASHBACK
ARCHIVE
-
ALTER
FLASHBACK
ARCHIVE
-
DROP
FLASHBACK
ARCHIVE
-
FLASHBACK
ARCHIVE
句を指定したCREATE
TABLE
-
FLASHBACK
ARCHIVE
句を指定したALTER
TABLE
関連項目:
-
フラッシュバック・データ・アーカイブの詳細は、Oracle Database開発ガイドを参照
8.6.3 XStream Inおよびトランスポータブル表領域
トランスポータブル表領域を使用して、XStreamレプリケーション環境に関係しているデータベースにデータをインポートできます。
この項の手順は、次の条件が満たされた場合に適用されます。
-
レプリケーションの構成が、インバウンド・サーバーでXStream Out構成の取得プロセスによって取得された変更を適用するものである。
-
トランスポータブル表領域のインポート対象データが、レプリケーション環境にある各データベースに含まれている必要がある。
-
インポート操作が完了した後、インポートされたデータに対する変更がレプリケートされる。
また、ルールにより、タグ付けされたLCRがレプリケートされないようにレプリケーション環境に指示する必要があります。
これらの条件が満たされている場合、次のステップを実行します。
- レプリケーションを停止します。
- トランスポータブル表領域を使用して、レプリケーション環境にある各データベースにデータをインポートします。
- レプリケーションを再起動します。
関連項目:
トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
8.6.4 XStream Inとマルチテナント環境
マルチテナント環境によって、移植可能な一連のスキーマ、オブジェクトおよび関連構造をOracleデータベースに含めることができ、アプリケーションには論理的に別のデータベースのように見えます。
この自己完結型コレクションは、プラガブル・データベース(PDB)と呼ばれます。1つのマルチテナント・コンテナ・データベース(CDB)には複数のPDBが格納されます。また、これはアプリケーション・コンテナも含むことができます。アプリケーション・コンテナは、アプリケーション・ルートとそれに関連付けられたすべてのアプリケーションPDBから構成されるCDBのオプション・コンポーネントです。アプリケーション・コンテナには、1つ以上のアプリケーションのデータが格納されています。アプリケーション・コンテナは、アプリケーションのメタデータおよび共通データを共有します。CDBでは、CDBルート、各PDB、各アプリケーション・ルートおよび各アプリケーションPDBのどれもがコンテナです。
CDBでは、インバウンド・サーバーは、1つのソース・データベースからLCRを受信し、現在のコンテナ(1つのPDB、1つのアプリケーション・ルート、1つのアプリケーションPDBまたはCDBルート)でのみ変更を実行するように制限されています。1つのインバウンド・サーバーでは、CDB内の複数のコンテナに変更を適用できません。
インバウンド・サーバーがCDBルートにある場合、適用ユーザーは共通ユーザーである必要があります。インバウンド・サーバーがアプリケーション・ルートにある場合、適用ユーザーは共通ユーザーまたはアプリケーション共通ユーザーである必要があります。インバウンド・サーバーがPDBまたはアプリケーションPDBにある場合、適用ユーザーは共通ユーザーまたはローカル・ユーザーにすることができます。
ノート:
XStreamはアプリケーション・ルート・コンテナで行われた変更を同期しません。アプリケーション・ルート・コンテナで行われた操作のレプリケートにXStream INレプリケーションを使用しないでください。アプリケーション・ルート・コンテナに対するこうした変更は、手動でターゲットに適用してください。なお、PDB内で行われた操作はレプリケートできます。