| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
次の各項では、Oracle Streamsでの情報のコンシュームについて説明します。
Oracle Streamsでの情報のコンシュームとは、キューから情報を含むメッセージをデキューして、メッセージを処理または廃棄することです。コンシュームされる情報は、データベースの変更に関する説明の場合もあれば、その他の情報である場合もあります。デキューされたメッセージは、デキューされたデータベースで生成されていることもあれば、別のデータベースで生成されていることもあります。
この項の内容は次のとおりです。
次の各項では、Oracle Streamsで情報をコンシュームする方法について説明します。
暗黙的コンシュームでは、適用プロセスが取得LCR、永続LCRまたは永続ユーザー・メッセージを自動的にデキューします。キューはANYDATAキューであることが必要です。メッセージに論理変更レコード（LCR）が含まれる場合、適用プロセスでは、LCRを直接適用することも、ユーザー指定プロシージャをコールして処理することも可能です。メッセージにLCRが含まれない場合、適用プロセスではメッセージ・ハンドラと呼ばれるユーザー指定プロシージャを起動してメッセージを処理できます。
|
注意: 取得LCRは適用プロセスによってデキューされる必要があります。ただし、適用プロセスまたは適用プロセスによってコールされたユーザー・プロシージャが取得LCRを再エンキューする場合、LCRは永続LCRになり明示的にデキューできます。 |
明示的コンシュームでは、メッセージは次のいずれかの方法でデキューされます。
メッセージ・クライアントで永続LCRまたは永続ユーザー・メッセージを明示的にデキューします。キューはANYDATAキューである必要があります。メッセージ・クライアントは、アプリケーションによって起動された場合にメッセージをデキューします。メッセージ・クライアントがメッセージをデキューした後、アプリケーションがメッセージを処理します。
アプリケーションがメッセージを明示的に手動でデキューして処理します。アプリケーションは、タイプが永続LCR、永続ユーザー・メッセージ、バッファLCRおよびバッファ・ユーザー・メッセージであるメッセージをデキューできます。メッセージは、ANYDATAキューまたは型付きキューからデキューできます。
Oracle Streamsでコンシュームされる情報のタイプは次のとおりです。
取得LCRは、取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード（LCR）です。
適用プロセスのみが取得LCRをデキューできます。デキュー後、適用プロセスは取得LCRを直接適用し、データベースを変更したり、取得LCRを取り消したり、処理のため適用ハンドラへ取得LCRを送信したり、永続キューに取得LCRを再エンキューしたりできます。
永続LCRは、ANYDATAキューの永続キュー部分にエンキューされた論理変更レコード（LCR）です。永続LCRは次のいずれかの方法でエンキューできます。
同期取得による暗黙的な取得およびエンキュー
アプリケーションによる明示的な作成およびエンキュー
適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー
永続LCRは、適用プロセス、メッセージ・クライアントまたはアプリケーションでデキューできます。
バッファLCRは、アプリケーションによって明示的に作成され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード（LCR）です。アプリケーションのみがバッファLCRをデキューできます。
永続ユーザー・メッセージは、永続キューにエンキューされたユーザー定義型のLCR以外のメッセージです。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。
アプリケーションによる明示的な作成およびエンキュー
適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー
適用プロセスおよびメッセージ・クライアントは、ANYDATAキューの永続ユーザー・メッセージのみをデキューできます。アプリケーションは、ANYDATAキューまたは型付きキューの永続ユーザー・メッセージをデキューできます。
バッファ・ユーザー・メッセージは、アプリケーションによって明示的に作成され、バッファ・キューにエンキューされたユーザー定義型のLCR以外のメッセージです。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。アプリケーションのみがバッファ・ユーザー・メッセージをデキューできます。
表4-1に、Oracle Streamsで使用可能な情報コンシューム・オプションのまとめを示します。
表4-1 Oracle Streamsでの情報コンシューム・オプション
| コンシュームのタイプ | メッセージのデキュー | メッセージのタイプ | 使用ケース |
|---|---|---|---|
|
|
有効にすると自動的に継続して行われる |
取得LCR 永続LCR 永続ユーザー・メッセージ |
取得LCRをデキューして処理する場合。 永続LCRまたは永続ユーザー・メッセージを、ANYDATAキューの永続キュー部分から自動的に継続してデキューする場合。 データベースを変更するためにデータベース・オブジェクトに直接適用する必要があるLCRをデキューする場合。 メッセージをデキューし、適用ハンドラを使用して処理する場合。 |
|
|
アプリケーションから起動されたときに行われる |
永続LCR 永続ユーザー・メッセージ |
単純な方法を使用して、 デキューの後でメッセージをアプリケーションに処理のために送信する場合。 |
|
|
アプリケーションのロジックに基づいて手動で行われる |
永続LCR バッファLCR 永続ユーザー・メッセージ バッファ・ユーザー・メッセージ |
アプリケーションで永続LCRまたはバッファLCRを手動で アプリケーションで永続ユーザー・メッセージまたはバッファ・ユーザー・メッセージを手動で |
|
注意: 1つのデータベースで、この表の情報コンシューム・オプションを任意に組み合せて使用することができます。 |
|
関連項目:
|
この項では、Oracle Streamsの適用プロセスに関連する概念について説明します。
この項の内容は次のとおりです。
適用プロセスとは、メッセージを特定のキューからデキューし、各メッセージを直接適用したり、廃棄したり、適用ハンドラにパラメータとして渡したり、または再リクエストするための、オプションのOracleバックグラウンド・プロセスです。これらのメッセージは、論理変更レコード（LCR）またはユーザー・メッセージです。
適用プロセスは、ユーザーが定義するルールに基づいてメッセージを適用します。LCRの場合は、各ルールでTRUEと評価するデータベース・オブジェクトと変更の種類を指定します。ユーザー・メッセージの場合は、特定のタイプのメッセージに対する適用プロセスの動作を制御するルールを作成できます。これらのルールは、適用プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットに指定します。
メッセージに対してルールがTRUEと評価され、そのルールが適用プロセスのポジティブ・ルール・セットに含まれる場合、適用プロセスはメッセージをデキューして処理します。メッセージに対してルールがTRUEと評価され、そのルールが適用プロセスのネガティブ・ルール・セットに含まれる場合、適用プロセスはメッセージを廃棄します。適用プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。
LCRの適用プロセスのルールは次のレベルで指定できます。
表ルールは、特定の表に対するDML変更による行変更またはDDL変更を適用または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。
スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を適用または廃棄します。
グローバル・ルールは、適用プロセスに関連付けられているキュー内のDML変更によるすべての行変更またはすべてのDDL変更を適用または廃棄します。
適用プロセスでデキューできるメッセージのタイプを次に示します。
取得LCR: 取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされた論理変更レコード（LCR）。状況によっては、最適化を行って、取得プロセスでLCRを適用プロセスにより効率的に送信することもできます。このような最適化は、取得と適用の複合と呼ばれます。
永続LCR: 同期取得によって暗黙的に取得されたLCR、アプリケーションによって永続的に作成およびエンキューされたLCR、または適用プロセスによってエンキューされたLCR。永続LCRはANYDATAキューの永続キュー部分にエンキューされます。
永続ユーザー・メッセージ: アプリケーションまたは適用プロセスによって明示的にエンキューされたユーザー定義型のLCR以外のメッセージ。永続ユーザー・メッセージは、ANYDATAキューの永続キュー部分にエンキューされます。また、ユーザー・メッセージはANYDATAキューまたは型付きキューにエンキューできますが、適用プロセスでデキューできるのはANYDATAキューのユーザー・メッセージのみです。
1つの適用プロセスで、1つのキューのバッファ・キュー部分と永続キュー部分の両方からデキューを行うことはできません。バッファ・キューと永続キューの両方のメッセージを適用プロセスで処理する必要がある場合は、宛先データベースにメッセージを処理するための2つ以上の適用プロセスが必要です。
適用プロセスは、メッセージを直接適用するか、メッセージを適用ハンドラに送信して処理します。メッセージ処理のオプションは、適用プロセスで受信したメッセージが行論理変更レコード（行LCR）、DDL論理変更レコード（DDL LCR）、ユーザー・メッセージのいずれであるかによって異なります。
図4-1に、適用プロセスのメッセージ処理オプションおよび様々なタイプのメッセージに使用できるオプションを示します。
次の各項では、これらのメッセージ処理オプションについてさらに詳しく説明します。
このオプションを使用すると、適用プロセスはユーザー・プロシージャを実行せずにLCRを適用します。適用プロセスは、LCR内の変更を正常に適用します。また、競合または適用エラーが発生した場合は、競合ハンドラまたはエラー・ハンドラと呼ばれるユーザー指定プロシージャを使用してエラーを解決しようとします。
競合ハンドラが競合を解消できる場合は、競合ハンドラがLCRを適用するか、LCR内の変更を廃棄します。エラー・ハンドラがエラーを解決できる場合は、エラー・ハンドラが必要に応じてLCRを適用します。エラー・ハンドラは、適用前にLCRを変更することでエラーを解決できる場合があります。競合ハンドラまたはエラー・ハンドラがエラーを解決できない場合、適用プロセスは、トランザクションとトランザクションに関連付けられたすべてのLCRをエラー・キューに入れます。
適用ハンドラを使用するとき、適用プロセスはメッセージを処理するためにユーザー・プロシージャにパラメータとして渡します。ユーザー・プロシージャはカスタマイズした方法でメッセージを処理できます。
次の各項では、特定の適用ハンドラの詳細と適用ハンドラの使用上の注意について説明します。
行LCRを処理するユーザー・プロシージャはDMLハンドラと呼ばれます。1つの適用プロセスが多数のDMLハンドラを使用できます。DMLハンドラは取得プロセス、同期取得またはアプリケーションで作成された行LCRを処理できます。
適用プロセスに関連付けられている表ごとに、行LCR内の次の各操作を処理するために個別のDMLハンドラを設定できます。
INSERT
UPDATE
DELETE
LOB_UPDATE
たとえば、hr.employees表は、1つのDMLハンドラ・プロシージャでINSERT操作を処理し、別のDMLハンドラ・プロシージャでUPDATE操作を処理できます。または、hr.employees表が、それぞれの種類の操作で同じDMLハンドラ・プロシージャを使用することもできます。
ユーザー・プロシージャは、行LCRの任意のカスタム処理を実行できます。たとえば、ソース・データベースの特定の表に挿入が行われるたびに、宛先データベースの複数の表に挿入を行う場合は、表に対するINSERT操作を処理するユーザー・プロシージャを作成してこれを達成できます。
ユーザー・プロシージャで設定された名前付きセーブポイントに対する場合を除き、DMLハンドラではコミットやロールバックを行うことはできません。DMLハンドラ内で行LCRを実行するには、行LCRのためのEXECUTEメンバー・プロシージャを起動します。
DMLハンドラを設定するには、DBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用します。DMLハンドラは、特定の適用プロセスに対して設定することも、データベースのすべての適用プロセスで使用される一般的なDMLハンドラとして設定することもできます。表の操作に対するDMLハンドラを特定の適用プロセスに設定したときに、別のDMLハンドラが同じ表の同じ操作に対する一般的なハンドラとして存在する場合、特定のDMLハンドラが一般的なDMLハンドラよりも優先されます。
エラー・ハンドラはDMLハンドラと同じ方法で作成しますが、SET_DML_HANDLERプロシージャを実行するときにerror_handlerパラメータをTRUEに設定する点が違います。エラー・ハンドラが起動されるのは、指定された表の指定された操作に対して適用プロセスが行LCRを適用しようとして適用エラーが発生した場合のみです。
通常、DMLハンドラは、行LCRのカスタム処理を実行するためにOracle Streamsレプリケーション環境で使用されますが、レプリケーション環境以外でも使用できます。たとえば、DMLハンドラを使用して、データベース・オブジェクトに対して行われた変更を記録し、変更をレプリケートしないことも可能です。
|
注意: SET_DML_HANDLERプロシージャを実行するときは、ハンドラを使用する対象のオブジェクトを指定します。このオブジェクトはプロシージャの実行時に宛先データベースに存在する必要はありません。 |
|
関連項目:
|
DDL LCRを処理するユーザー・プロシージャはDDLハンドラと呼ばれます。1つの適用プロセスは1つのDDLハンドラしか使用できません。1つのDDLハンドラが、適用プロセスでデキューされるすべてのDDL LCRを処理します。DDLハンドラは、取得プロセスまたはアプリケーションで作成されたDDL LCRを処理できます。
ユーザー・プロシージャはDDL LCRの任意のカスタム処理を実行できます。たとえば、DDL変更を適用する前に記録する場合、DDL操作を処理するユーザー・プロシージャを作成してこれを達成できます。
DDLハンドラ内でDDL LCRを実行するには、DDL LCRのEXECUTEメンバー・プロシージャを起動します。DDLハンドラを特定の適用プロセスに関連付けるには、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャまたはALTER_APPLYプロシージャのddl_handlerパラメータを使用します。
通常、DDLハンドラは、DDL LCRのカスタム処理を実行するためにOracle Streamsレプリケーション環境で使用されますが、レプリケーション環境以外でも使用できます。たとえば、DDLハンドラを使用して、データベース・オブジェクトに対して行われた変更を記録し、変更をレプリケートしないことも可能です。
|
関連項目:
|
永続ユーザー・メッセージは、適用プロセスに対して指定されたメッセージ・ハンドラによって処理されます。メッセージ・ハンドラとは、環境に合わせてカスタマイズした方法でユーザー・メッセージを処理できるユーザー定義プロシージャです。
メッセージ・ハンドラは、1つ以上のリモート・データベースの更新または他のリモート・アクションを実行する必要のあるアプリケーションを含む環境においてメリットがあります。このようなアプリケーションがユーザー・メッセージをローカル・データベースのキューにエンキューすると、Oracle Streamsが各ユーザー・メッセージを宛先データベースの適切なキューに伝播できます。複数の宛先がある場合、Oracle Streamsはこれらのメッセージを自動的に各宛先に伝播して処理するためのインフラストラクチャを提供します。宛先が1つしかない場合も、Oracle Streamsはソース・データベースのアプリケーションと宛先データベースのアプリケーションの間にレイヤーを提供します。これによって、リモート・データベースのアプリケーションが使用不可能になった場合も、ソース・データベースのアプリケーションはそのまま正常に動作できます。
たとえば、メッセージ・ハンドラは、ユーザー・メッセージを電子メール・メッセージに変換できます。この場合、ユーザー・メッセージには、from、to、subject、text_of_messageなど、電子メール・メッセージで使用される属性を含めることができます。メッセージを電子メール・メッセージに変換した後、メッセージ・ハンドラがそのメッセージを電子メール・ゲートウェイを介して送信できます。
適用プロセスにメッセージ・ハンドラを指定するには、DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャまたはALTER_APPLYプロシージャのmessage_handlerパラメータを使用します。Oracle Streams適用プロセスでは、常に、LCR以外のメッセージはキューのその他のメッセージに依存しないとみなされます。永続ユーザー・メッセージを適用する適用プロセスの並列性が1より大きい場合、これらのメッセージはメッセージ・ハンドラによって任意の順序でデキューされます。このため、ご使用の環境でメッセージ間に依存性がある場合は、適用プロセスの並列性を1に設定することをお薦めします。
プリコミット・ハンドラを使用して、取得LCRのコミット・ディレクティブ、および永続LCRと永続ユーザー・メッセージのトランザクション境界を監査できます。プリコミット・ハンドラは、トランザクションのコミット情報を受信し、カスタマイズした方法でコミット情報を処理できるユーザー定義のPL/SQLプロシージャです。プリコミット・ハンドラは、DMLハンドラまたはメッセージ・ハンドラと併用できます。
たとえば、ハンドラで1トランザクション分のデータをキャッシュすることで、パフォーマンスが改善される場合があります。このデータには、カーソル、一時LOB、メッセージのデータなどが含まれます。プリコミット・ハンドラは、トランザクションが完了すると、ハンドラでキャッシュしたオブジェクトを解放または実行できます。
プリコミット・ハンドラは、適用プロセスがトランザクションをコミットするときに実行されます。適用プロセスのcommit_serializationパラメータを使用すると、適用プロセスのコミット順序を制御できます。
次に、コミット・ディレクティブとトランザクション境界について説明します。
取得LCRのコミット・ディレクティブ: 取得プロセスの使用中にユーザーがトランザクションをコミットすると、取得プロセスによって取得された行LCRがトランザクションに含まれている場合、取得プロセスによってトランザクションの内部コミット・ディレクティブが取得されます。また、取得プロセスによって、トランザクション内の各取得LCRにトランザクション識別子も記録されます。
コミット・ディレクティブは、エンキューされた後、トランザクション内のLCRとともに宛先キューに伝播できます。プリコミット・ハンドラによって、これらの内部コミット・ディレクティブの各コミットSCNが適用プロセスのキューに受信されます。その後、それらのコミット・ディレクティブが適用プロセスによって処理されます。
同期取得によってエンキューされた永続LCRのトランザクション境界: 同期取得の使用中にユーザーがトランザクションをコミットすると、同期取得によってエンキューされた永続LCRはメッセージ・グループに編成されます。同期取得では、トランザクション内の各永続LCRにトランザクション識別子が記録されます。
同期取得によって永続LCRがエンキューされた後、メッセージ・グループの永続LCRを他のキューに伝播できます。適用プロセスがこれらの永続LCRを処理するように構成されている場合は、メッセージ・グループのすべての永続LCRに対して1つのコミットSCNが生成されます。個々の適用プロセスで生成されるコミットSCNの値は、ソース・トランザクションまたは他の適用プロセスで生成される値とは関係ありません。そのような適用プロセスに対して構成されているプリコミット・ハンドラが、適用プロセスによって提供されるコミットSCNを受信します。
アプリケーションによってエンキューされたメッセージのトランザクション境界: アプリケーションでは、永続LCR、永続ユーザー・メッセージおよびその他のタイプのメッセージをエンキューできます。これらのエンキュー操作を行っているユーザーが、COMMIT文を発行してトランザクションを終了すると、エンキューされた永続LCRおよび永続ユーザー・メッセージは、メッセージ・グループに編成されます。
アプリケーションによってエンキューされたメッセージがメッセージ・グループに分類されると、メッセージ・グループのメッセージを他のキューに伝播できます。適用プロセスがこれらのメッセージを処理するように構成されている場合は、メッセージ・グループのすべてのメッセージに対して1つのトランザクション識別子とコミットSCNを生成します。個々の適用プロセスで生成されるトランザクション識別子とコミットSCNの値は、ソース・トランザクションまたは他の適用プロセスで生成される値とは関係ありません。そのような適用プロセスに対して構成されているプリコミット・ハンドラが、適用プロセスによって提供されるコミットSCNを受信します。
適用ハンドラを使用する際には、次の点を考慮する必要があります。
DMLハンドラ、DDLハンドラおよびメッセージ・ハンドラは、LCRのEXECUTEメンバー・プロシージャをコールしてLCRを実行できます。
すべての適用済DDL LCRは、自動的にコミットされます。したがって、DDLハンドラがDDL LCRのEXECUTEメンバー・プロシージャをコールすると、自動的にコミットが実行されます。
必要な場合、適用ハンドラはOracle Streamsセッション・タグを設定できます。
適用ハンドラは、PL/SQLプロシージャでパブリッシュ（またはラップ）されたJavaストアド・プロシージャをコールできます。
適用プロセスが、存在しない適用ハンドラまたは無効な適用ハンドラを起動しようとすると、その適用プロセスは強制終了されます。
適用ハンドラがOracle提供パッケージのプロシージャまたはファンクションを起動する場合、適用ハンドラを実行するユーザーにはそのパッケージに対する直接のEXECUTE権限が必要です。ロールを介してこの権限を付与するだけでは不十分です。
|
関連項目:
|
前述した1つ以上の適用ハンドラを使用する場合に有効なメッセージ処理オプションを、この項の表に示します。行LCRとDDL LCRは適用プロセスで直接適用できるため、適用ハンドラはオプションです。ただし、ユーザー・メッセージを処理するにはメッセージ・ハンドラが必須です。また、適用プロセスがメッセージをデキューするのは、そのメッセージが適用プロセスのルール・セットを満たしている場合のみです。通常、メッセージが適用プロセスのルール・セットを満たすのは、メッセージについてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの少なくとも1つのルールがTRUEと評価された場合です。
表4-2 メッセージ処理オプションのまとめ
| メッセージ処理オプション | メッセージのタイプ | 適用プロセスのデフォルト動作 | ユーザー・プロシージャの有効範囲 |
|---|---|---|---|
|
メッセージの直接適用 |
行LCRまたはDDL LCR |
DMLまたはDDLを実行 |
適用不可 |
|
DMLハンドラまたはエラー・ハンドラ |
行LCR |
DMLを実行 |
1つの表に対する1つの操作 |
|
DDLハンドラ |
DDL LCR |
DDLを実行 |
適用プロセス全体 |
|
メッセージ・ハンドラ |
ユーザー・メッセージ |
エラー・トランザクションを作成（メッセージ・ハンドラが存在しない場合） |
適用プロセス全体 |
|
プリコミット・ハンドラ |
行LCRまたはユーザー・メッセージを含むトランザクションのコミット・ディレクティブ |
トランザクションをコミット |
適用プロセス全体 |
ここで説明したメッセージ処理オプションに加えて、DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャを使用すると、指定した宛先キューの永続キュー部分にメッセージをエンキューするように適用プロセスに指示できます。また、メッセージの実行を制御するには、DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャを使用する方法もあります。
適用プロセスで処理できる様々なメッセージのタイプに対応するソース・データベースを次に示します。
同期取得によって取得された永続LCRの場合、ソース・データベースは、行LCRを取得した同期取得が構成されているデータベースです。
アプリケーションによって作成およびエンキューされた永続LCRの場合、ソース・データベースはメッセージが最初にエンキューされたデータベースです。
ユーザー・メッセージの場合、ソース・データベースは、メッセージが最初にエンキューされたデータベースです。
1つの適用プロセスでは、複数のデータベースで発生したユーザー・メッセージを適用できます。一方、1つの適用プロセスでは、1つのソース・データベースのみから取得された取得LCRを適用できます。同様に、1つの適用プロセスでは、1つのソース・データベースのみから同期取得によって取得された永続LCRを適用できます。このようなLCRの適用には、依存関係、有効なトランザクション順序指定、およびソース・データベースでのトランザクション境界の理解が必要です。
複数のデータベースの取得LCRを1つの宛先キューに送信できます。同期取得により取得された永続LCRについても同様です。ただし、1つのキューに複数のソース・データベースのLCRが含まれる場合、それらのLCRを取得する複数の適用プロセスが必要です。ルールを使用して各適用プロセスが1つのソース・データベースからのメッセージを受信するように構成してください。各ソース・データベースのメッセージに対して別のANYDATAキューを使用することをお薦めします。
また、各適用プロセスで適用できるのは、1つの取得プロセスからの取得LCRのみです。ソース・データベース上で複数の取得プロセスが実行されていて、複数の取得プロセスからのLCRが宛先データベースで適用される場合は、各取得プロセスからの変更を適用するために1つの適用プロセスが必要です。このような環境では、取得プロセス、伝播または適用プロセスで使用される各ANYDATAキューで、特定のソース・データベースの最大1つの取得プロセスからの取得LCRを格納することをお薦めします。キューが複数の取得プロセスからのLCRを含むことができるのは、各取得プロセスが別のソース・データベースで発生した変更を取得している場合です。
同じソース・データベースの複数の同期取得で取得された永続LCRにも同じ制約が適用されます。これらのLCRは別のANYDATAキューに格納し、個別の適用プロセスを使用して各同期取得のLCRを適用します。
DML変更で生成される行LCRを表に適用するとき、適用プロセスは、次のデータ型の列に変更を適用します。
VARCHAR2
NVARCHAR2
NUMBER
FLOAT
LONG
DATE
BINARY_FLOAT
BINARY_DOUBLE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
LONG RAW
CHAR
NCHAR
BASICFILE記憶域を持つCLOB
BASICFILE記憶域を持つNCLOB
BASICFILE記憶域を持つBLOB
UROWID
CLOB、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType
|
注意: Oracle Streams取得プロセスは、CLOBとして格納されているXMLType列への変更しか取得できません。ただし、適用プロセスは、このような取得LCRを、CLOB、オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType列に適用することはできます。 |
|
関連項目:
|
行論理変更レコード（行LCR）の列のデータ型と表の対応する列のデータ型が一致しない場合、適用プロセスによって、適用時に自動的に特定のデータ型が変換されます。
表4-3に、適用時に自動的に変換されるデータ型の組合せを示します。
表4-3 適用時に自動的に変換されるデータ型の組合せ
| データ型 | CHARへ |
NCHARへ |
VARCHAR2へ |
NVARCHAR2へ |
CLOBへ |
BLOBへ |
DATEへ |
TIMESTAMPへ |
|---|---|---|---|---|---|---|---|---|
|
|
なし |
はい |
はい |
はい |
はい |
いいえ |
いいえ |
いいえ |
|
|
はい |
なし |
はい |
はい |
はい |
いいえ |
いいえ |
いいえ |
|
|
はい |
はい |
なし |
はい |
はい |
いいえ |
いいえ |
いいえ |
|
|
はい |
はい |
はい |
なし |
はい |
いいえ |
いいえ |
いいえ |
|
|
はい |
はい |
はい |
はい |
いいえ |
いいえ |
いいえ |
いいえ |
|
|
いいえ |
いいえ |
いいえ |
いいえ |
はい |
いいえ |
いいえ |
いいえ |
|
|
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
はい |
はい |
いいえ |
|
|
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
はい |
はい |
いいえ |
|
|
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
なし |
はい |
|
|
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
いいえ |
はい |
なし |
表4-3の組合せで「はい」が指定されている場合、適用プロセスはデータ型の組合せに対して自動的にデータ型変換を実行します。表4-3の組合せで「いいえ」が指定されている場合、適用プロセスはデータ型の組合せに対してデータ型変換を実行しません。たとえば、適用プロセスは自動的にCHARをNCHARに変換しますが、CHARをBLOBには変換しません。
また、対応する表の列が行LCR列から変換した文字列を保持できるほど十分に大きくない場合は、適用プロセスでエラーが発生します。
次の各項では、適用時の自動データ型変換について詳しく説明します。
|
注意: 自動データ型変換を実行するには、適用プロセスはOracle Database 11g リリース1（11.1.0.7）以上に含まれている必要があります。ただし、以前のOracle Databaseリリースで取得または作成された行LCRの列は適用プロセスによって変換できます。 |
|
関連項目: データ型の詳細は、Oracle Database SQL言語リファレンスを参照 |
rtrim_on_implicit_conversion適用プロセス・パラメータ では、適用プロセスがCHARまたはNCHARをVARCHAR2、NVARCHAR2またはCLOBに変換する場合にデータをトリミングするかどうかを決定します。このパラメータをYに設定すると、適用プロセスはデータ型の変換時に列の右端から埋め込まれている空白を自動的に削除します。このパラメータをNに設定すると、適用プロセスはデータ型の変換時に埋め込まれている空白を保持します。
次に例を示します。
行LCRでは、CHAR(10)列に「abc」が格納されています。
行LCRの対応する表の列はNVARCHAR2(10)です。
rtrim_on_implicit_conversion適用プロセス・パラメータをYに設定すると、適用プロセスは表の列に「abc」を挿入し、これらの文字の後に続く埋込みを削除します。rtrim_on_implicit_conversion適用プロセス・パラメータをNに設定すると、適用プロセスは表の列に「abc」を挿入し、列の残りの領域を空白で埋めます。
|
関連項目: Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス |
DMLハンドラとエラー・ハンドラでは、LONGから CLOBまたはLONG RAWからBLOBに変換されたデータにLOBアセンブリを使用できます。
|
関連項目: Oracle Streamsレプリケーション管理者ガイド |
システム起動時にSTARTUP RESTRICT文を発行して制限付きセッションを有効にすると、データベースの停止時に適用プロセスが実行中であった場合でも、適用プロセスは起動されません。制限付きセッションを無効にすると、停止されていない各適用プロセスが起動されます。
SQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONによって実行中のデータベースで制限付きセッションを有効にしても、実行中の適用プロセスには影響がありません。これらの適用プロセスは引き続き実行され、メッセージの適用が行われます。停止した適用プロセスを制限付きセッションで起動しても、この適用プロセスは、制限付きセッションを無効にするまで実際には起動されません。
適用プロセスのコンポーネントは次のとおりです。
メッセージをデキューするリーダー・サーバー。リーダー・サーバーは、論理変更レコード（LCR）間の依存性を計算してメッセージをトランザクションにアセンブルするプロセスです。その後、リーダー・サーバーは、アセンブルしたトランザクションをコーディネータ・プロセスに返します。
リーダー・サーバーからトランザクションを取得して適用サーバーに渡すコーディネータ・プロセス。コーディネータ・プロセス名はAPnn（nnは文字および数字）です。コーディネータ・プロセスはOracleバックグラウンド・プロセスです。
LCRをDML文またはDDL文としてデータベース・オブジェクトに適用するか、LCRを適切な適用ハンドラに渡す1つ以上の適用サーバー。LCR以外のメッセージの場合、適用サーバーはメッセージをメッセージ・ハンドラに渡します。適用サーバーは、DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATIONプロシージャで指定されたキューの永続キュー部分にLCRメッセージとLCR以外のメッセージをエンキューすることもできます。各適用サーバーはプロセスです。適用サーバーにエラーが発生すると、ユーザー指定の競合ハンドラまたはエラー・ハンドラを使用してエラーを解決しようとします。エラーを解決できない場合、適用サーバーはトランザクションをロールバックし、すべてのメッセージを含めてトランザクション全体をエラー・キューに置きます。
適用サーバーが完了したトランザクションをコミットする時点で、このトランザクションは適用済になっています。適用サーバーがトランザクションをエラー・キューに置いてコミットした場合も、このトランザクションは適用済になっています。
リーダー・サーバー名および適用サーバー・プロセス名はASnn（nnは文字および数字）です。適用サーバーで処理されているトランザクションに、適用されているかどうかが不明な別のトランザクションとの依存関係がある場合、適用サーバーはコーディネータ・プロセスに接続して指示を待ちます。コーディネータ・プロセスは、トランザクションが正しい順序で適用およびコミットされていることを確認するため、すべての適用サーバーを監視します。
次の各項では、適用プロセスの各コンポーネントの状態について説明します。
|
関連項目:
|
リーダー・サーバーの状態は、リーダー・サーバーが現在行っている処理を示します。適用プロセスのリーダー・サーバーの状態は、V$STREAMS_APPLY_READER動的パフォーマンス・ビューを問い合せることによって表示できます。リーダー・サーバーの状態は次のいずれかになります。
INITIALIZING: 起動中
IDLE: 実行中の作業なし
DEQUEUE MESSAGES: 適用プロセスのキューからメッセージをデキュー中
SCHEDULE MESSAGES: メッセージ間の依存性を計算して、メッセージをトランザクションにアセンブル中
SPILLING: 適用されていないメッセージがメモリーからハード・ディスクにオーバーフロー中
PAUSED: DDL LCRの適用を待機中
コーディネータ・プロセスの状態は、コーディネータ・プロセスが現在行っている処理を示します。コーディネータ・プロセスの状態は、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せることによって表示できます。コーディネータ・プロセスの状態は次のいずれかになります。
INITIALIZING: 起動中
APPLYING: 適用サーバーにトランザクションを引渡し中
SHUTTING DOWN CLEANLY: 停止中（エラーなし）
ABORTING: 適用エラーのために停止中
適用サーバーの状態は、適用サーバーが現在行っている処理を示します。適用プロセスの各適用サーバーの状態は、V$STREAMS_APPLY_SERVER動的パフォーマンス・ビューを問い合せることによって表示できます。適用サーバーの状態は次のいずれかになります。
INITIALIZING: 起動中。
IDLE: 実行中の作業なし。
RECORD LOW-WATERMARK: 適用の進捗に関する情報をメンテナンスする管理操作を実行中。この情報は、ALL_APPLY_PROGRESSおよびDBA_APPLY_PROGRESSデータ・ディクショナリ・ビューで使用されます。
ADD PARTITION: 進行中のトランザクションに関する情報の記録に使用されるパーティションを追加する管理操作を実行中。
DROP PARTITION: 進行中のトランザクションに関する情報の記録に使用されたパーティションを削除する管理操作を実行中。
EXECUTE TRANSACTION: トランザクションを適用中。
WAIT COMMIT: コミットSCNが小さい、他のすべてのトランザクションが適用されるまで、トランザクションのコミットを待機中。COMMIT_SERIALIZATION適用プロセス・パラメータがnone以外の値に設定され、PARALELLISM適用プロセス・パラメータが1より大きい値に設定された場合にのみ、この状態は発生します。
WAIT DEPENDENCY: 依存関係にある別のトランザクションが適用されるまで、トランザクション内のLCRの適用を待機中。PARALELLISM適用プロセス・パラメータが1より大きい値に設定されている場合のみ、この状態は発生します。
WAIT FOR NEXT CHUNK: 大規模なトランザクションの次のLCRのセットを待機中。
TRANSACTION CLEANUP: 適用済トランザクションのクリーンアップ中（適用プロセス・キューからのLCRの削除も含む）。
メッセージは、適用プロセスの適用ユーザーのセキュリティ・ドメインで適用されます。適用ユーザーは、適用プロセスのルール・セットを満たすすべてのメッセージをデキューします。適用ユーザーは、メッセージをデータベース・オブジェクトに直接適用できます。また、適用ユーザーは、これらのルール・セットのルールで指定されたすべてのカスタム・ルールベースの変換を実行します。ユーザー定義の適用ハンドラも実行します。
適用ユーザーは、次の権限を含む、変更の適用に必要な権限を持っている必要があります。
適用プロセスで使用するルール・セットのEXECUTE権限
ポジティブ・ルール・セットのルールに指定されているすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限
すべての適用ハンドラのEXECUTE権限
適用プロセス・キューからメッセージをデキューする権限
適用プロセスは1ユーザーのみに関連付けることができますが、1ユーザーは複数の適用プロセスと関連付けることができます。
適用プロセスは、DBMS_STREAMS_ADMパッケージまたはDBMS_APPLY_ADMパッケージを使用して作成できます。DBMS_STREAMS_ADMパッケージを使用すると、一部の構成オプションにデフォルトが自動的に使用されるため、適用プロセスをより簡単に作成できます。DBMS_APPLY_ADMパッケージを使用すると、適用プロセスをより柔軟に作成できます。
DBMS_APPLY_ADMパッケージのCREATE_APPLYプロシージャを実行して適用プロセスを作成する場合は、apply_captured、apply_database_linkおよびapply_tagパラメータに対してデフォルト以外の値を指定できます。これによって、DBMS_STREAMS_ADMパッケージまたはDBMS_RULE_ADMパッケージのプロシージャを使用して、適用プロセスのルール・セットにルールを追加できます。
1つのデータベースに複数の適用プロセスを作成した場合、これらの適用プロセスは完全に独立したものになります。同じソース・データベースからのLCRを適用する場合でも、これらの適用プロセスが相互に同期化することはありません。
表4-4に、適用プロセスの作成にDBMS_STREAMS_ADMパッケージを使用した場合とDBMS_APPLY_ADMパッケージを使用した場合の相違点を示します。
表4-4 DBMS_STREAMS_ADMを使用した場合とDBMS_APPLY_ADMを使用した場合の適用プロセスの作成
| DBMS_STREAMS_ADMパッケージ | DBMS_APPLY_ADMパッケージ |
|---|---|
|
適用プロセスに対して自動的にルール・セットが作成され、このルール・セットに対して自動的にルールを追加することができます。ルール・セットは、 |
適用プロセスの作成前または作成後に、適用プロセスに対して1つ以上のルール・セットおよびルールを作成します。 |
|
適用プロセスでは、ローカル・データベースでのみメッセージを適用できます。 |
適用プロセスの作成時に、ローカル・データベースまたはリモート・データベースのいずれでメッセージを適用するかを指定します。 |
|
適用プロセスによって適用された変更によって、宛先データベースのREDOログに、値が |
適用プロセスの作成時に、適用プロセスによって適用された変更に対するタグ値を指定します。タグのデフォルト値は、 |
ソース・データベースでデータベース・オブジェクトのインスタンス化が準備されている場合、オブジェクトに対する変更が取得プロセスによって取得されるデータベースで、Oracle Streamsデータ・ディクショナリが自動的に移入されます。Oracle Streamsデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリ内の一部の情報のマルチバージョン・コピーです。Oracle Streamsデータ・ディクショナリでは、ソース・データベースのオブジェクト番号、オブジェクト・バージョン情報、内部列番号が表名、列名、列データ型にマップされます。取得LCRでは名前ではなく番号を内部的に使用できるため、このマッピングによって、各取得LCRのサイズが最小に保たれます。
取得または伝播時に取得LCRがパラメータとしてカスタム・ルールベースの変換に渡される場合を除き、取得LCRを適用するすべてのデータベースで、LCRの内容の解釈にソース・データベースのOracle Streamsデータ・ディクショナリのマッピング情報が必要となります。適用プロセスでこのマッピング情報を使用できるようにするために、Oracle Streams適用プロセスを持つ各宛先データベースで、マルチバージョンOracle Streamsデータ・ディクショナリが自動的に移入されます。ソース・データベースのOracle Streamsデータ・ディクショナリから、ソース・データベースからの取得LCRを適用するその他すべてのデータベースに、関連情報が自動的に伝播されます。
適用プロセスの作成後、適用プロセスは、最初の起動前に環境に合わせて適用プロセス・パラメータを設定できるように無効になっています。適用プロセス・パラメータによって、適用プロセスの動作が制御されます。たとえば、parallelism適用プロセス・パラメータによって、トランザクションを同時に適用できる適用サーバーの数が指定され、time_limit 適用プロセス・パラメータによって、適用プロセスが自動的に停止されるまでの実行時間が指定されます。適用プロセス・パラメータを設定した後、適用プロセスを起動できます。
単一データベースで複数の適用プロセスを実行する場合は、システム・グローバル領域（SGA）のサイズを増やすことを検討してください。SGAサイズを増やすには、SGA_MAX_SIZE初期化パラメータを使用します。また、Oracle Streamsプールのサイズがデータベースで自動管理されていない場合は、適用プロセスの並列性ごとにOracle Streamsプールを 1MB増やす必要があります。たとえば、2つの適用プロセスがデータベースで実行されており、parallelismパラメータが一方の適用プロセスでは4、もう一方の適用プロセスでは1に設定されている場合、Oracle Streamsプールを5MB（並列性は(4+ 1= 5）増やします。
|
注意: MEMORY_TARGET、MEMORY_MAX_TARGETまたはSGA_TARGET初期化パラメータが0（ゼロ）以外の値に設定されている場合、Oracle Streamsプールのサイズは自動的に管理されます。 |
適用プロセスを実行しているデータベースが停止され、再起動されても、適用プロセスは永続的状態を保ちます。たとえば、データベースの停止時に適用プロセスを有効にすると、その適用プロセスはデータベースの再起動時に自動的に開始されます。同様に、データベースの停止時に適用プロセスを無効にするか、または強制終了させると、その適用プロセスはデータベースが再起動されても開始されず、無効または強制終了の状態のままとなります。
エラー・キューには、1つのデータベースの現在の適用エラーがすべて格納されます。データベースに複数の適用プロセスが存在する場合、エラー・キューには各適用プロセスの適用エラーが格納されます。適用エラーに関する情報を表示するには、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せるか、Enterprise Managerを使用します。
エラー・キューには、データベースで実行中の適用プロセスによって正常に適用できなかったトランザクションに関する情報が格納されます。1つのトランザクションに多数のメッセージが含まれる可能性があるため、適用中に未処理エラーが発生すると、適用プロセスのルール・セットを満たすトランザクション内のすべてのメッセージがエラー・キューに自動的に移されます。
エラーの原因となった状態を修正し、エラー・トランザクションを再実行できます。たとえば、表の1行を変更して、エラーの原因となった状態を修正できる場合もあります。
エラーの原因となった条件を訂正した後、EXECUTE_ERRORまたはEXECUTE_ALL_ERRORSプロシージャを使用してエラー・キュー内のトランザクションを再実行するか、またはDELETE_ERRORやDELETE_ALL_ERRORSプロシージャを使用してエラー・キューからトランザクションを削除できます。これらのプロシージャは、DBMS_APPLY_ADMパッケージに含まれています。
エラー・キュー内のトランザクションを再実行する場合は、そのトランザクションを実行するユーザーとして、最初にエラー・キューにエラーを置いたユーザーまたはトランザクションを再実行するユーザーを指定できます。また、エラー・キュー内のトランザクションを再実行する場合は、適用プロセスの現行のOracle Streamsタグが使用されます。
再実行されるトランザクションでは、関連する適用ハンドラと競合解決ハンドラが使用されます。エラーを解決するためにエラー・キュー内の行LCRを実行前に変更する必要がある場合は、エラーの原因となった行LCRをエラー・キュー内で処理するようにDMLハンドラを構成できます。この場合、DMLハンドラは行LCRを変更し、同じエラーの繰返しを回避できます。行LCRがDMLハンドラに渡されるのは、行LCRを含むエラーを再実行するときです。
エラー・キューには、ローカルの宛先データベースのみで発生したエラーに関する情報が格納されます。Oracle Streams環境の他のデータベースで実行中の適用プロセスに関するエラー情報は格納されません。
エラー・キューは、データベースの例外キューを使用します。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用してANYDATAキューを作成する際にキューのキュー表が存在しない場合は、プロシージャによって作成されます。キュー表が作成されると、キュー表の例外キューが自動的に作成されます。1つのキュー表を複数のキューで使用できます。また、各キュー表には1つの例外キューがあります。したがって、1つの例外キューで、複数のキューおよび複数の適用プロセスのエラーを格納できます。
例外キューには自身のキュー表に対する適用エラーのみが格納されますが、Oracle Streamsエラー・キューにはデータベースの各例外キュー内のすべての適用エラーに関する情報が格納されます。Oracle Streams適用エラーを管理するには、DBMS_APPLY_ADMパッケージ内のプロシージャを使用する必要があります。適用エラーは例外キューから直接デキューしないでください。
|
注意: メッセージ・クライアントは、メッセージのデキュー時にエラーが発生すると、自身のキュー表に関連付けられている例外キューにこれらのメッセージを移動します。ただし、メッセージ・クライアントのエラーに関する情報はエラー・キューには格納されません。適用プロセスのエラーに関する情報のみがエラー・キューに格納されます。 |
|
関連項目:
|
メッセージ・クライアントは、アプリケーションまたはユーザーに起動されたときに永続キューからメッセージをデキューします。ルールを使用して、メッセージ・クライアントによってキューからデキューされるメッセージを指定できます。このようなメッセージは、永続LCRまたは永続ユーザー・メッセージです。
メッセージ・クライアントを作成するには、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを実行するときにstreams_typeパラメータにdequeueを指定します。
ADD_MESSAGE_RULE
ADD_TABLE_RULES
ADD_SUBSET_RULES
ADD_SCHEMA_RULES
ADD_GLOBAL_RULES
メッセージ・クライアントを作成するとき、メッセージ・クライアントの名前と、メッセージ・クライアントがメッセージをデキューするANYDATAキューを指定します。これらのプロシージャを使用して、メッセージ・クライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットにルールを追加することもできます。ルールごとにメッセージ・タイプを指定すると、1つのメッセージ・クライアントで様々なタイプのメッセージをデキューできます。
メッセージ・クライアントを作成するユーザーは、そのメッセージ・クライアントを使用してキューからデキューする権限を付与されます。このユーザーは、メッセージ・クライアント・ユーザーです。メッセージ・クライアント・ユーザーは、メッセージ・クライアントのルール・セットを満たすメッセージをデキューできます。1つのメッセージ・クライアントを関連付けることができるのは1ユーザーだけですが、1人のユーザーには多数のメッセージ・クライアントを関連付けることができます。
図4-2に、メッセージをデキューするメッセージ・クライアントを示します。
|
関連項目:
|
手動デキューによる明示的コンシュームでは、アプリケーションはバッファLCR、永続LCR、バッファ・ユーザー・メッセージまたは永続ユーザー・メッセージを手動で明示的にデキューして処理します。メッセージがデキューされるキューは、ANYDATAキューまたは型付きキューです。DBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQパッケージを使用してメッセージをデキューできます。
Oracle Streamsアドバンスト・キューイングでは次のデキュー機能が使用できます。
バッファ・キューまたは永続キューからのデキュー
同時デキュー
デキュー方法
デキュー・モード
メッセージ配列のデキュー
メッセージの状態
デキュー時のメッセージの操作
メッセージの待機
遅延時の再試行
トランザクション保護（オプション）
例外キュー
|
関連項目:
|
