1. XStreamガイド
  2. XStreamの一般的概念とユースケース
  3. XStreamの一般的な概念

2 XStreamの一般的概念

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

関連項目:

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

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

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

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

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

2.1.1 行LCR

行LCRは、単一行のデータに対する変更、あるいは行内の単一の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など)。

2.1.1.1 行LCRのサブタイプ

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

このような行LCRは内部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ファンクションと、OCI_ROWLCR_SEQ_LCRフラグを設定したOCILCRHeaderSetファンクションを使用します。

  • 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の順序が決まります。

  • LCRの位置は、データベース、クライアント・アプリケーションまたはXStreamコンポーネントが再起動されても変わりません。

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

XStream Outはコミットされたデータのみを送信し、XStream Inはコミットされたデータのみを受信します。

LCRストリームには次の特性があります。

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

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

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

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

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

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

LCRストリームでは、複数のトランザクションからのLCRをまとめて、位置の昇順で並べ替えることができます。1つのトランザクションからのLCRは連続しており、位置はトランザクション内で増加していく必要があります。また、位置はすべてのLCRについて0(ゼロ)以外である必要があります。

関連項目:

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では、ルールおよびルール・セットが使用されます。

関連項目:

2.2.1 定義済のルールおよびルール・セット

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

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

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

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

DML変更の結果は行の変更であり、行の変更をカプセル化するLCRは行LCRと呼ばれます。1つのDML変更の結果、複数の行が変更される可能性があります。そのため、単一の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パッケージによって作成されます。

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

関連項目:

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変更の結果を廃棄します。

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

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

インバウンド・サーバーのポジティブ・ルール・セットに含まれる単一のグローバル・ルールが満たされると、インバウンド・サーバーが、XStreamクライアント・アプリケーションから送信されたすべての行LCRまたはDDL LCRを適用します。インバウンド・サーバーのネガティブ・ルール・セットに含まれる単一のグローバル・ルールが満たされると、インバウンド・サーバーが、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をソース・キューから廃棄します。

アウトバウンド・サーバーのポジティブ・ルール・セットに含まれる単一のスキーマ・ルールが満たされると、アウトバウンド・サーバーが、受信する行LCRまたはDDL LCRのうちスキーマに対する変更が含まれるものを、XStreamクライアント・アプリケーションにを送信します。アウトバウンド・サーバーのネガティブ・ルール・セットに含まれる単一のスキーマ・ルールが満たされると、アウトバウンド・サーバーが、受信する行LCRまたはDDL LCRのうちスキーマに対する変更が含まれるものを廃棄します。

インバウンド・サーバーのポジティブ・ルール・セットに含まれる単一のスキーマ・ルールが満たされると、インバウンド・サーバーが、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのうち、スキーマに対する変更が含まれるものを適用します。インバウンド・サーバーのネガティブ・ルール・セットに含まれる単一のスキーマ・ルールが満たされると、インバウンド・サーバーが、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのうち、スキーマに対する変更が含まれるものを廃棄します。

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

関連項目:

2.2.3.4 表ルール

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

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

取得プロセスのポジティブ・ルール・セットに含まれる単一の表ルールが満たされると、取得プロセスが表に対するDML変更またはDDL変更を取得します。また、取得プロセスのネガティブ・ルール・セットに含まれる単一の表ルールが満たされると、取得プロセスが表に対するDML変更またはDDL変更を廃棄します。

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

アウトバウンド・サーバーのポジティブ・ルール・セットに含まれる単一の表ルールが満たされると、アウトバウンド・サーバーが、受信した行LCRまたはDDL LCRのうち表に対する変更を含むものを、XStreamクライアント・アプリケーションに送信します。アウトバウンド・サーバーのネガティブ・ルール・セットに含まれる単一の表ルールが満たされると、アウトバウンド・サーバーが、受信した行LCRまたはDDL LCRのうち表に対する変更を含むものを廃棄します。

インバウンド・サーバーのポジティブ・ルール・セットに含まれる単一の表ルールが満たされると、インバウンド・サーバーが、XStreamクライアント・アプリケーションから受信した行LCRまたはDDL LCRのうち、表に対する変更を含むものを適用します。インバウンド・サーバーのネガティブ・ルール・セットに含まれる単一の表ルールが満たされると、インバウンド・サーバーが、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が、それぞれコンテナとなります。

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

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

2.2.3.6.1 CDBにおけるシステム生成ルールとXStream Out

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

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

表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

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

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

関連項目:

Oracle Database管理者ガイド

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パッケージで実行される変換については説明しません。

  • XStream In構成で行LCRの大部分が変換される場合、XStream InでDMLハンドラを使用できます。ただし、この方法では、XStreamクライアント・アプリケーションで変更を加えるよりも時間がかかる可能性があります。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

前述のタイプは、APPLYを除いて、Oracle Streams環境とXStream環境で同じです。APPLYコンポーネント・タイプは、XStreamのアウトバウンド・サーバーまたはインバウンド・サーバーに該当します。

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

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

XStream OutのAPPLYには、いくつかのサブタイプがあります。

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

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

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

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

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

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

XStream InのAPPLYには、いくつかのサブコンポーネントがあります。

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

  • 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: 適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーによって1秒間に適用されたLCRの平均数。

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

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

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

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

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

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

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

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

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

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

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

関連項目:

コンポーネント・レベルの統計の詳細は、Oracle Streams概要および管理を参照

2.4.4 UTL_SPADVパッケージ

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

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

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

UTL_SPADVパッケージは、適用プロセスを含むOracle Streams環境に対しても、アウトバウンド・サーバーまたはインバウンド・サーバーを含むXStream環境と基本的に同様に機能します。XStreamはクライアント・アプリケーションとの間でやり取りされるデータ変更を処理するため、XStreamに対するSHOW_STATSプロシージャの出力は、Oracle Streamsの場合とは異なります。

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

XStreamの統計を収集するには、UTL_SPADVパッケージを使用します。

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

注意:

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

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

関連項目:

データ型の詳細は、Oracle Database SQL言語リファレンスを参照

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

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

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

  • 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では使用できません。