次の各項では、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
を指定します。
関連項目:
|