6 ルールベースの変換
ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUE
に評価される場合に発生するメッセージへの変更です。ルールベースの変換には、宣言とカスタムという2つのタイプがあります。
次の各項では、ルールベースの変換について説明します。
6.1 宣言ルールベースの変換
宣言ルールベース変換は、行LCRに対する共通の変換シナリオ・セットを扱います。
DBMS_STREAMS_ADM
パッケージに含まれる次のいずれかのプロシージャを使用して変換を指定(宣言)します。
-
ADD_COLUMN
: 行LCRに列を追加する宣言変換を追加または削除します。 -
DELETE_COLUMN
: 行LCRから列を削除する宣言変換を追加または削除します。 -
KEEP_COLUMNS
: 行LCRの列のリストを保持する宣言変換を追加または削除します。リストに含まれていない列は、変換によって行LCRから削除されません。 -
RENAME_COLUMN
: 行LCRの列名を変更する宣言変換を追加または削除します。 -
RENAME_SCHEMA
: 行LCRのスキーマ名を変更する宣言変換を追加または削除します。 -
RENAME_TABLE
: 行LCRの表名を変更する宣言変換を追加または削除します。
宣言ルールベース変換を指定する場合、宣言ルールベース変換に関連付けられたルールを指定します。指定したルールが行LCRに関してTRUE
と評価されると、Oracle Streamsによって、行LCRに対する宣言変換が内部的に実行されます。このとき、PL/SQLは起動されません。
宣言ルールベースの変換には次のメリットがあります。
-
変換が内部的に実行され、PL/SQLを使用しないため、パフォーマンスが改善されます。
-
カスタムPL/SQLファンクションが不要なため複雑になりません。
注意:
宣言ルールベースの変換で変換できるのは行LCRのみです。この行LCRは、取得LCRまたは永続LCRです。このため、いずれかのプロシージャを実行して宣言変換を追加するときはDMLルールを指定する必要があります。DDLルールを指定すると、エラーが発生します。
関連項目:
-
「行LCR」
-
データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
6.2 カスタム・ルールベースの変換
カスタム・ルールベースの変換では、変換を実行するユーザー定義PL/SQLファンクションが必要です。このファンクションは、入力としてメッセージを含むANYDATA
オブジェクトを取り、変換済メッセージを含むANYDATA
オブジェクト、または0(ゼロ)個以上のANYDATA
メッセージをカプセル化した配列のいずれかを戻します。メッセージを1つ戻すカスタム・ルールベースの変換ファンクションは、1対1の変換ファンクションです。配列で2つ以上のメッセージを戻すことができるカスタム・ルールベースの変換ファンクションは、1対多の変換ファンクションです。1対1の変換ファンクションはすべてのタイプのOracle Streamsクライアントでサポートされますが、1対多の変換ファンクションがサポートされるのはOracle Streamsの取得プロセスと同期取得のみです。
カスタム・ルールベースの変換を指定するには、DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION
プロシージャを使用します。カスタム・ルールベースの変換を使用して、取得LCR、永続LCRおよび永続ユーザー・メッセージを変更できます。
たとえば、カスタム・ルールベースの変換は、表の特定の列のデータ型が2つのデータベースで異なる場合に使用できます。ある列がソース・データベースではNUMBER
列、宛先データベースではVARCHAR2
列という場合があります。この場合、変換は、列がNUMBER
データ型の行LCRを含むANYDATA
オブジェクトを入力として取り、同じ列がVARCHAR2
データ型の行LCRを含むANYDATA
オブジェクトを返します。
メッセージに対するカスタム変換のその他の例を次に示します。
-
列を複数列に分割する場合
-
複数列から1列に結合する場合
-
列の内容を変更する場合
-
ユーザー・メッセージのペイロードを変更する場合
カスタム・ルールベースの変換には次のメリットがあります。
-
PL/SQLを使用してカスタム変換を実行できるため柔軟性が増します。
-
行LCRのみでなくDDL LCRやユーザー・メッセージなど様々なメッセージを変換できます。
カスタム・ルールベースの変換では次の点に注意してください。
-
DDL LCRに対してカスタム・ルールベースの変換を実行するときは、他の変更と一致するようにDDL LCRのDDLテキストの変更が必要になる場合があります。たとえば、DDL LCRの表の名前をルールベースの変換で変更する場合は、DDLテキストの表名も変換によって同じように変更することが必要です。
-
可能であれば、ルールが
TRUE
と評価される比較的少数のLCRを変換する場合は、グローバル・ルールまたはスキーマ・ルールにカスタム・ルールベースの変換を指定しないでください。たとえば、1つの表を処理するカスタム・ルールベースの変換をスキーマ・ルールに指定したとき、このスキーマに数百の表が含まれることがあります。このようなルールベースの変換を指定すると、変換されないLCRに関して余分な処理が必要になるためパフォーマンスに影響します。このようなカスタム・ルールベース変換の指定を回避するには、プロシージャDMLハンドラを使用して変換を実行するか、グローバル・ルールやスキーマ・ルールではなく表ルールに変換を指定してください。ただし、グローバル・ルールまたはスキーマ・ルールを表ルールで置き換えると、ルールの合計数が増え、表の追加時のメンテナンス操作が増加します。
-
1対1変換ファンクションを使用するカスタム・ルールベースの変換では、取得LCRまたは永続LCRを受け取ると、新しいLCRを作成して返すことができます。同様に、1対多変換ファンクションを使用するカスタム・ルールベースの変換では、取得LCRまたは永続LCRを受け取ると、複数の新しいLCRを作成して配列として返すことができます。
カスタム・ルールベースの変換で作成されて返されるすべてのLCRでは、
source_database_name
、transaction_id
およびscn
パラメータ値が元のLCRの値と一致する必要があります。これらのパラメータでは、他の値でLCRを作成しようとした場合でも、元のLCRの値が自動的に指定されます。 -
ユーザー・メッセージを受け取るカスタム・ルールベースの変換では、新しいメッセージを作成して返すことができます。この場合、返されるメッセージは、カスタム・ルールベースの変換で作成されるLCRです。
-
カスタム・ルールベースの変換では、LCRをLCR以外のメッセージに変換することはできません。この制限は、取得LCRおよび永続LCRに適用されます。
-
カスタム・ルールベースの変換では、行LCRをDDL LCRに、またはDDL LCRを行LCRに変換することはできません。この制限は、取得LCRおよび永続LCRに適用されます。
関連項目:
-
SET_RULE_TRANSFORM_FUNCTION
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照
6.2.1 カスタム・ルールベースの変換およびアクション・コンテキスト
DBMS_STREAMS_ADM
パッケージのSET_RULE_TRANSFORM_FUNCTION
プロシージャを使用して、ルールのカスタム・ルールベースの変換を指定します。このプロシージャは、ルールのアクション・コンテキストを変更して、変換を指定します。ルール・アクション・コンテキストはルールに関連付けられたオプションの情報であり、メッセージのルールがTRUE
と評価された後でルール・エンジンのクライアントによって解析されます。ルール・エンジンのクライアントには、ユーザーが作成するアプリケーションや、Oracle StreamsなどのOracleの内部機能があります。アクション・コンテキストの情報は、名前/値ペアのリストで構成されるSYS.RE$NV_LIST
型のオブジェクトです。
Oracle Streamsのカスタム・ルールベースの変換は、常にアクション・コンテキスト内の次の名前/値ペアで構成されます。
-
ファンクションが1対1変換ファンクションである場合、名前は
STREAMS$_TRANSFORM_FUNCTION
になります。ファンクションが1対多変換ファンクションである場合、名前はSTREAMS$_ARRAY_TRANS_FUNCTION
になります。 -
値は、
VARCHAR2
と指定されたPL/SQLファンクション名を含むANYDATA
インスタンスです。このファンクションによって変換が実行されます。
データベース内の既存のカスタム・ルールベースの変換は、DBA_STREAMS_TRANSFORM_FUNCTION
データ・ディクショナリ・ビューを問い合せることで表示できます。
Oracle Streams環境で、ポジティブ・ルール・セットのルールで、メッセージがTRUE
と評価され、名前がSTREAMS$_TRANSFORM_FUNCTION
またはSTREAMS$_ARRAY_TRANS_FUNCTION
である名前/値のペアを含むアクション・コンテキストが返されると、メッセージを入力パラメータとして使用してPL/SQLファンクションが実行されます。アクション・コンテキスト内の、STREAMS$_
で始まるその他の名前は、Oracleによって内部的に使用されるため、直接追加、変更または削除することはできません。Oracle Streamsは、STREAMS$_
またはAPPLY$_
で始まらない名前/値ペアをすべて無視します。
Oracle Streams環境で、ルールによってメッセージがFALSE
と評価されると、このルールはクライアントに返されず、アクション・コンテキストの名前/値ペアに表示されるPL/SQLファンクションは実行されません。様々なルールに同じ変換または異なる変換を使用できます。たとえば、メッセージの取得、伝播、適用またはデキュー対象となる様々な操作タイプ、表またはスキーマに、異なる変換を関連付けることができます。
6.2.2 カスタム・ルールベースの変換に必須の権限
変換ファンクションをコールするユーザーは、ファンクションのEXECUTE
権限が必要です。次のリストに、変換ファンクションをコールするユーザーのタイプを示します。
6.3 ルールベースの変換およびOracle Streamsクライアント
次の各項では、ルールベースの変換とOracle Streamsクライアントについて説明します。
この項の情報は、宣言ルールベースの変換とカスタム・ルールベースの変換の両方に該当します。
6.3.1 ルールベースの変換と取得プロセス
取得プロセスによって取得中に変換を実行する場合は、REDOログの特定の変更に対して、取得プロセスのポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUE
と評価される必要があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、取得LCRが内部的に変換されます。カスタム・ルールベースの変換の場合は、取得LCRに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、STREAMS$_TRANSFORM_FUNCTION
またはSTREAMS$_ARRAY_TRANS_FUNCTION
という名前の名前/値ペアを含むアクション・コンテキストが取得プロセスに返されます。
取得プロセスは、次の手順でルールベースの変換を実行します。
-
REDOログ内の変更をLCRにフォーマットします。
-
LCRを
ANYDATA
オブジェクトに変換します。 -
LCRを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいて
ANYDATA
オブジェクトが内部的に変換されます。カスタム・ルールベースの変換の場合は、取得プロセスの取得ユーザーが名前/値ペアのPL/SQLファンクションを実行してANYDATA
オブジェクトを変換します。 -
変換された1つ以上の
ANYDATA
オブジェクトを、取得プロセスに関連付けられたキューにエンキューします。または、要素が0個の配列が変換ファンクションで返される場合はLCRを廃棄します。
すべてのアクションが、取得プロセスの取得ユーザーによって実行されます。図6-1は、取得プロセスによる取得中の変換を示しています。
たとえば、LCRが取得プロセスによって取得中に変換される場合、変換済LCRは、取得プロセスで使用されるキューにエンキューされます。このため、このような取得LCRがdbs1.example.com
データベースからdbs2.example.com
データベースとdbs3.example.com
データベースに伝播される場合は、伝播の後でdbs2.example.com
とdbs3.example.com
のキューに変換済LCRが含まれます。
取得プロセスによって取得中に変換を実行すると次のメリットがあります。
-
プライベート情報はソース・キューに入れられず宛先キューにも伝播されないため、変換によってプライベート情報を削除または変更することができ、セキュリティを向上できます。
-
実行する変換のタイプによっては、領域消費を削減できます。たとえば、変換でデータ容量を削減すると、エンキュー、伝播および適用するデータが減少します。
-
変換済LCRに複数の宛先がある場合、変換は複数の宛先ではなくソース側で1回しか実行されないため、変換によるオーバーヘッドが減少します。
-
取得プロセスの変換では、1つのメッセージを複数のメッセージに変換することができます。
取得プロセスによって取得中に変換を実行する場合に考えられるデメリットは、次のとおりです。
-
取得プロセスがローカル取得プロセスである場合、変換によるオーバーヘッドがソース・データベースで発生します。ただし、取得プロセスがダウンストリーム取得プロセスである場合、このオーバーヘッドはソース・データベースではなくダウンストリーム・データベースで発生します。
-
すべてのサイトで変換済LCRが受信されます。
注意:
取得プロセスでルールベースの変換を使用して、Oracle Streamsでサポートされないデータ型の列を変更または削除することはできません。
関連項目:
6.3.1.1 取得プロセスによる取得中のルールベース変換のエラー
取得プロセスの動作は、実行される変換の種類と発生したエラーの種類によって次のいずれかになります。取得プロセスの動作は、実行中の変換のタイプと、発生したエラーのタイプによって異なります。取得プロセスには次のいずれかの動作が考えられます。
-
変換が宣言ルールベースの変換で、取得プロセスがエラーを無視できる場合、取得プロセスは変換を実行して変更を取得します。たとえば、取得プロセスが
DELETE_COLUMN
宣言ルールベースの変換を実行しようとしたときに、削除対象として指定された列が行LCRに存在しない場合、取得プロセスは変更を取得して実行を続けます。 -
変換が宣言ルールベースの変換で、取得プロセスがエラーを無視できない場合、変更は取得されず、取得プロセスが無効になります。たとえば、取得プロセスが
ADD_COLUMN
宣言ルールベースの変換を実行しようとしたときに、追加対象として指定された列がすでに行LCRに存在していた場合、変更は取得されず、取得プロセスが無効になります。 -
カスタム・ルールベースの変換でエラーが発生した場合は、常に、変更は取得されず、取得プロセスが無効になります。
取得プロセスが無効になった場合は、エラーが発生しないようにルールベースの変換を変更または削除してから、取得プロセスを有効にしてください。
6.3.2 ルールベースの変換と同期取得
同期取得によって取得中に変換を実行する場合は、同期取得のポジティブ・ルール・セットのルールベースの変換に対応するルールが、表に対する特定のDML変更について、TRUE
と評価される必要があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、永続LCRが内部的に変換されます。カスタム・ルールベースの変換の場合は、永続LCRに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、STREAMS$_TRANSFORM_FUNCTION
という名前の名前/値ペアを含むアクション・コンテキストが取得プロセスに返されます。
同期取得は、次の手順でルールベースの変換を実行します。
-
REDOログ内の変更を行LCRにフォーマットします。
-
行LCRを
ANYDATA
オブジェクトに変換します。 -
LCRを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいて
ANYDATA
オブジェクトが内部的に変換されます。カスタム・ルールベースの変換の場合は、同期取得の取得ユーザーが名前/値ペアのPL/SQLファンクションを実行してANYDATA
オブジェクトを変換します。 -
変換された
ANYDATA
オブジェクトを、同期取得に関連付けられたキューにエンキューします。
すべてのアクションが、同期取得の取得ユーザーによって実行されます。図6-2は、取得中の変換を示しています。
たとえば、行LCRが同期取得によって取得中に変換される場合、変換済行LCRは、同期取得で使用されるキューにエンキューされます。このため、このような取得LCRがdbs1.example.com
データベースからdbs2.example.com
データベースとdbs3.example.com
データベースに伝播される場合は、伝播の後でdbs2.example.com
とdbs3.example.com
のキューに変換済行LCRが含まれます。
同期取得によって取得中に変換を実行すると次のメリットがあります。
-
プライベート情報はソース・キューに入れられず宛先キューにも伝播されないため、変換によってプライベート情報を削除または変更することができ、セキュリティを向上できます。
-
実行する変換のタイプによっては、領域消費を削減できます。たとえば、変換でデータ容量を削減すると、エンキュー、伝播および適用するデータが減少します。
-
変換済行LCRに複数の宛先がある場合、変換は複数の宛先ではなくソース側で1回しか実行されないため、変換によるオーバーヘッドが減少します。
同期取得によって取得中に変換を実行する場合に考えられるデメリットは、次のとおりです。
-
ソース・データベースで、変換オーバーヘッドが発生します。
-
すべてのサイトで変換済LCRが受信されます。
注意:
同期取得でルールベースの変換を使用して、Oracle Streamsでサポートされないデータ型の列を変更または削除することはできません。
関連項目:
6.3.2.1 同期取得による取得中のルールベースの変換のエラー
同期取得によって取得中に変換が実行されるときにエラーが発生すると、エラーは同期取得に返されます。同期取得の動作は、実行中の変換のタイプと、発生したエラーのタイプによって異なります。同時取得には次のいずれかの動作が考えられます。
-
変換が宣言ルールベースの変換で、同期取得がエラーを無視できる場合、同期取得は変換を実行して変更を取得します。たとえば、同期取得が
DELETE_COLUMN
宣言ルールベースの変換を実行しようとしたときに、削除対象として指定された列が行LCRに存在しない場合、同期取得は変更を取得して実行を続けます。 -
変換が宣言ルールベースの変換で、同期取得がエラーを無視できない場合、変更は取得されず、DML操作は中断されます。たとえば、同期取得が
ADD_COLUMN
宣言ルールベースの変換を実行しようとしたときに、追加対象として指定された列がすでに行LCRに存在していた場合、変更は取得されず、DMLは中断します。 -
カスタム・ルールベースの変換でエラーが発生した場合は常に、変更は取得されず、DMLは中断します。
DMLがルールベースの変換によって中断した場合は、そのルールベースの変換を変更するか、または削除してDML操作を実行する必要があります。
6.3.3 ルールベースの変換と伝播
伝播中に変換を実行する場合は、伝播のソース・キューのメッセージに対して、伝播のポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUE
と評価される必要があります。このメッセージは、取得LCR、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージの場合があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、STREAMS$_TRANSFORM_FUNCTION
という名前の名前/値ペアを含むアクション・コンテキストが伝播に返されます。
伝播は、次の手順でルールベースの変換を実行します。
-
ソース・キューからメッセージのデキューを開始します。
-
メッセージを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてメッセージが内部的に変換されます。カスタム・ルールベースの変換の場合は、ソース・キューの所有者が名前/値ペアのPL/SQLファンクションを実行してメッセージを変換します。
-
変換済メッセージのデキューを終了します。
-
変換済メッセージを宛先キューに伝播します。
図6-3は、伝播中の変換を示しています。
たとえば、メッセージのdbs1.example.com
データベースからdbs2.example.com
データベースへの伝播でルールベースの変換を使用するが、dbs1.example.com
データベースからdbs3.example.com
データベースへのメッセージの伝播ではルールベースの変換を使用しないとします。
この場合、dbs1.example.com
のキューのメッセージは、dbs2.example.com
に伝播する前に変換できますが、同じメッセージをdbs3.example.com
に伝播するときには元のままにしておくことができます。この場合、伝播の後には、dbs2.example.com
のキューには変換済メッセージが含まれ、dbs3.example.com
のキューには元のメッセージが含まれます。
伝播中に変換を実行するメリットは、次のとおりです。
-
メッセージを伝播する前に変換でプライベート情報を削除または変更すると、セキュリティを向上できます。
-
一部の宛先キューで変換済メッセージを受信し、その他の宛先キューで元のメッセージを受信できます。
-
様々な宛先が様々な形で同じ変換済メッセージを受信できます。
伝播中に変換を実行する場合に考えられるデメリットは、次のとおりです。
-
メッセージが変換されると、最初の伝播後に伝播先となるデータベースは変換済メッセージを受信します。たとえば、メッセージが
dbs2.example.com
からdbs4.example.com
に伝播される場合、dbs4.example.com
は変換済メッセージを受信します。 -
有向ネットワークで最初の伝播によって変換が実行され、ローカルの取得プロセスがメッセージを取得した場合、変換によるオーバーヘッドはソース・データベースで発生します。ただし、取得プロセスがダウンストリーム取得プロセスである場合、このオーバーヘッドはソース・データベースではなくダウンストリーム・データベースで発生します。
-
有向ネットワークで最初の伝播によって変換が実行され、同期取得がメッセージを取得した場合、変換によるオーバーヘッドはソース・データベースで発生します。
-
様々な伝播によって1つのメッセージが複数の宛先データベースに送信される場合は、そのメッセージに対して同じ変換が2回以上実行されることがあります。
6.3.4 ルールベースの変換と適用プロセス
適用中に変換を実行する場合は、適用プロセスのキューのメッセージに対して、適用プロセスのポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUE
と評価される必要があります。このメッセージは、取得LCR、永続LCRまたは永続ユーザー・メッセージの場合があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、STREAMS$_TRANSFORM_FUNCTION
という名前の名前/値ペアを含むアクション・コンテキストが適用プロセスに返されます。
適用プロセスは、次の手順でルールベースの変換を実行します。
-
キューからメッセージのデキューを開始します。
-
メッセージを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてメッセージが内部的に変換されます。カスタム・ルールベースの変換の場合は、適用ユーザーが名前/値ペアのPL/SQLファンクションを実行してメッセージを変換します。
-
変換済メッセージのデキューを終了します。
-
変換済メッセージを適用します。このとき、宛先データベースでのデータベース・オブジェクトの変更や、適用ハンドラへの変換済メッセージの送信が行われることがあります。
すべてのアクションは適用ユーザーが実行します。
図6-4は、適用中の変換を示しています。
たとえば、メッセージがdbs1.example.com
データベースからdbs2.example.com
データベースに元の形で伝播されるとします。適用プロセスがdbs2.example.com
でメッセージをデキューするときに、メッセージが変換されます。
適用中に変換を実行するメリットは、次のとおりです。
-
最初の伝播後にメッセージの伝播先となるデータベースは、メッセージを元の形で受信できます。たとえば、メッセージが
dbs2.example.com
からdbs4.example.com
に伝播される場合、dbs4.example.com
は元のメッセージを受信できます。 -
ソース・データベースと宛先データベースが異なる場合、ソース・データベースでは変換によるオーバーヘッドは発生しません。
適用中に変換を実行する場合に考えられるデメリットは、次のとおりです。
-
メッセージの伝播先となるデータベースすべてに元のメッセージが伝播されるため、メッセージにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。
-
複数の宛先データベースが同じ変換を必要とする場合は、同じ変換が2回以上実行される可能性があります。
注意:
適用プロセスの1つ以上のルールを変更するときは、その前に適用プロセスを停止する必要があります。
6.3.4.1 適用プロセスによるデキュー中のルールベースの変換のエラー
適用プロセスによるデキュー中に変換ファンクションの実行エラーが発生すると、エラーの原因となったメッセージはデキューされず、そのメッセージを含むトランザクションは適用されません。また、適用プロセスにエラーが返され、適用プロセスは無効化されます。適用プロセスを有効化する前に、ルールベースの変換を変更または削除してエラーを回避する必要があります。
6.3.5 ルールベースの変換とメッセージ・クライアント
メッセージ・クライアントによるデキュー中に変換を実行する場合は、メッセージ・クライアントのポジティブ・ルール・セット内のルールベースの変換に対応するルールが、メッセージ・クライアントのキュー内のメッセージに対して、TRUE
と評価される必要があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUE
と評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セット内のルールがTRUE
と評価されると、STREAMS$_TRANSFORM_FUNCTION
という名前の名前/値ペアを含むアクション・コンテキストがメッセージ・クライアントに返されます。
メッセージ・クライアントは、次の手順でルールベースの変換を実行します。
-
キューからメッセージのデキューを開始します。
-
メッセージを変換します。変換が宣言ルールベースの変換である場合、メッセージは永続LCRである必要があります。行LCRは、宣言変換の指定に基づいて内部的に変換されます。変換がカスタム・ルールベースの変換である場合、メッセージは、永続LCRまたは永続ユーザー・メッセージのいずれかになります。メッセージ・クライアントを起動するユーザーは、名前/値ペアのPL/SQLファンクションを実行して、デキュー中にメッセージを変換します。
-
変換済メッセージのデキューを終了します。
すべてのアクションは、メッセージ・クライアントを起動するユーザーによって実行されます。
図6-5は、メッセージ・クライアント・デキュー中の変換を示しています。
たとえば、メッセージがdbs1.example.com
データベースからdbs2.example.com
データベースに元の形で伝播されるとします。メッセージ・クライアントがdbs2.example.com
でメッセージをデキューするときに、メッセージが変換されます。
デキュー時にメッセージ環境で変換を実行するメリットの1つは、最初の伝播の後にメッセージが伝播されるすべてのデータベースが、メッセージを元の形式で受け取ることです。たとえば、メッセージがdbs2.example.com
からdbs4.example.com
に伝播される場合、dbs4.example.com
は元のメッセージを受信できます。
デキュー中にメッセージ環境で変換を実行する場合に考えられるデメリットは、次のとおりです。
-
メッセージの伝播先となるデータベースすべてに元のメッセージが伝播されるため、メッセージにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。
-
複数の宛先データベースが同じ変換を必要とする場合は、同じ変換が2回以上実行される可能性があります。
6.4 変換の順序
宣言ルールベースの変換とカスタム・ルールベースの変換に加えて、行の移行も、サブセット・ルールがTRUE
と評価された場合に発生する内部変換です。3種類の変換すべてが単一のルールに指定されている場合、ルールがTRUE
と評価されると、変換は次の順序で実行されます。
-
行の移行
-
宣言ルールベースの変換
-
カスタム・ルールベースの変換
6.4.1 宣言ルールベースの変換の順序
単一のルールに複数の宣言ルールベースの変換が指定されている場合、一定の順序で変換を実行する必要があります。宣言ルールベースの変換にデフォルトの順序を使用するか、または順序を指定できます。
この項では、次の項目について説明します。
6.4.1.1 宣言ルールベースの変換のデフォルトの順序
ルールが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が返されます。
6.4.1.2 宣言ルールベースの変換のユーザー指定の順序
特定のルールに対して、宣言ルールベースの変換のデフォルトの順序を使用しない場合、ルールに指定された各宣言変換に手順番号を指定できます。特定のルールに対する1つ以上の宣言ルールベースの変換に手順番号を指定した場合、宣言ルールベースの変換は、次のように実行されます。
-
宣言変換は、手順番号の昇順で実行されます。
-
宣言変換デフォルトの手順番号は
0
(ゼロ)です。宣言変換に手順番号が明示的に指定されていない場合、このデフォルトが使用されます。 -
複数の宣言変換に同じ手順番号が指定された場合、これらの宣言変換は、「宣言ルールベースの変換のデフォルトの順序」で説明されているデフォルトの順序付けに従います。
たとえば、特定のルールに関連付けられた変換に次の手順番号を指定すると、宣言変換のデフォルトの順序付けを逆にすることができます。
-
列の保持: 手順番号6
-
列の削除: 手順番号5
-
列名の変更: 手順番号4
-
列の追加: 手順番号3
-
表名の変更: 手順番号2
-
スキーマ名の変更: 手順番号1
このように順序を指定すると、スキーマ名の変更の変換が最初に実行され、列の削除の変換は最後に実行されます。
6.5 ルールベースの変換に関する考慮事項
宣言ルールベースの変換とカスタム・ルールベースの変換では次の点に注意してください。
-
ルールベースの変換をOracle Streamsクライアントで実行するには、ルールをOracle Streamsクライアントのポジティブ・ルール・セットに含める必要があります。ルールがOracle Streamsクライアントのネガティブ・ルール・セットにある場合、Oracle Streamsクライアントではルールベースの変換が無視されます。
-
ルールベースの変換は、
DBMS_TRANSFORM
パッケージを使用して実行される変換とは異なります。このヘルプでは、DBMS_TRANSFORM
パッケージで実行される変換については説明しません。 -
ご使用の環境で大半の行LCRを変換する場合、または実行が必要な行LCRの変換にコストがかかる場合、DMLハンドラ内で変更を行うことを検討してください。DMLハンドラは、適用の並列性が1より大きい場合にはパラレルで実行できるためです。
注意:
DBMS_TRANSFORM
パッケージの詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照