1. XStreamガイド
  2. XStream In
  3. XStream Inの概念

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コンポーネントと連携して動作できます。

8.1 XStream Inの概要

XStreamによって、リモート・クライアント・アプリケーションはOracle以外のデータベースやファイルシステムなどの別のシステムからOracleデータベースに情報を送信できます。

XStream Inでは、クライアント・アプリケーションからOracleデータベースに情報を送信するための、効率的なトランザクション・ベースのインタフェースが提供されます。XStream Inでは、データ・レプリケーション、監査、変更データの取得など、様々な方法でOracle Databaseに移入されている情報を利用できます。XStream Inでは、OCIおよびJavaインタフェースの両方がサポートされます。

ほぼリアルタイムでトランザクション・ベースの異機種間DML変更がOracleデータベースに対して行われる場合、OracleデータベースへのDML変更を直接作成するOCIクライアント・アプリケーションと比べて、XStream Inの方が効率的です。

XStream Inでは、Oracle Streamsの次の機能が使用されます。

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

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

  • ラウンド・トリップが最小限である情報のストリーミング・ネットワーク送信

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

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

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

関連項目:

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

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

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

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

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

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

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

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

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

図8-1の説明が続きます
「図8-1 XStream Inインバウンド・サーバー」の説明

注意:

インバウンド・サーバーはキューを使用しますが、このキューは図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)などのようにする必要があります。

注意:

  • COMPATIBLE初期化パラメータを12.0.0に、MAX_STRING_SIZE初期化パラメータをEXTENDEDに設定している場合、Oracle Database 12cでは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を処理することもできます。適用ハンドラを使用すると、インバウンド・サーバーにより、SQL文のコレクションまたはユーザー定義のPL/SQLプロシージャにLCRが渡されて処理されます。適用ハンドラでは、カスタマイズした方法でLCRを処理できます。

適用ハンドラにはいくつかのタイプがあります。この項では、適用ハンドラを次のカテゴリに分けて説明します。

表8-1 適用ハンドラの特性

カテゴリ 説明

メカニズム

適用ハンドラがLCRの処理に使用する手段のことです。適用ハンドラに使用されるメカニズムは、SQL文、またはユーザー定義のPL/SQLプロシージャです。

LCRのタイプ

適用ハンドラによって処理されるLCRのタイプです。LCRタイプには、行LCR、DDL LCRまたはトランザクション制御ディレクティブがあります。

有効範囲

適用ハンドラに設定されたレベルのことです。有効範囲は、1つの表に対する1つの操作か、またはすべてのデータベースに対するすべての操作のいずれかになります。

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

各インバウンド・サーバーに割り当てられた特定のタイプの適用ハンドラの数。割当て数は1つまたは複数のいずれかになります。

注意:

これらのハンドラの詳細とその使用方法については、Oracle Streams概要および管理を参照してください。

  • DMLハンドラ
    DMLハンドラは、インバウンド・サーバーによって受信された行LCRを処理します。
  • エラー・ハンドラ
    エラー・ハンドラは、プロシージャDMLハンドラに似ています。ただしエラー・ハンドラは、特定の表に対して特定の操作を行うための行LCRをインバウンド・サーバーが適用する際、適用エラーが発生した場合にのみ呼び出されます。
  • DDLハンドラ
    DDLハンドラでは、PL/SQLプロシージャを使用してDDL LCRを処理します。
  • プリコミット・ハンドラ
    プリコミット・ハンドラはPL/SQLプロシージャを使用して、行LCRが含まれるトランザクションのコミット・ディレクティブを処理します。
8.2.3.1 DMLハンドラ

DMLハンドラは、インバウンド・サーバーによって受信された行LCRを処理します。

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

  • 文DMLハンドラ
    文DMLハンドラでは、SQL文のコレクションを使用して行LCRを処理します。
  • プロシージャDMLハンドラ
    プロシージャ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 プリコミット・ハンドラ

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

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

  • メカニズム: ユーザー定義の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動的パフォーマンス・ビューを問い合せることによって表示できます。

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

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

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

リーダー・サーバーおよび適用サーバー・プロセス名はASnnであり、nnには文字および数字を含めることができます。適用サーバーで処理されているトランザクションに、適用されているかどうかが不明な別のトランザクションとの依存関係がある場合、適用サーバーはコーディネータ・プロセスに接続して指示を待ちます。コーディネータ・プロセスは、トランザクションが正しい順序で適用およびコミットされていることを確認するため、すべての適用サーバーを監視します。

関連項目:

8.2.6 インバウンド・サーバーの考慮事項

インバウンド・サーバーにはいくつかの考慮事項があります。

XStreamインバウンド・サーバーの考慮事項は次のとおりです。

  • DBMS_DDLパッケージのSET_TRIGGER_FIRING_PROPERTYプロシージャを使用すると、DMLまたはDDLトリガーの起動プロパティを制御できます。このプロシージャでは、トリガーを常に起動するか、1回起動するか、インバウンド・サーバーによって変更が行われたときのみ起動するかを指定できます。トリガーが1回起動されるように設定されている場合、ユーザー・プロセスによる変更が行われたときに起動されますが、インバウンド・サーバーによる変更が行われたときには起動されません。トリガーの起動プロパティは、適用プロセスとインバウンド・サーバーで同様に動作します。

  • クライアント・アプリケーションによってインバウンド・サーバーに送信されたLCRはトランザクションIDの値が指定されていない可能性があるため、インバウンド・サーバーでは、ignore_transaction適用パラメータの設定は無視されます。

  • クライアント・アプリケーションによってインバウンド・サーバーに送信されたLCRはSCNの値が指定されていない可能性があるため、インバウンド・サーバーでは、maximum_scn適用パラメータの設定は無視されます。

    関連項目:

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データ・ディクショナリ・ビューを問い合せることで、適用エラーの詳細情報を表示できます。これらのビューには、エラー・トランザクションでエラーが発生した行に関する情報が含まれます。

エラー・キューには、データベースで実行中のインバウンド・サーバーによって正常に適用できなかったトランザクションに関する情報が格納されます。1つのトランザクションには、多くの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位置に関連する概念について説明します。

各位置はバイト比較をサポートするフォーマット(base-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

関連項目:

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よりも少ない場合は、即時適用が開始される前にトランザクションがディスクに書き込まれますが、ディスクに書き込まれたトランザクションには即時適用を使用できません。

関連項目:

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にあることが保証されます。

関連項目:

8.5 XStream Inとセキュリティ

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

関連項目:

8.5.1 XStream Inクライアント・アプリケーションとセキュリティ

XStream Inを使用すると、アプリケーションがLCRをインバウンド・サーバーに送信でき、インバウンド・サーバーは、LCRのデータベース変更をデータベースに適用できます。

JavaおよびOCIクライアント・アプリケーションは、データベースで作成されたXStreamインバウンド・サーバーに接続する前に、Oracle Databaseに接続する必要があります。接続したユーザーはインバウンド・サーバーに対して構成された適用ユーザーと同じである必要があります。そうでない場合は、エラーが発生します。

XStreamはXStreamInクラスのXStream attachメソッドのクライアント・アプリケーションによって作成されたOracle JDBC接続インスタンスを受け入れるため、XStream JavaレイヤーAPIは、Oracle JDBCセキュリティに依存しています。接続したユーザーはXStreamユーザーとして検証されます。

関連項目:

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人のユーザーは多数のインバウンド・サーバーに関連付けることができます。

DBMS_XSTREAM_AUTHパッケージのGRANT_ADMIN_PRIVILEGEプロシージャでprivilege_typeパラメータにAPPLYを指定して、適用ユーザーに権限を付与します。

関連項目:

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

関連項目:

8.6.2 XStream Inおよびフラッシュバック・データ・アーカイブ

インバウンド・サーバーは、論理変更レコード(LCR)にカプセル化された変更を、フラッシュバック・データ・アーカイブの表に適用できます。

インバウンド・サーバーでは、次のDDL文もサポートされています。

  • CREATE FLASHBACK ARCHIVE

  • ALTER FLASHBACK ARCHIVE

  • DROP FLASHBACK ARCHIVE

  • FLASHBACK ARCHIVE句を指定したCREATE TABLE

  • FLASHBACK ARCHIVE句を指定したALTER TABLE

関連項目:

8.6.3 XStream Inおよびトランスポータブル表領域

トランスポータブル表領域を使用して、XStreamレプリケーション環境に関係しているデータベースにデータをインポートできます。

この項の手順は、次の条件が満たされた場合に適用されます。

  • レプリケーションの構成は、インバウンド・サーバーがXStream Out構成の取得プロセスによって取得された変更を適用するものです。

  • トランスポータブル表領域のインポート対象データは、レプリケーション環境にある各データベースに含まれている必要があります。

  • インポート操作が完了した後、インポートされたデータに対する変更がレプリケートされます。

また、ルールによって、タグ付きLCRがレプリケートされないように、レプリケーション環境に指示します。

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

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

関連項目:

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内で行われた操作はレプリケートできます。

関連トピック