1. XStreamガイド
  2. XStreamの一般的な概念および使用例
  3. XStreamの一般的な概念

2 XStreamの一般的な概念

XStreamの一般的な概念は、XStream OutおよびXStream Inの両方に当てはまります。

関連項目:

2.1 論理変更レコード(LCR)

LCRは、データベース変更を説明する特定の形式のメッセージです。

行LCR、DDL LCRおよび順序LCRという3種類のLCRがあります。XStreamで、LCRはデータベース変更を説明する情報の基本単位です。

XStream Out構成では、取得プロセスがLCRを取得し、アウトバウンド・サーバーに送信できます。アウトバウンド・サーバーは、LCRをXStreamクライアントのアプリケーションに送信できます。

XStream In構成では、XStreamクライアント・アプリケーションがLCRを作成し、インバウンド・サーバーに送信できます。インバウンド・サーバーは、データベース内のデータベース・オブジェクトにデータベースの変更を直接適用することも、カスタマイズされた方法でLCRを処理することもできます。

  • 行LCR
    行LCRでは、1行のデータに対する変更、あるいは1行の1つのLOB列、LONG列、LONG RAW列、またはXMLType列に対する変更が記述されます。
  • DDL LCR
    DDL LCRでは、データ定義言語(DDL)の変更が記述されます。
  • 行LCRおよびDDL LCRのその他の情報
    前の項で説明した情報の他に、その他の情報(LCR属性)をオプションとして行LCRとDDL LCRに含めることができます。
  • 順序LCR
    順序LCRは、順序値に関する情報を含む行LCRです。順序データベース・オブジェクトが順序値を生成します。
  • LCRストリーム内の位置の順序
    各LCRには位置属性があります。LCRの位置により、トランザクション内のLCRのストリームにおける配置が識別されます。
  • LCRIDおよびLCRの位置
    LCRIDは、XStream Outに対してLCRの位置を指定するRAW値です。これは単調に増加し、LCRを一意に識別し、再起動の前後で維持されます。XStreamは、論理変更レコード(LCR)の順序付けを行ったり、受信および適用されたLCRおよびトランザクションを判別したりするためにLCRID値を使用します。

2.1.1 行LCR

行LCRでは、1行のデータに対する変更、あるいは1行の1つのLOB列、LONG列、LONG RAW列、またはXMLType列に対する変更が記述されます。

この変更は、データ操作言語(DML)文またはピース単位の操作によるものです。行LCRをDML LCRとみなすと理解しやすくなる場合があります。たとえば、1つのDML文で、表への複数行の挿入またはマージ、表の複数行の更新、表からの複数行の削除を実行できます。

1つのDML文が複数の行に影響する可能性があるので、取得プロセスは、DML文によって変更される各行で行LCRを作成します。行LCRは、SQLまたはPL/SQLプロシージャ呼出しで行われたデータ変更を示します。

それぞれの行LCRは、LCR$_ROW_RECORDタイプのオブジェクトにカプセル化されます。次の表は、行LCRごとに存在する属性の一覧です。

表2-1 すべての行LCRに含まれる属性

属性 説明

source_database_name

行の変更が発生したソース・データベースの名前。

LCRがマルチテナント・コンテナ・データベース(CDB)で発生した場合、行変更が発生したグローバル名コンテナがこの属性によって指定されます。

command_type

変更を生成したDML文のタイプ(INSERT、UPDATE、DELETE、LOB ERASE、LOB WRITEまたはLOB TRIM)。

object_owner

行に変更があった表を含むスキーマの名前。

object_name

変更があった行を含む表の名前。

tag

LCRの追跡に使用できるRAWタグ。

transaction_id

DML文が実行されたトランザクションの識別子。

scn

変更が行われた時点のシステム変更番号(SCN)。

old_values

変更に関連する古い列の値。DML変更が行われる前の行の列値です。DML文のタイプがUPDATEまたはDELETEの場合、古い値には、DML文以前の変更対象行の一部またはすべての列が含まれます。DML文のタイプがINSERTの場合、古い値はありません。UPDATE文およびDELETE文の場合、取得プロセスによって作成される行LCRには、行の一部またはすべての古い列の値が含まれる可能性があります。

new_values

変更に関連する新しい列の値。DML変更が行われた後の行の列値です。DML文のタイプがUPDATEまたはINSERTの場合、新しい値には、DML文の後の変更対象行の一部またはすべての列が含まれます。DML文のタイプがDELETEの場合、新しい値はありません。UPDATE文およびINSERT文の場合、取得プロセスによって作成される行LCRには、行の一部またはすべての新しい列の値が含まれる可能性があります。

position

各LCRのRAWデータ型の一意の識別子。positionは、トランザクション内およびトランザクション全体で正確に増加します。

LCR位置は、XStream構成で一般的に使用されます。

LCRストリーム内の位置の順序を参照してください。

root_name

LCRがCDBで発生した場合、この属性では、CDBのルートのグローバル名が指定されます。

LCRがCDB以外で発生した場合、この属性はsource_database_name属性と同じです。

XStream Out構成の取得プロセスによって取得された行LCRには追加属性が含まれています。次の表に、これらの追加属性の説明を示します。これらの属性は、XStream In構成のXStreamクライアント・アプリケーションによって作成された行LCRに存在しません。

表2-2 取得プロセスによって取得されたLCR内の追加属性

属性 説明

commit_scn

LCRが属するトランザクションのコミット・システム変更番号(SCN)。

commit_scn_from_position

入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。

commit_time

LCRが属するトランザクションのコミット時間。

compatible

そのLCRのサポートに必要なデータベースの最小互換レベル。

instance_number

変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。

lob_information

列のLOB情報(NOT_A_LOBやLOB_CHUNKなど)。

lob_offset

指定された列のLOBオフセット(CLOB列の文字数とBLOB列のバイト数)。

lob_operation_size

LOB列の操作サイズ(CLOB列の文字数とBLOB列のバイト数)。

long_information

列のLONG情報(NOT_A_LONGやLONG_CHUNKなど)。

row_text

行LCR内にカプセル化された変更に対応するSQL文。

scn_from_position

LCRのSCN。

source_time

取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。

xml_information

列のXML情報(NOT_XML、XML_DOC、XML_DIFFなど)。

  • 行LCRのサブタイプ
    行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMITやROLLBACKなどのトランザクション制御ディレクティブが含まれています。
2.1.1.1 行LCRのサブタイプ

行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMITやROLLBACKなどのトランザクション制御ディレクティブが含まれています。

このような行LCRは内部的なもので、トランザクションの一貫性を保つためにアウトバウンド・サーバー、インバウンド・サーバーおよびXStreamクライアント・アプリケーションで使用できます。

関連項目:

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

2.1.2 DDL LCR

DDL LCRでは、データ定義言語(DDL)の変更が記述されます。

DDL文は、データベースの構造を変更します。たとえば、DDL文でデータベース・オブジェクトを作成、変更または削除できます。

それぞれのDDL LCRは、LCR$_DDL_RECORDタイプのオブジェクトにカプセル化されます。次の表は、DDL LCRごとに存在する属性の一覧です。

表2-3 すべてのDDL LCRに含まれる属性

属性 説明

source_database_name

DDLの変更が発生したソース・データベースの名前。

LCRがCDBで発生した場合、この属性では、DDL変更が発生したコンテナのグローバル名が指定されます。

command_type

変更を生成したDDL文のタイプ(ALTER TABLE、CREATE INDEXなど)。

object_owner

DDL文が実行されたデータベース・オブジェクトを所有しているユーザーのスキーマ名。

object_name

DDL文が実行されたデータベース・オブジェクトの名前。

object_type

DDL文が実行されたデータベース・オブジェクトのタイプ(TABLE、PACKAGEなど)。

ddl_text

DDL文のテキストです。

logon_user

ログオン・ユーザー。DDL文を実行したセッションのユーザーです。

current_schema

DDLテキストでオブジェクトに対するスキーマが指定されていない場合に使用されるスキーマ。

base_table_owner

実表の所有者。DDL文が表に依存する場合、実表の所有者は依存先となる表の所有者です。

base_table_name

実表の名前。DDL文が表に依存する場合、実表の名前は依存先となる表の名前です。

tag

LCRの追跡に使用できるRAWタグ。

transaction_id

DDL文が実行されたトランザクションの識別子。

scn

変更が行われた時点のシステム変更番号(SCN)。

position

各LCRのRAWデータ型の一意の識別子。positionは、トランザクション内およびトランザクション全体で正確に増加します。

LCR位置は、XStream構成で一般的に使用されます。

LCRストリーム内の位置の順序を参照してください。

edition_name

DDL文が実行されたエディションの名前。

root_name

LCRがCDBで発生した場合、この属性では、CDBのルートのグローバル名が指定されます。

LCRがCDB以外で発生した場合、この属性はsource_database_name属性と同じです。

取得プロセスによって取得されたDDL LCRには、追加の属性が含まれます。次の表に、これらの追加属性の説明を示します。これらの属性は、XStream In構成のXStreamクライアント・アプリケーションによって作成されたDDL LCRに存在しません。

表2-4 取得プロセスによって取得されたDDL LCR内の追加属性

属性 説明

commit_scn

LCRが属するトランザクションのコミット・システム変更番号(SCN)。

commit_scn_from_position

入力位置によって決定された、トランザクションのコミットSCN。XStreamアウトバウンド・サーバーによって生成される。

commit_time

LCRが属するトランザクションのコミット時間。

compatible

そのLCRのサポートに必要なデータベースの最小互換レベル。

instance_number

変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。

scn_from_position

LCRのSCN。

source_time

取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。

注意:

行LCRとDDL LCRの両方に、変更が発生したデータベースのソース・データベース名が含まれています。問題を回避するために、取得プロセスが変更の取得を開始した後で、ソース・データベースのグローバル名を変更しないことをお薦めします。

関連項目:

2.1.3 行LCRおよびDDL LCRのその他の情報

前の項で説明した情報の他に、その他の情報(LCR属性)をオプションとして行LCRとDDL LCRに含めることができます。

LCRのその他の属性の説明を次の表に示します。

表2-5 LCRのその他の属性

属性 説明

row_id

行のLCRで変更された行のROWID。この属性は、索引構成表のDDL LCRまたは行LCRには含まれません。

serial#

LCRに取得された変更を実行したセッションのシリアル番号。

session#

LCRに取得された変更を実行したセッションの識別子。

thread#

LCRに取得された変更が実行されたインスタンスのスレッド番号。通常、スレッド番号はOracle Real Application Clusters(Oracle RAC)環境のみで使用されます。

tx_name

LCRの属するトランザクションの名前。

username

LCRに取得された変更を実行した現行ユーザーの名前。

DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを使用して取得プロセスを実行すると、1つ以上の追加属性を取得できます。

関連項目:

2.1.4 順序LCR

順序LCRは、順序値に関する情報を含む行LCRです。順序データベース・オブジェクトが順序値を生成します。

順序LCRを次の方法でストリームできます。

  • 取得プロセスを使用して順序LCRを取得するには、取得プロセス・パラメータcapture_sequence_nextvalをYに設定します。

  • OCIインタフェースを使用して順序LCRを構成するには、OCILCRNewファンクションおよびOCILCRHeaderSetファンクションを使用してOCI_ROWLCR_SEQ_LCRフラグを指定します。

  • Javaインタフェースを使用して順序LCRを構成するには、DefaultRowLCRコンストラクタおよびsetSequenceLCRFlagメソッドを使用します。

XStreamインバウンド・サーバーまたはOracle Streams適用プロセスは、順序LCRを使用することで、宛先データベースの順序値に適切な値が使用されることを保証できます。増加する順序の場合、接続先の順序値は、ソース・データベースの順序値以上になります。減少する順序の場合、接続先の順序値は、ソース・データベースの順序値以下になります。インバウンド・サーバーまたは適用プロセスが順序LCRを使用するように指示するには、apply_sequence_nextval適用パラメータをYに設定します。

注意:

順序LCRは一方向レプリケーション構成を対象としています。順序LCRを双方向レプリケーション構成に使用することはできません。

関連項目:

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

各LCRには位置属性があります。LCRの位置により、トランザクション内のLCRのストリームにおける配置が識別されます。

XStream OutとXStream Inは両方とも、LCRストリームを使用してトランザクションを共有します。XStream OutはLCRストリームをクライアント・アプリケーションに送信します。XStream Inはクライアント・アプリケーションからLCRストリームを受信します。

LCRの各位置には次のプロパティがあります。

  • 位置はLCRごとに一意です。

  • 位置のデータ型はRAWです。

  • 位置は、LCRストリーム内、トランザクション内および複数のトランザクションにわたって単調に増加します。

  • 位置はバイト比較可能で、複数の位置の比較結果によってストリーム内でのLCRの順序が決定されます。

  • データベース、クライアント・アプリケーション、またはXStreamコンポーネントが再起動したとき、LCRの位置は同じままです。

  • 位置はストリーム内のLCR数が増減する可能性のあるルールの変更の影響を受けません。

XStream Outはコミット済のデータのみ送信し、XStream Inはコミット済のデータのみを取得します。

LCRストリームに関連するプロパティは次のとおりです。

  • LCRストリームは反復可能である必要があります。

  • LCRストリームには、アセンブルおよびコミット済のトランザクションのリストが含まれている必要があります。1つのトランザクションからのLCRは連続しています。LCRストリーム内にはトランザクションのインターリーブはありません。

  • LCRストリーム内の各トランザクションには、LCRの順序付きリストとトランザクションIDが含まれている必要があります。

  • 各トランザクションの最後のLCRにはコミットLCRが含まれている必要があります。

  • 各LCRは固有の位置を持つ必要があります。

  • 1つのトランザクション内およびトランザクション間のすべてのLCRの位置は、確実に増加する必要があります。

LCRストリームは複数のトランザクションのLCRをバッチ処理し、位置の順序の昇順に配置できます。1つのトランザクションからのLCRは連続しており、位置はトランザクション内で増加する必要があります。また、位置はすべてのLCRでゼロ以外である必要があります。

関連項目:

2.1.6 LCRIDおよびLCRの位置

LCRIDは、XStream Outに対してLCRの位置を指定するRAW値です。これは単調に増加し、LCRを一意に識別し、再起動の前後で維持されます。XStreamは、論理変更レコード(LCR)の順序付けを行ったり、受信および適用されたLCRおよびトランザクションを判別したりするためにLCRID値を使用します。

Oracle Database 12cリリース2 (12.2.0.1)以降では、LCRIDはバージョン管理されます。アウトバウンド・サーバーを作成または追加するときに、アウトバウンド・サーバーが使用するLCRIDバージョンを選択できます。バージョン2を指定するには、データベースの互換性レベルが12.2.0以上である必要があります。デフォルトでは、データベースの互換性が12.2.0未満の場合に作成または追加されたアウトバウンド・サーバーはLCRIDバージョン1を使用し、データベースの互換性が12.2.0以上の場合に作成または追加されたアウトバウンド・サーバーはLCRIDバージョン2を使用します。たとえば、アウトバウンド・サーバーが取得するLCRが、互換性レベルの低いデータベースに適用される場合、アウトバウンド・サーバーにLCRIDバージョン1を使用できます。

アウトバウンド・サーバーが作成または追加された後、そのLCRIDバージョンは変更できません。LCRIDバージョンを変更するには、アウトバウンド・サーバーを削除して再作成する必要があります。アウトバウンド・サーバーがインバウンド・サーバーにLCRを送信していた場合、インバウンド・サーバーを削除して再作成する必要があります。

同じデータベース変更でも、バージョン1とバージョン2ではLCRID値が異なります。DBMS_XSTREAM_ADMパッケージ内の新しいファンクションを使用すると、様々なバージョンで保存されている任意のLCRID値を比較したり、LCRID値をあるバージョンから別のバージョンに変換したりできます。特に、COMPARE_POSITIONファンクションは2つのLCRIDの値を比較し、CONVERT_POSITIONファンクションは、あるバージョンから別のバージョンにLCRID値を変換します。

関連トピック

2.2 ルールとルール・セット

XStreamは、ルールおよびルール・セットを使用します。

  • ルールとルール・セットの定義
    ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。XStream構成では、ルールによって、1つのコンポーネントから別のコンポーネントにストリームするLCRが識別されます。
  • ルール・セットおよびXStreamコンポーネント
    XStreamコンポーネントは、データベースの変更がそのルール・セットを満たしている場合に、そのタスクを実行します。
  • システム作成ルールとXStream
    XStreamコンポーネントは、LCRがそのルール・セットを満たしている場合に、LCRに対してそのタスクを実行します。システム作成ルールは、DBMS_XSTREAM_ADMパッケージによって作成されます。

関連項目:

2.2.1 ルールとルール・セットの定義

ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。XStream構成では、ルールによって、1つのコンポーネントから別のコンポーネントにストリームするLCRが識別されます。

取得プロセス、伝播、アウトバウンド・サーバーおよびインバウンド・サーバーでルールを使用できます。XStreamコンポーネントごとにルールを個別に構成でき、異なるXStreamコンポーネントに対するルールが一致する必要はありません。

ルール・セットはルールの集合です。各XStreamコンポーネントの動作は、それに関連付けられているルール・セット内のルールによって決まります。ポジティブ・ルール・セットとネガティブ・ルール・セットを、各XStreamコンポーネントに関連付けることができます。

また、1つのルールは、データ操作言語(DML)変更またはデータ定義言語(DDL)変更のいずれかの結果に関連しています。そのため、たとえば、特定の表のすべての変更に対処するには、DML変更の結果とDDL変更の結果それぞれに対応する少なくとも2つのルールが必要です。

DML変更の結果は行の変更であり、行の変更をカプセル化したLCRは行LCRと呼ばれます。1つのDML変更で複数の行が変更される可能性があります。そのため、1つのDML変更によって複数の行LCRが生じる可能性があります。DDL変更をカプセル化するLCRはDDL LCRと呼ばれます。

2.2.2 ルール・セットおよびXStreamコンポーネント

XStreamコンポーネントは、データベースの変更がそのルール・セットを満たしている場合、そのタスクを実行します。

一般に、変更がルール・セットを満たすのは、変更についてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの少なくとも1つのルールが変更についてTRUEと評価される場合です。ネガティブ・ルール・セットが常に最初に評価されます。

XStream構成でルール・セットを使用して、次を指定します。

  • 取得プロセスでREDOログから取得または廃棄する変更。REDOログ内で検出された変更が取得プロセスのルール・セットを満たしている場合、取得プロセスはその変更を取得します。REDOログで検出された変更が取得プロセスのルール・セットを満たさない場合、取得プロセスはその変更を廃棄します。

    複数のアウトバウンド・サーバーでの1つの取得プロセスを共有しているXStream Out構成では、取得プロセスのルールで、取得プロセスを共有するアウトバウンド・サーバーのいずれかで必要とされるLCRをパスさせる必要があります。

  • 伝播によって、あるキューから別のキューに送信されるか廃棄されるLCR。キュー内のLCRが伝播のルール・セットを満たしている場合、伝播はそのLCRを送信します。キュー内のLCRが伝播のルール・セットを満たさない場合、伝播はそのLCRを廃棄します。

  • アウトバウンド・サーバーがXStreamクライアント・アプリケーションに送信するか、破棄するLCR。LCRがアウトバウンド・サーバーのルール・セットを満たしている場合、アウトバウンド・サーバーはLCRをXStreamクライアント・アプリケーションに送信します。LCRがアウトバウンド・サーバーのルール・セットを満たしていない場合、アウトバウンド・サーバーはLCRを破棄します。

  • インバウンド・サーバーが適用または破棄するLCR。LCRがインバウンド・サーバーのルール・セットを満たしている場合、インバウンド・サーバーはLCRを適用します。LCRがインバウンド・サーバーのルール・セットを満たしていない場合、インバウンド・サーバーはLCRを破棄します。

XStreamコンポーネントにルール・セットが存在しない場合、コンポーネントはすべてのデータベース変更に対してタスクを実行します。たとえば、インバウンド・サーバーにルール・セットが存在しない場合、XStreamクライアント・アプリケーションによってインバウンド・サーバーに送信されたすべてのLCRが適用されます。

2.2.3 システム作成ルールとXStream

XStreamコンポーネントは、LCRがそのルール・セットを満たしている場合に、LCRに対してそのタスクを実行します。システム作成ルールは、DBMS_XSTREAM_ADMパッケージによって作成されます。

システム作成ルールは、表、スキーマまたはグローバルのいずれかの粒度レベルを指定できます。

  • XStreamシステム作成ルール・プロシージャ
    DBMS_XSTREAM_ADMパッケージ内のいくつかのPL/SQLプロシージャは、システム生成のルールを作成できます。
  • グローバル・ルール
    ルールを使用して、データベース全体に関連するタスクを指定する場合は、グローバル・ルールを指定します。
  • スキーマ・ルール
    ルールを使用してスキーマに関連するタスクを指定する場合は、スキーマ・ルールを指定します。
  • 表ルール
    ルールを使用して表に関連するタスクを指定する場合は、表ルールを指定します。
  • サブセット・ルール
    サブセット・ルールはDML変更の特殊な表ルールであり、表の行のサブセットのみに関連します。
  • システム作成ルールとマルチテナント環境
    マルチテナント環境によって、移植可能な一連のスキーマ、オブジェクトおよび関連構造をOracleデータベースに含めることができ、アプリケーションには論理的に別のデータベースのように見えます。この自己完結型コレクションは、プラガブル・データベース(PDB)と呼ばれます。CDBにはPDBが含まれています。

関連項目:

2.2.3.1 XStreamシステム作成ルール・プロシージャ

DBMS_XSTREAM_ADMパッケージ内のいくつかのPL/SQLプロシージャは、システム生成のルールを作成できます。

システム作成ルールを作成するプロシージャには3つの種類があります。

  • アウトバウンド・サーバーおよびアウトバウンド・サーバーのルールを作成または変更するプロシージャ

    これらのプロシージャには、CREATE_OUTBOUND、ADD_OUTBOUND、ALTER_OUTBOUNDなどがあります。これらのプロシージャでは、XStream Outの迅速な構成が容易になります。これらがユーザーのニーズを満たしている場合は、これらのプロシージャを使用してXStream Outの構成を簡略化するようにしてください。CREATE_OUTBOUNDプロシージャは、アウトバウンド・サーバーに加えて、アウトバウンド・サーバーで使用されるキューおよび取得プロセスを作成します。

  • 伝播を作成するか、既存の伝播にルールを追加するプロシージャ

    これらのプロシージャには、ADD_*_PROPAGATION_RULESプロシージャが含まれています。指定された伝播が存在しない場合、これらのプロシージャは伝播を作成し、その伝播のルール・セットにルールを追加します。指定された伝播が存在する場合、これらのプロシージャは既存の伝播のルール・セットにルールを追加します。

  • 既存のXStreamコンポーネント(取得プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーなど)にルールを追加するプロシージャ

    これらのプロシージャには、ADD_*_RULESプロシージャが含まれています。これらのプロシージャによって、システム作成ルールの柔軟性が高まり、きめ細かな制御が可能になります。XStream構成にルールを追加する必要がある場合は、これらのプロシージャを使用するようにしてください。

次の表は、どのプロシージャがどのXStreamコンポーネントに対してルールを作成できるかについて説明しています。

表2-6 XStreamシステム作成ルール・プロシージャ

プロシージャ 取得プロセス 伝播 アウトバウンド・サーバー インバウンド・サーバー

CREATE_OUTBOUND

はい

いいえ

はい

いいえ

ADD_OUTBOUND

いいえ

いいえ

はい

いいえ

ALTER_OUTBOUND

はい

いいえ

はい

いいえ

ADD_GLOBAL_RULES

はい

いいえ

はい

はい

ADD_GLOBAL_PROPAGATION_RULES

いいえ

はい

いいえ

いいえ

ADD_SCHEMA_RULES

はい

いいえ

はい

はい

ADD_SCHEMA_PROPAGATION_RULES

いいえ

はい

いいえ

いいえ

ADD_GLOBAL_RULES

はい

いいえ

はい

はい

ADD_SUBSET_OUTBOUND_RULES

いいえ

いいえ

はい

いいえ

ADD_SUBSET_RULES

はい

いいえ

はい

はい

ADD_SUBSET_PROPAGATION_RULES

いいえ

はい

いいえ

いいえ

ADD_TABLE_RULES

はい

いいえ

はい

はい

ADD_TABLE_PROPAGATION_RULES

いいえ

はい

いいえ

いいえ

関連項目:

これらのプロシージャの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。

2.2.3.2 グローバル・ルール

ルールを使用して、データベース全体に関連するタスクを指定する場合は、グローバル・ルールを指定します。

DML変更に関するグローバル・ルール、DDL変更に関するグローバル・ルール、または各のタイプの変更に関するグローバル・ルール(合計2つのルール)を指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・データベースに対するすべてのDML変更またはすべてのDDL変更の結果を取得します。また、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・データベースに対するすべてのDML変更またはすべてのDDL変更の結果を廃棄します。

伝播の場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、伝播ルールによって、特定のアウトバウンド・サーバーに適用されるLCRのセットが制御されます。単一の取得プロセスが複数のアウトバウンド・サーバーにサービスを提供する場合、各アウトバウンド・サーバーに配布される変更セットは、伝播ルールによって制御されます(取得ルールがすべての変更のスーパーセットです)。伝播の場合、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、伝播によって、取得プロセスからのすべての行LCRまたはすべてのDDL LCRが廃棄されます。

アウトバウンド・サーバーの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、アウトバウンド・サーバーは、受信したすべての行LCRまたはすべてのDDL LCRをXStreamクライアント・アプリケーションに送信します。アウトバウンド・サーバーの場合、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、アウトバウンド・サーバーは、受信したすべての行LCRまたはすべてのDDL LCRを廃棄します。

インバウンド・サーバーの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、インバウンド・サーバーは、XStreamクライアント・アプリケーションによって送信されたすべての行LCRまたはすべてのDDL LCRのいずれかを適用します。インバウンド・サーバーの場合、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、インバウンド・サーバーは、XStreamクライアント・アプリケーションによって送信されたすべての行LCRまたはすべてのDDL LCRのいずれかを廃棄します。

インバウンド・サーバーが、クライアント・アプリケーションから受信したすべてのLCRを適用する必要がある場合は、グローバル・ルールを使用するかわりにルール・セットを使用しないようにインバウンド・サーバーを構成できます。また、インバウンド・サーバーが最適に動作するためには、適用しないLCRを受信しないようにします。

アウトバウンド・サーバーのグローバル・ルールを指定するには、ALTER_OUTBOUNDプロシージャを使用します。あるいは、より詳細なレベルを指定するには、DBMS_XSTREAM_ADMパッケージのADD_GLOBAL_RULESプロシージャを使用します。

インバウンド・サーバーのグローバル・ルールを指定するには、ALTER_INBOUNDプロシージャを使用します。あるいは、より詳細なレベルを指定するには、DBMS_XSTREAM_ADMパッケージのADD_GLOBAL_RULESプロシージャを使用します。

関連項目:

2.2.3.3 スキーマ・ルール

ルールを使用してスキーマに関連するタスクを指定する場合は、スキーマ・ルールを指定します。

DML変更に関するスキーマ・ルール、DDL変更に関するスキーマ・ルール、またはスキーマに対するそれぞれの変更に関するスキーマ・ルール(合計2つのルール)を指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対するDML変更またはDDL変更を取得します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対するDML変更またはDDL変更の結果を廃棄します。

伝播の場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含む行LCRまたはDDL LCRをソース・キューから伝播します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含む行LCRまたはDDL LCRをソース・キューから廃棄します。

アウトバウンド・サーバーの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、アウトバウンド・サーバーは、スキーマへの変更を含む、受信した行LCRまたはDDL LCRをXStreamクライアント・アプリケーションに送信します。アウトバウンド・サーバーの場合、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、アウトバウンド・サーバーは、スキーマへの変更を含む、受信した行LCRまたはDDL LCRを廃棄します。

インバウンド・サーバーの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、インバウンド・サーバーは、スキーマへの変更を含む、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのいずれかを適用します。インバウンド・サーバーの場合、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、インバウンド・サーバーは、スキーマへの変更を含む、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのいずれかを廃棄します。

アウトバウンド・サーバーまたはインバウンド・サーバーのいずれかのスキーマ・ルールを指定するには、DBMS_XSTREAM_ADMパッケージのALTER_OUTBOUNDプロシージャまたはADD_SCHEMA_RULESプロシージャを使用します。

関連項目:

2.2.3.4 表ルール

ルールを使用して表に関連するタスクを指定する場合は、表ルールを指定します。

表に対するDML変更に関する表ルール、DDL変更に関する表ルール、または各タイプの変更に関する表ルール(合計2つのルール)を指定できます。

取得プロセスの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、取得プロセスは表に対するDML変更またはDDL変更を取得します。取得プロセスの場合、ネガティブ・ルール・セットに1つの表ルールを含めると、取得プロセスは、表に対するDML変更またはDDL変更のいずれかを廃棄します。

伝播の場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含む行LCRまたはDDL LCRをソース・キューから伝播します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含む行LCRまたはDDL LCRをソース・キューから廃棄します。

アウトバウンド・サーバーの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、アウトバウンド・サーバーは、表への変更を含む、受信した行LCRまたはDDL LCRのいずれかをXStreamクライアント・アプリケーションに送信します。アウトバウンド・サーバーの場合、ネガティブ・ルール・セットに1つの表ルールを含めると、アウトバウンド・サーバーは、表への変更を含む、受信した行LCRまたはDDL LCRのいずれかを廃棄します。

インバウンド・サーバーの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、インバウンド・サーバーは、表への変更を含む、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのいずれかを適用します。インバウンド・サーバーの場合、ネガティブ・ルール・セットに1つの表ルールを含めると、インバウンド・サーバーは、表への変更を含む、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのいずれかを廃棄します。

アウトバウンド・サーバーまたはインバウンド・サーバーの表ルールを指定するには、DBMS_XSTREAM_ADMパッケージのALTER_OUTBOUNDプロシージャまたはADD_TABLE_RULESプロシージャを使用します。

2.2.3.5 サブセット・ルール

サブセット・ルールはDML変更の特殊な表ルールであり、表の行のサブセットのみに関連します。

サブセット・ルールを作成する場合、SELECT文のWHERE句と同様の条件を使用して次の指定ができます。

  • 取得プロセスが、特定の表に対するDML変更によって発生する行変更のサブセットのみを取得するように指定

  • 伝播が、特定の表に関連する行LCRのサブセットのみを伝播するように指定

  • アウトバウンド・サーバーが、特定の表に関連する行LCRのサブセットのみをXStreamクライアント・アプリケーションに送信するように指定

  • インバウンド・サーバーが、特定の表に関連する行LCRのサブセットのみを適用するように指定

次のタイプのサブセット・ルールを指定すると、サプリメンタル・ロギングが必要になります。

  • 取得プロセスのサブセット・ルール

  • 取得プロセスで取得されたLCRを伝播する伝播のサブセット・ルール

  • 取得プロセスによって取得されたLCRをXStreamクライアント・アプリケーションに送信するアウトバウンド・サーバーのサブセット・ルール

いずれの場合も、サブセット条件のすべての列に対して、無条件のサプリメンタル・ログ・グループをソース・データベースで指定する必要があります。場合によっては、サブセット・ルールを指定すると、更新が挿入に変換されることがあり、このときに一部またはすべての列に補足情報が必要になることがあります。

アウトバウンド・サーバーのサブセット・ルールを指定するには、DBMS_XSTREAM_ADMパッケージのADD_SUBSET_OUTBOUND_RULES、ADD_SUBSET_RULESまたはREMOVE_SUBSET_OUTBOUND_RULESプロシージャを使用します。

関連項目:

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

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

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

CDBでは、LCRのsource_database_name属性には変更が発生したコンテナのグローバル名が入り、root_name属性にはCDBルートのグローバル名が入る可能性があります。XStreamコンポーネントのルールでは、これらの属性を考慮に入れることができます。

  • CDBのシステム作成ルールとXStream Out
    CDBでは、XStream OutをCDBルートに構成する必要があります。そのため、共通ユーザーとして接続しているときに、システム作成ルールを作成するDBMS_XSTREAM_ADMパッケージ内のPL/SQLプロシージャをCDBルートで実行する必要があります。
  • CDBのシステム作成ルールとXStream In
    CDB内のルートまたはすべてのコンテナにXStream Inを構成できます。

関連トピック

2.2.3.6.1 CDBのシステム作成ルールとXStream Out

CDBでは、XStream OutはCDBルートで構成する必要があります。そのため、共通ユーザーとして接続しているときに、システム作成ルールを作成するDBMS_XSTREAM_ADMパッケージ内のPL/SQLプロシージャをCDBルートで実行する必要があります。

伝播のルールを作成するプロシージャを除く、ADD_GLOBAL_RULESプロシージャなどのXStream Outのシステム作成ルールを作成するプロシージャには、次の表に示すキー・パラメータが含まれています。

表2-7 CDB内でのシステム作成ルールのキー・プロシージャ・パラメータ

パラメータ 説明

source_database

ソース・データベースのグローバル名。CDBでは、ルールに関連するコンテナのグローバル名を指定してください。このコンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。たとえば、mycdb.example.comまたはhrpdb.example.comのように指定します。

source_root_name

ソースCDBのCDBルートのグローバル名。たとえば、mycdb.example.comにように指定します。

source_container_name

ソース・コンテナの短縮名。このコンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。たとえば、CDB$ROOTまたはhrpdbのように指定します。

source_databaseまたはsource_root_nameを指定する際にドメイン名を指定しない場合、プロシージャによりドメイン名が名前に自動的に追加されます。たとえば、ドメイン名が.EXAMPLE.COMの場合にDBS1を指定すると、自動的にDBS1.EXAMPLE.COMが指定されます。

これらのキー・パラメータの組合せにより、プロシージャによって生成されたルールに基づいて、XStream Outが取得してクライアント・アプリケーションにストリームするコンテナの変更が判別されます。これらのパラメータの設定に関係なく、システム生成ルールは取得およびストリームされる変更を、特定のスキーマおよび表に制限できます。

ローカル取得とは、ソースCDB上で取得プロセスが実行されることを意味します。ローカルの取得構成では、source_root_nameパラメータは、ローカルCDBのCDBルートのグローバル名を指定します。このパラメータがNULLの場合、ローカルCDBのCDBルートのグローバル名が自動的に指定されます。生成されるルールは、現在のCDBのCDBルートのグローバル名についての条件を含みます。

ダウンストリーム取得とは、ソースCDB以外のCDB上で取得プロセスが実行されることを意味します。ダウンストリーム取得構成では、source_root_nameパラメータはNULL以外である必要があり、リモート・ソースCDB内のCDBルートのグローバル名を指定する必要があります。生成されるルールは、リモートCDBのCDBルートのグローバル名についての条件を含みます。このパラメータがNULLの場合、ローカル取得が想定されます。

次の表は、ローカル取得構成でのsource_databaseおよびsource_container_nameパラメータの各種設定に対するルール条件について説明しています。

表2-8 ローカル取得とXStream Outコンテナのルール条件

source_databaseパラメータ設定 source_container_nameパラメータ設定 説明

NULL

NULL

XStream OutはローカルCDB内のすべてのコンテナ(CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBが含まれます)で行われた変更を取得し、ストリームします。

NULL以外

NULL

XStream OutはローカルCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。DBMS_XSTREAM_ADMプロシージャはCDB_PDBSビューおよびCDB_PROPERTIESビューを問い合せて、source_container_name値を決定します。

NULL

NULL以外

XStream OutはローカルCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。DBMS_XSTREAM_ADMプロシージャはCDB_PDBSビューおよびCDB_PROPERTIESビューを問い合せて、source_database値を決定します。

NULL以外

NULL以外

XStream OutはローカルCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。

source_database値の接頭辞がsource_container_name値と異なる場合、生成されるルールにはsource_database値の条件が含まれており、内部表はsource_database値をsource_container_name値にマップします。

次の表は、ダウンストリーム取得構成でのsource_databaseおよびsource_container_nameパラメータの各種設定に対するルール条件について説明しています。

表2-9 ダウンストリーム取得とXStream Outコンテナのルール条件

source_databaseパラメータ設定 source_container_nameパラメータ設定 説明

NULL

NULL

XStream Outはリモート・ソースCDB内のすべてのコンテナ(CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBが含まれます)で行われた変更を取得し、ストリームします。

NULL以外

NULL

XStream Outはリモート・ソースCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。DBMS_XSTREAM_ADMプロシージャは、source_database値の接頭辞からsource_container_name値を導出します。

NULL

NULL以外

DBMS_XSTREAM_ADMプロシージャでエラーが発生します。

NULL以外

NULL以外

XStream Outはリモート・ソースCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。

source_database値の接頭辞がsource_container_name値と異なる場合、生成されるルールにはsource_database値の条件が含まれており、内部表はsource_database値をsource_container_name値にマップします。

2.2.3.6.2 CDBのシステム作成ルールとXStream In

CDB内のルートまたは任意のコンテナにXStream Inを構成できます。

一般的に、インバウンド・サーバーはルール・セットまたはルールを使用しません。そのかわりに、通常はクライアント・アプリケーションから受信したすべてのLCRを処理します。インバウンド・サーバーは、現在のコンテナにのみ変更を適用できます。そのため、インバウンド・サーバーがCDBルートに構成されている場合は、CDBルートにのみ変更を適用できます。インバウンド・サーバーがPDBに構成されている場合は、そのPDBにのみ変更を適用できます。インバウンド・サーバーがアプリケーション・ルートに構成されている場合、そのアプリケーション・ルートにのみ変更を適用できます。また、インバウンド・サーバーがアプリケーションPDBに構成されている場合、そのアプリケーションPDBにのみ変更を適用できます。

2.3 ルールベースの変換

XStreamでは、ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEと評価されたときの論理変更レコード(LCR)に対するあらゆる変更です。

一般的には、クライアント・アプリケーションでデータの変換を実行するのが最善の方法です。これが可能でない場合、データベースはDML LCR上でいくつかの単純な変換を実行できます。

2.3.1 宣言ルールベースの変換

宣言ルールベース変換は、行LCRに対する共通の変換シナリオ・セットを扱います。

DBMS_XSTREAM_ADMパッケージに含まれる次のいずれかのプロシージャを使用して変換を指定(宣言)します。

  • ADD_COLUMN: 行LCRに列を追加する宣言変換を追加または削除します。

  • DELETE_COLUMN: 行LCRから列を削除する宣言変換を追加または削除します。

  • KEEP_COLUMNS: 行LCRの列のリストを保持する宣言変換を追加または削除します。リストに含まれていない列は、変換によって行LCRから削除されません。

  • RENAME_COLUMN: 行LCRの列名を変更する宣言変換を追加または削除します。

  • RENAME_SCHEMA: 行LCRのスキーマ名を変更する宣言変換を追加または削除します。

  • RENAME_TABLE: 行LCRの表名を変更する宣言変換を追加または削除します。

宣言ルールベース変換を指定する場合、宣言ルールベース変換に関連付けられたルールを指定します。指定したルールが行LCRに関してTRUEと評価されると、XStreamによって、行LCRに対する宣言変換が内部的に実行されます。このとき、PL/SQLは起動されません。

宣言ルールベースの変換には次のメリットがあります。

  • 変換が内部的に実行され、PL/SQLを使用しないため、パフォーマンスが改善されます。

  • カスタムPL/SQLファンクションが不要なため複雑になりません。

宣言ルールベースの変換で変換できるのは行LCRのみです。このため、いずれかのプロシージャを実行して宣言変換を追加するときはDMLルールを指定する必要があります。DDLルールを指定すると、エラーが発生します。

2.3.2 宣言ルールベースの変換の順序

様々なタイプのルールベースの変換が評価される順序は、順序によって結果が変わることがあるため重要です。

ルールがTRUEと評価されると、デフォルトでは、次の順序で宣言ルールベースの変換が実行されます。

  1. 列の保持

  2. 列の削除

  3. 列名の変更

  4. 列の追加

  5. 表名の変更

  6. スキーマ名の変更

後続の各宣言変換では、宣言変換の結果が使用されます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたとします。

  • 列addressの削除

  • 列addressの追加

列addressが行LCRに存在するとした場合、両方の宣言変換を実行する必要があります。これは、列addressが行LCRに戻される前に、列addressアドレスが行LCRから削除されるためです。次の表に、この例での変換の順序付けを示します。

手順番号 変換タイプ 変換の詳細 変換が実行されるかどうか

1

列の保持

-

-

2

列の削除

行LCRから列addressを削除します

はい

3

列名の変更

-

-

4

列の追加

行LCRに列addressを追加します

はい

5

表名の変更

-

-

6

スキーマ名の変更

-

-

別の例として、表名を変更してからスキーマ名を変更する場合を考えます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたとします。

  • 表名john.customersをsue.clientsに変更

  • スキーマ名sueをmaryに変更

表名の変更の変換では、表のスキーマ名も変更されることに注意してください。この場合、変換は両方とも実行され、両方の変換後の表名はmary.clientsになります。次の表に、この例での変換の順序付けを示します。

手順番号 変換タイプ 変換の詳細 変換が実行されるかどうか

1

列の保持

-

-

2

列の削除

-

-

3

列名の変更

-

-

4

列の追加

-

-

5

表名の変更

表名john.customersをsue.clientsに変更

はい

6

スキーマ名の変更

スキーマ名sueをmaryに変更

はい

類似した例で、1つのルールに、次の宣言ルールベースの変換が指定された場合を考えます。

  • 表名john.customersをsue.clientsに変更

  • スキーマ名johnをmaryに変更

この場合、1つ目の変換は実行されますが、2つ目の変換は実行されません。1つ目の変換の実行後、表名はsue.clientsになります。2つ目の変換の実行時、表のスキーマ名はjohnではなくsueであるため、2つ目の変換は実行されません。次の表に、この例での変換の順序付けを示します。

手順番号 変換タイプ 変換の詳細 変換が実行されるかどうか

1

列の保持

-

-

2

列の削除

-

-

3

列名の変更

-

-

4

列の追加

-

-

5

表名の変更

表名john.customersをsue.clientsに変更

はい

6

スキーマ名の変更

スキーマ名johnをmaryに変更

いいえ

スキーマ名の変更の変換は実行されませんが、エラーは発生しません。この場合、表名の変更の変換によって、行LCRは変換され、表名sue.clientsの行LCRが返されます。

2.3.3 変換の順序の評価

変換の順序を評価できます。

2.3.3.1 行の移行の変換順序

宣言ルールベースの変換に加えて、行移行はサブセット・ルールがTRUEと評価されたときに実行される内部変換です。

DBMS_XSTREAM_ADM.ADD_SUBSET_RULESプロシージャを使用して、サブセット・ルールを追加できます。両方の種類の変換すべてが単一のルールに指定されている場合、ルールがTRUEと評価されると、変換は次の順序で実行されます。

  1. 行の移行

  2. 宣言ルールベースの変換

2.3.3.2 宣言ルールベースの変換のユーザー指定の順序

特定のルールに対して、宣言ルールベースの変換のデフォルトの順序を使用しない場合、ルールに指定された各宣言変換に手順番号を指定できます。

特定のルールに対する1つ以上の宣言ルールベースの変換に手順番号を指定した場合、宣言ルールベースの変換は、次のように実行されます。

  • 宣言変換は、手順番号の昇順で実行されます。

  • 宣言変換デフォルトの手順番号は0 (ゼロ)です。宣言変換に手順番号が明示的に指定されていない場合、このデフォルトが使用されます。

  • 複数の宣言変換に同じ手順番号が指定された場合、これらの宣言変換は、宣言ルールベースの変換の順序で説明されているデフォルトの順序付けに従います。

たとえば、特定のルールに関連付けられた変換に次の手順番号を指定すると、宣言変換のデフォルトの順序付けを逆にすることができます。

  • 列の保持: 手順番号6

  • 列の削除: 手順番号5

  • 列名の変更: 手順番号4

  • 列の追加: 手順番号3

  • 表名の変更: 手順番号2

  • スキーマ名の変更: 手順番号1

このように順序を指定すると、スキーマ名の変更の変換が最初に実行され、列の削除の変換は最後に実行されます。

2.3.3.3 ルールベースの変換に関する考慮事項

宣言ルールベースの変換に該当するいくつかの考慮事項があります。

これらの考慮事項には、次のものが含まれます。

  • XStreamコンポーネントによって実行されるルールベースの変換の場合、ルールはXStreamコンポーネントのポジティブ・ルール・セットである必要があります。ルールがXStreamコンポーネントのネガティブ・ルール・セットに含まれる場合、XStreamコンポーネントはルールベースの変換を無視します。

  • ルールベースの変換は、DBMS_TRANSFORMパッケージを使用して実行される変換とは異なります。このヘルプでは、DBMS_TRANSFORMパッケージで実行される変換については説明しません。

  • 行LCRの大部分がXStream In構成で変換される場合、XStream Inと一緒にDMLハンドラを使用できます。ただしこの方法は、XStream Inクライアント・アプリケーションでの変更の実行ほどはうまく実行されない場合があるため注意が必要です。XStream In構成で行LCRに複数の変換または複雑な変換を実行する場合、XStream Inに変更を送信する前にクライアント・アプリケーションでこれらの変更を行うことによって、XStream Inでの処理時間を減らすことを検討してください。

2.4 XStreamおよびOracle Streamsパフォーマンス・アドバイザ

Oracle Streamsパフォーマンス・アドバイザは、DBMS_STREAMS_ADVISOR_ADM PL/SQLパッケージと、データ・ディクショナリ・ビューのコレクションから構成されます。

パフォーマンス・アドバイザを使用すると、XStream環境のトポロジおよびパフォーマンスを監視できます。XStreamのトポロジには、XStream環境のコンポーネント、コンポーネント間のリンク、取得からコンシュームへの情報フローに関する情報が含まれています。パフォーマンス・アドバイザは、Oracle Streamsコンポーネントの実行方法に関する情報も提供します。

適用プロセスは、XStreamアウトバウンド・サーバーおよびインバウンド・サーバーとして機能します。一般的に、パフォーマンス・アドバイザは、適用プロセスを使用するOracle Streams環境と、アウトバウンド・サーバーまたはインバウンド・サーバーを使用するXStream環境とで同様に機能します。この項では、XStream環境でのパフォーマンス・アドバイザの使用に関する重要な考慮事項について説明します。

関連項目:

Oracle Streamsパフォーマンス・アドバイザの使用の詳細は、Oracle Streams概要および管理を参照してください。

2.4.1 XStreamコンポーネント

パフォーマンス・アドバイザは複数のXStreamコンポーネントを追跡します。

パフォーマンス・アドバイザは、XStream環境の次のタイプのコンポーネントを追跡します。

  • QUEUE

  • CAPTURE

  • PROPAGATION SENDER

  • PROPAGATION RECEIVER

  • APPLY

前述のタイプはOracle Streams環境とXStream環境で同じですが、APPLYは例外です。APPLYコンポーネント・タイプは、XStreamアウトバウンド・サーバーまたはインバウンド・サーバーです。

また、パフォーマンス・アドバイザは、最もビジーなコンポーネントとしてボトルネック・コンポーネントを特定できます。アイドル時間が最小のコンポーネントを特定することもできます。XStream構成で、DBA_STREAMS_TP_PATH_BOTTLENECKビューのACTION_NAME列にEXTERNALと表示されたら、XStreamクライアント・アプリケーションがボトルネックになっている可能性があります。

2.4.1.1 XStream Outの適用サブコンポーネント

XStream Outの適用サブコンポーネント・タイプがいくつかあります。

次のサブコンポーネント・タイプが可能です。

  • PROPAGATION SENDER+RECEIVER: 取得プロセスとアウトバウンド・サーバーが異なるデータベースにある場合に取得プロセスからアウトバウンド・サーバーにLCRを送信します。

  • APPLY READER: リーダー・サーバーを示します。APPLY READERは、取得プロセスからLCRを受信し、LCRをトランザクションに編成し、依存性計算を実行し、LCRを適用コーディネータに渡します。

  • APPLY COORDINATOR: コーディネータ・プロセスを示します。このプロセスは、取得プロセスからトランザクションを取得し、依存性情報を使用してトランザクションをスケジュールする方法を決定し、LCRを適用サーバーに送信します。

  • APPLY SERVER: 適用サーバーを示します。これはクライアント・アプリケーションにLCRを配信します。

2.4.1.2 XStream Inの適用サブコンポーネント

XStream Inの適用サブコンポーネント・タイプがいくつかあります。

次のサブコンポーネント・タイプが可能です。

  • APPLY READER: リーダー・サーバーを示します。クライアント・アプリケーションからLCRを取得してトランザクションに変換し、トランザクション順序を確認して、依存性計算を実行します。

  • APPLY COORDINATOR: コーディネータ・プロセスを示します。このプロセスは、リーダー・サーバーからトランザクションを取得し、依存性情報を使用してトランザクションをスケジュールする方法を決定し、LCRを適用サーバーに送信します。

  • APPLY SERVER: 適用サーバーを示します。これはLCRを適用ハンドラに適用します。LCRを適用できない場合、LCRはエラー・キューに配置されます。

2.4.2 トポロジおよびストリーム・パス

Oracle Streamsのトポロジのストリーム・パスは、ソースから宛先へのLCRのフローのことです。

ストリーム・パスは、取得プロセスまたはXStream Inクライアント・アプリケーションから始まります。ストリーム・パスは、適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーがLCRを受信したときに終了します。ストリーム・パスは、適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーに到達する前に複数のソースおよび宛先コンポーネントを通過することがあります。したがって、単一のストリーム・パスが最後のコンポーネントに到達するまでに、複数のソース/宛先コンポーネント・ペアが生成される場合があります。

Oracle Streamsトポロジは、ストリーム・パスが適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーで終わる場合のみ、ストリーム・パスに関する情報を収集します。

2.4.3 XStreamおよびコンポーネント・レベルの統計

パフォーマンス・アドバイザは、コンポーネント・レベルの統計を追跡します。

パフォーマンス・アドバイザは次のコンポーネント・レベルの統計を追跡します。

  • MESSAGE APPLY RATEは、適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーによって秒単位で適用されるLCRの平均数です。

  • TRANSACTION APPLY RATEは、適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーによって秒単位で適用されるトランザクションの平均数です。トランザクションには通常、複数のLCRが含まれます。

LCRは次のいずれかの方法で適用できます。

  • 適用プロセスまたはインバウンド・サーバーが、LCRでカプセル化された変更をデータベース・オブジェクトに対して実行します。

  • 適用プロセスまたはインバウンド・サーバーがLCRを適用ハンドラに渡します。

  • LCRでエラーが発生した場合、適用プロセスまたはインバウンド・サーバーがそのLCRをエラー・キューに送信します。

  • アウトバウンド・サーバーは、XStreamクライアント・アプリケーションにLCRを渡します。LCRでエラーが発生した場合、アウトバウンド・サーバーはクライアント・アプリケーションにもエラーを報告します。

また、パフォーマンス・アドバイザはLATENCYコンポーネント・レベルの統計を追跡します。LATENCYは次の方法で定義されます。

  • 適用プロセスの場合、LATENCYはLCRがソース・データベースで作成されてから、LCRが適用プロセスによって宛先データベースで適用されるまでの時間です。

  • アウトバウンド・サーバーの場合、LATENCYはLCRがソース・データベースで作成されてから、LCRがXStreamクライアント・アプリケーションに送信されるまでの時間です。

  • インバウンド・サーバーの場合、LATENCYはLCRがXStreamクライアント・アプリケーションによって作成されてから、LCRが適用プロセスによって適用されるまでの時間です。

取得プロセスがLCRを作成する場合、メッセージ作成時刻は、データベース変更のREDOエントリが記録された時刻です。XStreamクライアント・アプリケーションがLCRを作成する場合、メッセージ作成時刻はLCRが作成された時刻です。

関連項目:

コンポーネントレベルの統計の詳細は、Oracle Streams概要および管理を参照してください。

2.4.4 UTL_SPADVパッケージ

UTL_SPADVパッケージは、XStreamのパフォーマンスに関連する統計の収集を自動化します。

UTL_SPADVには、分散データベース環境でのXStreamコンポーネントの統計を収集および分析する一連のサブプログラムが用意されています。このパッケージでは、パフォーマンス・アドバイザとCOLLECT_STATSプロシージャを使用して、統計の収集を自動化します。

出力は、スプレッドシートに簡単にインポートして分析できるように書式設定されます。UTL_SPADV.SHOW_STATSプロシージャを使用してXStreamパフォーマンス統計を調べたり、UTL_SPADV.SHOW_STATS_HTMLプロシージャを使用して、HTML形式のレポートに同じ情報を表示したりできます。

UTL_SPADVパッケージは、適用プロセスを使用するOracle Streams環境において、アウトバウンド・サーバーまたはインバウンド・サーバーを使用するXStream環境で動作するのと基本的に同様に機能します。XStreamはクライアント・アプリケーションとの間でのデータの変更に関係するため、XStreamの場合のSHOW_STATSプロシージャの出力は、Oracle Streamsとは異なります。

2.4.4.1 UTL_SPADVパッケージを使用したXStreamの統計の収集

UTL_SPADVパッケージを使用してXStream統計を収集できます。

UTL_SPADVパッケージを使用してXStream統計を収集するには、次の手順を実行します。

  1. 情報の収集に使用するデータベースを指定します。このデータベースの管理ユーザーは、次の要件を満たしている必要があります。

    • 複数のデータベースのXStream統計を収集する場合、ユーザーは、監視するXStreamコンポーネントを含む各データベースへのデータベース・リンクにアクセスできる必要があります。

    • ユーザーは、DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限が付与されている必要があります。複数のデータベースのXStream統計を収集する場合、各データベース・リンクは、DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGEプロシージャを使用して権限が付与されているリモート・データベースのユーザーに接続する必要があります。

      XStreamコンポーネントを使用して各データベースでXStream管理者を構成すると、XStream管理者に必要な権限が割り当てられます。

    • ユーザーは、表やプロシージャを作成するために必要な権限を持っている必要があります。複数のデータベースのXStream統計を収集する場合、各データベース・リンクは、表やプロシージャを作成するために必要な権限を持つリモート・データベースのユーザーに接続する必要があります。

    ご使用の環境に、これらの要件を満たすデータベースがない場合は、データベースを1つ選択し、必要なデータベース・リンクを構成して、必要な権限をユーザーに付与してから処理を進めてください。

  2. SQL*Plusでは、手順1で指定したデータベースに、手順1に示される要件を満たすユーザーとして接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  3. ORACLE_HOMEのrdbms/adminディレクトリでutlspadv.sqlスクリプトを実行してUTL_SPADVパッケージをロードします。次に例を示します。
    @utlspadv.sql
  4. 現在のXStreamパフォーマンスの統計を1回収集するか、XStreamパフォーマンスを継続的に監視するジョブを作成します。

    • 現在のXStreamパフォーマンスの統計を1回収集するには、COLLECT_STATSプロシージャを実行します。 

      exec UTL_SPADV.COLLECT_STATS

      この例では、COLLECT_STATSプロシージャのパラメータにデフォルト値を使用します。したがって、この例では、60秒間隔でパフォーマンス・アドバイザが10回実行されます。これらの値は、COLLECT_STATSプロシージャのintervalおよびnum_runsパラメータのデフォルト値にそれぞれ対応します。

    • XStreamパフォーマンスを継続的に監視するジョブを作成するには、次のプロシージャを実行します。

      exec UTL_SPADV.START_MONITORING

      この例では、監視ジョブを作成します。その監視ジョブでは、設定した間隔で継続的にパフォーマンスの統計を収集します。この例では、START_MONITORINGプロシージャのパラメータにデフォルト値を使用します。したがって、この例では、60秒ごとにパフォーマンス・アドバイザが実行されます。この値は、START_MONITORINGプロシージャのintervalパラメータのデフォルト値に対応します。START_MONITORINGプロシージャで間隔を指定すると、COLLECT_STATSプロシージャのintervalパラメータにその間隔が使用されます。

    これらのプロシージャには、パフォーマンスの統計を収集する方法を調整するために使用できるいくつかのパラメータが用意されています。詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください。

統計を表示するには、SHOW_STATSプロシージャを実行します。コマンド行でのXStream統計の表示を参照してください。

関連項目:

UTL_SPADVパッケージの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください。

2.4.4.2 コマンド行でのXStream統計の表示

UTL_SPADVパッケージのSHOW_STATSプロシージャは、パフォーマンス・アドバイザによって収集および格納された統計を表示します。

path_stat_tableパラメータを使用して、統計を含む表を指定します。

COLLECT_STATSプロシージャを使用して統計を収集する場合は、COLLECT_STATSプロシージャのpath_stat_tableパラメータでこの表を指定します。デフォルトでは、表名はSTREAMS$_ADVISOR_PATH_STATです。

START_MONITORINGプロシージャを使用して統計を収集するとき、この表の名前を調べるには、STREAMS$_PA_MONITORINGビューのSHOW_STATS_TABLE列を問い合せます。監視ジョブのデフォルトの表はSTREAMS$_PA_SHOW_PATH_STATです。

UTL_SPADVパッケージによって収集され、STREAMS$_ADVISOR_PATH_STAT表に格納された統計を表示するには、次の手順を実行します。

  1. UTL_SPADVパッケージを使用したXStreamの統計の収集で説明した手順を実行して、統計を収集します。
  2. 統計を収集したユーザーとしてデータベースに接続します。
  3. 監視ジョブを使用している場合は、STREAMS$_PA_MONITORINGビューのSHOW_STATS_TABLE列を問い合せて、統計が格納されているこの表の名前を調べます。
    SELECT SHOW_STATS_TABLE FROM STREAMS$_PA_MONITORING;
  4. SHOW_STATSプロシージャを実行します。

    たとえば、監視ジョブおよびデフォルトの格納表を使用している場合は、次のプロシージャを実行します。

    SET SERVEROUTPUT ON SIZE 50000
BEGIN
  UTL_SPADV.SHOW_STATS(
    path_stat_table => 'STREAMS$_PA_SHOW_PATH_STAT');
END;
/
2.4.4.3 SHOW_STATSの出力の解釈

適用プロセスについての出力と、XStreamアウトバウンド・サーバーおよびインバウンド・サーバーについての出力には違いがあります。

注意:

この項の残りの部分では、UTL_SPADVパッケージと、適用プロセスについてのSHOW_STATSの出力を理解していることを前提としています。

関連項目:

UTL_SPADVパッケージの使用方法の詳細は、Oracle Streams概要および管理およびOracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。

2.4.4.3.1 アウトバウンド・サーバーがパスの最後のコンポーネントの場合の出力例

ここでは、アウトバウンド・サーバーがパスの最後のコンポーネントの場合の出力例を示します。

LEGEND
<statistics>=<capture>  [<queue>  <psender>  <preceiver>  <queue>  ]<apply>
<bottleneck>
<capture>    = '|<C>'<name>  <msgs captured/sec>  <msgs enqueued/sec>  <latency>
    'LMR'<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'LMP' (<parallelism>)<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'LMB'<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'CAP'<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'CAP+PS'<msgs sent/sec>  <bytes sent/sec>  <latency>  <idl%>
<flwctrl%>  <topevt%>  <topevt>
<apply>      = '|<A>'<name>  <msgs applied/sec>  <txns applied/sec>  <latency>
    'PS+PR'<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'APR'<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'APC'<idl%>  <flwctrl%>  <topevt%>  <topevt>
    'APS' (<parallelism>)<idl%>  <flwctrl%>  <topevt%>  <topevt>
<queue>      = '|<Q>'<name>  <msgs enqueued/sec>  <msgs spilled/sec>  <msgs in
queue>
<psender>    = '|<PS>'<name>  <msgs sent/sec>  <bytes sent/sec>  <latency>  <idl%>
<flwctrl%>  <topevt%>  <topevt>
<preceiver>  = '|<PR>'<name>  <idl%>  <flwctrl%>  <topevt%>  <topevt>
<bottleneck>= '|<B>'<name>  <sub_name>  <sessionid>  <serial#>  <topevt%>  <topevt> 


OUTPUT
PATH 1 RUN_ID 2 RUN_TIME 2009-MAY-15 12:20:55 CCA Y
|<C> CAP$_XOUT_1 2733 2730 3392 LMR 8.3% 91.7% 0% "" LMP (1) 8.3% 91.7% 0% ""
LMB 8.3% 91.7% 0% "" CAP 8.3% 91.7% 0% "" |<Q> "XSTRMADMIN"."Q$_XOUT_2" 2730 0.01
4109 |<A> XOUT 2329 2.73 0 -1 PS+PR 8.3% 91.7% 0% "" APR 8.3% 91.7% 0% "" APC
100% 0% 0% "" APS (1) 8.3% 83.3% 8.3% "" |<B> "EXTERNAL"
.
.
.

注意:

この出力は、説明のみを目的としています。実際のパフォーマンス特性は、個々の構成および条件によって異なります。

この出力では、Aコンポーネントがアウトバウンド・サーバーXOUTです。アウトバウンド・サーバーがパスの最後のコンポーネントの場合の出力は、適用プロセスがパス内の最後のコンポーネントの場合の出力と似ています。ただし、アウトバウンド・サーバーがクライアント・アプリケーションに接続しているため、適用サーバー(APS)は最後のコンポーネントではありません。クライアント・アプリケーションについての統計は収集されません。

XStream Out構成では、適用サーバーの「SQL*Net more data to client」パフォーマンス・メトリックがフロー制御イベントのように測定されるため、出力はネットワークのフロー制御を示すことができます。出力が適用サーバーのフロー制御を示す場合、ネットワークまたはクライアント・アプリケーションのいずれかがボトルネック・コンポーネントとみなされます。前の出力で、EXTERNALは、ネットワークまたはクライアント・アプリケーションのいずれかがボトルネックであることを示しています。

これらの相違点以外は、適用プロセスで終わるパスについて解釈する場合とほぼ同じ方法で、統計を解釈できます。出力の統計を判断するのに凡例および略称を使用します。

2.4.4.3.2 インバウンド・サーバーがパスの最後のコンポーネントの場合の出力例

ここでは、インバウンド・サーバーがパスの最後のコンポーネントの場合の出力例を示します。

OUTPUT     
PATH 1 RUN_ID 2 RUN_TIME 2009-MAY-16 10:11:38 CCA N
|<PR> "clientcap"=> 75% 0% 8.3% "CPU + Wait for CPU" |<Q> "XSTRMADMIN"."QUEUE2"  467 0.01 1 
|<A> XIN 476 4.71 0 APR 100% 0% 0% "" APC 100% 0% 0% "" APS (4) 366.7% 0% 33.3% "CPU + Wait for CPU" 
|<B> "EXTERNAL"
.
.
.

注意:

この出力は、説明のみを目的としています。実際のパフォーマンス特性は、個々の構成および条件によって異なります。

この出力では、Aコンポーネントがインバウンド・サーバーXINです。インバウンド・サーバーがパスの最後のコンポーネントの場合、XStreamクライアント・アプリケーションはインバウンド・サーバーに接続し、インバウンド・サーバーはLCRの変更を適用します。クライアント・アプリケーションは出力には表示されません。

伝播受信者はクライアント・アプリケーションからLCRを受信します。そのため、伝播受信者は、出力に示されている最初のコンポーネントです。前のサンプル出力で、伝播受信者にclientcapという名前が付けられています。この場合、clientcapは、インバウンド・サーバーへの連結時にクライアント・アプリケーションによって指定されたソース名です。

伝播受信者がアイドル状態である時間の割合が多い場合、ネットワークまたはクライアント・アプリケーションのいずれかがボトルネック・コンポーネントとみなされます。前の出力で、EXTERNALは、ネットワークまたはクライアント・アプリケーションのいずれかがボトルネックであることを示しています。

これらの相違点以外は、適用プロセスで終わるパスについて解釈する場合とほぼ同じ方法で、統計を解釈できます。出力の統計を判断するのに凡例および略称を使用します。

2.4.4.4 HTMLレポートでのXStream統計の表示

UTL_SPADVパッケージのSHOW_STATS_HTMLプロシージャは、パフォーマンス・アドバイザが収集および格納した統計を含むHTMLレポートを作成します。

comp_stat_tableパラメータを使用して、統計を含む表を指定します。

COLLECT_STATSプロシージャを使用して統計を収集するとき、COLLECT_STATSプロシージャのcomp_stat_tableパラメータでこの表を指定します。デフォルトでは、表名はSTREAMS$_ADVISOR_COMP_STATです。

START_MONITORINGプロシージャを使用して統計を収集するとき、この表の名前を調べるには、STREAMS$_PA_MONITORINGビューのSHOW_STATS_TABLE列を問い合せます。監視ジョブのデフォルトの表は、STREAMS$_ADVISOR_COMP_STATです。

comp_stat_tableパラメータのデフォルトはSTREAMS$_ADVISOR_COMP_STATです。SHOW_STATS_HTMLプロシージャを実行するときは、適切な表を指定していることを確認してください。

SHOW_STATS_HTMLプロシージャは、HTMLレポートをディレクトリに格納する必要があります。directoryパラメータを使用してディレクトリ・オブジェクトを指定します。

UTL_SPADVパッケージによって収集され、STREAMS$_ADVISOR_COMP_STAT表に格納された統計を表示するには、次の手順を実行します。

  1. UTL_SPADVパッケージを使用したXStreamの統計の収集で説明した手順を実行して、統計を収集します。
  2. 統計を収集したユーザーとしてデータベースに接続します。
  3. 監視ジョブを使用している場合は、STREAMS$_PA_MONITORINGビューのSHOW_STATS_TABLE列を問い合せて、統計が格納されているこの表の名前を調べます。
    SELECT SHOW_STATS_TABLE FROM STREAMS$_PA_MONITORING;
  4. HTMLレポートのファイルを格納するディレクトリのディレクトリ・オブジェクトを作成します。

    たとえば、/usr/xstream/reportsディレクトリのXSTREAM_STATS_HTMLというディレクトリ・オブジェクトを作成するには、次のSQL文を実行します。 

    CREATE DIRECTORY XSTREAM_STATS_HTML AS '/usr/xstream/reports';
  5. SHOW_STATS_HTMLプロシージャを実行します。

    たとえば、監視ジョブおよびデフォルトの格納表を使用している場合は、次のプロシージャを実行します。

    BEGIN
  UTL_SPADV.SHOW_STATS_HTML(
    directory       => 'XSTREAM_STATS_HTML',
    reportname      => 'xstream_stats.html',
    comp_stat_table => 'STREAMS$_ADVISOR_COMP_STAT');
END;
/
2.4.4.5 SHOW_STATS_HTMLからのHTMLレポートの解釈

UTL_SPADVパッケージのSHOW_STATS_HTMLプロシージャは、SHOW_STATSプロシージャと同じ出力を生成できますが、出力はHTMLファイルでHTMLとしてフォーマットされます。

SHOW_STATS_HTML出力は、SHOW_STATS出力よりも読みやすくなります。たとえば、プロシージャによって複数のファイルが生成され、各ファイルはレポート名で始まります。レポートには、パフォーマンス統計を示す表が含まれています。別のパスの統計は表内の別の行にあり、パスをクリックすると、パスに関するより詳細な統計情報が表示されます。report_nameパラメータは、他のHTMLファイルへのリンクが付いているマスターHTMLファイルを示します。

SHOW_STATS_HTMLプロシージャを使用するときの考慮事項は次のとおりです。

  • 統計を格納するデフォルト表は、STREAMS$_ADVISOR_COMP_STATです。SHOW_STATSプロシージャは、異なるデフォルト表(STREAMS$_ADVISOR_PATH_STAT)を使用します。

  • プロシージャのdirectoryパラメータにディレクトリ・オブジェクトを指定する必要があります。このディレクトリには、このプロシージャで生成されたHTMLファイルが格納されます。

    指定したディレクトリ・オブジェクトは、SQL文のCREATE DIRECTORYを使用して作成する必要があります。このプロシージャを起動するユーザーには、そのディレクトリのREAD権限およびWRITE権限が必要です。

図2-1はSHOW_STATS_HTMLプロシージャによって生成されたHTMLレポートの一部を示しています。

図2-1 SHOW_STATS_HTMLプロシージャによって生成されたHTMLレポート

図2-1の説明が続きます
「図2-1 SHOW_STATS_HTMLプロシージャによって生成されたHTMLレポート」の説明

関連項目:

SHOW_STATSの出力の解釈

2.5 XStreamおよびSQL生成

SQL生成とは、行LCRにカプセル化された変更を実行する際に必要となるSQL文を生成する機能です。

XStreamアウトバウンド・サーバーおよびXStreamインバウンド・サーバーはSQL生成を使用して、行LCRの挿入、更新、削除操作を実行するために必要なSQL文を生成できます。

2.5.1 SQL生成を実行するためのインタフェース

SQL生成用に各種のインタフェースを使用できます。

次のインタフェースを使用して、SQL生成を実行できます。

  • PL/SQLインタフェース。行LCRに対してGET_ROW_TEXTおよびGET_WHERE_CLAUSEメンバー・プロシージャを使用します。

  • XStreamのOCI

  • XStreamのJavaインタフェース

PL/SQLインタフェースを使用すると、CLOBデータ型のSQLが生成され、OCIおよびJavaインタフェースではSQLがプレーン・テキストで生成されます。Javaインタフェースでは、テキストのサイズはStringデータ型のサイズによって制限されます。

関連項目:

2.5.2 SQL生成のフォーマット

SQL文は、インライン値またはバインド変数の2つのフォーマットのいずれかで生成できます。

返されたSQL文が比較的小さい場合は、インライン値を使用します。SQL文が大きい場合は、バインド変数を使用します。この場合、バインド変数は、古い列値と新しい列値の両方を指すポインタを含む個別のリストでクライアント・アプリケーションに渡されます。

各インタフェースでのバインド変数の使用の詳細は、次のドキュメントを参照してください。

注意:

インライン値で生成されたSQL文の場合は、SQLインジェクションが発生する可能性があります。SQLインジェクションとは、SQL文内のクライアント提供データを使用するアプリケーションを不正に利用する手法であり、これにより機密データを表示または操作するためにデータベースに不正にアクセスできるようになります。生成されたSQL文を実行する予定の場合は、バインド変数を使用することを強くお薦めします。

関連項目:

2.5.3 SQL生成およびデータ型

SQL生成では、ほとんどのデータ型がサポートされています。

SQL生成では、次のデータ型がサポートされています。

  • VARCHAR2

  • NVARCHAR2

  • NUMBER

  • FLOAT

  • DATE

  • BINARY_FLOAT

  • BINARY_DOUBLE

  • LONG

  • TIMESTAMP

  • TIME WITH TIME ZONE

  • TIMESTAMP WITH LOCAL TIME ZONE

  • INTERVAL YEAR TO MONTH

  • INTERVAL DAY TO SECOND

  • RAW

  • LONG RAW

  • CHAR

  • NCHAR

  • BASICFILE記憶域を持つCLOB

  • BASICFILE記憶域を持つNCLOB

  • BASICFILE記憶域を持つBLOB

  • CLOB、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType

注意:

  • Oracle Database 12cでは、COMPATIBLE初期化パラメータを12.0.0に、MAX_STRING_SIZE初期化パラメータをEXTENDEDに設定すると、VARCHAR2、NVARCHAR2およびRAWの各データ型の最大サイズが増加します。

  • CLOBとして格納されるXMLTypeは、Oracle Database 12cリリース1 (12.1)からは非推奨になりました。

関連項目:

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

2.5.3.1 SQL生成および自動データ型変換

XStreamアウトバウンド・サーバーまたはインバウンド・サーバーでは暗黙的なデータ型変換が実行され(可能な場合)、生成されたSQLはANSI規格に従います(可能な場合)。

自動データ型変換では、次の点を考慮する必要があります。

  • NULLは"NULL"として指定します。

  • データ型CHAR、VARCHAR2、NVARCHAR2、NCHAR、CLOBおよびNCLOBでは、一重引用符は二重引用符に変換されます(インライン値の場合)。

  • LONGデータはCLOBデータに変換されます。

  • LONG RAWデータはBLOBデータに変換されます。

2.5.3.2 SQL生成とLOB、LONG、LONG RAWおよびXMLTypeの各データ型

LOB列に対するINSERTおよびUPDATE操作では、アウトバウンド・サーバーにより、LOBアセンブリを使用してLOBチャンクが自動的にアセンブルされます。

これらの操作の場合、生成されたSQLにはNULL以外の空の値が含まれます。チャンク化された列の実際の値は、後続のLCRに到達します。チャンクごとに、適切な列に対して適切なSQL操作を実行する必要があります。

同様に、LONG、LONG RAWおよびXMLTypeの各データ型に対して、アウトバウンド・サーバーによりNULL以外の空の値が生成され、列の実際の値が後続のLCRのチャンクに到達します。チャンクごとに、適切な列に対して適切なSQL操作を実行する必要があります。

生成されたSQLのインライン・バージョンでは、LOB、LONG、LONG RAWおよびXMLTypeの各データ型の列について、挿入と更新に対して次のSQLが生成されます。

  • CLOB、NCLOBおよびLONGの各データ型の列の場合: 

    EMPTY_CLOB()

  • BLOBおよびLONG RAWの各データ型の列の場合: 

    EMPTY_BLOB()

  • XMLType列の場合: 

    XMLTYPE.CREATEXML('xml /')

    ここで、xml /とはXMLチャンクのことです。

DML文を含むLCRが到達してから、これらの変更に対するデータが個別のチャンクに到達します。このような変更に対してWHERE句を生成し、生成したWHERE句を使用してチャンクに含まれる変更対象の行を識別できます。たとえば、PL/SQLでは、GET_WHERE_CLAUSE行LCRメンバー・プロシージャを使用して、行変更に対してWHERE句を生成できます。

INSERTおよびUPDATE操作の場合は、生成されたWHERE句によって挿入または更新後の行が識別されます。たとえば、hr.departments表に対する次の更新の場合を考えます。 

UPDATE hr.departments SET department_name='Management' 
  WHERE department_name='Administration';

この変更に対して生成されたWHERE句は、次のとおりです。 

WHERE "DEPARTMENT_NAME"='Management'

DBMS_LOBパッケージのサブプログラムによって実行されるピース単位のLOB操作(WRITE、TRIMおよびERASEの各プロシージャなど)の場合、生成されたSQLにはSELECT FOR UPDATE文が含まれます。

たとえば、clob_colに対するLOB_WRITE操作では、次のようなSQLが生成されます。 

SELECT "CLOB_COL" FROM "HR"."LOB_TAB" WHERE "N1"=2 FOR UPDATE

選択されるclob_colは定義されている必要があります。LOBロケータを使用して、行LCRに続くLOBチャンクでピース単位のLOB操作を実行できます。

関連項目:

2.5.4 SQL生成およびキャラクタ・セット

LCRメソッドを使用する場合、SQLはデータベース・キャラクタ・セットで生成されます。

INSERT、UPDATE、INTOなどのSQLキーワードは、キャラクタ・セットに応じて変更されることはありません。

関連項目:

2.5.5 生成されたSQL文の例

各例では、生成されたSQL文が示されています。

2.5.5.1 hr.employees表に対して生成されたSQL文の例

各例では、hr.employees表に対して行われた変更に対してアウトバウンド・サーバーによって生成されたSQL文が示されています。

注意:

生成されたSQLは単一行であり、フォーマットされていません。

例2-1 生成された挿入

次の挿入が実行されるとします。

INSERT INTO hr.employees (employee_id, 
                           last_name, 
                           email, 
                           hire_date, 
                           job_id, 
                           salary, 
                           commission_pct) 
                   VALUES (207, 
                           'Gregory', 
                           'pgregory@example.com', 
                           SYSDATE, 
                           'PU_CLERK', 
                           9000, 
                           NULL);

インライン値を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."EMPLOYEES"("EMPLOYEE_ID","FIRST_NAME","LAST_NAME",
"EMAIL","PHONE_NUMBER","HIRE_DATE","JOB_ID","SALARY","COMMISSION_PCT",
"MANAGER_ID","DEPARTMENT_ID" ) VALUES ( 207, NULL,'Gregory',
'pgregory@example.com', NULL , TO_DATE(' 2009-04-15','syyyy-mm-dd'),
'PU_CLERK',9000, NULL , NULL , NULL )

バインド変数を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."EMPLOYEES"("EMPLOYEE_ID","FIRST_NAME","LAST_NAME",
"EMAIL","PHONE_NUMBER","HIRE_DATE","JOB_ID","SALARY",
"COMMISSION_PCT","MANAGER_ID","DEPARTMENT_ID" ) VALUES ( :1   ,:2   ,:3   
,:4   ,:5   ,:6   ,:7   ,:8   ,:9   ,:10  ,:11  )

例2-2 生成された更新

次の更新が実行されるとします。

UPDATE hr.employees SET salary=10000 WHERE employee_id=207;

インライン値を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."EMPLOYEES" SET "SALARY"=10000 WHERE "EMPLOYEE_ID"=207 
AND "SALARY"=9000

バインド変数を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."EMPLOYEES" SET "SALARY"=:1    WHERE "EMPLOYEE_ID"=:2    
AND "SALARY"=:3

例2-3 生成された削除

次の削除が実行されるとします。

DELETE FROM hr.employees WHERE employee_id=207;

インライン値を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."EMPLOYEES" WHERE "EMPLOYEE_ID"=207 AND "FIRST_NAME" IS NULL 
AND "LAST_NAME"='Gregory' AND "EMAIL"='pgregory@example.com' AND 
"PHONE_NUMBER" IS NULL  AND "HIRE_DATE"= TO_DATE(' 2009-04-15','syyyy-mm-dd') 
AND "JOB_ID"='PU_CLERK' AND "SALARY"=10000 AND "COMMISSION_PCT" IS NULL  
AND "MANAGER_ID" IS NULL  AND "DEPARTMENT_ID" IS NULL

バインド変数を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."EMPLOYEES" WHERE "EMPLOYEE_ID"=:1    AND "FIRST_NAME"=:2    
AND "LAST_NAME"=:3    AND "EMAIL"=:4    AND "PHONE_NUMBER"=:5    AND 
"HIRE_DATE"=:6    AND "JOB_ID"=:7    AND "SALARY"=:8    AND 
"COMMISSION_PCT"=:9   AND "MANAGER_ID"=:10   AND "DEPARTMENT_ID"=:11
2.5.5.2 LOB列のある表に対して生成されたSQL文の例

各例では、LOB列のある表に対して行われた変更に対してアウトバウンド・サーバーによって生成されたSQL文が示されています。

各例では、次の表に対して行われた変更に対してアウトバウンド・サーバーによって生成されたSQL文が示されています。

CREATE TABLE hr.lob_tab(
   n1        number primary key,
   clob_col  CLOB,
   nclob_col NCLOB,
   blob_col  BLOB);

注意:

生成されたSQLは単一行であり、フォーマットされていません。

GET_WHERE_CLAUSEメンバー・プロシージャを使用すると、この挿入に対して次のWHERE句が生成されます。

  • インライン:

    WHERE "N1"=2

  • バインド変数:

    WHERE "N1"=:1

WHERE句を使用して、後続のチャンクがLOB列の変更に到達するときに挿入された行を識別できます。

例2-4 LOB列のある表に対して生成された挿入

次の挿入が実行されるとします。

INSERT INTO hr.lob_tab VALUES (2, 'test insert', NULL, NULL);

インライン値を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."LOB_TAB"("N1","BLOB_COL","CLOB_COL","NCLOB_COL" ) 
VALUES ( 2,, EMPTY_CLOB() ,)

バインド変数を使用して生成されたSQLは、次のとおりです。

INSERT INTO "HR"."LOB_TAB"("N1","BLOB_COL","CLOB_COL","NCLOB_COL" ) 
VALUES ( :1   ,:2   ,:3   ,:4   )

例2-5 LOB列のある表に対して生成された更新

次の更新が実行されるとします。

UPDATE hr.lob_tab SET clob_col='test update' WHERE n1=2;

インライン値を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."LOB_TAB" SET "CLOB_COL"= EMPTY_CLOB()  WHERE "N1"=2

バインド変数を使用して生成されたSQLは、次のとおりです。

UPDATE "HR"."LOB_TAB" SET "CLOB_COL"=:1    WHERE "N1"=:2

例2-6 LOB列のある表に対して生成された削除

次の削除が実行されるとします。

DELETE FROM hr.lob_tab WHERE n1=2;

インライン値を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."LOB_TAB" WHERE "N1"=2

バインド変数を使用して生成されたSQLは、次のとおりです。

DELETE  FROM "HR"."LOB_TAB" WHERE "N1"=:1

2.5.6 SQL生成のデモ

SQL生成を実行するデモを使用できます。

このデモではDBMS_XSTREAM_ADM PL/SQLパッケージを使用して、XStream Out環境を構成し、OCIクライアント・アプリケーションを使用してSQL生成を実行します。

このデモではSQL生成を使用して、ソース・データベースから宛先データベースにDML変更をレプリケートします。具体的には、デモではソース・データベースと宛先データベースの両方にxsdemosgスキーマが作成されます。ここでは各データベースのxsdemosgスキーマに、LOB列を含む表などの様々なタイプの表が作成されます。また、ソース・データベースのxsdemosgスキーマ内の表に対してDML文のセットが実行されます。取得プロセスおよびキューなどのOracle Streamsコンポーネントによって、ソース・データベースで実行中のXStreamアウトバウンド・サーバーに対してLCR形式で変更が送信されます。アウトバウンド・サーバーにより、デモのクライアント・アプリケーションでLCRが使用できるようになります。

デモのクライアント・アプリケーションは、実行するとOCI APIを使用してアウトバウンド・サーバーに接続し、LCRを受信します。デモのクライアント・アプリケーションはSQL生成を使用して、LCRにカプセル化された変更を実行します。したがって、クライアント・アプリケーションはソース・データベースのxsdemosgスキーマに行われた変更を、宛先データベースのxsdemosgスキーマにレプリケートします。

任意のスキーマに変更をレプリケートするようにデモを変更できます。スキーマおよびレプリケートされる表の両方が、ソース・データベースと宛先データベースの両方に存在する必要があります。SQL生成は、DML変更にかぎり可能です。したがって、このデモはDDL変更をレプリケートするためには使用できません。

このデモは、次の場所にあります。

$ORACLE_HOME/rdbms/demo/xstream/sqlgen

注意:

SQL生成のデモは、XStream Java APIに対しては使用できません。