| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
次の各項では、Oracle Streamsでのルールの使用方法について説明します。
Oracle Streamsでは、次の各メカニズムをOracle Streamsクライアントと呼びます。これは、各メカニズムがルール・エンジンのクライアントであるためです（メカニズムが1つ以上のルール・セットと関連付けられている場合）。
取得プロセス
同期取得
伝播
適用プロセス
メッセージ・クライアント
同期取得を除き、これらの各クライアントはポジティブ・ルール・セットとネガティブ・ルール・セットという最大2つのルール・セットに関連付けることができます。同期取得を関連付けることができるのは1つのポジティブ・ルール・セットだけです。ネガティブ・ルール・セットに関連付けることはできません。
1つのルール・セットは、同一データベース内の複数の取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。また、1つのルール・セットを、あるOracle Streamsクライアントに対してはポジティブ・ルール・セット、別のOracle Streamsクライアントに対してはネガティブ・ルール・セットとして使用できます。
図6-1は、1つのルール・セットをルール・エンジンの複数のクライアントがどのように使用できるかを示しています。
Oracle Streamsクライアントがタスクを実行するのは、メッセージがそのクライアントのルール・セットを満たす場合です。通常、メッセージがOracle Streamsクライアントのルール・セットを満たすのは、メッセージについてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの少なくとも1つのルールがTRUEと評価された場合です。
「ルール・セットおよびメッセージのルール評価」では、メッセージがどのようにOracle Streamsクライアントのルール・セットを満たすかに関する詳細情報を示します。これには、1つ以上のルール・セットが指定されていない場合のOracle Streamsクライアントの動作に関する情報が含まれます。
Oracle Streamsでは、次のようにルール・セットを使用します。
取得プロセスがREDOログから取得する変更または廃棄する変更を指定します。REDOログ内で検出された変更が取得プロセスのルール・セットを満たしている場合、取得プロセスはその変更を取得します。REDOログ内で検出された変更が取得プロセスのルール・セットを満たしていない場合、取得プロセスはその変更を廃棄します。
同期取得が取得する変更を指定します。つまり、DML変更が同期取得のルール・セットを満たす場合、同期取得は変更がコミットされた直後に変更を取得します。表に対して行われたDML変更が同期取得のルール・セットを満たさない場合、同期取得は変更を取得しません。
伝播があるキューから別のキューに伝播するメッセージ、または廃棄するメッセージを指定します。キュー内のメッセージが伝播のルール・セットを満たしている場合、伝播はそのメッセージを伝播します。キュー内のメッセージが伝播のルール・セットを満たしていない場合、伝播はそのメッセージを廃棄します。
適用プロセスがデキューまたは廃棄するメッセージを指定します。キュー内のメッセージが適用プロセスのルール・セットを満たしている場合、適用プロセスはそのメッセージをデキューして処理します。キュー内のメッセージが適用プロセスのルール・セットを満たしていない場合、適用プロセスはメッセージを廃棄します。
メッセージ・クライアントがデキューまたは廃棄する永続LCRまたは永続ユーザー・メッセージを指定します。永続キュー内のメッセージがメッセージ・クライアントのルール・セットの条件を満たしている場合、メッセージ・クライアントを使用しているユーザーまたはアプリケーションはそのメッセージをデキューします。永続キュー内のメッセージがメッセージ・クライアントのルール・セットの条件を満たしていない場合、メッセージ・クライアントを使用しているユーザーまたはアプリケーションはそのメッセージを廃棄します。
伝播の場合、ルール・セットで検証されるメッセージは、取得LCR、永続LCR、バッファLCR、永続ユーザー・メッセージまたはバッファ・ユーザー・メッセージを含むすべてのタイプのメッセージです。
適用プロセスの場合、ルール・セットで検証されるメッセージは、取得LCR、永続LCRまたは永続ユーザー・メッセージです。
クライアントに関連付けられているポジティブ・ルール・セットに競合するルールが含まれる場合、どちらかのルールがTRUEと評価されると、そのクライアントはタスクを実行します。たとえば、取得プロセスのポジティブ・ルール・セットに、hr.employees表に対するデータ操作言語（DML）変更の結果を取得するように指示する1つのルールが含まれているときは、同じルール・セットにhr.employees表に対するDML変更の結果を取得しないように指示する別のルールが含まれていても、取得プロセスはこれらの変更を取得します。
同様に、クライアントに関連付けられているネガティブ・ルール・セットに競合するルールが含まれる場合、メッセージについてどちらかのルールがTRUEと評価されると、そのクライアントはメッセージを廃棄します。たとえば、取得プロセスのネガティブ・ルール・セットに、hr.departments表に対するDML変更の結果を廃棄するように指示する1つのルールが含まれているときは、同じルール・セットにhr.departments表に対するDML変更の結果を廃棄しないように指示する別のルールが含まれていても、取得プロセスはこれらの変更を廃棄します。
Oracle Streamsクライアントでは、ルールに基づいて次のタスクを実行します。
取得プロセスは、REDOログで変更を取得し、取得した変更を論理変更レコード（LCR）に変換して、これらのLCRを含むメッセージを取得プロセスのキューにエンキューします。
同期取得は、表に対するDML変更の結果を取得し、取得した変更を行論理変更レコード（行LCR）に変換して、これらの行LCRを含むメッセージを同期取得のキューにエンキューします。
適用プロセスは、取得LCR、永続LCRまたは永続ユーザー・メッセージをそのキューからデキューし、これらのメッセージを直接適用するか、または適用ハンドラに送信します。
メッセージ・クライアントは、永続LCRまたは永続ユーザー・メッセージをそのキューからデキューします。
これらのOracle Streamsクライアントは、すべてルール・エンジンのクライアントです。メッセージがOracle Streamsクライアントで使用されるルール・セットを満たしている場合、Oracle Streamsクライアントはそのメッセージに対してタスクを実行します。Oracle Streams クライアントには、ルール・セットが存在しない場合、ポジティブ・ルール・セットのみが存在する場合、ネガティブ・ルール・セットのみが存在する場合、またはポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合があります。
次の各項では、それぞれの場合のルール評価について説明します。
ルール・セットが存在しないOracle Streamsクライアントは、表示されるすべてのメッセージのタスクを実行します。空のルール・セットが存在する場合とルール・セットが存在しない場合は区別されます。
取得プロセスでは、サポートされていないデータベース・オブジェクトに対する変更を取得しないように、常に、1つ以上のルール・セットを所有する必要があります。常に、伝播がソース・キュー内のすべてのメッセージを伝播する必要がある場合、または常に、適用プロセスがキュー内のすべてのメッセージをデキューする必要がある場合、伝播または適用プロセスからすべてのルール・セットを削除すると、パフォーマンスが向上する場合があります。 同期取得には、ポジティブ・ルール・セットが必要です。ルール・セットがないと、同期取得を構成できません。
ポジティブ・ルール・セットが存在してネガティブ・ルール・セットが存在しない場合、メッセージについてポジティブ・ルール・セットのいずれかのルールがTRUEと評価されると、そのメッセージに対してOracle Streamsクライアントのタスクが実行されます。ただし、メッセージについてポジティブ・ルール・セットのすべてのルールがFALSEと評価されると、Oracle Streamsクライアントによってメッセージが破棄されます。
Oracle Streamsクライアントでは、ネガティブ・ルール・セットが存在してポジティブ・ルール・セットが存在しない場合、メッセージについてネガティブ・ルール・セットのいずれかのルールがTRUEと評価されると、そのメッセージは破棄されます。ただし、メッセージについてネガティブ・ルール・セットのすべてのルールがFALSEと評価されると、Oracle Streamsクライアントによってメッセージのタスクが実行されます。同期取得は、ネガティブ・ルール・セットを保持できません。
Oracle Streamsクライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在する場合は、メッセージについてネガティブ・ルール・セットが最初に評価されます。メッセージについてネガティブ・ルール・セットのいずれかのルールがTRUEと評価されると、メッセージは破棄されて、ポジティブ・ルール・セットに対する評価は行われなくなります。
ただし、メッセージについてネガティブ・ルール・セットのすべてのルールがFALSEと評価されると、メッセージがポジティブ・ルール・セットに対して評価されます。この場合の動作は、Oracle Streamsクライアントにポジティブ・ルール・セットのみが存在する場合と同じになります。つまり、メッセージについてポジティブ・ルール・セットのいずれかのルールがTRUEと評価されると、そのメッセージに対してOracle Streamsクライアントのタスクが実行されます。メッセージについてポジティブ・ルール・セットのすべてのルールがFALSEと評価されると、Oracle Streamsクライアントによってメッセージが廃棄されます。
同期取得にはネガティブ・ルール・セットを関連付けることができません。
Oracle Streamsクライアントに空のルール・セットが1つ以上存在する場合があります。その場合、Oracle Streamsクライアントは次のように動作します。
Oracle Streamsクライアントにポジティブ・ルール・セットが存在せず、ネガティブ・ルール・セットが空の場合、すべてのメッセージに対してOracle Streamsクライアントのタスクが実行されます。
Oracle Streamsクライアントにポジティブ・ルール・セットとネガティブ・ルール・セットの両方が存在し、ネガティブ・ルール・セットは空だが、ポジティブ・ルール・セットにルールが含まれている場合、ポジティブ・ルール・セットのルールに基づいてOracle Streamsクライアントのタスクが実行されます。
Oracle Streamsクライアントに空のポジティブ・ルール・セットがある場合、ネガティブ・ルール・セットの状態にかかわりなく、Oracle Streamsクライアントによってすべてのメッセージが廃棄されます。
表6-1に、前項で説明したOracle Streamsクライアントの動作のまとめを示します。
表6-1 ルール・セットとOracle Streamsクライアントの動作
| ネガティブ・ルール・セット | ポジティブ・ルール・セット | Oracle Streamsクライアントの動作 |
|---|---|---|
|
なし |
なし |
すべてのメッセージに対してタスクが実行されます。 |
|
なし |
あり（ルールを含む） |
ポジティブ・ルール・セットで |
|
あり（ルールを含む） |
なし |
ネガティブ・ルール・セットで |
|
あり（ルールを含む） |
あり（ルールを含む） |
ネガティブ・ルール・セットで |
|
あり（空） |
なし |
すべてのメッセージに対してタスクが実行されます。 |
|
あり（空） |
あり（ルールを含む） |
ポジティブ・ルール・セットで |
|
なし |
あり（空） |
すべてのメッセージが廃棄されます。 |
|
あり（空） |
あり（空） |
すべてのメッセージが廃棄されます。 |
|
あり（ルールを含む） |
あり（空） |
すべてのメッセージが廃棄されます。 |
Orcle Streamsクライアントがメッセージに対するタスクを実行するのは、メッセージがそのクライアントのルール・セットを満たしている場合です。システム作成ルールは、DBMS_STREAMS_ADMパッケージで作成され、粒度レベルとして表、スキーマまたはグローバルのいずれかを指定できます。この項では、各レベルについて説明します。特定のタスクに複数のレベルを指定できます。たとえば、1つの適用プロセスに対して、oeスキーマの特定の表に表レベルの適用を実行し、hrスキーマ全体にスキーマ・レベルの適用を実行するように指示できます。また、1つのルールは、データ操作言語（DML）変更またはデータ定義言語（DDL）変更のいずれかの結果に関連しています。そのため、たとえば、特定の表のすべての変更に対処するには、DML変更の結果とDDL変更の結果それぞれに対応する少なくとも2つのシステム作成ルールが必要です。DML変更の結果とは、DML変更の結果として生成される行変更、または各行の変更をカプセル化するキュー内の行LCRです。
表6-2は、ルールの各レベルが各Oracle Streamsタスクについてどのような意味を持つかを示します。ネガティブ・ルール・セットがポジティブ・ルール・セットよりも前に評価されることに注意してください。
表6-2 タスクのタイプとルールのレベル
| タスク | 表ルール | スキーマ・ルール | グローバル・ルール |
|---|---|---|---|
|
取得プロセスによる取得 |
ネガティブ・ルール・セットに含まれる場合、指定した表に関するREDOログ内の変更を廃棄します。 ポジティブ・ルール・セットに含まれる場合、指定した表に関するREDOログ内のすべての変更または変更のサブセットを取得し、論理変更レコード（LCR）に変換してエンキューします。 |
ネガティブ・ルール・セットに含まれる場合、スキーマ自体および指定したスキーマ内のデータベース・オブジェクトに関するREDOログ内の変更を廃棄します。 ポジティブ・ルール・セットに含まれる場合、スキーマ自体および指定したスキーマ内のデータベース・オブジェクトに関するREDOログ内の変更を取得し、論理変更レコード（LCR）に変換してエンキューします。 |
ネガティブ・ルール・セットに含まれる場合、データベース内のすべてのデータベース・オブジェクトに対する変更を廃棄します。 ポジティブ・ルール・セットに含まれる場合、データベース内のすべてのデータベース・オブジェクトに対する変更を取得し、LCRに変換してエンキューします。 |
|
同期取得による取得 |
ポジティブ・ルール・セットに含まれる場合、指定した表に対するすべての変更または変更のサブセットを取得し、論理変更レコード（LCR）に変換してエンキューします。 同期取得にはネガティブ・ルール・セットを関連付けることができません。 |
同期取得にはスキーマ・ルールを関連付けることができません。 |
同期取得にはグローバル・ルールを関連付けることができません。 |
|
伝播による伝播 |
ネガティブ・ルール・セットに含まれる場合、指定した表に関連するLCRをソース・キューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、指定した表に関連するLCRのすべてまたはサブセットをソース・キューから宛先キューに伝播します。 |
ネガティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するLCRをソース・キューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連するLCRをソース・キューから宛先キューに伝播します。 |
ネガティブ・ルール・セットに含まれる場合、ソース・キュー内のすべてのLCRを廃棄します。 ポジティブ・ルール・セットに含まれる場合、ソース・キュー内のすべてのLCRを宛先キューに伝播します。 |
|
適用プロセスによる適用 |
ネガティブ・ルール・セットに含まれる場合、指定した表に関連するLCRをキューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、指定した表に関連する、キュー内のLCRのすべてまたはサブセットを適用します。 |
ネガティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびそのスキーマ内のデータベース・オブジェクトに関連するLCRをキューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、指定したスキーマ自体およびそのスキーマ内のデータベース・オブジェクトに関連するキュー内のLCRを適用します。 |
ネガティブ・ルール・セットに含まれる場合、キュー内のすべてのLCRを廃棄します。 ポジティブ・ルール・セットに含まれる場合、キュー内のすべてのLCRを適用します。 |
|
メッセージ・クライアントによるデキュー |
ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定した表に関連する永続LCRをキューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定した表に関連する永続LCRのすべてまたはサブセットをキューからデキューします。 |
ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連する永続LCRをキューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、指定したスキーマ自体およびスキーマ内のデータベース・オブジェクトに関連する永続LCRをキューからデキューします。 |
ネガティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、すべての永続LCRをキューから廃棄します。 ポジティブ・ルール・セットに含まれる場合、メッセージ・クライアントが起動されると、すべての永続LCRをキューからデキューします。 |
DBMS_STREAMS_ADMパッケージのプロシージャを使用して、これらの各レベルでルールを作成できます。システム作成ルールには、表6-2で説明されている以外にも、Oracle Streamsクライアントの動作を変更する条件を含めることができます。たとえば、LCRに対して特定のソース・データベースを指定できるルールがあります。この場合は、LCRが指定されたソース・データベースで発生したときのみ、このルールがTRUEと評価されます。表6-3に、DBMS_STREAMS_ADMパッケージによって作成されるルールで指定できるシステム作成ルール条件のタイプを示します。
表6-3 DBMS_STREAMS_ADMパッケージによって生成されるシステム作成ルールの条件
| ルール条件がTRUEと評価される対象 | Oracle Streamsクライアント | 作成に使用されるプロシージャ |
|---|---|---|
|
特定のデータベース内の任意の表に対するDML変更のためにREDOログに記録されるすべての行変更 |
取得プロセス |
|
|
特定のデータベース内の任意のデータベース・オブジェクトに対する、REDOログに記録されるすべてのDDL変更 |
取得プロセス |
|
|
特定のスキーマ内の任意の表に対するDML変更のためにREDOログに記録されるすべての行変更 |
取得プロセス |
|
|
特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに対する、REDOログに記録されるすべてのDDL変更 |
取得プロセス |
|
|
特定の表に対するDML変更のためにREDOログに記録されるすべての行変更 |
取得プロセス |
|
|
特定の表に対する、REDOログに記録されるすべてのDDL変更 |
取得プロセス |
|
|
特定の表内の行のサブセットに対するDML変更のためにREDOログに記録されるすべての行変更 |
取得プロセス |
|
|
DML文の結果、特定の表に対して行われるすべての行変更 |
同期取得 |
|
|
DML文の結果、特定の表内の行のサブセットに対して行われるすべての行変更 |
同期取得 |
|
|
ソース・キュー内のすべての行LCR |
伝播 |
|
|
ソース・キュー内のすべてのDDL LCR |
伝播 |
|
|
特定のスキーマ内の表に関連するソース・キュー内のすべての行LCR |
伝播 |
|
|
特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに関連するソース・キュー内のすべてのDDL LCR |
伝播 |
|
|
特定の表に関連するソース・キュー内のすべての行LCR |
伝播 |
|
|
特定の表に関連するソース・キュー内のすべてのDDL LCR |
伝播 |
|
|
特定の表内の行のサブセットに関連するソース・キュー内のすべての行LCR |
伝播 |
|
|
ユーザー指定のルール条件を満たす、指定されたタイプのソース・キュー内のすべてのユーザー・メッセージ |
伝播 |
|
|
適用プロセスで使用されるキュー内のすべての行LCR |
適用プロセス |
|
|
適用プロセスで使用されるキュー内のすべてのDDL LCR |
適用プロセス |
|
|
特定のスキーマ内の表に関連する適用プロセスで使用されるキュー内のすべての行LCR |
適用プロセス |
|
|
特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに関連する適用プロセスで使用されるキュー内のすべてのDDL LCR |
適用プロセス |
|
|
特定の表に関連する適用プロセスで使用されるキュー内のすべての行LCR |
適用プロセス |
|
|
特定の表に関連する適用プロセスで使用されるキュー内のすべてのDDL LCR |
適用プロセス |
|
|
特定の表内の行のサブセットに関連する適用プロセスで使用されるキュー内のすべての行LCR |
適用プロセス |
|
|
ユーザー指定のルール条件を満たす、指定されたタイプの適用プロセスで使用されるキュー内のすべての永続ユーザー・メッセージ |
適用プロセス |
|
|
メッセージ・クライアントで使用されるキュー内のすべての永続行LCR |
メッセージ・クライアント |
|
|
メッセージ・クライアントで使用されるキュー内のすべての永続DDL LCR |
メッセージ・クライアント |
|
|
特定のスキーマ内の表に関連するメッセージ・クライアントで使用されるキュー内のすべての永続行LCR |
メッセージ・クライアント |
|
|
特定のスキーマと、そのスキーマ内の任意のデータベース・オブジェクトに関連するメッセージ・クライアントで使用されるキュー内のすべての永続DDL LCR |
メッセージ・クライアント |
|
|
特定の表に関連するメッセージ・クライアントのキュー内のすべての永続行LCR |
メッセージ・クライアント |
|
|
特定の表に関連するメッセージ・クライアントで使用されるキュー内のすべての永続DDL LCR |
メッセージ・クライアント |
|
|
特定の表内の行のサブセットに関連するメッセージ・クライアントで使用されるキュー内のすべての永続行LCR |
メッセージ・クライアント |
|
|
ユーザー指定のルール条件を満たす、指定されたタイプのメッセージ・クライアントで使用されるキュー内のすべての永続メッセージ |
メッセージ・クライアント |
|
表6-3に示した各プロシージャでは、次の操作が実行されます。
取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントは、存在しない場合には作成されます。
指定された取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットは、存在しない場合には作成されます。取得プロセス、伝播、適用プロセスまたはメッセージ・クライアントについては、このルール・セットはポジティブ・ルール・セットまたはネガティブ・ルール・セットになります。プロシージャを2回以上実行して、各タイプのルール・セットを作成できます。同期取得については、このルール・セットはポジティブ・ルール・セットである必要があります。
0（ゼロ）個以上のルールが作成され、指定された取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのルール・セットに追加されます。これらのプロシージャのいずれかを実行すると、ユーザーによる指定に基づいて、ポジティブ・ルール・セットまたはネガティブ・ルール・セットのいずれかにルールが追加されます。
ADD_MESSAGE_RULEおよびADD_MESSAGE_PROPAGATION_RULEプロシージャを除き、これらのプロシージャを実行すると、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストを使用するルール・セットが作成されます。これは、Oracle Streams環境向けにOracleが提供する評価コンテキストです。
グローバル・ルール、スキーマ・ルール、表ルールおよび サブセット・ルールでは、SYS.STREAMS$_EVALUATION_CONTEXT評価コンテキストが使用されます。ただし、ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャを使用してルールを作成すると、そのルールではメッセージ・タイプごとに特別にカスタマイズされたシステム生成評価コンテキストが使用されます。ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャによって作成されたルール・セットには、評価コンテキストがありません。
ADD_SUBSET_RULES、ADD_SUBSET_PROPAGATION_RULES、ADD_MESSAGE_RULEおよびADD_MESSAGE_PROPAGATION_RULEを除き、これらのプロシージャではルールが作成されないか、1つまたは2つのルールが作成されます。DML変更またはDDL変更の結果発生する行変更のみについて、Oracle Streamsタスクを実行する場合は、ルールが1つのみ作成されます。ただし、DML変更とDDL変更の両方の結果についてOracle Streamsタスクを実行する場合は、ルールが個々に作成されます。ここで表のDMLルールを作成すると、以前に作成したDMLルールを変更せずに、後で同じ表のDDLルールを作成できます。これは、最初に表のDDLルールを作成してから、後で同じ表のDMLルールを作成する場合も同じです。
ADD_SUBSET_RULESおよびADD_SUBSET_PROPAGATION_RULESプロシージャでは、表に対する3種類のDML操作であるINSERT、UPDATEおよびDELETEについて、常に3つのルールが作成されます。これらのプロシージャでは、表に対するDDL変更のルールは作成されません。ADD_TABLE_RULESまたはADD_TABLE_PROPAGATION_RULESプロシージャを使用すると、表のDDLルールを作成できます。また、サブセット・ルールはポジティブ・ルール・セットにのみ追加でき、ネガティブ・ルール・セットには追加できません。
ADD_MESSAGE_RULEおよびADD_MESSAGE_PROPAGATION_RULEプロシージャでは、ユーザー指定のルール条件のある1つのルールが常に作成されます。これらのプロシージャでは、ユーザー・メッセージのルールが作成されます。表に対するDML変更またはDDL変更の結果のルールは作成されません。
取得LCRの伝播ルールを作成する場合は、変更対象のソース・データベースを指定することをお薦めします。適用プロセスでは、トランザクション制御メッセージを使用して、取得LCRがコミット済のトランザクションに組み立てられます。COMMITやROLLBACKなどのトランザクション制御メッセージには、メッセージが発生したソース・データベースの名前が含まれます。意図に反したこれらのメッセージの循環を回避するには、ソース・データベースを指定する条件を伝播ルールに含める必要があります。そのためには、伝播ルールの作成時にソース・データベースを指定します。
次の各項では、システム作成ルールについてさらに詳しく説明します。
|
注意:
|
|
関連項目:
|
ルールを使用して、データベース全体またはキュー全体に関連するOracle Streamsタスクを指定するときには、グローバル・ルールを指定します。DML変更に関するグローバル・ルール、DDL変更に関するグローバル・ルール、または各のタイプの変更に関するグローバル・ルール（合計2つのルール）を指定できます。
取得プロセスの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・データベースに対するすべてのDML変更またはすべてのDDL変更の結果を取得します。また、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・データベースに対するすべてのDML変更またはすべてのDDL変更の結果を廃棄します。
伝播の場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・キュー内のすべての行LCRまたはすべてのDDL LCRを宛先キューに伝播します。また、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、ソース・キュー内のすべての行LCRまたはすべてのDDL LCRを廃棄します。
適用プロセスの場合、ポジティブ・ルール・セットに1つのグローバル・ルールを含めると、指定したソース・データベースに関する、キュー内のすべての行LCRまたはすべてのDDL LCRを適用します。適用プロセスの場合、ネガティブ・ルール・セットに1つのグローバル・ルールを含めると、指定したソース・データベースに関する、キュー内のすべての行LCRまたはすべてのDDL LCRを廃棄します。
グローバル・ルールを使用する際、Oracle Streamsでサポートされないデータベース・オブジェクトを変更する場合は、DBMS_RULE_ADMパッケージを使用してサポートされない変更を廃棄するルールを作成できます。
DBMS_STREAMS_ADMパッケージのADD_GLOBAL_RULESプロシージャを使用し、Oracle Streamsの取得プロセスに対してデータベース内のすべてのDML変更とDDL変更を取得するよう指示する場合を考えます。
ADD_GLOBAL_RULESプロシージャを実行してルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES(
streams_type => 'capture',
streams_name => 'capture',
queue_name => 'streams_queue',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => FALSE,
source_database => NULL,
inclusion_rule => TRUE);
END;
/
inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが取得プロセスのポジティブ・ルール・セットに追加されます。
作成しているルールはローカル取得プロセス用であるため、source_databaseパラメータにNULLを指定できます。ローカル・データベースのグローバル名も指定できます。ADD_GLOBAL_RULESを使用してダウンストリーム取得プロセスまたは適用プロセスのルールを作成する場合は、ソース・データベース名を指定します。
ADD_GLOBAL_RULESプロシージャによって2つのルールが作成されます。1つは行LCR（DML変更の結果を含む）用、もう1つはDDL LCR用です。
行LCRルールで使用されるルール条件を次に示します。
(:dml.is_null_tag() = 'Y' )
DMLルールの条件は変数:dmlで始まることに注意してください。この値は、評価される行LCRに対して指定されたメンバー・ファンクションのコールによって決定されます。したがって:dml.is_null_tag()は、評価される行LCRのIS_NULL_TAGメンバー・ファンクションのコールです。
DDL LCRルールで使用されるルール条件を次に示します。
(:ddl.is_null_tag() = 'Y' )
DDLルールの条件は変数:ddlで始まることに注意してください。この値は、評価されるDDL LCRに対して指定されたメンバー・ファンクションのコールによって決定されます。したがって:ddl.is_null_tag()は、評価されるDDL LCRのIS_NULL_TAGメンバー・ファンクションのコールです。
取得プロセスの場合、これらの条件は、取得プロセスによって変更を取得するにはREDOレコード内のタグがNULLである必要があることを示します。伝播の場合、これらの条件は、伝播によってLCRを伝播するにはLCR内のこのタグがNULLである必要があることを示します。適用プロセスの場合、これらの条件は、適用プロセスによってLCRを適用するにはLCR内のこのタグがNULLである必要があることを示します。
この例で作成したルールを取得プロセスのポジティブ・ルール・セットで使用すると、データベースに対して行ったサポート対象のDML変更とDDL変更が取得プロセスによってすべて取得されます。
|
注意: 取得プロセスのポジティブ・ルール・セットにグローバル・ルールを追加する場合は、取得プロセスでサポートされないデータベース・オブジェクトを除外するために、必ず取得プロセスのネガティブ・ルール・セットにルールを追加してください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされないデータベース・オブジェクトを特定します。サポートされないデータベース・オブジェクトを除外しないと、取得エラーが発生します。
適用プロセスのポジティブ・ルール・セットにグローバル・ルールを追加する場合は、適用プロセスによってサポートされない列への変更の適用が試行されないようにしてください。そのためには、適用プロセスのネガティブ・ルール・セットにルールを追加して、その列を含む表を除外するか、ルールベースの変換またはDMLハンドラを使用してその列を除外できます。 |
DBMS_STREAMS_ADMパッケージのプロシージャを実行する場合、include_tagged_lcrパラメータにTRUEを指定すると、システム作成ルールでis_null_tag条件を省略できます。たとえば、次のADD_GLOBAL_RULESプロシージャでは、is_null_tag条件なしでもルールが作成されます。
BEGIN DBMS_STREAMS_ADM.ADD_GLOBAL_RULES( streams_type => 'capture', streams_name => 'capture_002', queue_name => 'streams_queue', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => TRUE, source_database => NULL, inclusion_rule => TRUE); END; /
グローバル・ルールについてinclude_tagged_lcrパラメータをTRUEに設定し、source_database_nameパラメータをNULLに設定すると、行LCRルールで使用されるルール条件は次のようになります。
(( :dml.get_source_database_name()>=' ' OR :dml.get_source_database_name()<=' ') )
DDL LCRルールで使用されるルール条件を次に示します。
(( :ddl.get_source_database_name()>=' ' OR :ddl.get_source_database_name()<=' ') )
システム作成グローバル・ルールに含まれるこれらの条件によって、すべての行LCRおよびDDL LCRがTRUEと評価されます。
これらのルール条件は、これらのルールに対するNULLのルール条件を回避するために指定されます。NULLのルール条件はサポートされません。この場合、データベースに対するすべてのDML変更とDDL変更を取得する必要があり、取得時にそれらの変更に対してルールベースの変換を使用しないときは、グローバル・ルールを指定するかわりに、ポジティブ・ルール・セットなしで取得プロセスを実行できます。
|
注意:
|
|
関連項目:
|
ルールを使用してスキーマに関連するOracle Streamsタスクを指定するときには、スキーマ・ルールを指定します。DML変更に関するスキーマ・ルール、DDL変更に関するスキーマ・ルール、またはスキーマに対するそれぞれの変更に関するスキーマ・ルール（合計2つのルール）を指定できます。
取得プロセスの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対するDML変更またはDDL変更を取得します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対するDML変更またはDDL変更の結果を廃棄します。
伝播の場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含む行LCRまたはDDL LCRをソース・キューから伝播します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含む行LCRまたはDDL LCRをソース・キューから廃棄します。
適用プロセスの場合、ポジティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含むキュー内の行LCRまたはDDL LCRを適用します。また、ネガティブ・ルール・セットに1つのスキーマ・ルールを含めると、スキーマに対する変更を含むキュー内の行LCRまたはDDL LCRを廃棄します。
スキーマ・ルールを使用する際、Oracle Streamsでサポートされないスキーマのデータベース・オブジェクトを変更する場合は、DBMS_RULE_ADMパッケージを使用してサポートされない変更を廃棄するルールを作成できます。
DBMS_STREAMS_ADMパッケージのADD_SCHEMA_PROPAGATION_RULESプロシージャを使用して、Oracle Streams伝播でhrスキーマに関連する行LCRおよびDDL LCRをdbs1.example.comデータベースのキューからdbs2.example.comデータベースのキューに伝播するよう指示する場合を考えます。
dbs1.example.comでADD_SCHEMA_PROPAGATION_RULESプロシージャを実行して、ルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES(
schema_name => 'hr',
streams_name => 'dbs1_to_dbs2',
source_queue_name => 'streams_queue',
destination_queue_name => 'streams_queue@dbs2.example.com',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => FALSE,
source_database => 'dbs1.example.com',
inclusion_rule => TRUE);
END;
/
inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが伝播のポジティブ・ルール・セットに追加されます。
ADD_SCHEMA_PROPAGATION_RULESプロシージャによって2つのルールが作成されます。1つは行LCR（DML変更の結果を含む）用、もう1つはDDL LCR用です。
行LCRルールで使用されるルール条件を次に示します。
((:dml.get_object_owner() = 'HR') and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )
DDL LCRルールで使用されるルール条件を次に示します。
((:ddl.get_object_owner() = 'HR' or :ddl.get_base_table_owner() = 'HR') and :ddl.is_null_tag() = 'Y' and :ddl.get_source_database_name() = 'DBS1.EXAMPLE.COM' )
オブジェクトを所有しないユーザーがそのオブジェクトのDDL変更を実行した場合、GET_OBJECT_OWNERファンクションではNULLが返される可能性があるため、DDL LCRルールではGET_BASE_TABLE_OWNERメンバー・ファンクションが使用されます。
伝播のポジティブ・ルール・セットにこれらのルールが含まれる場合に、伝播によって伝播される変更の例を次に示します。
hr.countries表への1行の挿入
hr.loc_city_ix索引の変更
hr.employees表の切捨て
hr.countries表への列の追加
hr.update_job_historyトリガーの変更
hrスキーマでのcandidatesという新規表の作成
hr.candidates行への20行の挿入
伝播によって、これらの変更のすべてを含むLCRがソース・キューから宛先キューに伝播されます。
次に、同じルールが使用され、oe.inventories表に1行が挿入されたる場合を考えます。oeスキーマがスキーマ・ルールで指定されておらず、oe.inventories表が表ルールで指定されていないため、この変更は無視されます。
|
注意: 取得プロセスのポジティブ・ルール・セットにスキーマ・ルールを追加する場合は、取得プロセスでサポートされないスキーマ内のデータベース・オブジェクトを除外するために、必ず取得プロセスのネガティブ・ルール・セットにルールを追加してください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされないデータベース・オブジェクトを特定します。サポートされないデータベース・オブジェクトを除外しないと、取得エラーが発生します。
適用プロセスのポジティブ・ルール・セットにスキーマ・ルールを追加する場合は、適用プロセスによってサポートされない列への変更の適用が試行されないようにしてください。そのためには、適用プロセスのネガティブ・ルール・セットにルールを追加して、その列を含む表を除外するか、ルールベースの変換またはDMLハンドラを使用してその列を除外できます。 |
ルールを使用して個々の表のみに関連するOracle Streamsタスクを指定するときには、表ルールを指定します。特定の表に対するDML変更に関する表ルール、DDL変更に関する表ルール、または各タイプの変更に関する表ルール（合計2つのルール）を指定できます。
取得プロセスの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対するDML変更またはDDL変更の結果を取得します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対するDML変更またはDDL変更の結果を廃棄します。
同期取得の場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対するDML変更の結果を取得します。ネガティブ・ルール・セットを同期取得に関連付けることはできません。
伝播の場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含む行LCRまたはDDL LCRをソース・キューから伝播します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含む行LCRまたはDDL LCRをソース・キューから廃棄します。
適用プロセスの場合、ポジティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含むキュー内の行LCRまたはDDL LCRを適用します。また、ネガティブ・ルール・セットに1つの表ルールを含めると、表に対する変更を含むキュー内の行LCRまたはDDL LCRを廃棄します。
DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを使用して、Oracle Streamsの適用プロセスに次の動作を指示する場合を考えます。
これらの行LCRの変更が、dbs1.example.comソース・データベースで発生しました。
ADD_TABLE_RULESプロシージャを実行して次のルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.locations',
streams_type => 'apply',
streams_name => 'apply',
queue_name => 'streams_queue',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'dbs1.example.com',
inclusion_rule => TRUE);
END;
/
inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのポジティブ・ルール・セットに追加されます。
ADD_TABLE_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。
(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'LOCATIONS')) and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )
これらのDDL LCRの変更が、dbs1.example.comソース・データベースで発生しました。
ADD_TABLE_RULESプロシージャを実行して次のルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.countries',
streams_type => 'apply',
streams_name => 'apply',
queue_name => 'streams_queue',
include_dml => FALSE,
include_ddl => TRUE,
include_tagged_lcr => FALSE,
source_database => 'dbs1.example.com',
inclusion_rule => TRUE);
END;
/
inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのポジティブ・ルール・セットに追加されます。
ADD_TABLE_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。
(((:ddl.get_object_owner() = 'HR' and :ddl.get_object_name() = 'COUNTRIES') or (:ddl.get_base_table_owner() = 'HR' and :ddl.get_base_table_name() = 'COUNTRIES')) and :ddl.is_null_tag() = 'Y' and :ddl.get_source_database_name() = 'DBS1.EXAMPLE.COM' )
オブジェクトを所有しないユーザーがそのオブジェクトのDDL変更を実行した場合、GET_OBJECT_OWNERおよびGET_OBJECT_NAMEファンクションではNULLが返される可能性があるため、DDL LCRルールではGET_BASE_TABLE_OWNERおよびGET_BASE_TABLE_NAMEメンバー・ファンクションが使用されます。
生成されたDDL表のルールは、表または表の一部を構成するオブジェクト（表の索引やトリガーなど）で行われるすべてのDDL変更について、TRUEと評価します。DDL変更は、表を参照しない場合または次の方法で表を参照する場合にFALSEと評価されます。たとえば、表に基づいてシノニムまたはビューを作成する変更について、FALSEと評価されます。また、表を参照するPL/SQLサブプログラムに対する変更についてもFALSEと評価されます。
この例では、次の表ルールが定義されています。
hr.locations表に対するDML操作の結果発生した行変更が行LCRに含まれている場合にTRUEに評価される表ルール
hr.countries表で実行されたDDL変更がDDL LCRに含まれている場合にTRUEに評価される表ルール
これらのルールを使用した場合に適用プロセスによって適用される変更の例を次に示します。
hr.locations表への1行の挿入
hr.locations表からの5行の削除
hr.countries表への列の追加
適用プロセスによって、これらの変更を含むLCRがその関連キューからデキューされ、宛先データベースのデータベース・オブジェクトに適用されます。
これらのルールを使用した場合に適用プロセスによって無視される変更の例を次に示します。
hr.employees表への1行の挿入。hr.employees表の変更はどのルールも満たさないため、この変更は適用されません。
hr.countries表内の1行の更新。この変更はDDL変更ではなくDML変更です。hr.countries表に関するルールはDDL変更のみを対象としているため、この変更は適用されません。
hr.locations表への1列の追加。この変更はDML変更ではなくDDL変更です。hr.locations表に関するルールはDML変更のみを対象としているため、この変更は適用されません。
|
注意: 取得プロセスでサポートされない表については、取得プロセスのポジティブ・ルール・セットに表ルールを追加しないでください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされない表を特定します。サポートされない表を除外しないと、取得エラーが発生します。
同期取得または適用プロセスのポジティブ・ルール・セットに表ルールを追加する場合は、サポートされない列の変更の処理がこれらのOracle Streamsクライアントによって試行されないようにしてください。サポートされない列が表に含まれる場合はルールベースの変換によって、また、適用プロセスの場合はDMLハンドラによってその列を除外できます。 |
サブセット・ルールはDML変更の特殊な表ルールであり、表の行のサブセットのみに関連します。取得プロセス、同期取得、適用プロセスおよびメッセージ・クライアントのサブセット・ルールはADD_SUBSET_RULESプロシージャを使用して作成できます。伝播のサブセット・ルールはADD_SUBSET_PROPAGATION_RULESプロシージャを使用して作成できます。これらのプロシージャでは、SELECT文のWHERE句と同様の条件を使用して次の指定ができます。
取得プロセスが、特定の表に対するDML変更によって発生する行変更のサブセットのみを取得するように指定
同期取得が、特定の表に対するDML変更によって発生する行変更のサブセットのみを取得するように指定
伝播が、特定の表に関連する行LCRのサブセットのみを伝播するように指定
適用プロセスが、特定の表に関連する行LCRのサブセットのみを適用するように指定
メッセージ・クライアントが、特定の表に関連する行LCRのサブセットのみをデキューするように指定
ADD_SUBSET_RULESプロシージャとADD_SUBSET_PROPAGATION_RULESプロシージャでは、Oracle Streamsクライアントのポジティブ・ルール・セットのみにサブセット・ルールを追加できます。これらのプロシージャでは、Oracle Streamsクライアントのネガティブ・ルール・セットにサブセット・ルールを追加できません。
次の各項では、サブセット・ルールについてさらに詳しく説明します。
この例では、region_idが2であるhr.regions表に関連する行LCRのサブセットをOracle Streamsの適用プロセスで適用するよう指示します。これらの変更は、dbs1.example.comソース・データベースで発生しています。
ADD_SUBSET_RULESプロシージャを実行して3つのルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_SUBSET_RULES(
table_name => 'hr.regions',
dml_condition => 'region_id=2',
streams_type => 'apply',
streams_name => 'apply',
queue_name => 'streams_queue',
include_tagged_lcr => FALSE,
source_database => 'dbs1.example.com');
END;
/
ADD_SUBSET_RULESプロシージャによって、INSERT操作用、UPDATE操作用およびDELETE操作用に1つずつ、合計3つのルールが作成されます。
挿入ルールで使用されるルール条件を次に示します。
:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS'
AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.EXAMPLE.COM'
AND :dml.get_command_type() IN ('UPDATE','INSERT')
AND (:dml.get_value('NEW','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2)
AND (:dml.get_command_type()='INSERT'
OR ((:dml.get_value('OLD','"REGION_ID"') IS NOT NULL)
AND (((:dml.get_value('OLD','"REGION_ID"').AccessNumber() IS NOT NULL)
AND NOT (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2))
OR ((:dml.get_value('OLD','"REGION_ID"').AccessNumber() IS NULL)
AND NOT EXISTS (SELECT 1 FROM SYS.DUAL
WHERE (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2))))))
このルール条件に基づいて、行LCRが次のように評価されます。
挿入の場合は、行LCRでregion_idの新しい値が2であれば、挿入が適用されます。
挿入の場合は、行LCRでregion_idの新しい値が2でないか、またはNULLであれば、挿入が除外されます。
更新の場合は、行LCRでregion_idの古い値が2でないか、またはNULLであり、行LCRでregion_idの新しい値が2であれば、更新が挿入に変換されてから適用されます。この自動変換を行の移行といいます。詳細は、「行の移行およびサブセット・ルール」を参照してください。
更新ルールで使用されるルール条件を次に示します。
:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS'
AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.EXAMPLE.COM'
AND :dml.get_command_type()='UPDATE'
AND (:dml.get_value('NEW','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('OLD','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2)
AND (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2)
このルール条件に基づいて、行LCRが次のように評価されます。
更新の場合は、行LCRでregion_idの古い値と新しい値がどちらも2であれば、更新がそのまま適用されます。
更新の場合は、行LCRでregion_idの古い値または新しい値が2でないか、あるいはNULLであれば、その更新は更新ルールを満たしません。LCRは、挿入ルールを満たす場合、削除ルールを満たす場合、またはどちらのルールも満たさない場合があります。
削除ルールで使用されるルール条件を次に示します。
:dml.get_object_owner()='HR' AND :dml.get_object_name()='REGIONS'
AND :dml.is_null_tag()='Y' AND :dml.get_source_database_name()='DBS1.EXAMPLE.COM'
AND :dml.get_command_type() IN ('UPDATE','DELETE')
AND (:dml.get_value('OLD','"REGION_ID"') IS NOT NULL)
AND (:dml.get_value('OLD','"REGION_ID"').AccessNumber()=2)
AND (:dml.get_command_type()='DELETE'
OR ((:dml.get_value('NEW','"REGION_ID"') IS NOT NULL)
AND (((:dml.get_value('NEW','"REGION_ID"').AccessNumber() IS NOT NULL)
AND NOT (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2))
OR ((:dml.get_value('NEW','"REGION_ID"').AccessNumber() IS NULL)
AND NOT EXISTS (SELECT 1 FROM SYS.DUAL
WHERE (:dml.get_value('NEW','"REGION_ID"').AccessNumber()=2))))))
このルール条件に基づいて、行LCRが次のように評価されます。
削除の場合は、行LCRでregion_idの古い値が2であれば、削除が適用されます。
削除の場合は、行LCRでregion_idの古い値が2でないか、またはNULLであれば、削除が除外されます。
更新の場合は、行LCRでregion_idの古い値が2で、かつ、行LCRでregion_idの新しい値が2でないか、NULLであれば、更新が削除に変換されてから適用されます。この自動変換を行の移行といいます。詳細は、「行の移行およびサブセット・ルール」を参照してください。
これらのサブセット・ルールを使用した場合に適用プロセスによって適用される変更の例を次に示します。
region_idの古い値が4で、region_idの新しい値が2であるhr.regions表での行の更新。この更新は挿入に変換されます。
region_idの古い値が2で、region_idの新しい値が1である hr.regions表での行の更新。この更新は削除に変換されます。
適用プロセスによって、これらの変更を含む行LCRがその関連キューからデキューされ、宛先データベースのhr.regions表に適用されます。
これらのサブセット・ルールを使用した場合に適用プロセスによって無視される変更の例を次に示します。
hr.employees表への1行の挿入。hr.employees表の変更はサブセット・ルールを満たさないため、この変更は適用されません。
更新前のregion_idが1であり、更新後も1のままであるhr.regions表での行の更新。hr.regions表のサブセット・ルールはregion_idの新しい値または古い値（あるいはその両方）が2の場合にのみTRUEと評価されるため、この変更は適用されません。
|
注意: 取得プロセスでサポートされない表については、取得プロセスのポジティブ・ルール・セットにサブセット・ルールを追加しないでください。DBA_STREAMS_UNSUPPORTEDデータ・ディクショナリ・ビューを問い合せて、取得プロセスでサポートされない表を特定します。サポートされない表を除外しないと、取得エラーが発生します。
同期取得または適用プロセスのポジティブ・ルール・セットにサブセット・ルールを追加する場合は、サポートされない列の変更の処理がこれらのOracle Streamsクライアントによって試行されないようにしてください。サポートされない列が表に含まれる場合はルールベースの変換によって、また、適用プロセスの場合はDMLハンドラによってその列を除外できます。 |
サブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされる際に挿入操作または削除操作に変換されることがあります。この自動変換は行の移行と呼ばれ、サブセット・ルールのアクション・コンテキストで自動的に指定された内部変換によって実行されます。次の項では、取得、伝播、適用およびデキュー中の行の移行について説明します。
この項は次のトピックで構成されています。
|
注意: サブセット・ルールはポジティブ・ルール・セットにのみ存在する必要があります。ネガティブ・ルール・セットにはサブセット・ルールを追加しないでください。ネガティブ・ルール・セットで廃棄されないLCRでは行の移行が実行されないため、ネガティブ・ルール・セットにサブセット・ルールを追加すると、予期せぬ結果が発生する可能性があります。また、ネガティブ・ルール・セットでTRUEと評価されたために廃棄されるLCRでも、行の移行は実行されません。 |
サブセット・ルールが取得プロセスまたは同期取得のルール・セットに含まれる場合、そのサブセット・ルールを満たす更新は、取得時に挿入または削除に変換されることがあります。
たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を取得プロセスまたは同期取得で取得するよう指定する場合を考えます。ソース・データベースの表に、全部門の従業員レコードが含まれていると仮定します。DML操作によって従業員のdepartment_idが80から50に変更された場合、このサブセット・ルールによって更新操作が挿入操作に変換され、変更が取得されます。したがって、INSERTを含む行LCR がキューにエンキューされます。図6-2は、取得プロセスのサブセット・ルールが使用される場合のこの例を示しています。
同様に、取得される更新によって従業員のdepartment_idが50から20に変更される場合、このサブセット・ルールが指定された取得プロセスまたは同期取得では、更新操作がDELETE操作に変換されます。
サブセット・ルールが伝播のルール・セットに含まれる場合、更新操作は、行LCRの伝播時に挿入操作または削除操作に変換されることがあります。
たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を伝播によって伝播するよう指定する場合を考えます。伝播のソース・キューに、従業員のdepartment_idを50から80に変更するhr.employees表の更新操作を指定した行LCRが含まれる場合、このサブセット・ルールが指定されている伝播では更新操作が削除操作に変換され、行LCRが宛先キューに伝播されます。したがって、DELETEを含む行LCRが宛先キューにエンキューされます。図6-3はこの例を示しています。
同様に、取得される更新によって従業員のdepartment_idが80から50に変更される場合、このサブセット・ルールが指定された伝播では、更新操作がINSERT操作に変換されます。
サブセット・ルールが適用プロセスのルール・セットに含まれる場合は、行LCRの適用時に更新操作が挿入操作または削除操作に変換されることがあります。
たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を適用プロセスで適用するよう指定する場合を考えます。宛先データベースの表が、department_idが50の従業員のレコードのみを含むサブセット表であると仮定します。従業員のdepartment_idを80から50に変更する従業員の変更がソース・データベースで取得された場合、このサブセット・ルールが指定されている宛先データベースの適用プロセスによって、更新操作が挿入操作に変換されてこの変更が適用されます。この変換が必要なのは、その従業員の行が宛先の表に存在しないためです。図6-4はこの例を示しています。
同様に、取得される更新によって従業員のdepartment_idが50から20に変更される場合、このサブセット・ルールが指定された適用プロセスでは、更新操作がDELETE操作に変換されます。
サブセット・ルールがメッセージ・クライアントのルール・セットに含まれる場合は、行LCRのデキュー時に更新操作が挿入操作または削除操作に変換されることがあります。
たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更をメッセージ・クライアントでデキューするよう指定する場合を考えます。従業員のdepartment_idを50から90に変更するhr.employees表の更新操作を含む永続行LCRがメッセージ・クライアントのキューに含まれる場合、このサブセット・ルールが指定されているメッセージ・クライアントをユーザーまたはアプリケーションが起動したとき、メッセージ・クライアントによって更新操作が削除操作に変換され、行LCRがデキューされます。したがって、DELETEを含む行LCRがデキューされます。メッセージ・クライアントでは、カスタマイズされた任意の方法でこの行LCRを処理できます。たとえば、行LCRをカスタム・アプリケーションに送信できます。図6-5はこの例を示しています。
同様に、従業員のdepartment_idを90から50に変更する更新が永続行LCRに含まれる場合、このサブセット・ルールが指定されたメッセージ・クライアントでは、デキュー中にUPDATE操作がINSERT操作に変換されます。
次のタイプのサブセット・ルールを指定すると、サプリメンタル・ロギングが必要になります。
取得プロセスのサブセット・ルール
取得プロセスで取得されたLCRを伝播する伝播のサブセット・ルール
取得プロセスで取得されたLCRを適用する適用プロセスのサブセット・ルール
いずれの場合も、サブセット条件に含まれるすべての列と、これらの変更を適用する宛先データベースにある表のすべての列について、無条件のサプリメンタル・ログ・グループをソース・データベースに指定する必要があります。場合によっては、サブセット・ルールを指定すると、更新が挿入に変換されることがあり、このときに一部またはすべての列に補足情報が必要になることがあります。
たとえば、データベースdbs2.example.comでhr.locations表のpostal_code列に取得LCRを適用する適用プロセスにサブセット・ルールを指定する場合、この表に対する変更のソース・データベースがdbs1.example.comであれば、postal_code列だけでなくdbs2.example.comのhr.locations表に存在するすべての列について、dbs1.example.comでサプリメンタル・ロギングを指定します（postal_code列が宛先データベースの表に存在しない場合も、このように指定します）。
|
注意: サプリメンタル・ロギングが必要ないのは、サブセット・ルールが同期取得で使用されるときです。また、同期取得で取得されたLCRを処理する伝播や適用プロセスに関しても、サプリメンタル・ロギングは必要ありません。 |
次の各項では、サブセット・ルールを使用する際のガイドラインを示します。
取得される変更のすべての宛先データベースで、表のサブセット条件を満たす行変更のみが必要な場合は、取得プロセスまたは同期取得でサブセット・ルールを使用する必要があります。この場合、取得プロセスまたは同期取得によって、表に対するDML変更のサブセットが取得され、1つ以上の伝播によってこれらの変更が行LCRの形式で1つ以上の宛先データベースに伝播されます。各宛先データベースでは、適用プロセスによって、すべての行が取得プロセスのサブセット・ルールのサブセット条件を満たしているサブセット表にこれらの行LCRが適用されます。どの宛先データベースでも、表に対して行われるすべてのDML変更が必要なわけではありません。ローカル取得プロセスまたは同期取得のサブセット・ルールを使用すると、ソース・データベースが実行されているサイトで、行の移行を実行するために追加のオーバーヘッドが発生します。
環境内の一部の宛先で、取得されるDML変更のサブセットのみが必要な場合は、伝播または適用プロセスでサブセット・ルールを使用する必要があります。このような環境の例を次に示します。
表に対するDML変更が取得される宛先データベースのほとんどで、これらの変更の別のサブセットが必要な場合
表に対するDML変更のうち、ほとんどの宛先データベースでは取得されたすべての変更が必要だが、一部の宛先データベースではこれらの変更のサブセットのみが必要な場合
このような環境では、取得プロセスまたは同期取得によって表に対する変更をすべて取得する必要があります。ただし、伝播および適用プロセスでサブセット・ルールを使用すると、宛先データベースのサブセット表が、取得されたDML変更の正しいサブセットのみを適用できます。
このような環境で伝播にサブセット・ルールを使用することを決定する場合、次の点を考慮します。
ネットワークを介して伝播される行LCRの数が少ないため、ネットワーク通信量を削減できます。
伝播のソース・キューを含むサイトでは、行の移行を実行するためにオーバーヘッドが増加します。
このような環境で適用プロセスにサブセット・ルールを使用することを決定する場合、次の点を考慮します。
適用プロセスで使用されるキューには、サブセット表のすべての行LCRを含めることができます。有向ネットワーク環境で伝播を実行すると、適用プロセスによる行LCRの適用の有無に関係なく、必要に応じて表の行LCRを宛先キューに伝播できます。
適用プロセスが実行されているサイトでは、行の移行を実行するためにオーバーヘッドが増加します。
行の移行によって変換された行LCRが、適用プロセスによって適用される可能性がある場合は、宛先データベースの表を、各行がサブセット・ルールの条件に適合するサブセット表にすることをお薦めします。表がこのようなサブセット表でない場合、適用エラーが発生する可能性があります。
たとえば、取得プロセスのサブセット・ルールに、hr.employees表のDML変更に関してdepartment_id = 50という条件がある場合を考えます。この取得プロセスの宛先データベースのhr.employees表に、部門50だけでなく全部門の従業員の行が含まれていると、適用中に制約違反が発生する可能性があります。
ソース・データベースで、DML変更によってhr.employees表が更新され、employee_idが100である従業員のdepartment_idが90から50に変更されます。
サブセット・ルールを使用する取得プロセスが変更を取得し、更新を挿入に変換して、変更を行LCR として取得プロセスのキューにエンキューします。
伝播によって、行LCRが変更されずに宛先データベースに伝播されます。
適用プロセスでは、宛先データベースで挿入としての行LCRの適用が試行されますが、employee_idが100の従業員はすでにhr.employees表に存在するため、適用エラーが発生します。
この場合、宛先データベースの表がhr.employees表のサブセットで、department_idが50である従業員の行のみが含まれていれば、挿入は正常に適用されます。
同様に、行の移行によって変換された行LCRが適用プロセスで表に適用される可能性があり、ユーザーまたはアプリケーションによる表のDML操作を許可する場合は、すべてのDML変更がサブセット条件を満たすようにすることをお薦めします。表に対するローカル変更を許可すると、適用プロセスでは表のすべての行がサブセット条件を満たしていることを確認できません。たとえば、hr.employees表の条件がdepartment_id = 50であるとします。department_idが30である従業員の行をユーザーまたはアプリケーションが挿入した場合、この行は表に残り、適用プロセスでは削除されません。同様に、ユーザーまたはアプリケーションが行をローカルに更新してdepartment_idを30に変更した場合、この行も表に残ります。
ルールを使用して、LCR以外の特定のメッセージ・タイプのユーザー・メッセージのみに関連するOracle Streamsタスクを実行する場合は、メッセージ・ルールを指定します。メッセージ・ルールは、伝播、適用プロセスおよびメッセージ・クライアントに指定できます。
伝播の場合、ポジティブ・ルール・セットに1つのメッセージ・ルールを含めると、ソース・キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを伝播します。また、ネガティブ・ルール・セットに1つのメッセージ・ルールを含めると、ソース・キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを廃棄します。
適用プロセスの場合、ポジティブ・ルール・セットに1つのメッセージ・ルールを含めると、ルール条件を満たすメッセージ・タイプのユーザー・メッセージをデキューします。これらのユーザー・メッセージは適用プロセスのメッセージ・ハンドラに送信されます。また、ネガティブ・ルール・セットに1つのメッセージ・ルールを含めると、キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを廃棄します。
メッセージ・クライアントの場合、ポジティブ・ルール・セットに1つのメッセージ・ルールを含めると、ユーザーまたはアプリケーションはメッセージ・クライアントを使用して、ルール条件を満たすメッセージ・タイプのユーザー・メッセージをデキューできます。また、ネガティブ・ルール・セットに1つのメッセージ・ルールを含めると、キュー内のルール条件を満たすメッセージ・タイプのユーザー・メッセージを廃棄します。伝播および適用プロセスでは実行時にメッセージが自動的に伝播または適用されるのに対して、メッセージ・クライアントではメッセージは自動的にデキューまたは廃棄されません。メッセージをデキューまたは廃棄するためには、ユーザーまたはアプリケーションがメッセージ・クライアントを起動する必要があります。
DBMS_STREAMS_ADMパッケージのADD_MESSAGE_RULEプロシージャを使用して、Oracle Streamsクライアントの動作を次のように指示する場合を考えます。
前述の1つ目の指示はメッセージ・クライアントに関連し、2つ目の指示は適用プロセスに関連します。
これらの例では、次のようなメッセージに関するルールを作成します。
CREATE TYPE strmadmin.region_pri_msg AS OBJECT( region VARCHAR2(100), priority NUMBER, message VARCHAR2(3000)) /
ADD_MESSAGE_RULEプロシージャを実行して、region_pri_msgタイプのメッセージに対するルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_MESSAGE_RULE (
message_type => 'strmadmin.region_pri_msg',
rule_condition => ':msg.region = ''EUROPE'' AND ' ||
':msg.priority = ''1'' ',
streams_type => 'dequeue',
streams_name => 'msg_client',
queue_name => 'streams_queue',
inclusion_rule => TRUE);
END;
/
streams_typeパラメータにdequeueが指定されていることに注意してください。つまり、msg_clientという名前のメッセージ・クライアントが存在しなければ、このプロシージャによって作成されます。このメッセージ・クライアントがすでに存在する場合は、このプロシージャによってメッセージ・ルールがそのルール・セットに追加されます。また、inclusion_ruleパラメータがTRUEに設定されていることにも注意してください。この設定によって、システム作成ルールがメッセージ・クライアントのポジティブ・ルール・セットに追加されます。このプロシージャを実行するユーザーには、メッセージ・クライアントを使用してキューからデキューする権限が付与されます。
ADD_MESSAGE_RULEプロシージャによって、次のようなルール条件のあるルールが作成されます。
:"VAR$_52".region = 'EUROPE' AND :"VAR$_52".priority = '1'
ルール条件内のVAR$で始まる変数は、ルールのシステム生成評価コンテキストで指定される変数です。
ADD_MESSAGE_RULEプロシージャを実行して、region_pri_msgタイプのメッセージに対するルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_MESSAGE_RULE (
message_type => 'strmadmin.region_pri_msg',
rule_condition => ':msg.region = ''AMERICAS'' AND ' ||
':msg.priority = ''2'' ',
streams_type => 'apply',
streams_name => 'apply_msg',
queue_name => 'streams_queue',
inclusion_rule => TRUE);
END;
/
streams_typeパラメータにapplyが指定されていることに注意してください。つまり、apply_msgという名前の適用プロセスが存在しなければ、このプロシージャによって作成されます。この適用プロセスがすでに存在する場合は、このプロシージャによってメッセージ・ルールがそのルール・セットに追加されます。また、inclusion_ruleパラメータがTRUEに設定されていることにも注意してください。この設定によって、システム作成ルールがメッセージ・クライアントのポジティブ・ルール・セットに追加されます。
ADD_MESSAGE_RULEプロシージャによって、次のようなルール条件のあるルールが作成されます。
:"VAR$_56".region = 'AMERICAS' AND :"VAR$_56".priority = '2'
ルール条件内のVAR$で始まる変数は、ルールのシステム生成評価コンテキストで指定される変数です。
この例では、次のメッセージ・ルールが定義されています。
メッセージの地域がEUROPE、優先度が1の場合にTRUEと評価される、msg_clientという名前のメッセージ・クライアントのメッセージ・ルール。このルールが指定されている場合、ユーザーまたはアプリケーションはこのメッセージ・クライアントを使用して、ルール条件を満たすregion_pri_msgタイプのメッセージをデキューできます。
メッセージの地域がAMERICAS、優先度が2の場合にTRUEと評価される、apply_msgという名前の適用プロセスのメッセージ・ルール。このルールが指定されている場合、ルール条件を満たすregion_pri_msgタイプのメッセージが適用プロセスによってデキューされ、これらのメッセージがメッセージ・ハンドラに送信されるか、指定されたキューに再エンキューされます。
システム作成ルールをネガティブ・ルール・セットに追加すると、ルールを満たす変更に対してOracle Streamsクライアントがタスクを実行しないように指定することになります。システム作成ルールがネガティブ・ルール・セットに含まれる場合、各タイプのOracle Streamsクライアントは具体的には次のように動作します。
取得プロセスは、ルールを満たす変更を廃棄します。
メッセージ・クライアントは、ルールを満たすキュー内のメッセージを廃棄します。
Oracle Streamsクライアントにネガティブ・ルール・セットが存在する場合、次のいずれかのプロシージャを実行してinclusion_ruleパラメータをFALSEに設定すると、ネガティブ・ルール・セットを作成してルールを追加できます。
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
DBMS_STREAMS_ADM.ADD_MESSAGE_RULE
DBMS_STREAMS_ADM.ADD_TABLE_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_PROPAGATION_RULES
DBMS_STREAMS_ADM.ADD_MESSAGE_PROPAGATION_RULE
Oracle Streamsクライアントにすでにネガティブ・ルール・セットが存在している場合に、このいずれかのプロシージャを実行すると、プロシージャによってシステム作成ルールが既存のネガティブ・ルール・セットに追加されます。
また、次のいずれかのプロシージャを実行してnegative_rule_set_nameパラメータにNULL以外の値を指定すると、Oracle Streamsクライアントの作成時にネガティブ・ルール・セットを作成することもできます。
DBMS_CAPTURE_ADM.CREATE_CAPTURE
DBMS_PROPAGATION_ADM.CREATE_PROPAGATION
DBMS_APPLY_ADM.CREATE_APPLY
また、クライアントを変更することで、既存のOracle Streamsクライアントにネガティブ・ルール・セットを指定することもできます。たとえば、既存の取得プロセスにネガティブ・ルール・セットを指定するには、DBMS_CAPTURE_ADM.ALTER_CAPTUREプロシージャを使用します。Oracle Streamsクライアントにネガティブ・ルール・セットを指定した後、前述のDBMS_STREAM_ADMパッケージのプロシージャを使用して、ネガティブ・ルール・セットにシステム作成ルールを追加できます。
ネガティブ・ルール・セットにルールを追加するかわりに、次のように、特定の表またはスキーマに対する変更を除外することもできます。
該当する表またはスキーマのシステム作成ルールを、Oracle Streamsクライアントのポジティブ・ルール・セットに追加しないようにします。たとえば、特定のスキーマに存在する1つの表を除くすべての表に対するDML変更を取得するには、除外する表以外のスキーマの各表に対するDML表ルールを、取得プロセスのポジティブ・ルール・セットに追加します。この方法のデメリットは、スキーマに多くの表が存在する場合にも各表に個別のDMLルールが必要であるという点です。また、スキーマに新規の表を追加して、その表に対する変更を取得する場合は、この表のための新規DMLルールを取得プロセスのポジティブ・ルール・セットに追加する必要があります。
Oracle Streamsクライアントのポジティブ・ルール・セットに複合ルールを追加し、そのルール条件でNOT論理条件を使用します。たとえば、特定のスキーマに存在する1つの表を除くすべての表に対するDML変更を取得するには、DBMS_STREAMS_ADM.ADD_SCHEMA_RULESプロシージャを使用して、そのスキーマに対する変更を取得するように取得プロセスに指示するシステム作成DMLスキーマ・ルールを取得プロセスのポジティブ・ルール・セットに追加し、and_conditionパラメータを使用して、該当の表をNOT論理条件で除外します。この方法のデメリットは、ルール条件の一部を手動で指定するため、ミスが発生する可能性があるという点です。また、変更を加えないシステム作成ルールに比べて、複合ルールに対するルール評価は効率的に実行できません。
特定のスキーマに存在する1つの表を除くすべての表に対するDML変更を取得する場合は、取得プロセスのポジティブ・ルール・セットにDMLスキーマ・ルールを追加し、除外する表に対するDML表ルールをネガティブ・ルール・セットに追加できます。
この方法には、前述した方法と比べると次のようなメリットがあります。
2つのルールを追加するだけで目標を達成できます。
スキーマに新規の表を追加して、その表に対するDML変更を取得する場合も、既存のルールの変更または新規ルールの追加を行わずに、取得プロセスによってこれらの変更を取得できます。
ルール条件を手動で指定または編集する必要がありません。
複合ルールを使用しないため、ルール評価をより効率的に実行できます。
job_history表を除き、hrスキーマ内のすべての表に対するDML変更の結果を含む行LCRを適用する場合を考えます。これを行うには、DBMS_STREAMS_ADMパッケージのADD_SCHEMA_RULESプロシージャを使用して、hrスキーマ内の表に対するDML変更の結果を含む行LCRを適用するように、Oracle Streamsの適用プロセスに指示します。この場合、プロシージャによってスキーマ・ルールが作成され、適用プロセスのポジティブ・ルール・セットに追加されます。
DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESプロシージャを使用すると、表に対するDML変更の結果を含む行LCRをhr.job_history表では廃棄するように、Oracle Streamsに指示できます。この場合、プロシージャによって表ルールが作成され、適用プロセスのネガティブ・ルール・セットに追加されます。
次の各項では、これらのプロシージャの実行方法について説明します。
これらの変更がdbs1.example.comソース・データベースで発生しました。
ADD_SCHEMA_RULESプロシージャを実行して次のルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(
schema_name => 'hr',
streams_type => 'apply',
streams_name => 'apply',
queue_name => 'streams_queue',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => FALSE,
source_database => 'dbs1.example.com',
inclusion_rule => TRUE);
END;
/
inclusion_ruleパラメータがTRUEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのポジティブ・ルール・セットに追加されます。
ADD_SCHEMA_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。
((:dml.get_object_owner() = 'HR') and :dml.is_null_tag() = 'Y' and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )
これらの変更がdbs1.example.comソース・データベースで発生しました。
ADD_TABLE_RULESプロシージャを実行して次のルールを作成します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.job_history',
streams_type => 'apply',
streams_name => 'apply',
queue_name => 'streams_queue',
include_dml => TRUE,
include_ddl => FALSE,
include_tagged_lcr => TRUE,
source_database => 'dbs1.example.com',
inclusion_rule => FALSE);
END;
/
inclusion_ruleパラメータがFALSEに設定されていることに注意してください。この設定によって、システム作成ルールが適用プロセスのネガティブ・ルール・セットに追加されます。
また、include_tagged_lcrパラメータがTRUEに設定されていることにも注意してください。この設定によって、表に対するすべての変更（他のすべてのルール条件を満たすタグ付きLCRを含む）が廃棄されます。ほとんどの場合、inclusion_ruleパラメータがFALSEに設定されているときは、include_tagged_lcrパラメータにTRUEを指定します。
ADD_TABLE_RULESプロシージャによって、次のようなルール条件のあるルールが作成されます。
(((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'JOB_HISTORY')) and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' )
この例では、次のルールが定義されています。
hrスキーマの表に対してDML操作が実行された場合にTRUEと評価されるスキーマ・ルール。このルールは適用プロセスのポジティブ・ルール・セットに含まれます。
hr.job_history表に対してDML操作が実行された場合にTRUEと評価される表ルール。このルールは適用プロセスのネガティブ・ルール・セットに含まれます。
これらのルールを使用した場合に適用プロセスによって適用される変更の例を次に示します。
hr.departments表への1行の挿入
hr.employees表内の5行の更新
hr.countries表からの1行の削除
適用プロセスによって、これらの変更がその関連キューからデキューされ、宛先データベースのデータベース・オブジェクトに適用されます。
これらのルールを使用した場合に適用プロセスによって無視される変更の例を次に示します。
hr.job_history表への1行の挿入
hr.job_history表内の1行の更新
hr.job_history表からの1行の削除
これらの変更は、適用プロセスのネガティブ・ルール・セットのルールを満たすため適用されません。
DBMS_STREAMS_ADMパッケージのプロシージャには、and_conditionパラメータを使用してルールを作成するものがあります。このパラメータを使用すると、システム作成ルールに条件を追加できます。and_conditionパラメータによって指定される条件は、次のようにAND句を使用してシステム作成ルール条件に追加されます。
(system_condition) AND (and_condition)
指定する条件内の変数は:lcrである必要があります。たとえば、表がhr.departments、ソース・データベースがdbs1.example.com、Oracle Streamsタグが02に等しい16進数の場合にのみ、ADD_TABLE_RULESプロシージャによって生成される表ルールがTRUEと評価されるよう指定するには、次のプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'hr.departments',
streams_type => 'apply',
streams_name => 'apply_02',
queue_name => 'streams_queue',
include_dml => TRUE,
include_ddl => TRUE,
include_tagged_lcr => TRUE,
source_database => 'dbs1.example.com',
inclusion_rule => TRUE,
and_condition => ':lcr.get_tag() = HEXTORAW(''02'')');
END;
/
ADD_TABLE_RULESプロシージャによって、次の条件のあるDMLルールが作成されます。
(((((:dml.get_object_owner() = 'HR' and :dml.get_object_name() = 'DEPARTMENTS'))
and :dml.get_source_database_name() = 'DBS1.EXAMPLE.COM' ))
and (:dml.get_tag() = HEXTORAW('02')))
次の条件のあるDDLルールが作成されます。
(((((:ddl.get_object_owner() = 'HR' and :ddl.get_object_name() = 'DEPARTMENTS')
or (:ddl.get_base_table_owner() = 'HR'
and :ddl.get_base_table_name() = 'DEPARTMENTS'))
and :ddl.get_source_database_name() = 'DBS1.EXAMPLE.COM' ))
and (:ddl.get_tag() = HEXTORAW('02')))
指定された条件の:lcrが、生成されるルールに応じて:dmlまたは:ddlに変換されることに注意してください。LCRタイプ（行またはDDL）に依存するLCRメンバー・サブプログラムを指定する場合は、このプロシージャによって適切なルールのみが作成されることを確認します。特に、行LCRに対してのみ有効なLCRメンバー・サブプログラムを指定する場合は、include_dmlパラメータにTRUE、include_ddlパラメータにFALSEを指定します。DDL LCRのみに対して有効なLCRメンバー・サブプログラムを指定する場合は、include_dmlパラメータにFALSE、include_ddlパラメータにTRUEを指定します。
たとえば、GET_OBJECT_TYPEメンバー・ファンクションはDDL LCRのみに適用されます。したがって、and_conditionでこのメンバー・ファンクションを使用する場合は、include_dmlパラメータにFALSE、include_ddlパラメータにTRUEを指定します。
|
関連項目:
|
次の各項では、Oracle Streamsで使用されるシステム作成の評価コンテキストについて説明します。
グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールを作成する際、システム作成のルール・セットおよびルールでは、SYSスキーマ内のSTREAMS$_EVALUATION_CONTEXTという名前の組込み評価コンテキストが使用されます。この評価コンテキストのEXECUTE権限はPUBLICに付与されます。グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールは、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。
Oracleのインストール中に、次の文によってOracle Streamsの評価コンテキストが作成されます。
DECLARE
vt SYS.RE$VARIABLE_TYPE_LIST;
BEGIN
vt := SYS.RE$VARIABLE_TYPE_LIST(
SYS.RE$VARIABLE_TYPE('DML', 'SYS.LCR$_ROW_RECORD',
'SYS.DBMS_STREAMS_INTERNAL.ROW_VARIABLE_VALUE_FUNCTION',
'SYS.DBMS_STREAMS_INTERNAL.ROW_FAST_EVALUATION_FUNCTION'),
SYS.RE$VARIABLE_TYPE('DDL', 'SYS.LCR$_DDL_RECORD',
'SYS.DBMS_STREAMS_INTERNAL.DDL_VARIABLE_VALUE_FUNCTION',
'SYS.DBMS_STREAMS_INTERNAL.DDL_FAST_EVALUATION_FUNCTION'));
SYS.RE$VARIABLE_TYPE(NULL, 'SYS.ANYDATA',
NULL,
'SYS.DBMS_STREAMS_INTERNAL.ANYDATA_FAST_EVAL_FUNCTION'));
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT(
evaluation_context_name => 'SYS.STREAMS$_EVALUATION_CONTEXT',
variable_types => vt,
evaluation_function =>
'SYS.DBMS_STREAMS_INTERNAL.EVALUATION_CONTEXT_FUNCTION');
END;
/
この文には、SYS.DBMS_STREAM_INTERNALパッケージ内の次の内部ファンクションへの参照が含まれます。
ROW_VARIABLE_VALUE_FUNCTION
DDL_VARIABLE_VALUE_FUNCTION
EVALUATION_CONTEXT_FUNCTION
ROW_FAST_EVALUATION_FUNCTION
DDL_FAST_EVALUATION_FUNCTION
ANYDATA_FAST_EVAL_FUNCTION
|
注意: 前述の内部ファンクションに関する情報は、あくまでも参考用です。これらのファンクションは直接実行しないでください。 |
ROW_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_ROW_RECORDインスタンスをカプセル化するANYDATAペイロードがSYS.LCR$_ROW_RECORDインスタンスに変換されてから、データに対するルールが評価されます。
DDL_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_DDL_RECORDインスタンスをカプセル化するANYDATAペイロードがSYS.LCR$_DDL_RECORDインスタンスに変換されてから、データに対するルールが評価されます。
EVALUATION_CONTEXT_FUNCTIONは、CREATE_EVALUATION_CONTEXTプロシージャのコールでevaluation_functionとして指定されます。このファンションによって、取得LCRに対する通常のルール評価が補足されます。取得プロセスによって行LCRとDDL LCRがそのキューにエンキューされ、このファンクションによってコミット、ロールバック、データ・ディクショナリの変更などの他の内部メッセージをキューにエンキューできます。取得プロセスによってエンキューされる情報は、伝播または適用プロセスのルール評価中にも使用されます。同期取得ではEVALUATION_CONTEXT_FUNCTIONは使用されません。
ROW_FAST_EVALUATION_FUNCTIONでは、ルール評価中に次のLCR$_ROW_RECORDメンバー・ファンクションへのアクセスを最適化することで、パフォーマンスが改善されます。
GET_OBJECT_OWNER
GET_OBJECT_NAME
IS_NULL_TAG
GET_SOURCE_DATABASE_NAME
GET_COMMAND_TYPE
DDL_FAST_EVALUATION_FUNCTIONでは、条件が<、<=、=、>=または>であり、残りのオペランドが定数である場合は、ルール評価中に次のLCR$_DDL_RECORDメンバー・ファンクションへのアクセスを最適化することで、パフォーマンスが改善されます。
GET_OBJECT_OWNER
GET_OBJECT_NAME
IS_NULL_TAG
GET_SOURCE_DATABASE_NAME
GET_COMMAND_TYPE
GET_BASE_TABLE_NAME
GET_BASE_TABLE_OWNER
ANYDATA_FAST_EVAL_FUNCTIONでは、ANYDATAオブジェクト内の値へのアクセスを最適化することで、パフォーマンスが改善されます。
DBMS_STREAMS_ADMパッケージを使用して作成されたルールでは、ADD_SUBSET_RULESまたはADD_SUBSET_PROPAGATION_RULESプロシージャを使用して作成されたサブセット・ルールを除き、ROW_FAST_EVALUATION_FUNCTIONまたはDDL_FAST_EVALUATION_FUNCTIONが使用されます。
|
関連項目:
|
ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャを使用してメッセージ・ルールを作成する場合、メッセージ・ルールでは作成時に指定したユーザー定義のメッセージ・タイプが使用されます。このようなシステム作成メッセージ・ルールでは、システム作成評価コンテキストが使用されます。システム作成評価コンテキスト名は、メッセージ・ルールの作成に使用されるメッセージ・タイプごとに異なります。このような評価コンテキストにはシステム生成名が付けられ、ルールを所有するスキーマに作成されます。この評価コンテキストのEXECUTE権限は、この評価コンテキストを所有するユーザーにのみ付与されます。
このタイプのメッセージ・ルールの評価コンテキストには、メッセージ・タイプと同じタイプの変数が含まれます。この変数の名前はVAR$_numberという形式になります（numberはシステム生成番号）。たとえば、メッセージ・ルールの作成時にstrmadmin.region_pri_msgをメッセージ・タイプとして指定すると、システム作成評価コンテキストにこのタイプの変数が組み込まれ、変数がルール条件で使用されます。次の文によってstrmadmin.region_pri_msgタイプを作成したと想定します。
CREATE TYPE strmadmin.region_pri_msg AS OBJECT( region VARCHAR2(100), priority NUMBER, message VARCHAR2(3000)) /
このタイプを使用してメッセージ・ルールを作成すると、次のルール条件を指定できます。
:msg.region = 'EUROPE' AND :msg.priority = '1'
システム作成メッセージ・ルールでは、指定したルール条件の:msgが変数名で置換されます。置換されたメッセージ・ルール条件の例を次に示します。
:VAR$_52.region = 'EUROPE' AND :VAR$_52.priority = '1'
この場合、VAR$_52が変数名、変数VAR$_52のタイプがstrmadmin.region_pri_msgであり、ルールの評価コンテキストにこの変数が含まれます。
メッセージ・ルールそのものに評価コンテキストが含まれます。次のような文によってメッセージ・ルールの評価コンテキストが作成されます。
DECLARE
vt SYS.RE$VARIABLE_TYPE_LIST;
BEGIN
vt := SYS.RE$VARIABLE_TYPE_LIST(
SYS.RE$VARIABLE_TYPE('VAR$_52', 'STRMADMIN.REGION_PRI_MSG',
'SYS.DBMS_STREAMS_INTERNAL.MSG_VARIABLE_VALUE_FUNCTION', NULL));
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT(
evaluation_context_name => 'STRMADMIN.EVAL_CTX$_99',
variable_types => vt,
evaluation_function => NULL);
END;
/
評価コンテキストの名前はEVAL_CTX$_numberという形式になります（numberはシステム生成番号）。この例では、評価コンテキスト名はEVAL_CTX$_99になります。
この文には、SYS.DBMS_STREAM_INTERNALパッケージのMSG_VARIABLE_VALUE_FUNCTION内部ファンクションへの参照も含まれています。このファンクションでは、メッセージ・インスタンスをカプセル化するANYDATAペイロードが変数と同じタイプのインスタンスに変換された後、データに対するルールが評価されます。たとえば、変数のタイプがstrmadmin.region_pri_msgである場合、MSG_VARIABLE_VALUE_FUNCTIONでは、メッセージ・ペイロードがANYDATAペイロードからstrmadmin.region_pri_msgペイロードに変換されます。
様々なメッセージ・タイプについてルールを作成する場合、Oracleでは、それぞれのメッセージ・タイプに対して異なる評価コンテキストが作成されます。既存のルールと同じメッセージ・タイプの新規ルールを作成する場合、新規ルールでは既存のルールの評価コンテキストが使用されます。ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEによってメッセージ・クライアントまたは適用プロセスのルール・セットを作成する場合は、新規のルール・セットには評価コンテキストが含まれません。
Oracle Streamsで、取得プロセス、同期取得およびメッセージ・クライアントではイベント・コンテキストは使用されませんが、伝播および適用プロセスでは使用されます。取得LCR、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージの各タイプのメッセージを、キュー内でステージングできます。メッセージがキュー内でステージングされると、伝播または適用プロセスでは、メッセージとイベント・コンテキストを評価するためにルール・エンジンに送信できます。イベント・コンテキストには常に、AQ$_MESSAGEを名前、メッセージを値とする名前/値ペアがあります。
カスタム評価コンテキストを作成する場合は、暗黙的変数を使用して、Oracle Streamsイベントを参照する伝播および適用プロセスのルールを作成できます。各暗黙的変数の変数値ファンクションでは、AQ$_MESSAGEという名前のイベント・コンテキストをチェックできます。この名前のイベント・コンテキストが検出されると、変数値ファンクションによってメッセージに基づく値が返されます。イベント・コンテキストは、評価ファンクションおよび変数メソッド・ファンクションにも渡すことができます。
次の各項では、Oracle Streamsにおけるアクション・コンテキストの用途と、特定のルール条件についてTRUEと評価できるルールがルール・セット内に1つのみであることの重要性について説明します。
Oracle Streamsにおけるアクション・コンテキストの用途は、次のとおりです。
それぞれの用途に対し、ルールのアクション・コンテキストには異なる名前/値ペアが存在する場合があります。ルールのアクション・コンテキストに複数の名前/値ペアが含まれる場合、名前/値ペアで指定または記述されたアクションは、次の順序で実行されます。
サブセットの変換が実行されます。
宣言ルールベースの変換に関する情報が表示されます。
カスタム・ルールベースの変換が実行されます。
実行ディレクティブに従います。指示があれば、その指示が実行されます（適用のみ）。
宛先キューにエンキューされます（適用のみ）。
|
注意: ルールのアクション・コンテキストで指定されたアクションは、そのルールが取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのポジティブ・ルール・セットに含まれる場合にのみ実行されます。ルールがネガティブ・ルール・セットに含まれる場合、そのルールのアクション・コンテキストはこれらのOracle Streamsクライアントによって無視されます。 |
サブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされる際に挿入操作または削除操作に変換されることがあります。この自動変換は行の移行と呼ばれ、サブセット・ルールがTRUEと評価された場合に、アクション・コンテキストで指定された内部変換によって実行されます。サブセット変換の名前/値ペアでは、名前はSTREAMS$_ROW_SUBSET、値はINSERTまたはDELETEとなります。
宣言ルールベースの変換は、ルールがTRUEと評価された結果発生する行LCRの内部変更です。宣言ルールベースの変換の名前/値ペアでは、名前はSTREAMS$_INTERNAL_TRANFORM、値は変換に関する追加情報を提供するデータ・ディクショナリ・ビューの名前となります。
宣言ルールベースの変換に追加される名前/値ペアは、あくまでも参考用です。これらの名前/値ペアは、Oracle Streamsクライアントによって使用されません。ただし、アクション・コンテキストに記述された宣言ルールベースの変換は、同じアクション・コンテキストに指定されたどのカスタム・ルールベースの変換よりも前に内部的に実行されます。
カスタム・ルールベースの変換は、ルールがTRUEと評価された場合に発生する、ユーザー定義ファンクションによるメッセージの変更です。カスタム・ルールベースの変換の名前/値ペアでは、名前はSTREAMS$_TRANSFORM_FUNCTION、値は変換ファンクションの名前となります。
DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャでは、指定されたルールを満たすメッセージが適用プロセスで実行されるかどうかが指定されます。適用プロセスでメッセージを実行しない場合、実行ディレクティブの名前/値ペアでは、名前はAPPLY$_EXECUTE、値はNOとなります。ルールを満たすメッセージを適用プロセスで実行する場合は、そのルールのアクション・コンテキストにこの名前/値ペアを含めません。
DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャでは、指定されたルールを満たすメッセージが適用プロセスによって自動的にエンキューされるキューが設定されます。エンキューの宛先の名前/値ペアでは、名前はAPPLY$_ENQUEUE、値は宛先キューの名前となります。
ポジティブ・ルール・セット内の1つ以上のルールにNULL以外のアクション・コンテキストを使用する場合は、特定のルール条件についてTRUEと評価できるルールが1つのみであることを確認してください。特定の条件について複数のルールがTRUEと評価された場合も、返されるルールは1つのみであるため、予測できない結果が発生する可能性があります。
たとえば、hr.employees表に対するDML変更がLCRに含まれている場合に2つのルールがTRUEと評価されるとします。最初のルールにはNULLのアクション・コンテキストがあります。2つ目のルールには、カスタム・ルールベースの変換を指定するアクション・コンテキストがあります。hr.employees表に対するDML変更が存在する場合、両方のルールが変更についてTRUEと評価されますが、返されるルールは1つのみです。この場合、どちらのルールが返されるかに応じて、変換が行われる場合と行われない場合があります。
いずれかのルールにNULL以外のアクション・コンテキストがあるかどうかに関係なく、TRUEと評価できるルールがどの条件についてもポジティブ・ルール・セット内で1つのみになるようにする必要があります。このガイドラインに従うと、NULL以外のアクション・コンテキストが将来ルールに追加された場合などでも、予測できない結果を回避できます。
スキーマ・ルールまたはグローバル・ルールに、カスタム・ルールベースの変換、エンキューの宛先、または実行ディレクティブのアクション・コンテキストを使用すると、そのアクション・コンテキストで指定されたアクションは、メッセージによってスキーマ・ルールまたはグローバル・ルールがTRUEと評価された場合に、メッセージに対して実行されます。たとえば、スキーマ・ルールにカスタム・ルールベースの変換を指定するアクション・コンテキストがある場合、スキーマ内の表のLCRに対して変換が実行されます。
スキーマ・ルールまたはグローバル・ルールにアクション・コンテキストを使用するが、アクション・コンテキストによって実行されるアクションからLCRのサブセットを除外する場合があります。たとえば、hrスキーマ内のjob_history表を除くすべての表に対してカスタム・ルールベースの変換を実行する場合は、表がjob_historyである場合に変換ファンクションによって元のLCRが返されるようにします。
hrスキーマ内のjob_history表を除くすべての表に対してエンキューの宛先または実行ディレクティブを設定する場合は、スキーマ・ルールを使用して、次の条件を追加できます。
:dml.get_object_name() != 'JOB_HISTORY'
この場合、job_history表のLCRがTRUEと評価されても、エンキューまたは実行ディレクティブが実行されないようにするために、この表の表ルールをポジティブ・ルール・セットに追加できます。つまり、スキーマ・ルールにはエンキューの宛先または実行ディレクティブが含まれますが、表ルールにはそれらが含まれません。
DBMS_STREAMS_ADMパッケージでは、システム作成のルールおよびルール・セットが生成されます。また、Oracleが提供する評価コンテキストがルールおよびルール・セットに対して指定されるか、システム作成評価コンテキストが生成されます。DBMS_STREAMS_ADMパッケージを使用して作成できないルール、ルール・セットまたは評価コンテキストを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用してそれらを作成できます。
次のような場合に、DBMS_RULE_ADMパッケージを使用します。
特定タイプの操作のルール条件や、LIKE条件を使用するルール条件など、DBMS_STREAMS_ADMパッケージでは作成できないルール条件のあるルールを作成する必要がある場合。
Oracle Streams環境でルールのカスタム評価コンテキストを作成する必要がある場合。
DBMS_RULE_ADMパッケージを使用してルール・セットを作成し、それを取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントに関連付けることができます。このようなルール・セットは、Oracle Streamsクライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットとして使用でき、1つのルール・セットを1つのOracle Streamsクライアントのポジティブ・ルール・セットおよび別のOracle Streamsクライアントのネガティブ・ルール・セットとして使用することもできます。
この項は次のトピックで構成されています。
次の各項では、DBMS_RULE_ADMパッケージを使用して作成できる一部のタイプのルールおよびルール・セットについて説明します。
|
注意: DBMS_STREAMS_ADMパッケージの一部のプロシージャで使用可能なand_conditionパラメータを使用して、ユーザー定義条件をシステム作成ルールに追加できます。and_conditionパラメータを使用する方が、DBMS_RULE_ADMパッケージでルールを作成するよりも簡単な場合があります。 |
特定タイプの操作を含む変更のみの取得、伝播、適用またはデキューが必要になることがあります。たとえば、特定の表に対する挿入操作のみが含まれ、更新や削除などの他の操作が含まれない変更の適用が必要な場合があります。
hr.employees表に対するINSERT操作についてのみTRUEと評価されるルール条件を指定する場合を考えます。そのためには、ルール条件でINSERTコマンド・タイプを指定します。
:dml.get_command_type() = 'INSERT' AND :dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'EMPLOYEES' AND :dml.is_null_tag() = 'Y'
同様に、DELETE操作を除き、hr.departments表に対するすべてのDML操作についてTRUEと評価されるルール条件を指定する場合を考えます。そのためには、次のルール条件を指定します。
:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS' AND :dml.is_null_tag() = 'Y' AND (:dml.get_command_type() = 'INSERT' OR :dml.get_command_type() = 'UPDATE')
このルール条件は、DELETE操作を除き、hr.departments表に対するINSERTおよびUPDATE操作についてはTRUEと評価されます。hr.departments表にはLOB列が含まれていないため、DML操作のLOBコマンド・タイプ（LOB ERASE、LOB WRITEおよびLOB TRIM）を指定する必要はありませんが、1つ以上のLOB列を含む表のルール条件ではこれらのコマンド・タイプを指定する必要があります。
次のルール条件では、hr.departments表に対して同じ動作が実行されます。つまり、次のルール条件では、DELETE操作を除き、hr.departments表に対するすべてのDML操作についてTRUEと評価されます。
:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS' AND :dml.is_null_tag() = 'Y' AND :dml.get_command_type() != 'DELETE'
この項で前述した例のルール条件は、すべて単純ルール条件です。ただし、システム作成ルール条件にカスタム条件を追加すると、条件全体が単純ルール条件でなくなる可能性があり、単純ルールでないルールは効率的に評価されないことがあります。通常は、ルール評価のパフォーマンスを改善するために、可能なかぎり単純ルール条件を使用する必要があります。DBMS_STREAMS_ADMパッケージを使用して作成され、カスタム条件が追加されていないルール条件は常に単純です。
ルール条件で次のファンクションを使用して、サポートされていない変更をカプセル化するLCRを廃棄するようにOracle Streamsクライアントに指示できます。
LCR用のGET_COMPATIBLEメンバー・ファンクション。このファンクションでは、LCRのサポートに必要なデータベースの最小互換レベルが返されます。
DBMS_STREAMSパッケージのCOMPATIBLE_9_2ファンクション、COMPATIBLE_10_1ファンクション、COMPATIBLE_10_2ファンクションおよびCOMPATIBLE_11_1ファンクション。これらのファンクションでは、それぞれデータベースの互換レベル9.2.0、10.1.0、10.2.0および11.1.0に対応する定数の値が返されます。Oracle Databaseの互換性は、COMPATIBLE初期化パラメータを使用して制御します。
たとえば、次のルールを考えてみます。
BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_9_2',
condition => ':dml.GET_COMPATIBLE() > DBMS_STREAMS.COMPATIBLE_9_2()');
END;
/
このルールが取得プロセス、伝播、適用プロセスなどのOracle Streamsクライアントのネガティブ・ルール・セットに含まれる場合は、Oracle9i Database リリース2（9.2）と互換性のない行LCRがOracle Streamsによって廃棄されます。
ポジティブ・ルール・セットの場合のより適切な例を次に示します。
BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_9_2',
condition => ':dml.GET_COMPATIBLE() <= DBMS_STREAMS.COMPATIBLE_10_1()');
END;
/
このルールがOracle Streamsクライアントのポジティブ・ルール・セットに含まれる場合、Oracle Database 10g リリース1以下と互換性のない行LCRがOracle Streamsクライアントによって廃棄されます。つまり、Oracle9i Database リリース2（9.2）またはOracle Database 10g リリース1（10.1）と互換性があり、ルール・セットのその他のルールを満たす行LCRはOracle Streamsクライアントによって処理されますが、これらのリリースと互換性のない行LCRは廃棄されます。
前述の例のルールは、どちらも効率的に評価されます。DBMS_STREAMS_ADMパッケージによって作成されたスキーマ・ルールまたはグローバル・ルールを使用してLCRを取得、伝播、適用またはデキューする場合は、これらのルールを使用して、特定のデータベースでサポートされていないLCRを廃棄できます。
|
注意:
|
|
関連項目:
|
複合ルール条件とは、「単純ルール条件」で説明した単純ルール条件の要件を満たしていないルール条件です。Oracle Streams環境では、DBMS_STREAMS_ADMパッケージによって作成されるルールには単純ルール条件のみが含まれ、システム作成ルールにはカスタム条件が追加されていないことが想定されます。
DBMS_STREAMS_ADMパッケージで作成できる各タイプのシステム作成ルール条件については、表6-3を参照してください。複合条件のあるルールを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用できます。
様々な複合ルール条件があります。次の各項では、複合ルール条件の例をいくつか示します。
|
注意:
|
NOT論理条件を使用すると、Oracle Streams環境で特定の変更を取得、伝播、適用またはデキューから除外できます。
たとえば、hr.regions表の変更を除き、hrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML変更およびDDL変更についてTRUEと評価されるルール条件を指定する必要があるとします。NOT論理条件を使用すると、DML変更用に1つとDDL変更用に1つ、合計2つのルールを使用して、このルール条件を指定できます。これらのルールのルール条件を次に示します。
(:dml.get_object_owner() = 'HR' AND NOT :dml.get_object_name() = 'REGIONS') AND :dml.is_null_tag() = 'Y' ((:ddl.get_object_owner() = 'HR' OR :ddl.get_base_ table_owner() = 'HR') AND NOT :ddl.get_object_name() = 'REGIONS') AND :ddl.is_ null_tag() = 'Y'
この例ではHRやREGIONSなどのオブジェクト名がすべて大文字で指定されていることに注意してください。ルールが正しく評価されるには、表やユーザーなどのオブジェクト名での大/小文字の表記が、データ・ディクショナリでの大/小文字の表記と一致する必要があります。したがって、オブジェクトの作成時に大/小文字の表記が指定されなかった場合、ルール条件ではオブジェクト名をすべて大文字で指定します。ただし、オブジェクトの作成時に二重引用符を使用して特定の大/小文字の表記を指定した場合は、ルール条件でも同じように大/小文字の表記を指定します。ただし、ルール条件ではオブジェクト名を二重引用符で囲むことはできません。
たとえば、HRスキーマ内のREGIONS表が実際には"Regions"という名前で作成された場合、この表に関連するルール条件では、次の例のようにRegionsを指定します。
:dml.get_object_name() = 'Regions'
DBMS_RULE_ADMパッケージを使用してこれらのルールを作成する場合は、Oracle Streams評価コンテキストを使用できます。次の例では、複合ルールを保持するルール・セットを作成し、前述の条件を伴うルールを作成して、それらのルールをルール・セットに追加します。
BEGIN
-- Create the rule set
DBMS_RULE_ADM.CREATE_RULE_SET(
rule_set_name => 'strmadmin.complex_rules',
evaluation_context => 'SYS.STREAMS$_EVALUATION_CONTEXT');
-- Create the complex rules
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.hr_not_regions_dml',
condition => ' (:dml.get_object_owner() = ''HR'' AND NOT ' ||
' :dml.get_object_name() = ''REGIONS'') AND ' ||
' :dml.is_null_tag() = ''Y'' ');
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.hr_not_regions_ddl',
condition => ' ((:ddl.get_object_owner() = ''HR'' OR ' ||
' :ddl.get_base_table_owner() = ''HR'') AND NOT ' ||
' :ddl.get_object_name() = ''REGIONS'') AND ' ||
' :ddl.is_null_tag() = ''Y'' ');
-- Add the rules to the rule set
DBMS_RULE_ADM.ADD_RULE(
rule_name => 'strmadmin.hr_not_regions_dml',
rule_set_name => 'strmadmin.complex_rules');
DBMS_RULE_ADM.ADD_RULE(
rule_name => 'strmadmin.hr_not_regions_ddl',
rule_set_name => 'strmadmin.complex_rules');
END;
/
この場合、ルールはルール・セットからOracle Streams評価コンテキストを継承します。
|
注意: ほとんどの場合、DBMS_STREAMS_ADMパッケージを使用してOracle Streamsクライアントのネガティブ・ルール・セットにルールを追加すれば、NOT論理条件を持つ複合ルールを使用する必要はありません。 |
LIKE条件を使用すると、ルールの条件が指定されたパターンと一致する場合にTRUEと評価される複合ルールを作成できます。たとえば、JOBというパターンで始まるhrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML変更およびDDL変更についてTRUEと評価されるルール条件を指定する必要があるとします。DML変更用に1つとDDL変更用に1つ、合計2つのルール条件を指定して、LIKE条件を使用できます。これらのルールのルール条件を次に示します。
(:dml.get_object_owner() = 'HR' AND :dml.get_object_name() LIKE 'JOB%') AND :dml.is_null_tag() = 'Y' ((:ddl.get_object_owner() = 'HR' OR :ddl.get_base_table_owner() = 'HR') AND :ddl.get_object_name() LIKE 'JOB%') AND :ddl.is_null_tag() = 'Y'
評価中に、変数に対する変数値のファンクションからNULLが返される場合、ルール条件内の暗黙的変数は未定義となります。DBMS_RULE.EVALUATEプロシージャの実行時に変数の値がクライアントからルール・エンジンに送信されないと、ルール条件内に属性を持たない明示的変数は未定義となります。
属性を持つ変数に関しては、DBMS_RULE.EVALUATEプロシージャの実行時にクライアントからルール・エンジンへ、変数またはそのいずれかの属性の値が送信されないと、変数は未定義となります。たとえば、変数xが属性aとbを持つ場合、クライアントからxの値が送信されず、aの値もbの値も送信されないと、この変数は未定義となります。ただし、1つ以上の属性の値がクライアントから送信されると、この変数は定義されます。この場合では、クライアントからaの値が送信され、bの値が送信されなくても、この変数は定義されます。
ルール条件内の未定義の変数は、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントを含む、ルール・エンジンのOracle Streamsクライアントに対して NULLと評価されます。これに対し、ルール・エンジンのOracle Streams以外のクライアントに対しては、ルール条件内の未定義の変数が原因で、ルール・エンジンからクライアントにmaybe_rulesが返されることがあります。ルール・セットの評価時に、さらに情報を提供するとTRUEと評価される可能性があるルールがmaybe_rulesです。
未定義の各変数をNULLとして処理すると、Oracle Streamsクライアントに返されるmaybe_rulesの数が削減されます。maybe_rulesの数が削減され、その結果、メッセージの発生時にルール・セットがより効率的に評価されれば、パフォーマンスが改善される可能性があります。Oracle Streams以外のクライアントにmaybe_rulesを返すルールは、次の各例に示すように、Oracle Streamsクライアントに対してはTRUEまたはFALSEのルールとなる可能性があります。
次のユーザー定義ルール条件を考えてみます。
:m IS NULL
評価中に変数mの値が定義されない場合、ルール・エンジンのOracle Streams以外のクライアントにmaybeルールが発生します。ただし、Oracle Streamsクライアントについては、未定義変数mがNULLとして処理されるため、この条件はTRUEと評価されます。このようなルールはすべてのメッセージに対してTRUEと評価されるため、Oracle Streamsクライアントのルール・セットには追加しないでください。そのため、たとえば、取得プロセスのポジティブ・ルール・セットにこのようなルールが含まれる場合、取得の対象外とされているメッセージが取得プロセスによって取得される場合があります。
次に、Oracle Streamsの:dml変数を使用する別のユーザー指定ルール条件を示します。
:dml.get_object_owner() = 'HR' AND :m IS NULL
Oracle Streamsクライアントでは、メッセージがhrスキーマ内の表に対する行変更で構成されていて、評価時に変数mの値が不明な場合、未定義変数mがNULLとして処理されるため、この条件はTRUEと評価されます。
次のユーザー定義ルール条件を考えてみます。
:m = 5
評価中に変数mの値が定義されない場合、ルール・エンジンのOracle Streams以外のクライアントにmaybeルールが発生します。ただし、Oracle Streamsクライアントについては、未定義変数mがNULLとして処理されるため、この条件はFALSEと評価されます。
Oracle Streamsの:dml変数を使用する別のユーザー指定ルール条件を考えてみます。
:dml.get_object_owner() = 'HR' AND :m = 5
Oracle Streamsクライアントでは、メッセージがhrスキーマ内の表に対する行変更で構成されていて、評価時に変数mの値が不明な場合、未定義変数mがNULLとして処理されるため、この条件はFALSEと評価されます。
ルール条件のファンクション・パラメータとして、:dmlおよび:ddl変数を使用しないことをお薦めします。次の例では、:dml変数がmy_functionというファンクションのパラメータとして使用されています。
my_function(:dml) = 'Y'
このようなルール条件を指定すると、ルール評価のパフォーマンスが低下したり、誤ったOracle Streamsデータ・ディクショナリ情報が取得または伝播される結果となる可能性があります。
Oracle Streams環境では、カスタム評価コンテキストを使用できます。LCRに関連するユーザー定義評価コンテキストには、SYS.STREAMS$_EVALUATION_CONTEXT内のすべての変数を含める必要があります。各変数のタイプとその変数値ファンクションは、SYS.STREAMS$_EVALUATION_CONTEXTで変数ごとに定義されているタイプおよびファンクションと同じである必要があります。また、DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXTを使用して評価コンテキストを作成する場合は、evaluation_functionパラメータに対してSYS.DBMS_STREAMS_INTERNAL.EVALUATION_CONTEXT_FUNCTIONを指定する必要があります。DBMS_RULE_ADM.ALTER_EVALUATION_CONTEXTプロシージャを使用すると、既存の評価コンテキストを変更できます。
評価コンテキストに関する情報は、次のデータ・ディクショナリ・ビューで参照できます。
ALL_EVALUATION_CONTEXT_TABLES
ALL_EVALUATION_CONTEXT_VARS
ALL_EVALUATION_CONTEXTS
必要に応じて、これらのデータ・ディクショナリ・ビューの情報を使用し、SYS.STREAMS$_EVALUATION_CONTEXTに基づいて新しい評価コンテキストを作成できます。
|
注意: Oracleが提供する評価コンテキストの変数との競合を回避するために、$や#などの特殊文字を含む変数名は使用しないでください。 |
|
関連項目: これらのデータ・ディクショナリ・ビューの詳細は、Oracle Databaseリファレンスを参照 |
