2 XStreamの一般的概念
XStreamの一般的概念は、XStream OutとXStream Inの両方に当てはまります。
- 論理変更レコード(LCR)
LCRは、データベース変更を説明する特定の形式のメッセージです。 - ルールとルール・セット
XStreamでは、ルールおよびルール・セットを使用します。 - ルールベースの変換
XStreamでは、ルールベース変換は、ポジティブ・ルール・セットのルールがTRUE
と評価されたときの論理変更レコード(LCR)に対するあらゆる変更です。 - XStreamとOracle Replicationパフォーマンス・アドバイザ
Oracle Replicationパフォーマンス・アドバイザは、データ・ディクショナリ・ビューのコレクションで構成されています。 - XStreamおよびSQL生成
SQL生成とは、行LCRにカプセル化された変更を実行する際に必要となるSQL文を生成する機能です。
関連項目:
親トピック: XStreamの一般的な概要およびユースケース
2.1 論理変更レコード(LCR)
LCRは、データベース変更を説明する特定の形式のメッセージです。
LCRには、行LCR、DDL LCRおよび順序LCRの3種類があります。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値を使用します。
親トピック: XStreamの一般的な概念
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に含まれる属性
属性 | 説明 |
---|---|
|
行の変更が発生したソース・データベースの名前。 LCRがマルチテナント・コンテナ・データベース(CDB)で発生した場合は、行変更が発生したコンテナのグローバル名がこの属性によって指定されます。 |
|
変更を生成したDML文のタイプ( |
|
行に変更があった表を含むスキーマの名前。 |
|
変更があった行を含む表の名前。 |
|
LCRの追跡に使用できるRAWタグ。 |
|
DML文が実行されたトランザクションの識別子。 |
|
変更が行われた時点のシステム変更番号(SCN)。 |
|
変更に関連する古い列の値。DML変更が行われる前の行の列値です。DML文のタイプが |
|
変更に関連する新しい列の値。DML変更が行われた後の行の列値です。DML文のタイプが |
|
各LCRの LCR位置は、XStream構成で一般的に使用されます。 LCRストリーム内の位置の順序を参照してください。 |
|
LCRがCDBで発生した場合、この属性では、CDBのルートのグローバル名が指定されます。 LCRがCDB以外で発生した場合、この属性は |
XStream Out構成の取得プロセスによって取得された行LCRには、追加属性が含まれています。次の表で、これらの追加属性について説明します。これらの属性は、XStream In構成のXStreamクライアント・アプリケーションによって作成された行LCRに存在しません。
表2-2 取得プロセスによって取得されたLCR内の追加属性
属性 | 説明 |
---|---|
|
LCRが属するトランザクションのコミット・システム変更番号(SCN)。 |
|
入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。 |
|
LCRが属するトランザクションのコミット時間。 |
|
そのLCRのサポートに必要なデータベースの最小互換レベル。 |
|
変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。 |
|
列のLOB情報( |
|
指定された列のLOBオフセット( |
|
LOB列の操作サイズ( |
|
列の |
|
行LCR内にカプセル化された変更に対応するSQL文。 |
|
LCRのSCN。 |
|
取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。 |
|
列のXML情報( |
- 行LCRのサブタイプ
行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMIT
やROLLBACK
などのトランザクション制御ディレクティブが含まれています。
親トピック: 論理変更レコード(LCR)
2.1.1.1 行LCRのサブタイプ
行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMIT
やROLLBACK
などのトランザクション制御ディレクティブが含まれています。
このような行LCRは内部LCRであり、アウトバウンド・サーバー、インバウンド・サーバーおよびXStreamクライアント・アプリケーションが、トランザクションの一貫性を保つために使用できます。
親トピック: 行LCR
2.1.2 DDL LCR
DDL LCRでは、データ定義言語(DDL)の変更が記述されます。
DDL文は、データベースの構造を変更します。たとえば、DDL文でデータベース・オブジェクトを作成、変更または削除できます。
それぞれのDDL LCRは、LCR$_DDL_RECORD
タイプのオブジェクトにカプセル化されます。次の表に、DDL LCRごとに存在する属性を示します。
表2-3 すべてのDDL LCRに含まれる属性
属性 | 説明 |
---|---|
|
DDLの変更が発生したソース・データベースの名前。 LCRがCDBで発生した場合、この属性では、DDL変更が発生したコンテナのグローバル名が指定されます。 |
|
変更を生成したDDL文のタイプ( |
|
DDL文が実行されたデータベース・オブジェクトを所有しているユーザーのスキーマ名。 |
|
DDL文が実行されたデータベース・オブジェクトの名前。 |
|
DDL文が実行されたデータベース・オブジェクトのタイプ( |
|
DDL文のテキストです。 |
|
ログオン・ユーザー。DDL文を実行したセッションのユーザーです。 |
|
DDLテキストでオブジェクトに対するスキーマが指定されていない場合に使用されるスキーマ。 |
|
実表の所有者。DDL文が表に依存する場合、実表の所有者は依存先となる表の所有者です。 |
|
実表の名前。DDL文が表に依存する場合、実表の名前は依存先となる表の名前です。 |
|
LCRの追跡に使用できるRAWタグ。 |
|
DDL文が実行されたトランザクションの識別子。 |
|
変更が行われた時点のシステム変更番号(SCN)。 |
|
各LCRの LCR位置は、XStream構成で一般的に使用されます。 LCRストリーム内の位置の順序を参照してください。 |
|
DDL文が実行されたエディションの名前。 |
|
LCRがCDBで発生した場合、この属性では、CDBのルートのグローバル名が指定されます。 LCRがCDB以外で発生した場合、この属性は |
取得プロセスによって取得されたDDL LCRには、追加の属性が含まれます。次の表に、これらの追加属性の説明を示します。これらの属性は、XStream In構成のXStreamクライアント・アプリケーションによって作成されたDDL LCRには存在しません。
表2-4 取得プロセスによって取得されたDDL LCR内の追加属性
属性 | 説明 |
---|---|
|
LCRが属するトランザクションのコミット・システム変更番号(SCN)。 |
|
入力位置によって決定されたトランザクションのコミットSCN。XStreamアウトバウンド・サーバーによって生成される。 |
|
LCRが属するトランザクションのコミット時間。 |
|
そのLCRのサポートに必要なデータベースの最小互換レベル。 |
|
変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。 |
|
LCRのSCN。 |
|
取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。 |
ノート:
行LCRとDDL LCRの両方に、変更が発生したデータベースのソース・データベース名が含まれています。問題を回避するには、取得プロセスが変更の取得を開始した後に、ソース・データベースのグローバル名を変更しないことをお薦めします。
関連項目:
-
SQLコマンド・コード表のDDL文のタイプの完全なリストについては、Oracle Call Interfaceプログラマーズ・ガイドを参照
親トピック: 論理変更レコード(LCR)
2.1.3 行LCRおよびDDL LCRに含まれる追加情報
前の項で説明した情報の他に、追加の情報(LCR属性)をオプションとして行LCRとDDL LCRに含めることができます。
次の表に、LCR内の追加属性の説明を示します。
表2-5 LCRのその他の属性
属性 | 説明 |
---|---|
|
行のLCRで変更された行のROWID。この属性は、索引構成表のDDL LCRまたは行LCRには含まれません。 |
|
LCRに取得された変更を実行したセッションのシリアル番号。 |
|
LCRに取得された変更を実行したセッションの識別子。 |
|
LCRに取得された変更が実行されたインスタンスのスレッド番号。通常、スレッド番号はOracle Real Application Clusters(Oracle RAC)環境のみで使用されます。 |
|
LCRの属するトランザクションの名前。 |
|
LCRに取得された変更を実行した現行ユーザーの名前。 |
DBMS_CAPTURE_ADM
パッケージのINCLUDE_EXTRA_ATTRIBUTE
プロシージャを使用して取得プロセスを実行すると、1つ以上の追加属性を取得できます。
関連項目:
-
INCLUDE_EXTRA_ATTRIBUTE
プロシージャの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照 -
現在のユーザーの詳細は、Oracle Database PL/SQL言語リファレンスを参照
親トピック: 論理変更レコード(LCR)
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適用プロセスでは、順序LCRを使用することで、宛先データベースの順序値に適切な値が使用されることを保証できます。増加する順序の場合、接続先の順序値は、ソース・データベースの順序値以上になります。減少する順序の場合、接続先の順序値は、ソース・データベースの順序値以下になります。インバウンド・サーバーまたは適用プロセスに順序LCRを使用するよう指示するには、apply_sequence_nextval
適用パラメータをY
に設定します。
ノート:
順序LCRは一方向レプリケーション構成での使用を想定して提供されています。双方向レプリケーション構成では順序LCRを使用できません。
関連項目:
-
OCIインタフェースの詳細は、Oracle Call Interfaceプログラマーズ・ガイド
-
Javaインタフェースの詳細は、Oracle Database XStream Java APIリファレンス
-
順序の詳細は、Oracle Database管理者ガイド
親トピック: 論理変更レコード(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(ゼロ)以外である必要があります。
親トピック: 論理変更レコード(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値を別のバージョンに変換します。
関連項目
親トピック: 論理変更レコード(LCR)
2.2 ルールとルール・セット
XStreamでは、ルールおよびルール・セットが使用されます。
- ルールとルール・セットの定義
ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。XStream構成では、ルールによって、1つのコンポーネントから別のコンポーネントにストリームするLCRが識別されます。 - ルール・セットおよびXStreamコンポーネント
XStreamコンポーネントは、データベースの変更がそのルール・セットを満たしている場合に、そのタスクを実行します。 - システム作成ルールとXStream
XStreamコンポーネントは、LCRがそのルール・セットを満たしている場合に、LCRに対してそのタスクを実行します。システム作成ルールは、DBMS_XSTREAM_ADM
パッケージによって作成されます。
親トピック: 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
パッケージによって作成されます。
システム作成ルールでは、粒度レベルとして、表、スキーマまたはグローバルのいずれかを指定できます。
- 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システム作成ルールのプロシージャ
プロシージャ | 取得プロセス | 伝播 | アウトバウンド・サーバー | インバウンド・サーバー |
---|---|---|---|---|
|
可 |
不可 |
はい |
不可 |
|
不可 |
不可 |
はい |
不可 |
|
はい |
不可 |
はい |
不可 |
|
はい |
不可 |
はい |
はい |
|
不可 |
はい |
不可 |
不可 |
|
はい |
不可 |
はい |
はい |
|
不可 |
はい |
不可 |
不可 |
|
はい |
不可 |
はい |
はい |
|
不可 |
不可 |
はい |
不可 |
|
はい |
不可 |
はい |
はい |
|
不可 |
はい |
不可 |
不可 |
|
はい |
不可 |
はい |
はい |
|
不可 |
はい |
不可 |
不可 |
関連項目:
これらのプロシージャの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照
親トピック: システム作成ルールとXStream
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
プロシージャのいずれかを使用します。
親トピック: システム作成ルールとXStream
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を構成できます。
関連トピック
親トピック: システム作成ルールと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のシステム作成ルール用プロシージャのキー・パラメータ
パラメータ | 説明 |
---|---|
|
ソース・データベースのグローバル名。CDBでは、ルールに関連するコンテナのグローバル名を指定してください。このコンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。例: |
|
ソースCDBのCDBルートのグローバル名。例: |
|
ソース・コンテナの短縮名。このコンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。例: |
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パラメータの設定 | 説明 |
---|---|---|
|
|
XStream Outが、ローカルCDB内のすべてのコンテナ(CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBを含む)に加えられた変更を取得してストリームします。 |
|
|
XStream Outが、ローカルCDBの指定されたソース・コンテナで行われた変更を取得してストリームします。ソース・コンテナには、CDBルート、PDB、アプリケーション・ルートまたはアプリケーションPDBを指定できます。 |
|
|
XStream OutはローカルCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。 |
|
|
XStream OutはローカルCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。
|
次の表に、ダウンストリーム取得の構成におけるsource_database
およびsource_container_name
の様々なパラメータ設定に対応するルール条件を示します。
表2-9 ダウンストリーム取得とXStream Outのコンテナのルール条件
source_databaseパラメータ設定 | source_container_nameパラメータ設定 | 説明 |
---|---|---|
|
|
XStream Outが、リモート・ソースCDB内のすべてのコンテナ(CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBを含む)に加えられた変更を取得してストリームします。 |
|
|
XStream Outが、リモート・ソースCDBの指定されたソース・コンテナに加えられた変更を取得してストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。 |
|
|
|
|
|
XStream Outはリモート・ソースCDBの指定されたソース・コンテナで行われた変更を取得し、ストリームします。ソース・コンテナは、CDBルート、PDB、アプリケーション・ルート、またはアプリケーションPDBの可能性があります。
|
2.2.3.6.2 CDBのシステム作成ルールとXStream In
XStream Inは、ルートまたはCDB内の任意のコンテナで構成できます。
通常、インバウンド・サーバーでは、ルール・セットやルールを使用しません。かわりに、通常はクライアント・アプリケーションから受信したすべてのLCRを処理します。インバウンド・サーバーは、現在のコンテナにのみ変更を適用できます。そのため、インバウンド・サーバーがCDBルートで構成されている場合は、CDBルートにのみ変更を適用できます。インバウンド・サーバーがPDBで構成されている場合は、そのPDBにのみ変更を適用できます。インバウンド・サーバーがアプリケーション・ルートで構成されている場合は、そのアプリケーション・ルートにのみ変更を適用できます。また、インバウンド・サーバーがアプリケーションPDBで構成されている場合は、そのアプリケーションPDBにのみ変更を適用できます。
関連トピック
親トピック: システム作成ルールとマルチテナント環境
2.3 ルールベースの変換
XStreamにおいて、ルールベースの変換とは、ポジティブ・ルール・セットのルールがTRUE
と評価される場合に発生する、論理変更レコード(LCR)に対する変更です。
一般的には、クライアント・アプリケーションがデータの変換を実行するのが最善の方法です。これが可能でない場合は、データベースがDML LCRに対していくつかの単純な変換を実行できます。
- 宣言ルールベースの変換
宣言ルールベースの変換は、行LCRに対する共通の変換シナリオ・セットを扱います。 - 宣言ルールベースの変換の順序
様々なタイプのルールベース変換が評価される順序は、順序によって結果が変わることがあるため重要です。 - 変換の順序の評価
変換の順序を評価できます。
親トピック: XStreamの一般的な概念
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つのルールに、次の宣言ルールベースの変換が指定されたとします。
-
列addressの削除
-
列addressの追加
列addressが行LCRに存在するとした場合、両方の宣言変換を実行する必要があります。これは、列addressが行LCRに戻される前に、列addressが行LCRから削除されるためです。次の表に、この例での変換の順序付けを示します。
ステップ番号 | 変換タイプ | 変換の詳細 | 変換が実行されるかどうか |
---|---|---|---|
1 |
列の保持 |
- |
- |
2 |
列の削除 |
行LCRから列 |
はい |
3 |
列名の変更 |
- |
- |
4 |
列の追加 |
行LCRに列 |
はい |
5 |
表名の変更 |
- |
- |
6 |
スキーマ名の変更 |
- |
- |
別の例として、表名を変更してからスキーマ名を変更する場合を考えます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたとします。
-
表名
john.customers
をsue.clients
に変更 -
スキーマ名
sue
をmary
に変更
表名の変更の変換では、表のスキーマ名も変更されることに注意してください。この場合、変換は両方とも実行され、両方の変換後の表名はmary.clients
になります。次の表に、この例での変換の順序付けを示します。
ステップ番号 | 変換タイプ | 変換の詳細 | 変換が実行されるかどうか |
---|---|---|---|
1 |
列の保持 |
- |
- |
2 |
列の削除 |
- |
- |
3 |
列名の変更 |
- |
- |
4 |
列の追加 |
- |
- |
5 |
表名の変更 |
表名 |
はい |
6 |
スキーマ名の変更 |
スキーマ名 |
はい |
類似した例で、1つのルールに、次の宣言ルールベースの変換が指定された場合を考えます。
-
表名
john.customers
をsue.clients
に変更 -
スキーマ名
john
をmary
に変更
この場合、1つ目の変換は実行されますが、2つ目の変換は実行されません。1つ目の変換の実行後、表名はsue.clients
になります。2つ目の変換の実行時、表のスキーマ名はjohn
ではなくsue
であるため、2つ目の変換は実行されません。次の表に、この例での変換の順序付けを示します。
ステップ番号 | 変換タイプ | 変換の詳細 | 変換が実行されるかどうか |
---|---|---|---|
1 |
列の保持 |
- |
- |
2 |
列の削除 |
- |
- |
3 |
列名の変更 |
- |
- |
4 |
列の追加 |
- |
- |
5 |
表名の変更 |
表名 |
はい |
6 |
スキーマ名の変更 |
スキーマ名 |
いいえ |
スキーマ名の変更の変換は実行されませんが、エラーは発生しません。この場合、表名の変更の変換によって、行LCRは変換され、表名sue.clients
の行LCRが返されます。
親トピック: ルールベースの変換
2.3.3 変換順序の評価
変換の順序を評価できます。
- 行の移行の変換順序
宣言ルールベースの変換に加えて、行移行はサブセット・ルールがTRUE
と評価されたときに実行される内部変換です。 - 宣言ルールベースの変換のユーザー指定の順序
特定のルールに対して、宣言ルールベースの変換のデフォルトの順序を使用しない場合、ルールに指定された各宣言変換にステップ番号を指定できます。 - ルールベースの変換に関する考慮事項
宣言ルールベースの変換に該当するいくつかの考慮事項があります。
親トピック: ルールベースの変換
2.3.3.1 行の移行変換の順序
宣言ルールベースの変換に加えて、サブセット・ルールがTRUE
と評価されたときに実行される内部変換として、行の移行があります。
サブセット・ルールは、DBMS_XSTREAM_ADM.ADD_SUBSET_RULES
プロシージャを使用して追加できます。次の両方の変換が単一のルールに指定されている場合、ルールがTRUE
と評価されると、次の順序で変換が実行されます。
-
行の移行
-
宣言ルールベースの変換
親トピック: 変換順序の評価
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 Replicationパフォーマンス・アドバイザ
Oracle Replicationパフォーマンス・アドバイザは、データ・ディクショナリ・ビューのコレクションで構成されています。
パフォーマンス・アドバイザを使用すると、XStream環境のトポロジおよびパフォーマンスを監視できます。XStreamのトポロジには、XStream環境のコンポーネント、コンポーネント間のリンク、取得からコンシュームへの情報フローに関する情報が含まれています。パフォーマンス・アドバイザは、Oracle Replicationコンポーネントの実行状況に関する情報も提供します。
適用プロセスは、XStreamのアウトバウンド・サーバーとインバウンド・サーバーの役割を果たします。一般に、パフォーマンス・アドバイザは、適用プロセスを含むOracle Replication環境と、アウトバウンド・サーバーまたはインバウンド・サーバーを含むXStream環境に対して、同様に機能します。この項では、XStream環境でパフォーマンス・アドバイザを使用する場合の重要な考慮事項について説明します。
- XStreamコンポーネント
パフォーマンス・アドバイザは複数のXStreamコンポーネントを追跡します。 - トポロジおよびストリーム・パス
Oracle Replicationのトポロジでのストリーム・パスとは、ソースから宛先へのLCRのフローのことです。 - XStreamおよびコンポーネント・レベルの統計
パフォーマンス・アドバイザは、コンポーネント・レベルの統計を追跡します。 - UTL_RPADVパッケージ
UTL_RPADV
パッケージは、XStreamのパフォーマンスに関連する統計の収集を自動化します。
親トピック: XStreamの一般的な概念
2.4.1 XStreamコンポーネント
パフォーマンス・アドバイザは、いくつかのXStreamコンポーネントを追跡します。
パフォーマンス・アドバイザが追跡するXStream環境内のコンポーネントのタイプは、次のとおりです。
-
QUEUE
-
CAPTURE
-
PROPAGATION
SENDER
-
PROPAGATION
RECEIVER
-
APPLY
前述のタイプは、APPLY
を除いて、Oracle Replication環境とXStream環境で同じです。APPLY
コンポーネント・タイプは、XStreamのアウトバウンド・サーバーまたはインバウンド・サーバーに該当します。
また、パフォーマンス・アドバイザは、最もビジーなコンポーネント、またはアイドル時間が最も少ないコンポーネントとして、ボトルネック・コンポーネントを識別します。XStream構成では、DBA_STREAMS_TP_PATH_BOTTLENECK
ビューのACTION_NAME
列にEXTERNAL
が表示されると、XStreamクライアント・アプリケーションがボトルネックとなっている可能性があります。
- XStream Outの適用サブコンポーネント
XStream Outの適用サブコンポーネント・タイプがいくつかあります。 - XStream Inの適用サブコンポーネント
XStream Inの適用サブコンポーネント・タイプがいくつかあります。
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をクライアント・アプリケーションに配信します。
親トピック: XStreamコンポーネント
2.4.1.2 XStream InのAPPLYのサブコンポーネント
XStream InのAPPLYには、いくつかのサブコンポーネントがあります。
次のサブコンポーネント・タイプが可能です。
-
APPLY
READER
: リーダー・サーバーを示します。クライアント・アプリケーションからLCRを取得し、それらをトランザクションに変換し、トランザクション順序を確認して、依存性計算を実行します。 -
APPLY
COORDINATOR
: コーディネータ・プロセスを示します。リーダー・サーバーからトランザクションを取得し、依存性情報を使用してトランザクションのスケジュール方法を決定し、それらのLCRを適用サーバーに送信します。 -
APPLY
SERVER
: 適用サーバーを示します。LCRを適用ハンドラに適用します。LCRを適用できない場合は、そのLCRがエラー・キューに配置されます。
親トピック: XStreamコンポーネント
2.4.2 トポロジとストリーム・パス
Oracle Replicationのトポロジでのストリーム・パスとは、ソースから宛先へのLCRのフローです。
ストリーム・パスは、取得プロセスまたはXStream Inクライアント・アプリケーションで始まります。ストリーム・パスは、適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーがLCRを受信すると終了します。ストリーム・パスは、適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーに到達する前に、複数のソースおよび宛先コンポーネントを通過する可能性があります。したがって、単一のストリーム・パスが最後のコンポーネントに到達するまでに、複数のソース/宛先コンポーネント・ペアが生成される場合があります。
Oracle Replicationのトポロジによってストリーム・パスに関する情報が収集されるのは、ストリーム・パスが適用プロセス、アウトバウンド・サーバーまたはインバウンド・サーバーで終了する場合のみです。
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が作成された時間です。
2.4.4 UTL_RPADVパッケージ
UTL_RPADV
パッケージは、XStreamのパフォーマンスに関連する統計の収集を自動化します。
UTL_RPADV
には、分散データベース環境のXStreamコンポーネントの統計を収集および分析する一連のサブプログラムが用意されています。このパッケージは、パフォーマンス・アドバイザとCOLLECT_STATS
プロシージャを使用して、統計の収集を自動化します。
出力は、スプレッドシートに簡単にインポートして分析できるように書式設定されます。XStreamパフォーマンス統計の出力を調べるには、UTL_RPADV.SHOW_STATS
プロシージャを使用します。また、UTL_RPADV.SHOW_STATS_HTML
プロシージャを使用すると、同じ情報をHTML形式のレポートで表示できます。
UTL_RPADV
パッケージは、適用プロセスを含むOracle Replication環境に対しても、アウトバウンド・サーバーまたはインバウンド・サーバーを含むXStream環境と基本的に同様に機能します。XStreamはクライアント・アプリケーションとの間でやり取りされるデータ変更を処理するため、XStreamに対するSHOW_STATS
プロシージャの出力は、Oracle Replicationの場合とは異なります。
- UTL_RPADVパッケージを使用したXStream統計の収集
UTL_RPADV
パッケージを使用してXStream統計を収集できます。 - コマンドラインでのXStream統計の表示
UTL_RPADV
パッケージのSHOW_STATS
プロシージャは、パフォーマンス・アドバイザが収集および格納した統計を表示します。 - SHOW_STATSの出力の解釈
適用プロセスについての出力と、XStreamアウトバウンド・サーバーおよびインバウンド・サーバーについての出力には違いがあります。 - HTMLレポートでのXStream統計の表示
UTL_RPADV
パッケージのSHOW_STATS_HTML
プロシージャは、パフォーマンス・アドバイザが収集および格納した統計を含むHTMLレポートを作成します。 - SHOW_STATS_HTMLからのHTMLレポートの解釈
UTL_RPADV
パッケージのSHOW_STATS_HTML
プロシージャは、SHOW_STATS
プロシージャと同じ出力を生成できますが、その出力はHTMLとしてフォーマットされてHTMLファイルとなります。
2.4.4.1 UTL_RPADVパッケージを使用したXStream統計の収集
UTL_RPADV
パッケージを使用してXStream統計を収集できます。
UTL_RPADV
パッケージを使用してXStreamの統計を収集するには、次のステップを実行します。
統計を表示するには、SHOW_STATS
プロシージャを実行します。コマンドラインでのXStream統計の表示を参照してください。
関連項目:
UTL_RPADV
パッケージの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください。
親トピック: UTL_RPADVパッケージ
2.4.4.2 コマンドラインでのXStream統計の表示
UTL_RPADV
パッケージの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_RPADV
パッケージによって収集され、STREAMS$_ADVISOR_PATH_STAT
表に格納された統計を表示するには、次のステップを実行します。
親トピック: UTL_RPADVパッケージ
2.4.4.3 SHOW_STATS出力の解釈
適用プロセスの出力と、XStreamアウトバウンド・サーバーおよびインバウンド・サーバーの出力には相違点があります。
ノート:
この項の残りの部分では、適用プロセスでのUTL_RPADV
パッケージおよびSHOW_STATS
出力について理解していることを前提としています。
- アウトバウンド・サーバーがパスの最後のコンポーネントの場合の出力例
ここでは、アウトバウンド・サーバーがパスの最後のコンポーネントの場合の出力例を示します。 - インバウンド・サーバーがパスの最後のコンポーネントの場合の出力例
ここでは、インバウンド・サーバーがパスの最後のコンポーネントの場合の出力例を示します。
関連項目:
UTL_RPADV
パッケージの使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: UTL_RPADVパッケージ
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
が、ネットワークまたはクライアント・アプリケーションのいずれかがボトルネックであることを示しています。
これらの相違点以外は、適用プロセスで終了するパスの場合と同じ方法で統計を解釈できます。出力の統計を判断するのに凡例および略称を使用します。
親トピック: SHOW_STATS出力の解釈
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
は、ネットワークまたはクライアント・アプリケーションのいずれかがボトルネックであることを示しています。
これらの相違点以外は、適用プロセスで終わるパスについて解釈する場合とほぼ同じ方法で、統計を解釈できます。出力の統計を判断するには、凡例および略称を使用します。
親トピック: SHOW_STATS出力の解釈
2.4.4.4 HTMLレポートでのXStreamの統計の表示
UTL_RPADV
パッケージの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_RPADV
パッケージによって収集され、STREAMS$_ADVISOR_COMP_STAT
表に格納された統計を表示するには、次のステップを実行します。
親トピック: UTL_RPADVパッケージ
2.4.4.5 SHOW_STATS_HTMLからのHTMLレポートの解釈
UTL_RPADV
パッケージの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
権限が必要です。
関連項目:
親トピック: UTL_RPADVパッケージ
2.5 XStreamとSQL生成
SQL生成とは、行LCRにカプセル化された変更を実行する際に必要となるSQL文を生成する機能です。
XStreamアウトバウンド・サーバーとXStreamインバウンド・サーバーは、SQL生成を使用して、行LCR内の挿入、更新または削除操作を実行するために必要なSQL文を生成できます。
- SQL生成を実行するためのインタフェース
SQL生成用に各種のインタフェースを使用できます。 - SQL生成のフォーマット
SQL文は、インライン値またはバインド変数の2つのフォーマットのいずれかで生成できます。 - SQL生成およびデータ型
SQL生成ではほとんどのデータ型がサポートされています。 - SQL生成および文字セット
LCRメソッドを使用する場合、SQLはデータベース文字セットで生成されます。 - 生成されたSQL文の例
各例では、生成されたSQL文が示されています。 - SQL生成のデモ
SQL生成を実行するデモを使用できます。
親トピック: XStreamの一般的な概念
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
データ型のサイズによって制限されます。
関連項目:
-
行LCRの
GET_ROW_TEXT
およびGET_WHERE_CLAUSE
の各メンバー・ファンクションの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照 -
XStreamのJavaインタフェースの詳細は、Oracle Database XStream Java APIリファレンスを参照
親トピック: XStreamとSQL生成
2.5.2 SQL生成のフォーマット
SQL文は、インライン値またはバインド変数の2つのフォーマットのいずれかで生成できます。
返されたSQL文が比較的小さい場合は、インライン値を使用します。SQL文が大きい場合は、バインド変数を使用します。この場合、バインド変数は、古い列値と新しい列値の両方のポインタを含む個別のリストとしてクライアント・アプリケーションに渡されます。
各インタフェースでのバインド変数の使用の詳細は、次の資料を参照してください。
-
Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスの
GET_ROW_TEXT
およびGET_WHERE_CLAUSE
の各行LCRメンバー・プロシージャに関する資料 -
Oracle Database XStream Java APIリファレンスの
DefaultRowLCR.getBinds()
に関する資料
ノート:
インライン値で生成されたSQL文の場合は、SQLインジェクションが発生する可能性があります。SQLインジェクションとは、SQL文内のクライアント提供データを使用するアプリケーションを不正に利用する手法であり、これにより機密データを表示または操作するためにデータベースに不正にアクセスできるようになります。生成されたSQL文を実行する予定の場合は、バインド変数を使用することを強くお薦めします。
関連項目:
SQLインジェクションの詳細は、Oracle Database PL/SQL言語リファレンスを参照
親トピック: XStreamと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)からは非推奨になりました。
- SQL生成および自動データ型変換
XStreamアウトバウンド・サーバーまたはインバウンド・サーバーでは暗黙的なデータ型変換が実行され(可能な場合)、生成されたSQLはANSI規格に従います(可能な場合)。 - SQL生成とLOB、LONG、LONG RAWおよびXMLTypeの各データ型
LOB列に対するINSERT
およびUPDATE
操作では、アウトバウンド・サーバーにより、LOBアセンブリを使用してLOBチャンクが自動的にアセンブルされます。
関連項目:
データ型の詳細は、Oracle Database SQL言語リファレンスを参照
親トピック: XStreamとSQL生成
2.5.3.1 SQL生成および自動データ型変換
XStreamアウトバウンド・サーバーまたはインバウンド・サーバーは、可能な場合は暗黙的なデータ型変換を実行し、生成されるSQLでは、可能な場合はANSI SQL標準に従います。
自動データ型変換では、次の点を考慮する必要があります。
-
NULL
は"NULL"
として指定します。 -
データ型
CHAR
、VARCHAR2
、NVARCHAR2
、NCHAR
、CLOB
およびNCLOB
では、一重引用符は二重引用符に変換されます(インライン値の場合)。 -
LONG
データはCLOB
データに変換されます。 -
LONG
RAW
データはBLOB
データに変換されます。
親トピック: SQL生成およびデータ型
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操作を実行できます。
関連項目:
親トピック: SQL生成およびデータ型
2.5.4 SQL生成および文字セット
LCRメソッドを使用する場合、SQLはデータベース文字セットで生成されます。
INSERT
、UPDATE
、INTO
などのSQLキーワードは、文字セットに応じて変更されることはありません。
関連項目:
-
JDBCでのデータ変換の詳細は、Oracle Databaseグローバリゼーション・サポート・ガイドを参照
-
SQLキーワードの詳細は、Oracle Database SQL言語リファレンスを参照
親トピック: XStreamとSQL生成
2.5.5 生成されたSQL文の例
各例では、生成されたSQL文が示されています。
- hr.employees表に対して生成されたSQL文の例
各例では、hr.employees
表に対して行われた変更に対してアウトバウンド・サーバーによって生成されたSQL文が示されています。 - LOB列のある表に対して生成されたSQL文の例
各例では、LOB列のある表に対して行われた変更に対してアウトバウンド・サーバーによって生成されたSQL文が示されています。
親トピック: XStreamと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
親トピック: 生成されたSQL文の例
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
親トピック: 生成されたSQL文の例
2.5.6 SQL生成のデモ
SQL生成を実行するデモが用意されています。
このデモでは、DBMS_XSTREAM_ADM
PL/SQLパッケージを使用してXStream Out環境を構成し、OCIクライアント・アプリケーションを使用してSQL生成を実行します。
このデモでは、SQL生成を使用して、ソース・データベースから宛先データベースにDML変更をレプリケートします。具体的には、ソース・データベースと宛先データベースの両方にxsdemosg
スキーマを作成します。各データベースのxsdemosg
スキーマに、様々なタイプの表(LOB列を持つ表を含む)を作成します。ソース・データベースのxsdemosg
スキーマ内の表に対して、DML文のセットを実行します。取得プロセスやキューなどのOracle Replicationコンポーネントが、ソース・データベースで実行されているXStreamアウトバウンド・サーバーに、LCRの形で変更を送信します。アウトバウンド・サーバーは、LCRをデモ・クライアント・アプリケーションが使用できるようにします。
デモ・クライアント・アプリケーションは、実行時にOCI APIを使用してアウトバウンド・サーバーに接続し、LCRを受信します。デモ・クライアント・アプリケーションは、SQL生成を使用して、LCRにカプセル化された変更を実行します。このため、クライアント・アプリケーションは、ソース・データベースのxsdemosg
スキーマに対する変更を、宛先データベースのxsdemosg
にレプリケートします。
デモを変更して、任意のスキーマに変更をレプリケートできます。スキーマとレプリケート対象の表の両方が、ソース・データベースと宛先データベースの両方に存在している必要があります。SQL生成はDML変更に対してのみ実行可能です。したがって、このデモを使用してDDL変更をレプリケートすることはできません。
このデモは次の場所に用意されています。
$ORACLE_HOME/rdbms/demo/xstream/sqlgen
ノート:
SQL生成のデモは、XStream Java APIでは使用できません。
親トピック: XStreamとSQL生成