| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
ルールベースの変換は、ポジティブ・ルール・セットのルールがTRUEに評価される場合に発生するメッセージへの変更です。ルールベースの変換には、宣言とカスタムという2つのタイプがあります。
次の各項では、ルールベースの変換について説明します。
宣言ルールベースの変換は、行LCRの共通的な変換シナリオ・セットに対応します。
DBMS_STREAMS_ADMパッケージに含まれる次のいずれかのプロシージャを使用して変換を指定（宣言）します。
ADD_COLUMN: 行LCRに列を追加する宣言変換を追加または削除します。
DELETE_COLUMN: 行LCRから列を削除する宣言変換を追加または削除します。
RENAME_COLUMN: 行LCRの列名を変更する宣言変換を追加または削除します。
RENAME_SCHEMA: 行LCRのスキーマ名を変更する宣言変換を追加または削除します。
RENAME_TABLE: 行LCRの表名を変更する宣言変換を追加または削除します。
宣言ルールベースの変換を指定する場合は、その宣言ルールベースの変換に関連付けられたルールを指定します。指定したルールが行LCRについてTRUEと評価されると、Oracle Streamsによって、行LCRに対する宣言的変換が内部的に実行されます。このとき、PL/SQLは起動されません。
宣言ルールベースの変換には次のメリットがあります。
変換が内部的に実行され、PL/SQLを使用しないため、パフォーマンスが改善されます。
カスタムPL/SQLファンクションが不要なため複雑になりません。
|
注意:
|
カスタム・ルールベースの変換では、変換を実行するユーザー定義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を作成しようとしても、Oracleによってこれらのパラメータには元のLCRの値が自動的に指定されます。
ユーザー・メッセージを受け取るカスタム・ルールベースの変換では、新しいメッセージを作成して返すことができます。この場合、返されるメッセージは、カスタム・ルールベースの変換で作成されるLCRです。
カスタム・ルールベースの変換では、LCRをLCR以外のメッセージに変換することはできません。この制限は、取得LCRおよび永続LCRに適用されます。
カスタム・ルールベースの変換では、行LCRをDDL LCRに、またはDDL LCRを行LCRに変換することはできません。この制限は、取得LCRおよび永続LCRに適用されます。
|
関連項目:
|
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ファンクションは実行されません。様々なルールに同じ変換または異なる変換を使用できます。たとえば、メッセージの取得、伝播、適用またはデキュー対象となる様々な操作タイプ、表またはスキーマに、異なる変換を関連付けることができます。
変換ファンクションをコールするユーザーは、ファンクションのEXECUTE権限が必要です。変換ファンクションをコールするユーザーを次に示します。
次の各項では、ルールベースの変換とOracle Streamsクライアントについて説明します。
この項の情報は、宣言ルールベースの変換とカスタム・ルールベースの変換の両方に該当します。
取得プロセスによって取得中に変換を実行する場合は、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を廃棄します。
すべてのアクションが、取得プロセスの取得ユーザーによって実行されます。図7-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でサポートされないデータ型の列を変更または削除することはできません。 |
取得プロセスによって取得中に変換が実行されるときにエラーが発生すると、エラーは取得プロセスに返されます。取得プロセスの動作は、実行される変換の種類と発生したエラーの種類によって次のいずれかになります。
変換が宣言ルールベースの変換で、取得プロセスがエラーを無視できる場合、取得プロセスは変換を実行して変更を取得します。たとえば、取得プロセスがDELETE_COLUMN宣言ルールベースの変換を実行しようとしたときに、削除対象として指定された列が行LCRに存在しない場合、取得プロセスは変更を取得して実行を続けます。
変換が宣言ルールベースの変換で、取得プロセスがエラーを無視できない場合、変更は取得されず、取得プロセスが無効になります。たとえば、取得プロセスがADD_COLUMN宣言ルールベースの変換を実行しようとしたときに、追加対象として指定された列がすでに行LCRに存在していた場合、変更は取得されず、取得プロセスが無効になります。
カスタム・ルールベースの変換でエラーが発生した場合は、常に、変更は取得されず、取得プロセスが無効になります。
取得プロセスが無効になった場合は、エラーが発生しないようにルールベースの変換を変更または削除してから、取得プロセスを有効にしてください。
同期取得によって取得中に変換を実行する場合は、同期取得のポジティブ・ルール・セットのルールベースの変換に対応するルールが、表に対する特定のDML変更について、TRUEと評価される必要があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、永続LCRが内部的に変換されます。カスタム・ルールベースの変換の場合は、永続LCRに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが取得プロセスに返されます。
同期取得は、次の手順でルールベースの変換を実行します。
REDOログ内の変更を行LCRにフォーマットします。
行LCRをANYDATAオブジェクトに変換します。
LCRを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてANYDATAオブジェクトが内部的に変換されます。カスタム・ルールベースの変換の場合は、同期取得の取得ユーザーが名前/値ペアのPL/SQLファンクションを実行してANYDATAオブジェクトを変換します。
変換されたANYDATAオブジェクトを、同期取得に関連付けられたキューにエンキューします。
すべてのアクションが、同期取得の取得ユーザーによって実行されます。図7-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でサポートされないデータ型の列を変更または削除することはできません。 |
同期取得によって取得中に変換が実行されるときにエラーが発生すると、エラーは同期取得に返されます。同期取得の動作は、実行される変換の種類と発生したエラーの種類によって次のいずれかになります。
変換が宣言ルールベースの変換で、同期取得がエラーを無視できる場合、同期取得は変換を実行して変更を取得します。たとえば、同期取得がDELETE_COLUMN宣言ルールベースの変換を実行しようとしたときに、削除対象として指定された列が行LCRに存在しない場合、同期取得は変更を取得して実行を続けます。
変換が宣言ルールベースの変換で、同期取得がエラーを無視できない場合、変更は取得されず、DML操作は中断されます。たとえば、同期取得がADD_COLUMN宣言ルールベースの変換を実行しようとしたときに、追加対象として指定された列がすでに行LCRに存在していた場合、変更は取得されず、DMLは中断します。
カスタム・ルールベースの変換でエラーが発生した場合は常に、変更は取得されず、DMLは中断します。
DMLがルールベースの変換によって中断した場合は、そのルールベースの変換を変更するか、または削除してDML操作を実行する必要があります。
伝播中に変換を実行する場合は、伝播のソース・キューのメッセージに対して、伝播のポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUEと評価される必要があります。このメッセージは、取得LCR、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージの場合があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが伝播に返されます。
伝播は、次の手順でルールベースの変換を実行します。
ソース・キューからメッセージのデキューを開始します。
メッセージを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてメッセージが内部的に変換されます。カスタム・ルールベースの変換の場合は、ソース・キューの所有者が名前/値ペアのPL/SQLファンクションを実行してメッセージを変換します。
変換済メッセージのデキューを終了します。
変換済メッセージを宛先キューに伝播します。
図7-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回以上実行されることがあります。
適用中に変換を実行する場合は、適用プロセスのキューのメッセージに対して、適用プロセスのポジティブ・ルール・セット内のルールベースの変換に対応するルールがTRUEと評価される必要があります。このメッセージは、取得LCR、永続LCRまたは永続ユーザー・メッセージの場合があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セットのルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストが適用プロセスに返されます。
適用プロセスは、次の手順でルールベースの変換を実行します。
キューからメッセージのデキューを開始します。
メッセージを変換します。宣言ルールベースの変換の場合は、宣言変換の指定に基づいてメッセージが内部的に変換されます。カスタム・ルールベースの変換の場合は、適用ユーザーが名前/値ペアのPL/SQLファンクションを実行してメッセージを変換します。
変換済メッセージのデキューを終了します。
変換済メッセージを適用します。このとき、宛先データベースでのデータベース・オブジェクトの変更や、適用ハンドラへの変換済メッセージの送信が行われることがあります。
すべてのアクションは適用ユーザーが実行します。
図7-4は、適用中の変換を示しています。
たとえば、メッセージがdbs1.example.comデータベースからdbs2.example.comデータベースに元の形で伝播されるとします。適用プロセスがdbs2.example.comでメッセージをデキューするときに、メッセージが変換されます。
適用中に変換を実行するメリットは、次のとおりです。
最初の伝播後にメッセージの伝播先となるデータベースは、メッセージを元の形で受信できます。たとえば、メッセージがdbs2.example.comからdbs4.example.comに伝播される場合、dbs4.example.comは元のメッセージを受信できます。
ソース・データベースと宛先データベースが異なる場合、ソース・データベースでは変換によるオーバーヘッドは発生しません。
適用中に変換を実行する場合に考えられるデメリットは、次のとおりです。
メッセージの伝播先となるデータベースすべてに元のメッセージが伝播されるため、メッセージにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。
複数の宛先データベースが同じ変換を必要とする場合は、同じ変換が2回以上実行される可能性があります。
|
注意: 適用プロセスの1つ以上のルールを変更するときは、その前に適用プロセスを停止する必要があります。 |
適用プロセスによるデキュー中に変換ファンクションの実行エラーが発生すると、エラーの原因となったメッセージはデキューされず、そのメッセージを含むトランザクションは適用されません。また、適用プロセスにエラーが返され、適用プロセスは無効化されます。適用プロセスを有効化する前に、ルールベースの変換を変更または削除してエラーを回避する必要があります。
トランザクションで適用エラーが発生し、そのトランザクションの一部のメッセージがルールベースの変換によって変換済の場合、変換済メッセージもトランザクションの他のすべてのメッセージとともにエラー・キューに移動されます。DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを使用して、エラー・キュー内の変換済メッセージを含むトランザクションを再実行しても、メッセージの変換は再実行されません。対応するルールを含む適用プロセスのルール・セットが再評価されないためです。
メッセージ・クライアントによるデキュー中に変換を実行する場合は、メッセージ・クライアントのポジティブ・ルール・セット内のルールベースの変換に対応するルールが、メッセージ・クライアントのキュー内のメッセージに対して、TRUEと評価される必要があります。
宣言ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セット内のルールがTRUEと評価されると、メッセージは内部的に変換されます。カスタム・ルールベースの変換の場合は、メッセージに対してポジティブ・ルール・セット内のルールがTRUEと評価されると、STREAMS$_TRANSFORM_FUNCTIONという名前の名前/値ペアを含むアクション・コンテキストがメッセージ・クライアントに返されます。
メッセージ・クライアントは、次の手順でルールベースの変換を実行します。
キューからメッセージのデキューを開始します。
メッセージを変換します。変換が宣言ルールベースの変換である場合、メッセージは永続LCRである必要があります。行LCRは、宣言変換の指定に基づいて内部的に変換されます。変換がカスタム・ルールベースの変換である場合、メッセージは、永続LCRまたは永続ユーザー・メッセージのいずれかになります。メッセージ・クライアントを起動するユーザーは、名前/値ペアのPL/SQLファンクションを実行して、デキュー中にメッセージを変換します。
変換済メッセージのデキューを終了します。
すべてのアクションは、メッセージ・クライアントを起動するユーザーによって実行されます。
図7-5は、メッセージ・クライアント・デキュー中の変換を示しています。
たとえば、メッセージがdbs1.example.comデータベースからdbs2.example.comデータベースに元の形で伝播されるとします。メッセージ・クライアントがdbs2.example.comでメッセージをデキューするときに、メッセージが変換されます。
デキュー時にメッセージ環境で変換を実行する利点の1つは、最初の伝播の後にメッセージが伝播されるすべてのデータベースが、メッセージを元の形式で受け取ることです。たとえば、メッセージがdbs2.example.comからdbs4.example.comに伝播される場合、dbs4.example.comは元のメッセージを受信できます。
デキュー中にメッセージ環境で変換を実行する場合に考えられるデメリットは、次のとおりです。
メッセージの伝播先となるデータベースすべてに元のメッセージが伝播されるため、メッセージにプライベート情報が含まれている場合はセキュリティが問題になる可能性があります。
複数の宛先データベースが同じ変換を必要とする場合は、同じ変換が2回以上実行される可能性があります。
宣言ルールベースの変換とカスタム・ルールベースの変換に加えて、行の移行も、サブセット・ルールがTRUEと評価された場合に発生する内部変換です。3種類の変換すべてが単一のルールに指定されている場合、ルールがTRUEと評価されると、変換は次の順序で実行されます。
行の移行
宣言ルールベースの変換
カスタム・ルールベースの変換
単一のルールに複数の宣言ルールベースの変換が指定されている場合、一定の順序で変換を実行する必要があります。宣言ルールベースの変換にデフォルトの順序を使用するか、または順序を指定できます。
この項の内容は次のとおりです。
ルールがTRUEと評価されると、デフォルトでは、次の順序で宣言ルールベースの変換が実行されます。
列の削除
列名の変更
列の追加
表名の変更
スキーマ名の変更
後続の各宣言変換では、宣言変換の結果が使用されます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたとします。
列addressの削除
列addressの追加
列addressが行LCRに存在するとした場合、両方の宣言変換を実行する必要があります。これは、列addressが行LCRに戻される前に、列addressアドレスが行LCRから削除されるためです。次の表は、この例の変換順序を示しています。
| 手順番号 | 変換のタイプ | 変換の詳細 | 変換が実行されるかどうか |
|---|---|---|---|
| 1 | 列の削除 | 行LCRから列addressを削除します |
はい |
| 2 | 列名の変更 | - | - |
| 3 | 列の追加 | 行LCRに列addressを追加します |
はい |
| 4 | 表名の変更 | - | - |
| 5 | スキーマ名の変更 | - | - |
別の例として、表名を変更してからスキーマ名を変更する場合を考えます。たとえば、1つのルールに、次の宣言ルールベースの変換が指定されたと想定します。
表名john.customersをsue.clientsに変更
スキーマ名sueをmaryに変更
表名の変更の変換では、表のスキーマ名も変更されることに注意してください。この場合、この場合、変換は両方とも実行され、両方の変換後の表名はmary.clientsになります。次の表に、この例での変換の順序付けを示します。
| 手順番号 | 変換のタイプ | 変換の詳細 | 変換が実行されるかどうか |
|---|---|---|---|
| 1 | 列の削除 | - | - |
| 2 | 列名の変更 | - | - |
| 3 | 列の追加 | - | - |
| 4 | 表名の変更 | 表名john.customersをsue.clientsに変更 |
はい |
| 5 | スキーマ名の変更 | スキーマ名sueをmaryに変更 |
はい |
類似した例で、1つのルールに、次の宣言ルールベースの変換が指定された場合を考えます。
表名john.customersをsue.clientsに変更
スキーマ名johnをmaryに変更
この場合、1つ目の変換は実行されますが、2つ目の変換は実行されません。1つ目の変換の実行後、表名はsue.clientsになります。2つ目の変換の実行時、表のスキーマ名はjohnではなくsueであるため、2つ目の変換は実行されません。次の表に、この例での変換の順序付けを示します。
| 手順番号 | 変換のタイプ | 変換の詳細 | 変換が実行されるかどうか |
|---|---|---|---|
| 1 | 列の削除 | - | - |
| 2 | 列名の変更 | - | - |
| 3 | 列の追加 | - | - |
| 4 | 表名の変更 | 表名john.customersをsue.clientsに変更 |
はい |
| 5 | スキーマ名の変更 | スキーマ名johnをmaryに変更 |
いいえ |
スキーマ名の変更の変換は実行されませんが、エラーは発生しません。この場合、表名の変更の変換によって、行LCRは変換され、表名sue.clientsの行LCRが戻されます。
特定のルールに対して、宣言ルールベースの変換のデフォルトの順序を使用しない場合、ルールに指定された各宣言変換に手順番号を指定できます。特定のルールに対する1つ以上の宣言ルールベースの変換に手順番号を指定した場合、宣言ルールベースの変換は、次のように実行されます。
宣言変換は、手順番号の昇順で実行されます。
宣言変換デフォルトの手順番号は0（ゼロ）です。宣言変換に手順番号が明示的に指定されていない場合、このデフォルトが使用されます。
複数の宣言変換に同じ手順番号が指定された場合、これらの宣言変換は、「宣言ルールベースの変換のデフォルトの順序」で説明されているデフォルトの順序付けに従います。
たとえば、特定のルールに関連付けられた変換に次の手順番号を指定すると、宣言変換のデフォルトの順序付けを逆にすることができます。
列の削除: 手順番号5
列名の変更: 手順番号4
列の追加: 手順番号3
表名の変更: 手順番号2
スキーマ名の変更: 手順番号1
このように順序を指定すると、スキーマ名の変更の変換が最初に実行され、列の削除の変換は最後に実行されます。
宣言ルールベースの変換とカスタム・ルールベースの変換では次の点に注意してください。
ルールベースの変換をOracle Streamsクライアントで実行するには、ルールをOracle Streamsクライアントのポジティブ・ルール・セットに含める必要があります。ルールがOracle Streamsクライアントのネガティブ・ルール・セットにある場合、Oracle Streamsクライアントではルールベースの変換が無視されます。
ルールベースの変換は、DBMS_TRANSFORMパッケージを使用して実行される変換とは異なります。このヘルプでは、DBMS_TRANSFORMパッケージで実行される変換については説明しません。
ご使用の環境で大半の行LCRを変換する場合、または実行が必要な行LCRの変換にコストがかかる場合、DMLハンドラ内で変更を行うことを検討してください。DMLハンドラは、適用の並列性が1より大きい場合にはパラレルで実行できるためです。
|
関連項目: DBMS_TRANSFORMパッケージの詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびOracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照 |
