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

3 XStream Outの概念

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

  • XStream Outの概要
    XStream Outでは、OracleデータベースのREDOログからトランザクションを取得して、クライアント・アプリケーションに効率よく送信できます。
  • 取得プロセス
    取得プロセスに関連する概念について理解します。
  • アウトバウンド・サーバー
    XStream Outでは、アウトバウンド・サーバーからクライアント・アプリケーションにデータベース変更が送信されます。
  • LCRの位置およびXStream Out
    XStream Outのアウトバウンド・サーバーでは、取得プロセスで取得したLCRがクライアント・アプリケーションにストリームされます。LCRの位置により、トランザクション内のLCRのストリームにおける配置が識別されます。
  • XStream Outと分散トランザクション
    XStream Outと分散トランザクションに関する考慮事項があります。
  • XStream Outとセキュリティ
    クライアント・アプリケーションとXStreamコンポーネントに関連するセキュリティ、および取得ユーザーと接続ユーザーに必要な権限について理解します。
  • XStream Outと他のOracle Databaseコンポーネント
    XStream Outは、他のOracle Databaseコンポーネントと連携できます。

関連項目:

XStream Outの構成

3.1 XStream Outの概要

XStream OutはOracleデータベースのREDOログからトランザクションを取得し、それらをクライアント・アプリケーションに効率的に送信できます。

XStream Outは、これらの変更をクライアント・アプリケーションにストリームするためのトランザクション・ベースのインタフェースを提供します。クライアント・アプリケーションは、Oracle以外のシステムを含む他のシステム(Oracle以外のデータベースやファイル・システムなど)と相互作用できます。

XStream Out構成では、取得プロセスによってデータベースに対する変更が取得され、アウトバウンド・サーバーに送信されます。この項では、取得プロセスとアウトバウンド・サーバーについて詳しく説明します。

XStream OutにはOCIインタフェースとJavaインタフェースがあり、LOB、LONG、LONG RAW、XMLTypeなど、Oracle Databaseでサポートされるデータ型のほとんどがサポートされます。

関連項目:

3.2 取得プロセス

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

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

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

関連項目:

データ型の詳細は、Oracle Database SQL言語リファレンスを参照してください。

3.2.2.1 IDキーLCR

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

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

  • 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での表に対するサポートのタイプが次のように表示されます。

  • XStream Outで(IDキーLCRを使用せずに)完全にサポートされる表の場合は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

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

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

  • 必須チェックポイントSCN
    取得プロセスでREDOデータが必要となる最小のチェックポイントに対応するシステム変更番号(SCN)は、必須チェックポイントSCNと呼ばれます。
  • 最大チェックポイントSCN
    取得プロセスで記録された最後の物理チェックポイントに対応するSCNは、最大チェックポイントSCNと呼ばれます。
  • チェックポイント保存時間
    チェックポイント保存時間とは、チェックポイントが自動的に消去されるまで取得プロセスによって保持される時間(日数)です。
3.2.9.1 必須チェックポイントSCN

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

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

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データ・ディクショナリ・ビューを問い合せます。

  • 取得済SCNと適用済SCN
    取得済SCNは、取得プロセスでスキャンされたREDOログの最新の変更に対応するSCNです。取得プロセスの適用済SCNは、関連するアウトバウンド・サーバーで最後に処理されたLCRのSCNです。
  • 先頭SCNと開始SCN
    取得プロセスでは先頭SCNと開始SCNが重要です。
3.2.10.1 取得済SCNおよび適用済SCN

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

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

3.2.10.2 先頭SCNおよび開始SCN

取得プロセスでは先頭SCNと開始SCNが重要です。

  • 先頭SCN
    先頭SCNは、取得プロセスで変更を取得できる、REDOログ内の最小SCNです。
  • 開始SCN
    開始SCNは、取得プロセスで変更の取得を開始するSCNです。
  • 先頭SCN以上であることが必要な開始SCN
    取得プロセスの作成時または変更時に開始SCNを指定する場合は、取得プロセスの先頭SCN以上のSCNを指定する必要があります。
3.2.10.2.1 先頭SCN

先頭SCNは、取得プロセスで変更を取得できる、REDOログ内の最小SCNです。

取得プロセスの作成時に先頭SCNを指定する場合、データベースは、指定したSCN以上のREDOデータにアクセスできる必要があります。

DBMS_CAPTURE_ADM.BUILDプロシージャは、ソース・データベースのデータ・ディクショナリをREDOログに抽出します。取得プロセスを作成する際、REDOログのこのデータ・ディクショナリ・ビルドに対応する先頭SCNを指定できます。特に、作成中の取得プロセスの先頭SCNは、次の問合せで返される任意の値に設定できます。 

COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999
COLUMN NAME HEADING 'Log File Name' FORMAT A50
 
SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG
  WHERE DICTIONARY_BEGIN = 'YES';

NAME列に対して返される値は、先頭SCNに相当するSCNが含まれるREDOログ・ファイルの名前です。このREDOログ・ファイルおよびすべての後続のREDOログ・ファイルは、取得プロセスで使用可能であることが必要です。この問合せでFIRST_CHANGE#に対して複数の異なる値が返される場合、DBMS_CAPTURE_ADM.BUILDプロシージャがソース・データベースに対して2回以上実行されています。この場合、作成する取得プロセスに最も適した先頭SCN値を選択します。

場合によっては、取得プロセスの作成時に、DBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されます。このとき、取得プロセスの先頭SCNは、このデータ・ディクショナリ・ビルドに対応します。

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にカプセル化されてアウトバウンド・サーバーに送信されます。アウトバウンド・サーバーでは、LCRをOCIやJavaなどの様々な形式でパブリッシュできます。クライアント・アプリケーションでは、アウトバウンド・サーバーから渡されたLCRを処理することも、ループを使用してアウトバウンド・サーバーからのLCRを待機することもできます。

アウトバウンド・サーバーは、LOB、LONG、LONG、RAWおよびXMLTypeのデータをチャンクに分けてクライアント・アプリケーションに送信します。複数のチャンクから、LOB、LONG、LONG RAW、XMLTypeのいずれかのデータ型の列値が1つ構成されます。

図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 アウトバウンド・サーバーに関する考慮事項

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

アウトバウンド・サーバーに関する考慮事項は次のとおりです。

  • アウトバウンド・サーバーで処理されるLCRは、取得プロセスで取得されたLCRであることが必要です。アウトバウンド・サーバーでは、アプリケーションで作成されたLCRがサポートされません。

  • 個々のアウトバウンド・サーバーは、単一のソース・データベースから取得したLCRを処理できます。ソース・データベースは、LCRにカプセル化された変更がREDOログに生成されたデータベースです。

  • 取得プロセスで取得された変更をアウトバウンド・サーバーで処理するには、この変更のソース・データベースの互換性レベルが10.2.0以上であることが必要です。

  • アウトバウンド・サーバーの取得プロセスは、Oracle Database 11gリリース2 (11.2)以降のデータベースで実行される必要があります。

  • 1つの取得プロセスでアウトバウンド・サーバーと適用プロセスの両方の変更を取得することはできません。ただし、1つの取得プロセスで複数のアウトバウンド・サーバーの変更を取得することは可能です。

  • ストリームの取得プロセスとアウトバウンド・サーバーが別々のデータベースで実行されている場合は、ストリームの自動的な分割とマージが可能です。一方、ストリームの取得プロセスとアウトバウンド・サーバーが同じデータベースで実行されている場合は、ストリームの自動的な分割とマージが不可能です。

  • アウトバウンド・サーバーのLCRが一定期間処理されずバッファ・キューに入っていた場合やトランザクションに多数のLCRがある場合、あるいはメモリー領域が不十分ですべてのLCRを保持できない場合は、メモリーからハード・ディスクにLCRがオーバーフローすることがあります。メモリーからオーバーフローするLCRが最小限である場合、アウトバウンド・サーバーは最も高いパフォーマンスを発揮します。LCRのオーバーフローに関連するアウトバウンド・サーバーの動作は、適用パラメータtxn_age_spill_thresholdとtxn_lcr_spill_thresholdを使用して制御できます。

  • インスタンス化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のストリームにおける配置が識別されます。

  • XStream Outでの位置に関連する追加のLCR属性
    取得プロセスで取得されたLCRには、LCRの位置に関する追加情報が含まれています。
  • XStream Outでの処理済最低位置と再起動性
    処理済最低位置は、その位置より下ですべてのトランザクションがクライアント・アプリケーションによって処理されたことを示します。
  • ストリーミング・ネットワーク送信
    アウトバウンド・サーバーは、ネットワーク・レイテンシを最小限に抑えるために、時間ベースの確認応答を使用してクライアント・アプリケーションにLCRをストリームします。たとえば、アウトバウンド・サーバーは30秒ごとに確認応答を送信する場合があります。

関連項目:

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

3.4.1 XStream Outでの位置に関連する追加のLCR属性

取得プロセスで取得されたLCRには、LCRの位置に関連する追加情報が含まれています。

取得プロセスで取得されたLCRには、LCRの位置に関連する次の属性が追加で含まれています。

  • scn_from_position属性には、LCRのSCNが含まれています。

  • commit_scn_from_position属性には、LCRが属するトランザクションのコミットSCNが含まれています。

注意:

明示的に取得された行LCRには、scn_from_position属性とcommit_scn_from_position属性が含まれていません。

関連項目:

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

3.4.2 XStream Outでの処理済最低位置と再起動性

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

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

クライアント・アプリケーションまたはアウトバウンド・サーバー(あるいはその両方)の再起動後に適切なリカバリが行われるためには、クライアント・アプリケーションの処理済最低位置が維持される必要があります。処理済最低位置は、この値以下の位置にあるすべての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を破棄しなければならなくなります。

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初期化パラメータの値に関係なくサポートされます。Oracle RACソース・データベースで密結合のブランチによって行われる変更のレプリケーションについては、COMPATIBLE初期化パラメータが11.2.0.0以上に設定されている場合にのみサポートされます。

関連項目:

3.6 XStream Outとセキュリティ

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

関連項目:

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

XStream Outではクライアント・アプリケーションにLCRの受信を許可しているため、クライアント・アプリケーションのセキュリティについて考慮する必要があります。

XStream Outアプリケーションは、LCRを受信すると、LCRのコンテンツをファイルに保存するか、Oracle以外のデータベースでLCRを実行するSQL文を生成します。

Javaクライアント・アプリケーションとOCIクライアント・アプリケーションは、Oracleデータベースで作成されたXStreamアウトバウンド・サーバーに連結する前に、そのデータベースに接続する必要があります。接続ユーザーは、アウトバウンド・サーバー用に構成された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ユーザーは複数の取得プロセスに関連付けることができます。

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

関連項目:

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

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

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

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

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

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

1つのアウトバウンド・サーバーは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インスタンスで実行する必要があります。

取得プロセスがそのキューと同じOracle RACインスタンスで実行されていることを確認するには、DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャでuse_rac_serviceパラメータをYに設定します。

取得プロセス・パラメータ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キューの所有者インスタンスで起動および停止されます。コーディネータ・プロセス、およびその対応する適用リーダー・サーバーと適用サーバーは、1つのインスタンスで実行されます。同じ取得プロセスを使用する複数の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ログ・ファイルを削除しないことを確認してください。

  • RMANとローカル取得プロセス
    ローカル取得プロセスを構成した場合、高速リカバリ領域に余裕があるかぎり、RMANはローカル取得プロセスに必要なアーカイブREDOログ・ファイルを削除しません。
  • RMANとダウンストリーム取得プロセス
    ソース・データベースで行われたデータベース変更をダウンストリーム取得プロセスで取得する場合は、アーカイブ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より大きくなった場合です。

    • TO BACKEDUPiinteger TIMESTODEVICE 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初期化パラメータの値に関係なくサポートされます。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のどれもがコンテナです。

CDBと非CDBでは、XStream Outの機能が主に次のように異なります。

  • XStream OutはCDBルートでのみ構成する必要があります。

  • XStream Outは、CDB内のどのコンテナに加えられた変更も認識できます。

  • XStream Outの取得ルールでは、LCRをクライアント・アプリケーションに必要なものに制限できます。システムで生成された取得ルールにより、DBMS_XSTREAM_ADMパッケージのADD_OUTBOUNDプロシージャとCREATE_OUTBOUNDプロシージャに渡されたパラメータに基づいて適切なLCRが選択されます。同じパッケージのADD_*_RULESプロシージャを使用すると、XStream Outのコンポーネントで使用されるルールよりもきめ細かい制御が可能となります。

  • XStream Outのタスクを実行するユーザーは、共通ユーザーであることが必要です。

XStream環境での切断操作とプラグ操作

XStream Outに関係するPDB、アプリケーション・ルートまたはアプリケーションPDBがそのCDBから切断されて別のCDBにプラグインされると、取得プロセスやアウトバウンド・サーバーがコンテナの一部とみなされなくなります。この別のCDBで取得プロセスとアウトバウンド・サーバーを再度構成する必要があります。

アウトバウンド・サーバーが取得プロセスとは別のデータベースで構成されている場合は、切断操作とプラグ操作に関する追加の考慮事項が生じます。

この例では、次のことを想定しています。

  • CDB1というCDBに、PDB1というPDBが含まれています。

  • 取得プロセスはCDB1で構成されており、CDB2というCDBにあるアウトバウンド・サーバーにPDB1からLCRを送信します。

  • PDB1をCDB1から切断し、CDB3というCDBにプラグインします。

CDB2内のアウトバウンド・サーバーにPDB1から引き続きLCRを配信するには、LCRを取得してCDB2に送信する新たな取得プロセスをCDB3で構成する必要があります。

データベースB内のアウトバウンド・サーバーで使用されるルールを変更して、CDB1のルートへの参照をCDB3のルートに変える必要があります。また、PDB1にCDB3で別の名前が付けられている場合は、ルールを変更して新しいPDBの名前を反映させる必要があります。

XStream環境のアプリケーション・コンテナ

CDBに1つ以上のアプリケーション・コンテナがある場合は、CDBルートでXStream Outを構成する必要があります。これによりXStream Outは、アプリケーション・ルートとアプリケーションPDBを含むCDB内のあらゆるコンテナで行われる変更を取得できるようになります。アプリケーション・コンテナで取得された変更は、PDB、アプリケーション・ルート、アプリケーションPDBなどのあらゆるタイプのコンテナに送信できます。

XStreamでは、アプリケーション・ルート間で変更をレプリケートする際に、ALTER PLUGGABLE DATABASE APPLICATION文をレプリケートできます。エラーを回避するには、文を適用するターゲット・アプリケーション・ルートにソース・アプリケーション・ルートと同じアプリケーションがインストールされていることと、そのアプリケーションの名前が両方のアプリケーション・ルートで同じであることが必要です。

アプリケーション・ルートではないコンテナにアプリケーション・ルートから変更をレプリケートする際にエラーが発生しないようにするには、ALTER PLUGGABLE DATABASE APPLICATION文がレプリケートされないようにする必要があります。

XStream OCI APIを使用する場合は、OCIXStreamOutAttachファンクションとOCILCRHeaderGetファンクションを使用して、ALTER PLUGGABLE DATABASE APPLICATION文をレプリケートするかどうかを制御できます。XStream Java APIを使用する場合は、XStreamOut.attachメソッドでmodeパラメータを使用してこの動作を制御できます。

関連トピック