| Oracle® Streams概要および管理 11gリリース2 (11.2) B61351-03 |
|
 前 |
 次 |
次の各項では、Oracle Streamsでのルールの使用方法について説明します。
Oracle Streamsでは、次の各メカニズムをOracle Streamsクライアントと呼びます。これは、各メカニズムがルール・エンジンのクライアントであるためです(メカニズムが1つ以上のルール・セットと関連付けられている場合)。
取得プロセス
同期取得
伝播
適用プロセス
メッセージ・クライアント
同期取得を除き、これらの各クライアントはポジティブ・ルール・セットとネガティブ・ルール・セットという最大2つのルール・セットに関連付けることができます。同期取得を関連付けることができるのは1つのポジティブ・ルール・セットのみです。ネガティブ・ルール・セットに関連付けることはできません。
1つのルール・セットは、同一データベース内の複数の取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。また、1つのルール・セットを、あるOracle Streamsクライアントに対してはポジティブ・ルール・セット、別のOracle Streamsクライアントに対してはネガティブ・ルール・セットとして使用できます。
図5-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クライアントによってすべてのメッセージが廃棄されます。
表5-1に、前項で説明したOracle Streamsクライアントの動作のまとめを示します。
表5-1 ルール・セットとOracle Streamsクライアントの動作
| ネガティブ・ルール・セット | ポジティブ・ルール・セット | Oracle Streamsクライアントの動作 |
|---|---|---|
|
なし |
なし |
すべてのメッセージに対してタスクが実行されます。 |
|
なし |
あり(ルールを含む) |
ポジティブ・ルール・セットで |
|
あり(ルールを含む) |
なし |
ネガティブ・ルール・セットで |
|
あり(ルールを含む) |
あり(ルールを含む) |
ネガティブ・ルール・セットで |
|
あり(空) |
なし |
すべてのメッセージに対してタスクが実行されます。 |
|
あり(空) |
あり(ルールを含む) |
ポジティブ・ルール・セットで |
|
なし |
あり(空) |
すべてのメッセージが廃棄されます。 |
|
あり(空) |
あり(空) |
すべてのメッセージが廃棄されます。 |
|
あり(ルールを含む) |
あり(空) |
すべてのメッセージが廃棄されます。 |
Oracle Streamsクライアントがメッセージに対するタスクを実行するのは、メッセージがそのクライアントのルール・セットを満たしている場合です。システム作成ルールは、DBMS_STREAMS_ADMパッケージで作成され、粒度レベルとして表、スキーマまたはグローバルのいずれかを指定できます。このセクションでは、各レベルについて説明します。特定のタスクに複数のレベルを指定できます。たとえば、1つの適用プロセスに対して、oeスキーマの特定の表に表レベルの適用を実行し、hrスキーマ全体にスキーマ・レベルの適用を実行するように指示できます。また、1つのルールは、データ操作言語(DML)変更またはデータ定義言語(DDL)変更のいずれかの結果に関連しています。そのため、たとえば、特定の表のすべての変更に対処するには、DML変更の結果とDDL変更の結果それぞれに対応する少なくとも2つのシステム作成ルールが必要です。DML変更の結果とは、DML変更の結果として生成される行変更、または各行の変更をカプセル化するキュー内の行LCRです。
表5-2は、ルールの各レベルが各Oracle Streamsタスクについてどのような意味を持つかを示します。ネガティブ・ルール・セットがポジティブ・ルール・セットよりも前に評価されることに注意してください。
表5-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パッケージのプロシージャを使用して、これらの各レベルでルールを作成できます。システム作成ルールには、表5-2で説明されている以外にも、Oracle Streamsクライアントの動作を変更する条件を含めることができます。たとえば、LCRに対して特定のソース・データベースを指定できるルールがあります。この場合は、LCRが指定されたソース・データベースで発生したときのみ、このルールがTRUEと評価されます。表5-3に、DBMS_STREAMS_ADMパッケージによって作成されるルールで指定できるシステム作成ルール条件のタイプを示します。
表5-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 |
メッセージ・クライアント |
|
|
ユーザー指定のルール条件を満たす、指定されたタイプのメッセージ・クライアントで使用されるキュー内のすべての永続メッセージ |
メッセージ・クライアント |
|
表5-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がキューにエンキューされます。図5-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が宛先キューにエンキューされます。図5-3はこの例を示しています。
同様に、取得される更新によって従業員のdepartment_idが80から50に変更される場合、このサブセット・ルールが指定された伝播では、更新操作がINSERT操作に変換されます。
サブセット・ルールが適用プロセスのルール・セットに含まれる場合は、行LCRの適用時に更新操作が挿入操作または削除操作に変換されることがあります。
たとえば、サブセット・ルールを使用し、department_id = 50というサブセット条件を指定して、従業員のdepartment_idが50の場合にhr.employees表の変更を適用プロセスで適用するよう指定する場合を考えます。宛先データベースの表が、department_idが50の従業員のレコードのみを含むサブセット表であると仮定します。従業員のdepartment_idを80から50に変更する従業員の変更がソース・データベースで取得された場合、このサブセット・ルールが指定されている宛先データベースの適用プロセスによって、更新操作が挿入操作に変換されてこの変更が適用されます。この変換が必要なのは、その従業員の行が宛先の表に存在しないためです。図5-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をカスタム・アプリケーションに送信できます。図5-5はこの例を示しています。
同様に、従業員のdepartment_idを90から50に変更する更新が永続行LCRに含まれる場合、このサブセット・ルールが指定されたメッセージ・クライアントでは、デキュー中にUPDATE操作がINSERT操作に変換されます。
次のタイプのサブセット・ルールを指定すると、サプリメンタル・ロギングが必要になります。
取得プロセスのサブセット・ルール
取得プロセスで取得されたLCRを伝播する伝播のサブセット・ルール
取得プロセスで取得されたLCRを適用する適用プロセスのサブセット・ルール
いずれの場合も、サブセット条件に含まれるすべての列と、これらの変更を適用する宛先データベースにある表のすべての列について、無条件のサプリメンタル・ログ・グループをソース・データベースに指定する必要があります。場合によっては、サブセット・ルールを指定すると、更新が挿入に変換されることがあり、このときに一部またはすべての列に補足情報が必要になることがあります。
たとえば、データベースdbs2.example.comでhr.locations表のpostal_code列に取得LCRを適用する適用プロセスにサブセット・ルールを指定する場合、この表に対する変更のソース・データベースがdbs1.example.comであれば、dbs2.example.comのhr.locations表に存在するすべての列、およびpostal_code列について、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_STREAMS_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を指定します。
|
関連項目:
|
