8 XStream Inの概念

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 Streamsの次の機能が使用されます。

• DML変更の高パフォーマンスの処理(オプションで並列処理を使用)

• SQL生成、競合検出と解決、エラー処理および適用ハンドラを使用した処理のカスタマイズなどの適用プロセス機能

• ネットワークのラウンド・トリップが最小限である情報のネットワーク伝達ストリーム

• ルール、ルール・セットおよびルールベースの変換

  カスタム・ルールベースの変換がインバウンド・サーバーで使用されるルールで指定されている場合、変換関数をコールするユーザーは、インバウンド・サーバーの適用ユーザーです。

XStream Inでは、LOB、LONG、LONG RAWおよびXMLTypeなど、Oracle Streamsでサポートされているすべてのデータ型がサポートされています。クライアント・アプリケーションから、LOBおよびXMLTypeデータがチャンクでインバウンド・サーバーに送信されます。いくつかのチャンクは、LOB、LONG、LONG RAWまたはXMLTypeデータ型の単一の列値で構成されます。

関連項目:

• Oracle Call Interfaceプログラマーズ・ガイド

• Oracle Database XStream Java APIリファレンス

8.2 インバウンド・サーバー

XStream Inでは、インバウンド・サーバーが、クライアント・アプリケーションからデータベースの変更を受信します。

8.2.1 インバウンド・サーバーの概要

インバウンド・サーバーは、クライアント・アプリケーションからLCRを受信するオプションのOracleバックグラウンド・プロセスです。

具体的には、クライアント・アプリケーションによってインバウンド・サーバーに連結し、LCRにカプセル化された行変更、DDL変更およびプロシージャ・コールを送信できます。

外部クライアント・アプリケーションは、OCIまたはJavaインタフェースを使用してインバウンド・サーバーに接続します。接続の確立後、クライアント・アプリケーションは、LCRをストリームすることによりインバウンド・サーバーの取得エージェントとして機能します。

1つのクライアント・アプリケーションで複数のセッションを作成できます。各セッションは1つのインバウンド・サーバーにのみ連結でき、各インバウンド・サーバーは一度に1つのセッションのみを処理できます。ただし、クライアント・アプリケーションのセッションは、それぞれ異なるインバウンド・サーバーまたはアウトバウンド・サーバーに接続できます。クライアント・アプリケーションは、必要に応じて、インバウンド・サーバーから連結解除できます。

図8-1では、インバウンド・サーバーの構成を示しています。

図8-1 XStream Inインバウンド・サーバー

「図8-1 XStreamインバウンド・サーバー」の説明

注意:

インバウンド・サーバーでは、図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、メディア型

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)からは非推奨になりました。

関連項目:

データ型の詳細は、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つまたは複数のいずれかになります。

注意:

これらのハンドラの詳細およびその使用方法の説明は、Oracle Streams概要および管理を参照

8.2.3.1 DMLハンドラ

DMLハンドラでは、インバウンド・サーバーで受信した行LCRを処理します。

DMLハンドラには2つのタイプがあります。文DMLハンドラとプロシージャDMLハンドラです。文DMLハンドラは、SQL文のコレクションを使用して行LCRを処理します。一方プロシージャDMLハンドラは、PL/SQLプロシージャを使用して行LCRを処理します。

8.2.3.1.1 文DMLハンドラ

文DMLハンドラでは、SQL文のコレクションを使用して行LCRを処理します。

文DMLハンドラの特性は次のとおりです。

• メカニズム: SQL文のコレクション

• LCRのタイプ: 行LCR

• 有効範囲: 1つの表に対する1つの操作

• 各インバウンド・サーバーへの割当て数: 複数(同じ表に対する同じ操作について複数指定可能)

文DMLハンドラに含まれる各SQL文には、それぞれ固有の実行順序番号があります。文DMLハンドラが呼び出されると、文は実行順序番号の小さいものから大きいものへと進める順序で実行されます。実行順序番号は、正の数、負の数、または小数で指定できます。

文DMLハンドラは、インバウンド・サーバーに関連付けられている表ごとに個別に設定できます。処理できる操作(行LCR内の操作)は次のとおりです。

• INSERT

• UPDATE

• DELETE

文DMLハンドラは、特定の表に対する特定の操作を実行する行LCRをインバウンド・サーバーで受信したときに呼び出されます。そのため、たとえばhr.employees表でINSERT操作を処理するための文DMLハンドラを1つ設定し、それとは別に、UPDATE操作を処理するための文DMLハンドラをもう1つ設定することなどが可能です。また、hr.employees表にあるこれら各タイプの操作に、同じ文DMLハンドラを使用することもできます。

同じ表に対する同じ操作について、複数の文DMLハンドラを指定することもできます。その場合、それらの文DMLハンドラは任意の順序で実行できます。それぞれの文DMLハンドラは、インバウンド・サーバーで受信した元の行LCRのコピーを受け取ります。

8.2.3.1.2 プロシージャ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ハンドラと違い、プロシージャDMLハンドラでは行LCR内の列値を修正することができます。

8.2.3.2 エラー・ハンドラ

エラー・ハンドラは、プロシージャDMLハンドラに似ています。ただしエラー・ハンドラは、特定の表に対して特定の操作を行うための行LCRをインバウンド・サーバーが適用する際、適用エラーが発生した場合にのみ呼び出されます。

エラー・ハンドラの特性は次のとおりです。

• メカニズム: ユーザー定義のPL/SQLプロシージャ

• LCRのタイプ: 行LCR

• 有効範囲: 1つの表に対する1つの操作

• 各インバウンド・サーバーへの割当て数: 複数(ただし、同じ表に対する同じ操作については1つのみ指定可能)

注意:

文DMLハンドラは、エラー・ハンドラとしては使用できません。

関連項目:

プロシージャDMLハンドラ

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操作の処理に使用するプロシージャを独自に作成することでこのことを実現できます。

8.2.3.4 プリコミット・ハンドラ

プリコミット・ハンドラでは、行LCRが含まれているトランザクションのコミット・ディレクティブを処理するためにPL/SQLプロシージャを使用します。

プリコミット・ハンドラの特性は次のとおりです。

• メカニズム: ユーザー定義のPL/SQLプロシージャ

• LCRのタイプ: 行LCRが含まれているトランザクションのコミット・ディレクティブ

• スコープ: インバウンド・サーバーで受信したコミット・ディレクティブが含まれているすべての行LCR

• 各インバウンド・サーバーへの割当て数: 1

プリコミット・ハンドラを使用して、LCRのコミット・ディレクティブを監査できます。コミット・ディレクティブは、COMMITを含むトランザクション制御ディレクティブです。プリコミット・ハンドラは、トランザクションのコミット情報を受信し、カスタマイズした方法でコミット情報を処理できるユーザー定義のPL/SQLプロシージャです。プリコミット・ハンドラは、文DMLハンドラまたはプロシージャDMLハンドラと併用できます。

たとえば、プリコミット・ハンドラで1トランザクション分のデータをキャッシュすることで、パフォーマンスが改善される場合があります。このデータには、カーソル、一時LOB、メッセージのデータなどが含まれます。プリコミット・ハンドラは、トランザクションが完了すると、ハンドラでキャッシュしたオブジェクトを解放または実行できます。

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動的パフォーマンス・ビューを問い合せることによって表示できます。

• リーダー・サーバーからトランザクションを取得して適用サーバーに渡すコーディネータ・プロセス。コーディネータ・プロセス名はAPnn (nnは文字および数字)です。コーディネータ・プロセスはOracleバックグラウンド・プロセスです。

  コーディネータ・プロセスの状態は、V$XSTREAM_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せることによって表示できます。

• 1つ以上の適用サーバー。LCRをDML文またはDDL文としてデータベース・オブジェクトに適用するか、LCRを適切な適用ハンドラに渡します。適用サーバーは、DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATIONプロシージャで指定されたキューの永続キュー部分にLCRをエンキューすることもできます。各適用サーバーはプロセスです。エラーが発生すると、適用サーバーはユーザー指定の競合ハンドラまたはエラー・ハンドラを使用してエラーの解決を試みる。エラーを解決できない場合、適用サーバーはトランザクションをロールバックし、すべてのLCRを含めてトランザクション全体をエラー・キューに置きます。

  適用サーバーが完了済トランザクションをコミットした場合、そのトランザクションは適用される。トランザクションをエラー・キューに配置してコミットした場合にも、トランザクションは適用される。

  インバウンド・サーバーの各適用サーバーの状態は、V$XSTREAM_APPLY_SERVER動的パフォーマンス・ビューを問い合せることによって表示できます。

リーダー・サーバーおよび適用サーバー・プロセス名はASnnであり、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 Streams概要および管理

  • 適用パラメータの詳細は、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が示す挿入とは異なる値を挿入することができますし、プロシージャ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 Streams適用プロセスの最も古いSCNに対応します。

  処理済最低位置は、この位置以下のLCRがインバウンド・サーバーで処理済であることを示します。クライアントがインバウンド・サーバーに再連結されると、インバウンド・サーバーでは、処理済最低位置以下の位置のLCRがすべて破棄されるため、処理済最低位置より大きい位置のLCRのみを送信する必要があります。

クライアント・アプリケーションが異常停止した場合は、クライアント・アプリケーションとインバウンド・サーバー間の接続は自動的に切断されます。再起動時、クライアント・アプリケーションで処理済最低位置がインバウンド・サーバーから取り出され、この処理済最低位置から変更を取り出すように取得エージェントに指示が出されます。

XStream Inインタフェースを使用してクライアント・アプリケーションのリカバリ時間を制限するため、クライアント・アプリケーションから空のトランザクションなどのアクティビティを定期的にインバウンド・サーバーに送信できます。行LCRにはコミット・トランザクション制御ディレクティブを含めることができます。サーバーに送信するLCRが存在しない場合、インバウンド・サーバーの処理済最低位置を進めるように、コミット・ディレクティブが含まれた行LCRをクライアント・アプリケーションから送信できます。このアクティビティは、インバウンド・サーバーの処理済最低位置を進めるように承認する役割を果たします。

位置3の後、インバウンド・サーバーに送信する、関連する変更はありません。クライアント・アプリケーションで位置101までのすべての変更が処理されて、インバウンド・サーバーが再起動した場合、再起動後、クライアント・アプリケーションは、位置4以降の外部データベースのすべての変更を再確認する必要があります。インバウンド・サーバーの処理済最低位置が3であるため、再確認が必要になります。

そうではなく、hr.employees表に対する関連する変更がない場合でも、クライアント・アプリケーションからコミットをインバウンド・サーバーに定期的に送信するものと想定してください。

位置	変更	クライアント・アプリケーションのアクティビティ
1	hr.employees表への挿入	インバウンド・サーバーに変更が含まれた行LCRを送信する
2	oe.orders表への挿入	なし
3	コミット	コミット・ディレクティブが含まれた行LCRをインバウンド・サーバーに送信する
4	oe.orders表に挿入	なし
5	oe.orders表の更新	なし
6	コミット	なし
7	コミット	なし
...	... (外部データ・ソースでのアクティビティ。ただし、hr.employees表に対する変更なし)	それぞれにコミット・ディレクティブが含まれた複数の行LCRをインバウンド・サーバーに送信する
100	oe.orders表に挿入	なし
101	コミット	コミット・ディレクティブが含まれた行LCRをインバウンド・サーバーに送信する

この場合、インバウンド・サーバーでは、クライアント・アプリケーションによって送信された行LCRのすべてを処理したら、処理済最低位置を101に進めます。インバウンド・サーバーが再起動すると、処理済最低位置は101になり、クライアント・アプリケーションは、位置3までのすべての変更を確認する必要はありません。

サンプルXStreamクライアント・アプリケーションのサンプル・アプリケーションでは、コミット・ディレクティブが含まれた行LCRをインバウンド・サーバーに送信するコードが含まれています。これらのコミット・ディレクティブは、「ping LCR」と呼ばれる場合があります。サンプルXStreamクライアント・アプリケーションで「ping」という単語を検索して、このコードが含まれているアプリケーションの部品を検索します。

例8-1 インバウンド・サーバーの処理済最低位置の進行

クライアント・アプリケーションと外部データ・ソースについて考えてみます。クライアント・アプリケーションでは、hr.employees表に対する変更をインバウンド・サーバーに処理のために送信しますが、外部データ・ソースには、他の多くの表(oe.orders表など)が含まれています。

次の変更が外部のデータ・ソースに対して実行されるものとします。

位置	変更	クライアント・アプリケーション・アクティビティ
1	hr.employees表に挿入	インバウンド・サーバーに変更を含む行LCRを送信します
2	oe.orders表に挿入	なし
3	コミット	コミット・ディレクティブを含む行LCRをインバウンド・サーバーに送信します
4	oe.orders表に挿入	なし
5	oe.orders表の更新	なし
6	コミット	なし
7	コミット	なし
...	...(外部データ・ソースでのアクティビティ、ただしhr.employees表への変更はなし)	なし
100	oe.orders表に挿入	なし
101	コミット	なし

クライアント・アプリケーションは、外部データ・ソースから変更を取得し、適切なLCRを生成し、LCRをインバウンド・サーバーに送信します。そのため、インバウンド・サーバーでは、次のLCRを受信します。

• 位置1の行LCR

• 位置3の行LCR

関連項目:

• LCRストリーム内の位置の順序

• インバウンド・サーバーの位置情報の表示

8.4 XStream Inおよびパフォーマンスの考慮事項

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よりも小さい場合、即時適用が開始される前にトランザクションがディスクにオーバーフローし、インバウンド・サーバーでは、ディスクにオーバーフローしたトランザクションに対して即時適用を使用できません。

関連項目:

• Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

• インバウンド・サーバーで発生した即時エラーの管理

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では、トラッキング用の表が使用されます。

関連項目:

Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.4.3 トランザクション適用スケジューリングの最適化

ターゲット表の制約がソース表での制約と一致する場合は、インバウンド・サーバーのcompute_lcr_dep_on_arrival適用パラメータをYに設定して、依存性の計算を最適化できます。

制約が一致していない場合は、この適用パラメータをN(デフォルト)に設定します。

この適用パラメータがYに設定されている場合、トランザクションのLCRの受信時に依存性が計算されます。この適用パラメータがNに設定されている場合、依存性は、コミットされたトランザクションのすべてのLCRを受信した後にのみ計算されます。

compute_lcr_dep_on_arrival適用パラメータの設定に関係なく、キー列のビフォア・イメージが、インバウンド・サーバーで受信したLCRで使用可能である必要があります。キー列には、主キー列、外部キー列、一意制約列が含まれます。インバウンド・サーバーでXStream Out構成の取得プロセスによって取得された変更を適用するXStream構成では、サプリメンタル・ロギングによって、必要な情報がLCRにあることが保証されます。

関連項目:

• 必要な場合のサプリメンタル・ロギングの構成

• Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

8.5 XStream Inとセキュリティ

クライアント・アプリケーションおよびXStreamコンポーネントに関連するセキュリティに加え、インバウンド・サーバーの適用ユーザーに必要な権限について理解します。

関連項目:

• XStreamのセキュリティ・モデル

• Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

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リファレンスを参照

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管理者の構成を参照

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パッケージで適用ユーザーに権限を付与します。

関連項目:

• XStream管理者の構成

• インバウンド・サーバーの適用ユーザーの変更

• GRANT_ADMIN_PRIVILEGEプロシージャの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照

8.6 XStream Inと他のOracle Databaseコンポーネント

XStream Inは、他のOracle Databaseコンポーネントと連携して動作できます。

8.6.1 XStream InおよびOracle Real Application Clusters

Oracle Real Application Clusters (Oracle RAC)環境での変更を適用するようにインバウンド・サーバーを構成できます。

インバウンド・サーバーは、接続したOracle RACインスタンスで実行されます。このインスタンスに障害が発生した場合、残っているインスタンスに接続し、インバウンド・サーバーを再び起動できます。

関連項目:

• インバウンド・サーバー

• Oracle Real Application Clusters管理およびデプロイメント・ガイド

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がレプリケートされないようにレプリケーション環境に指示する必要があります。

これらの条件が満たされている場合、次の手順を実行します。

1. レプリケーションを停止します。
2. トランスポータブル表領域を使用して、レプリケーション環境にある各データベースにデータをインポートします。
3. レプリケーションを再起動します。

関連項目:

• トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。

• タグ付けされたLCRの詳細は、Oracle Streamsレプリケーション管理者ガイドを参照

8.6.4 XStream Inとマルチテナント環境

マルチテナント環境によって、移植可能な一連のスキーマ、オブジェクトおよび関連構造をOracleデータベースに含めることができ、アプリケーションには論理的に別のデータベースのように見えます。

この自己完結型コレクションは、プラガブル・データベース(PDB)と呼ばれます。1つのマルチテナント・コンテナ・データベース(CDB)には複数のPDBが格納されます。また、これはアプリケーション・コンテナも含むことができます。アプリケーション・コンテナは、アプリケーション・ルートとそれに関連付けられたすべてのアプリケーションPDBから成るCDBのオプション・コンポーネントです。アプリケーション・コンテナには、1つ以上のアプリケーションのデータが格納されています。アプリケーション・コンテナは、アプリケーションのメタデータおよび共通データを共有します。CDBでは、CDBルート、各PDB、各アプリケーション・ルートおよび各アプリケーションPDBのどれもがコンテナです。

この項では、マルチテナント・アーキテクチャの概念を理解していることを前提としています。詳細はOracle Database概要を参照してください。

CDBでは、インバウンド・サーバーは、1つのソース・データベースからLCRを受信し、現在のコンテナ(1つのPDB、1つのアプリケーション・ルート、1つのアプリケーションPDBまたはCDBルート)でのみ変更を実行するように制限されています。1つのインバウンド・サーバーでは、CDB内の複数のコンテナに変更を適用できません。

インバウンド・サーバーがCDBルートにある場合、適用ユーザーは共通ユーザーである必要があります。インバウンド・サーバーがアプリケーション・ルートにある場合、適用ユーザーは共通ユーザーまたはアプリケーション共通ユーザーである必要があります。インバウンド・サーバーがPDBまたはアプリケーションPDBにある場合、適用ユーザーは共通ユーザーまたはローカル・ユーザーにすることができます。

関連項目:

• システム作成ルールとマルチテナント環境

• Oracle Database管理者ガイド