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

3 XStream Outの概念

XStream Outに関連する概念について理解します。

関連項目:

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 取得プロセス

取得プロセスに関連する概念について理解します。

3.2.1 取得プロセスの概要

取得プロセスはオプションのOracleバックグラウンド・プロセスであり、データベースのREDOログをスキャンし、データベース・オブジェクトに対するDML変更とDDL変更を取得します。

REDOログの主要な機能は、データベースに対して行われた変更をすべて記録することです。取得プロセスでは、REDOログからデータベース変更が取得され、変更が生成されたデータベースは、取得プロセスのソース・データベースと呼ばれます。

取得プロセスはデータベースの変更を取得すると、論理変更レコード(LCR).と呼ばれる特殊なメッセージ・フォーマットに変換しますXStream Out構成の取得プロセスでは、アウトバウンド・サーバーにこれらのLCRが送信されます。

図3-1では取得プロセスを示しています。

図3-1 取得プロセス

図3-1の説明が続きます
「図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、メディア・タイプ

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

3.2.2.1 IDキーLCR

IDキーLCRは特別なタイプの行LCRです。IDキーLCRにより、XStreamクライアント・アプリケーションで、サポートされていないデータ型を含む行に対する変更の処理が可能になります。

XStream Outでは行LCRの次のデータ型は完全にはサポートされていません。

  • BFILE

  • 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)以降である必要があります。

3.2.4.2.1 リアルタイム・ダウンストリーム取得

アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。

リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。

リアルタイム・ダウンストリーム取得構成は、次のように機能します。

  • REDO転送サービスがREDOデータをダウンストリーム・データベースに同期または非同期に送信します。同時に、ログ・ライター・プロセス(LGWR)は、REDOデータをソース・データベースのオンラインREDOログに記録します。

  • ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)が、ネットワークを介してREDOデータを受信し、スタンバイREDOログにREDOデータを格納します。

  • ソース・データベースでログ・スイッチが発生すると、ダウンストリーム・データベースでもログ・スイッチが発生し、ダウンストリーム・データベースのARCHnプロセスによって、現行のスタンバイREDOログ・ファイルがアーカイブされます。

  • リアルタイム・ダウンストリーム取得プロセスは、可能な場合は常にスタンバイREDOログからの変更を取得し、必要に応じてアーカイブ済スタンバイREDOログ・ファイルからの変更を取得します。取得プロセスは、遅延が発生すると、アーカイブ済スタンバイREDOログ・ファイルの変更を取得できるようになります。遅延が解消されたら、スタンバイREDOログからの変更の取得を再開します。

図3-2 リアルタイム・ダウンストリーム取得

図3-2の説明が続きます
「図3-2 リアルタイム・ダウンストリーム取得」の説明

注意:

同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。

3.2.4.2.2 アーカイブ・ログ・ダウンストリーム取得

リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、1つのダウンストリーム・データベースで複数のソース・データベースからダウンストリーム取得プロセスを実行できるというメリットがあります。

アーカイブ・ログ・ダウンストリーム取得構成では、ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイルの変更が取得されます。アーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーするには、REDO転送サービス、DBMS_FILE_TRANSFERパッケージ、ファイル転送プロトコル(FTP)などのメカニズムを使用します。

図3-3 アーカイブ・ログ・ダウンストリーム取得

図3-3の説明が続きます
「図3-3 アーカイブ・ログ・ダウンストリーム取得」の説明

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に設定する必要があります。そうでない場合は、エラーが発生します。

関連項目:

ダウンストリーム取得プロセスでデータベース・リンクが使用されている場合、取得プロセスの作成時にDBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されるタイミングの詳細は、Oracle Streamsレプリケーション管理者ガイドを参照

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バックグラウンド・プロセスであり、プロセス名はCPnn (nnは文字または数字)です。取得プロセスは、LogMinerのインフラストラクチャを使用してREDOログから変更を取得します。LogMinerは、XStreamによって自動的に構成されます。取得プロセスの作成、変更、起動、停止および削除を行うことができます。また、取得プロセスで取得される変更を制御する取得プロセスのルールを定義できます。

parallelism取得プロセス・パラメータにより、取得プロセスの並列性が制御されます。取得プロセスの並列性が0(ゼロ、XStream Outのデフォルト)である場合は、取得プロセスでは、サブコンポーネントを使用してその作業を実行しません。かわりに、CPnnプロセスによって、データベース変更を取得するために必要なすべてのタスクが実行されます。

取得プロセスの並列性が0より大きい場合は、取得プロセスでは、基礎となるLogMinerプロセス名MSnnを使用します。ここで、nnには文字および数字が含まれることがあります。取得プロセスの並列性が0(ゼロ)の場合、取得プロセスでは、このプロセスを使用しません。

取得プロセスの並列性が0を超えている場合、取得プロセスは、次のサブコンポーネントで構成されます。

  • 1つのリーダー・サーバー。REDOログを読み取って複数の領域に分割します。

  • 1つ以上のプリペアラ・サーバー。リーダー・サーバーによって定義された領域をパラレルでスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。事前フィルタ処理では、変更に関する部分的な情報(変更のスキーマ名やオブジェクト名など)が評価のためにルール・エンジンに送信され、評価の結果が受信されます。parallelism取得プロセス・パラメータを使用してプリペアラ・サーバーの数を制御できます。

  • 1つのビルダー・サーバー。プリペアラ・サーバーからのREDOレコードをマージします。これらのREDOレコードには、部分評価の実行中にTRUEと評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号(SCN)の順序を保持し、マージされたREDOログ・レコードを取得プロセスに渡します。

  • 取得プロセス(CPnn)。マージされたREDOレコードをビルダー・サーバーから受信すると、各変更に対して次のアクションを実行します。

    • 変更をLCR形式でフォーマットします

    • プリペアラ・サーバーによって実行された部分評価で、LCRの変更に対する結果が生成されていない場合は、LCRを完全評価のためにルール・エンジンに送信します。

    • LCRの完全評価が実行された場合は、その結果を受信します

    • LCRが取得プロセスのネガティブ・ルール・セットのルールを満たすか、ポジティブ・ルール・セットのルールを満たさない場合は、LCRを廃棄します。

    • LCRが取得プロセスのポジティブ・ルール・セット内のルールを満たしている場合、LCRが取得プロセスに関連付けられているキューにエンキューされます。

リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーはそれぞれが1つのプロセスである。

3.2.7 取得プロセスの状態

取得プロセスの状態は、取得プロセスが現在行っている処理を示します。

取得プロセスの状態は、V$XSTREAM_CAPTURE動的パフォーマンス・ビューのSTATE列を問い合せることによって表示できます。

関連項目:

Oracle Databaseリファレンス

3.2.8 取得プロセス・パラメータ

取得プロセス・パラメータによって、取得プロセスの動作が制御されます。

たとえば、parallelism取得プロセス・パラメータによって、取得プロセスで使用されるプリペアラ・サーバーの数が制御され、time_limit取得プロセス・パラメータによって、取得プロセスが自動的に停止されるまでの実行時間が指定されます。DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャを使用して取得プロセス・パラメータを設定します。作成後の取得プロセスは、最初に起動する前に環境に合わせて取得プロセス・パラメータを設定できるように無効になっています。

関連項目:

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

3.2.9 取得プロセスのチェックポイントおよびXStream Out

チェックポイントは、取得プロセスの現在の状態に関する情報です。この情報は、取得プロセスを実行しているデータベースのデータ・ディクショナリに永続的に格納されます。

取得プロセスでは、チェックポイント間隔と呼ばれる定期的な間隔でチェックポイントの記録が試行されます。

3.2.9.1 必須チェックポイントSCN

取得プロセスでREDOデータが必要となる最小のチェックポイントに対応するシステム変更番号(SCN)は、必須チェックポイントSCNと呼ばれます。

必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが、取得プロセスで使用可能である必要があります。取得プロセスを停止して再起動すると、REDOログのスキャンは、必須チェックポイントSCNに対応するSCNから開始されます。必須チェックポイントSCNは、データベースが予期せず停止した場合のリカバリで重要となります。また、取得プロセス用に先頭SCNをリセットする場合は、取得プロセスの必須チェックポイントSCN以下の値に設定する必要があります。取得プロセスの必須チェックポイントSCNを確認するには、ALL_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せます。

3.2.9.2 最大チェックポイントSCN

取得プロセスによって記録された最後のチェックポイントに対応するSCNは、最大チェックポイントSCNと呼ばれます。

最大チェックポイントSCNは、取得プロセスの必須チェックポイントSCNより小さいことも大きいこともあります。取得プロセスが新規であり、物理的なチェックポイントがまだ記録されていない場合、最大チェックポイントSCNは0(ゼロ)のこともあります。

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が表示されます。

関連項目:

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

3.2.10 取得プロセスに関連するSCN値

特定のシステム変更番号(SCN)値は、取得プロセスにとって重要です。

1つ以上の取得プロセスのシステム変更番号を表示するには、ALL_CAPTUREデータ・ディクショナリ・ビューを問い合せます。

3.2.10.1 取得済SCNおよび適用済SCN

取得済SCNは、取得プロセスによってスキャンされたREDOログの最新の変更に対応するSCNです。取得プロセスの適用済SCNは、関連するアウトバウンド・サーバーによって最後に処理されたLCRのSCNです。

適用済SCNより小さいすべてのLCRは、取得プロセスによって取得された変更を処理するすべてのアウトバウンド・サーバーで処理されています。取得プロセスの適用済SCNは、取得プロセスで取得された変更を処理するアウトバウンド・サーバーの最低水位標SCNと等価です。

3.2.10.2 先頭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は、このデータ・ディクショナリ・ビルドに対応します。

3.2.10.2.2 開始SCN

開始SCNは、取得プロセスが変更の取得を開始するSCNです。

開始SCNは、取得プロセスが変更の取得を開始するSCNです。取得プロセスの作成時に先頭SCNとは別に開始SCNを指定するか、または取得プロセスを変更して開始SCNを設定できます。取得プロセスの通常の操作については開始SCNを変更する必要はありません。取得プロセスから変更を受け取るいずれかの接続先データベースでPoint-in-Timeリカバリを実行する必要がある場合、通常は取得プロセスの開始SCNをリセットします。このような場合は、取得プロセスを使用して、Point-in-Timeリカバリの後にソース・データベースで行われた変更を取得することができます。

注意:

開始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ログ・ファイルが必要です。

3.3 アウトバウンド・サーバー

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は、アウトバウンド・サーバーの構成を示しています。

図3-4 XStream Outのアウトバウンド・サーバー

図3-4の説明が続きます
「図3-4 XStream Outのアウトバウンド・サーバー」の説明

クライアント・アプリケーションは、必要に応じて、アウトバウンド・サーバーから連結解除できます。クライアント・アプリケーションが再接続されると、アウトバウンド・サーバーでは、連結解除されたときにクライアント・アプリケーションが対象としていた、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動的パフォーマンス・ビューを問い合せることによって表示できます。

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

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

  • 適用サーバー。XStreamクライアント・アプリケーションにLCRを送信します。適用サーバーはプロセスです。適用サーバーでエラーが検出された場合は、ALL_APPLYビューにエラーの情報が記録されます。

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

リーダー・サーバーおよび適用サーバー・プロセス名はASnnであり、nnには文字および数字を含めることができます。

関連項目:

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のみが送信されます。

関連項目:

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

関連項目:

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

3.4 LCRの位置とXStream Out

XStream Outアウトバウンド・サーバーは、取得プロセスによって取得されたLCRをクライアント・アプリケーションにストリームします。LCRの位置により、トランザクション内のLCRのストリームにおける配置が識別されます。

関連項目:

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

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では存在しません。

関連項目:

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

3.4.2 XStream Outの処理済最低位置および再起動可能性

処理済最低位置は、その位置未満のすべてのトランザクションがクライアント・アプリケーションで処理された位置を示します。

アウトバウンド・サーバーまたはクライアント・アプリケーションが異常終了した場合、この2つの間の接続は自動的に切断されます。この場合、クライアント・アプリケーションでは、すべての未完了のトランザクションをロールバックする必要があります。

クライアント・アプリケーションでは、クライアント・アプリケーションまたはアウトバウンド・サーバー(あるいはその両方)の再起動後に適切にリカバリするには、処理済最低位置を保持する必要があります。処理済最低位置は、クライアント・アプリケーションでその値以下のすべてのLCRが処理されたことを示します。クライアント・アプリケーションでは、使用するトランザクションごとに処理済最低位置を更新できます。

クライアント・アプリケーションがアウトバウンド・サーバーに連結すると、処理済最低位置に関連する次の状態が発生する可能性があります。

  • クライアント・アプリケーションでは、アウトバウンド・サーバーの処理済最低位置以上の処理済最低位置をアウトバウンド・サーバーに渡すことができます。この場合、アウトバウンド・サーバーでは、クライアント・アプリケーションの処理済最低位置よりも大きい位置を持つ最初のLCRから、LCRのストリーミングを再開します。

  • クライアント・アプリケーションでは、アウトバウンド・サーバーの処理済最低位置未満の処理済最低位置をアウトバウンド・サーバーに渡すことができます。この場合、アウトバウンド・サーバーでエラーが発生します。

  • クライアント・アプリケーションでは、NULLをアウトバウンド・サーバーに渡すことができます。この場合、アウトバウンド・サーバーでは、処理済最低位置が自動的に判別され、その処理済最低位置よりも大きい位置を持つLCRから、LCRのストリーミングが開始されます。これが発生した場合、クライアント・アプリケーションでは、クライアント・アプリケーションの処理済最低位置以下の位置を持つ各LCRを抑制または破棄する必要があります。

関連項目:

アウトバウンド・サーバーの処理済最低位置の表示

3.4.3 ネットワーク伝達ストリーム

ネットワーク待機時間を最小にするために、アウトバウンド・サーバーでは、時間ベースの確認を使用してクライアント・アプリケーションにLCRをストリームします。たとえば、アウトバウンド・サーバーでは30秒ごとに確認を送信することがあります。

このストリーミング・プロトコルでは、使用可能なネットワーク帯域幅を完全に利用します。パフォーマンスは、送信者と受信者を分離するWide Area Network(WAN)の存在による影響を受けません。アウトバウンド・サーバーにより、基盤のOracle Streamsインフラストラクチャが拡張されます。アウトバウンド・サーバーでは、ストリーミング・パフォーマンス・レートが維持されます。

OCIを使用する場合、OCIクライアント・アプリケーションを介してOCI_ATTR_XSTREAM_ACK_INTERVAL属性を設定することで、間隔の期間を制御できます。デフォルトは30秒です。

Javaを使用する場合、XStreamOutクラスのattachメソッドでbatchIntervalパラメータを設定することで、間隔の期間を制御できます。クライアント・アプリケーションでは、attachメソッドを呼び出す際に、この間隔を指定できます。

間隔が大きい場合、アウトバウンド・サーバーでは各確認間隔に、より多くのLCRをストリーム・アウトできます。ただし、間隔が長くなると、クライアント・アプリケーションからアウトバウンド・サーバーに処理済最低位置を送信できる頻度が低くなります。そのため、間隔が長いと、アウトバウンド・サーバーで保持されている処理済最低位置が最新のものではない可能性があります。この場合、アウトバウンド・サーバーの再起動時に、クライアント・アプリケーションで保持されている処理済最低位置に対応するLCRよりも前の位置にあるLCRの処理を開始する必要があります。このため、より多くのLCRが再送信される可能性があり、クライアント・アプリケーションでは適用済のLCRを破棄する必要があります。

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以上に設定されている場合にのみサポートされます。

関連項目:

3.6 XStream Outとセキュリティ

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

関連項目:

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ユーザーとして検証されます。

関連項目:

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

3.6.3 取得プロセスの取得ユーザーに必要な権限

変更は、取得プロセスの取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。取得ユーザーは、これらのアクションの実行に必要な権限を持っている必要があります。

取得ユーザーには次の権限が必要です。

  • 取得プロセスで使用するルール・セットのEXECUTE権限

  • ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

  • LCRを取得プロセス・キューにエンキューする権限

1つの取得プロセスは1ユーザーにしか関連付けできませんが、1ユーザーは複数の取得プロセスに関連付けることができます。

GRANT_ADMIN_PRIVILEGEプロシージャでprivilege_typeパラメータにCAPTUREを指定することで、DBMS_XSTREAM_AUTHパッケージで取得ユーザーに権限を付与します。

関連項目:

3.6.4 アウトバウンド・サーバーの接続ユーザーに必要な権限

アウトバウンド・サーバーは接続ユーザーのセキュリティ・ドメイン内で、XStreamクライアント・アプリケーションにLCRを送信します。

接続ユーザーは、アウトバウンド・サーバーのルール・セットを満たしているLCRをXStreamクライアント・アプリケーションに送信します。また、接続ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベース変換をすべて実行します。

接続ユーザーには次の権限が必要です。

  • アウトバウンド・サーバーで使用されるルール・セットに対するEXECUTE権限

  • ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限

アウトバウンド・サーバーは1人のユーザーにのみ関連付けることができますが、1人のユーザーを多数のアウトバウンド・サーバーに関連付けることができます。

関連項目:

3.7 XStream Outと他のOracle Databaseコンポーネント

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

3.7.1 XStream OutおよびOracle Real Application Clusters

XStream Outは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データベースとして構成できます。

関連項目:

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によって自動的に管理されます。

関連項目:

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インスタンスで実行される必要があります。

アウトバウンド・サーバーで使用されるキューが含まれているキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに譲渡されます。また、現行の所有者インスタンスが使用不可能になった場合、アウトバウンド・サーバーは、別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。さらに、所有者インスタンスが使用できなくなったときにアウトバウンド・サーバーが有効化されている場合、アウトバウンド・サーバーは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用できなくなったときにアウトバウンド・サーバーが無効になっていた場合、アウトバウンド・サーバーは新しい所有者インスタンスで無効のままです。

関連項目:

3.7.2 XStream Outおよび透過的データ暗号化

XStream Outは、透過的データ暗号化と連携して動作できます。

関連項目:

透過的データ暗号化の詳細は、Oracle Database Advanced Securityガイドを参照

3.7.2.1 取得プロセスおよび透過的データ暗号化

取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。

ローカル取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。ダウンストリーム取得プロセスでは、ダウンストリーム・データベースが暗号化キーストア(認証および署名証明書のコンテナ)をソース・データベースと共有している場合にのみ、暗号化されている列に対する変更を取得できます。キーストアは、ネットワーク・ファイル・システム(NFS)を介して共有するか、または1つのコンピュータ・システムから別のコンピュータ・システムに手動でコピーできます。キーストアがダウンストリーム・データベースと共有されている場合は、ダウンストリーム・データベースのsqlnet.oraファイルのENCRYPTION_WALLET_LOCATIONパラメータにキーストアの場所が指定されていることを確認してください。

ダウンストリーム・データベースにキーストアをコピーする場合は、ソース・データベースのキーストアが変更されるたびに、ソース・データベースからダウンストリーム・データベースにキーストアをコピーしてください。ダウンストリーム・データベースのキーストアに対して、レプリケートされた表の暗号化鍵の変更などの操作は実行しないでください。

ローカル取得プロセスまたはダウンストリーム取得プロセスによって取得された行論理変更レコード(行LCR)内の暗号化された列は、行LCRがバッファ・キューにステージングされると復号化されます。

注意:

取得プロセスによって使用されるREDOログが互換性レベル11.0.0以上のデータベースで生成されている場合、取得プロセスでは、暗号化された列のみがサポートされます。互換性レベルは、COMPATIBLE初期化パラメータによって制御されます。

関連項目:

取得プロセス

3.7.2.2 伝播と透過的データ暗号化

伝播では、透過的データ暗号化を使用して暗号化された列に対する変更を含む行論理変更レコード(行LCR)を伝播できます。

この項の情報は、伝播が組み込まれたXStream構成のみに該当します。標準のXStream構成では、アウトバウンド・サーバーとその取得プロセスが同じデータベース上で構成されるため、伝播は不要です。この項の情報は、伝播が組み込まれていない構成には該当しません。ただし、取得プロセスとアウトバウンド・サーバーが別々のデータベースで構成される可能性があります。この場合、伝播によって取得プロセスのキューからアウトバウンド・サーバーのキューにLCRが送信されます。

伝播によって、暗号化された列とともに行LCRが伝播されると、行LCRがネットワーク上を転送される間に、暗号化された列が復号化されます。必要に応じて、Oracle Advanced Securityの機能を使用して、ネットワーク上でのデータ転送を暗号化できます。

関連項目:

ネットワーク・データの暗号化の構成の詳細は、Oracle Databaseセキュリティ・ガイドを参照

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;

列が暗号化されているすべてのインスタンスで同じキーストアが使用可能でオープンしている必要があるため、必ず、キーストアをダウンストリーム取得データベースにコピーしてください。ダウンストリーム取得の場合は、ダウンストリーム・インスタンスで前述のコマンドを実行する必要もあります。

関連項目:

アウトバウンド・サーバー

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では、フラッシュバック・データ・アーカイブによって使用される内部表に対する変更は取得されません。

関連項目:

3.7.4 XStream OutおよびRecovery Manager

RMANの削除方針は、取得プロセスに影響する可能性があります。

RMANの一部の削除ポリシーおよびコマンドでは、アーカイブREDOログ・ファイルが削除されます。RMANのこれらのポリシーまたはコマンドのいずれかを、1つ以上の取得プロセスに対してREDOログ・ファイルを生成するデータベースで使用する場合は、そのRMANのコマンドが取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しないことを確認してください。

関連項目:

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以上に設定されている場合にのみサポートされます。

関連項目:

3.7.6 XStream Outとマルチテナント環境

マルチテナント環境によって、移植可能な一連のスキーマ、オブジェクトおよび関連構造をOracleデータベースに含めることができ、アプリケーションには論理的に別のデータベースのように見えます。この自己完結型コレクションは、プラガブル・データベース(PDB)と呼ばれます。1つのマルチテナント・コンテナ・データベース(CDB)には複数のPDBが格納されます。CDBでのXStream Outの機能は非CDBでの機能とほとんど同じです。

また、これはアプリケーション・コンテナも含むことができます。アプリケーション・コンテナは、アプリケーション・ルートとそれに関連付けられたすべてのアプリケーションPDBから成るCDBのオプション・コンポーネントです。アプリケーション・コンテナには、1つ以上のアプリケーションのデータが格納されています。アプリケーション・コンテナは、アプリケーションのメタデータおよび共通データを共有します。CDBでは、CDBルート、各PDB、各アプリケーション・ルートおよび各アプリケーションPDBのどれもがコンテナです。

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

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にPDB PDB1が含まれている。

  • 取得プロセスが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パラメータを使用して、この動作を制御できます。