3 Oracle Streamsのステージングと伝播
3.1 メッセージのステージングと伝播の概要
Oracle Streamsでは、キューを使用してメッセージをステージングします。ステージングされたメッセージは、コンシュームまたは伝播(あるいはその両方)の対象になります。ステージングされたメッセージは、適用プロセス、メッセージ・クライアントまたはユーザー・アプリケーションでコンシュームできます。実行中の適用プロセスはメッセージを暗黙的にデキューしますが、メッセージ・クライアントとユーザー・アプリケーションはメッセージを明示的にデキューします。Oracle Streamsの伝播で他の1つ以上のキューへのメッセージの伝播(送信)を構成している場合、またはキューでメッセージの保存が指定されている場合は、メッセージがコンシュームされた後でも、キューに残ることができます。メッセージの保存は、同期取得で取得されたメッセージまたは明示的にエンキューされたメッセージに適用されます。取得プロセスで取得されたメッセージには適用されません。
3.2 キュー
キューは、メッセージ・システムがメッセージを格納するために使用する抽象的な記憶域単位です。この項には次のトピックが含まれます:
3.2.1 ANYDATAキューおよび型付きキュー
ANYDATA
タイプのキューは、ほとんどのタイプのメッセージをステージングでき、ANYDATAキューと呼ばれます。型付きキューは特定のタイプのメッセージをステージングできます。Oracle Streamsクライアントでは、常にANYDATA
キューを使用します。
Oracle Streamsレプリケーション環境では、論理変更レコード(LCR)をANYDATA
キューにステージングする必要があります。Oracle Streamsメッセージ環境では、ANYDATA
キューと型付きキューの両方がメッセージをステージングできます。パブリッシュ・アプリケーションはメッセージを1つのキューにエンキューでき、サブクライブ・アプリケーションがそれらのメッセージをデキューできます。
LCRとユーザー・メッセージという2種類のメッセージをANYDATA
オブジェクトにカプセル化してANYDATA
キューにステージングできます。LCRは、データベース・オブジェクトに対する変更に関する情報を格納するオブジェクトです。ユーザー・メッセージは、ユーザーまたはアプリケーションによって作成された、ユーザー定義型のメッセージです。どちらのタイプのメッセージも、単一データベース内またはデータベース間で情報を共有するために使用できます。
ANYDATA
キューは、ペイロードのタイプがANYDATA
のユーザー・メッセージをステージングできます。ANYDATA
ペイロードは、様々なデータ型のペイロードのラッパーとして使用できます。
メッセージのペイロードにANYDATA
ラッパーを使用すると、パブリッシュ・アプリケーションが様々なタイプのメッセージを1つのキューにエンキューでき、サブスクライブ・アプリケーションが、メッセージ・クライアントまたはアプリケーションを使用して明示的に、あるいは適用プロセスを使用して暗黙的に、それらのメッセージをデキューできます。サブスクライブ・アプリケーションがリモートの場合、メッセージをリモート・サイトに伝播することができ、サブスクライブ・アプリケーションがリモート・データベースのローカル・キューからメッセージをデキューできます。または、リモート・サブスクライブ・アプリケーションが、様々な標準プロトコル(PL/SQLやOCIなど)を使用してソース・キューからメッセージを直接デキューすることもできます。
ほぼすべての型のペイロードをANYDATA
ペイロードでラップできます。このためには、ANYDATA
タイプのConvert
data_type
静的関数を使用します。data_type
はラップするオブジェクトの型です。このような関数は入力としてオブジェクトを取り、ANYDATA
オブジェクトを返します。
Oracle StreamsにはOracle Databaseアドバンスト・キューイング(AQ)の機能が含まれ、マルチ・コンシューマ・キュー、パブリッシュおよびサブスクライブ、コンテンツベースのルーティング、インターネット伝播、変換、他のメッセージ・サブシステムへのゲートウェイなど、メッセージ・キューイング・システムの標準機能がすべてサポートされます。
関連項目:
-
「キューの制限事項」
-
ANYDATA
ラッパーでのペイロードのラップ、ANYDATA
キューへのメッセージのエンキューおよびデキューのためのプログラム的な環境、伝播およびユーザー定義型など、ANYDATA
キューの関連情報については、Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド を参照 -
ANYDATA
タイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照
3.2.2 永続キューとバッファ・キュー
Oracle Streamsでは、次のメッセージ・モードがサポートされています。
-
永続メッセージ機能: メッセージは、ディスク上のキュー表と呼ばれるデータベース表に常に格納されます。この記憶域のタイプは、永続キュー記憶域と呼ばれることがあります。
-
バッファ・メッセージ機能: メッセージは、メモリーに格納されますが、一定の条件でキュー表にあふれることがあります。この記憶域のタイプは、バッファ・キュー記憶域と呼ばれることがあります。このメモリーには、取得プロセスで取得されたメッセージまたはアプリケーションでエンキューされたメッセージを含むキューに関連付けられているOracle Streamsプール・メモリーが含まれます。
バッファ・キューを使用すると、Oracleでは、メッセージを常にキュー表に格納するのではなく、システム・グローバル領域(SGA)に格納することによって、メッセージを最適化できます。バッファ・メッセージ機能は、より高いパフォーマンスを提供しますが、メッセージ保持などの一部のメッセージ機能をサポートしません。メッセージ保持では、デキュー後にメッセージがキュー表に保持される時間を指定できます。
Oracle Streamsプールのサイズが自動的に管理されない場合は、データベースの各バッファ・キューに対してOracle Streamsプールのサイズを10MBずつ増やす必要があります。バッファ・キューによってパフォーマンスは改善されますが、バッファ・キューを含むインスタンスが正常または異常な状態で停止すると、バッファ・キューの一部の情報が失われることがあります。このような場合に、インスタンス上でデータベース全体のリカバリが実行されるとOracle Streamsは自動的にリカバリします。
バッファ・キューのメッセージがメモリーからオーバーフローしてキュー表に格納されるのは、メッセージがバッファ・キューにステージングされてから一定期間デキューされない場合か、すべてのメッセージを保持する十分な領域がメモリーにない場合です。メモリーからオーバーフローしたメッセージは、適切なAQ$_
queue_table_name
_p
表に格納されます。queue_table_name
はキューのキュー表の名前です。また、オーバーフローした各メッセージについては、メッセージの処理に使用できる伝播や適用プロセスに関する情報がAQ$_
queue_table_name
_d
表に格納されます。
取得プロセスで取得されたLCRは常にバッファ・キューに格納されますが、同期取得で取得されたLCRは常に永続キューに格納されます。バッファ・キューには、他のタイプのメッセージが格納されることがあります。アプリケーションがメッセージをエンキューすると、エンキュー操作によって、エンキューされたメッセージがバッファ・キューと永続キューのいずれに格納されるかが指定されます。DBMS_AQ.ENQUEUE
プロシージャのenqueue_options
パラメータのdelivery_mode
属性によって、メッセージがバッファ・キューと永続キューのどちらに格納されるかが決まります。具体的には、delivery_mode
属性がデフォルトのPERSISTENT
の場合、メッセージは永続キューにエンキューされます。この属性をBUFFERED
に設定すると、メッセージはバッファ・キューにエンキューされます。トランザクションがエラー・キューに移動される場合、そのトランザクションのすべてのメッセージはバッファ・キューではなく常にキュー表に格納されます。
注意:
バッファ・メッセージと永続メッセージを同一のキューに格納できます。1つのキューにバッファ部と永続部があると考えることをお薦めします。ここでは、各部分をバッファ・キューおよび永続キューと呼びます。ANYDATA
キューおよび型付きキューは、バッファ・キューと永続キューの両方を含むことができます。
関連項目:
-
Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
-
バッファ・メッセージ機能の概念および使用の詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
3.2.2.1 キューおよびOracle Streamsクライアント
Oracle Streamsクライアントでは、常にANYDATA
キューを使用します。次の項では、Oracle Streamsクライアントとキューの対話方法を説明します。
関連項目:
-
バッファ・メッセージ機能の概念および使用の詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
3.2.2.1.2 キューと同期取得
同期取得がLCRをエンキューできるのは永続キューにのみできます。同期取得によって取得されたLCRは、適用プロセス、メッセージ・クライアント、アプリケーションおよびユーザーによってデキューできます。
3.2.2.1.4 キューと適用プロセス
1つの適用プロセスは、バッファ・キューまたは永続キューのいずれかからメッセージをデキューできますが、両方からデキューすることはできません。適用プロセスでは、バッファ・キューの取得LCRをデキューおよび処理できます。取得LCRをデキューするには、適用プロセスの構成でapply_captured
パラメータをTRUE
に設定する必要があります。適用プロセスではバッファLCRまたはバッファ・ユーザー・メッセージをデキューできません。永続LCRまたは永続ユーザー・メッセージをデキューするには、適用プロセスの構成でapply_captured
パラメータをFALSE
に設定する必要があります。
3.2.2.1.5 キューとメッセージ・クライアント
メッセージ・クライアントでは、永続キューからのみメッセージをデキューできます。また、DBMS_STREAMS_MESSAGING
パッケージを使用してバッファ・キューにメッセージをエンキューしたり、バッファ・キューからメッセージをデキューすることはできません。
注意:
DBMS_AQ
およびDBMS_AQADM
パッケージは、バッファ・メッセージをサポートします。
関連項目:
DBMS_AQ
およびDBMS_AQADM
パッケージの使用の詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
3.3 キュー間でのメッセージの伝播
Oracle Streamsを使用すると、2つのキュー間でメッセージ伝播するように構成できます。これらのキューは、同じデータベースに存在することも異なるデータベースに存在することもできます。Oracle StreamsではOracle Schedulerジョブを使用してメッセージが伝播されます。
伝播は、常にソース・キューと宛先キューの間で行われます。伝播は常に2つのキュー間で行われますが、1つのキューが多数の伝播にかかわることができます。つまり、1つのソース・キューがメッセージを複数の宛先キューに伝播でき、1つの宛先キューが複数のソース・キューからメッセージを受信できます。また、1つのキューが、ある伝播の宛先キューと他の伝播のソース・キューを兼ねることができます。ただし、特定のソース・キューと特定の宛先キューの間で許可される伝播は1つのみです。
図3-1に、ソース・キューから宛先キューへの伝播を示します。
伝播の作成、変更および削除を行うことができます。また、伝播するメッセージを制御する伝播ルールを定義できます。ソース・キューを所有するユーザーが、メッセージを伝播するユーザーです。このユーザーは、メッセージの伝播に必要な権限を持っている必要があります。これには、次の権限が含まれます。
-
伝播で使用されるルール・セットの
EXECUTE
権限 -
ルール・セットで使用されるすべてのカスタム・ルールベースの変換ファンクションの
EXECUTE
権限 -
宛先キューのエンキュー権限(宛先キューが同じデータベースにある場合)
伝播によってメッセージがリモート・データベース内の宛先キューに伝播される場合、ソース・キューの所有者は、伝播で使用されるデータベース・リンクを使用できる必要があり、リモート・データベースでデータベース・リンクの接続先となるユーザーは、宛先キューに対するエンキュー権限を持っている必要があります。
伝播では、ソース・キューのすべてのメッセージを宛先キューに伝播することも、メッセージのサブセットのみを伝播することもできます。一度の伝播で、キューのバッファ・キュー部分および永続キュー部分の両方のメッセージを伝播できます。また、一度の伝播でLCRとユーザー・メッセージを伝播することもできます。ルールを使用して、ソース・キューから宛先キューに伝播するメッセージおよび破棄するメッセージを制御できます。
Oracle Streams環境の設定方法によっては、変更が発生元のサイトに送り返される場合があります。変更が無限ループで循環しないように環境を構成していることを確認してください。Oracle Streamsタグを使用すると、このような変更の循環ループを回避できます。
次の各項では、伝播についてさらに詳しく説明します。
関連項目:
-
Oracle Streams AQの伝播インフラストラクチャの詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
-
Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
3.3.1 伝播ルール
伝播は、ユーザーが定義するルールに基づいてメッセージを伝播または廃棄します。LCRの場合は、各ルールでTRUE
と評価するデータベース・オブジェクトと変更の種類を指定します。ユーザー・メッセージの場合は、特定のタイプのメッセージに対する伝播の動作を制御するルールを作成できます。これらのルールは、伝播で使用されるポジティブ・ルール・セットまたはネガティブ・ルール・セットに指定します。
ルールがメッセージをTRUE
と評価し、そのルールが伝播のポジティブ・ルール・セットに含まれる場合、伝播はその変更を伝播します。ルールがメッセージをTRUE
と評価し、そのルールが伝播のネガティブ・ルール・セットに含まれる場合、伝播はその変更を廃棄します。伝播にポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。
LCRの伝播ルールは次のレベルで指定できます。
-
表ルールは、特定の表に対するDML変更による行変更またはDDL変更を伝播または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。
-
スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を伝播または廃棄します。
-
グローバル・ルールは、ソース・キュー内のDML変更によるすべての行変更またはすべてのDDL変更を伝播または廃棄します。
条件を指定するキュー・サブスクライバによって、システムでルールが生成されます。キューのすべてのサブスクライバ用のルール・セットが組み合されて、サブスクリプションをより効率的にする1つのシステム生成ルール・セットとなります。
3.3.2 キュー・ツー・キュー伝播
伝播は、キュー・ツー・キューまたはキュー・ツー・データベース・リンク(キュー・ツーdblink)が可能です。キュー・ツー・キュー伝播は、独自の排他的な伝播ジョブを使用してメッセージをソース・キューから宛先キューに伝播します。各伝播ジョブには独自の伝播スケジュールがあるため、各キュー・ツー・キュー伝播は個別に管理することができます。複数のキュー・ツー・キュー伝播が同じデータベース・リンクを使用する場合でも、各伝播の無効化、有効化および伝播スケジュールの設定を個別に行うことができます。伝播ジョブについては次に詳しく説明します。
1つのデータベース・リンクは、複数のキュー・ツー・キュー伝播で使用できます。このデータベース・リンクを作成するときのサービス名には、宛先キューを含むデータベースのグローバル名を指定する必要があります。
反対に、キュー・ツーdblink伝播は、同じソース・キューの同じデータベース・リンクを使用するキュー・ツーdblink伝播と伝播ジョブを共有します。このため、これらの伝播は同じ伝播スケジュールを共有し、伝播スケジュールを変更すると、データベース・リンクを使用するソース・キューのすべてのキュー・ツーdblink伝播に影響します。
3.3.3 保証付きのメッセージ配信
取得LCRが宛先キューに正常に伝播されるのは、次の両方のアクションが完了した時点です。
他のタイプのメッセージが宛先キューに正常に伝播されるのは、宛先キューへのエンキューがコミットされた時点です。他のタイプのメッセージには、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよびバッファ・ユーザー・メッセージがあります。
2つのキュー間でメッセージが正常に伝播されると、宛先キューはそのことを確認します。ソース・キューが複数の宛先キューにメッセージを伝播するように構成されている場合は、各宛先キューがソース・キューにメッセージ伝播の確認を送信し終わるまで、メッセージはソース・キューに残ります。各宛先キューがメッセージの正常な伝播を確認し、ソース・キュー・データベース内のすべてのローカル・コンシューマがメッセージをコンシュームし終わると、ソース・キューはメッセージを削除できます。
この確認システムによって、メッセージが常にソース・キューから宛先キューに確実に伝播されますが、構成によってはソース・キューが最適サイズより大きくなる可能性があります。ソース・キューが大きくなると、システム・グローバル領域(SGA)メモリーの使用量が増加し、ディスク領域の使用量も増加する場合があります。
ソース・キューの拡大には、通常、次の2つの原因があります。
-
なんらかの理由(ネットワークの問題など)で、メッセージを指定された宛先キューに伝播できない場合、メッセージは宛先キューが使用可能になるまでソース・キューに残ります。この状況がソース・キューの拡大の原因となることがあります。そのため、キューを定期的に監視して問題を早期に検出する必要があります。
-
取得プロセスまたは同期取得によって取得されたメッセージをソース・キューが複数の宛先キューに伝播しており、1つ以上の宛先データベースが、他のキューよりもはるかに低速でメッセージが正常に伝播されたことを確認する場合を考えます。この場合、低速の宛先データベースでは、高速の宛先データベースによってすでに確認されたメッセージのバックログが作成されるため、ソース・キューが大きくなることがあります。このような環境では、複数の取得プロセスまたは同期取得を作成してソース・データベースでの変更を取得することを検討してください。これによって、あるソース・キューを低速の宛先データベースに、別のソース・キューを高速の宛先データベースに使用できます。
関連項目:
3.3.4 有向ネットワーク
有向ネットワークとは、伝播されるメッセージが宛先データベースに到達する前に1つ以上の中間データベースを経由するネットワークです。メッセージは、中間データベースで適用プロセスによって処理される場合と、処理されない場合があります。Oracle Streamsを使用すると、各宛先データベースに伝播させるメッセージを選択し、メッセージが宛先データベースに到達するまでのルートを指定できます。図3-2に、有向ネットワーク環境の例を示します。
有向ネットワークを使用する利点は、ソース・データベースと宛先データベースとの間に物理的なネットワーク接続を必要としないことです。そのため、メッセージをデータベース間で伝播する必要があるが、これらのデータベースを実行しているコンピュータ間にダイレクト・ネットワーク接続がない場合も、1つ以上の中間データベースがソース・データベースを宛先データベースに接続していれば、ネットワークを再構成せずにメッセージを伝播させることができます。
有向ネットワークを使用している場合に、中間サイトが長期間停止されるか、中間サイトが削除されると、ネットワークとOracle Streams環境の再構成が必要になることがあります。
3.3.4.1 キューによる転送と適用による転送
有向ネットワークにおける中間データベースでは、キューによる転送または適用による転送を使用してメッセージを伝播できます。キューによる転送は、中間データベースで転送されるメッセージが中間データベースによって受信されるメッセージであることを意味します。メッセージのソース・データベースは、メッセージが発生したデータベースです。
適用による転送は、中間データベースで転送されるメッセージが、最初に適用プロセスによって処理されることを意味します。このようなメッセージは、中間データベースで取得プロセスまたは同期取得によって再取得されてから転送されます。適用による転送を使用すると、中間データベースがメッセージの新しいソース・データベースになります。メッセージは、中間データベースで生成されたREDOログから取得プロセスによって再取得されるか、中間データベースで構成された同期取得によって再取得されます。
Oracle Streams環境を計画するときには、キューによる転送と適用による転送に次の違いがあることに注意してください。
-
キューによる転送を使用すると、取得または伝播に伴う変換がなければ、メッセージは変更されずにそのまま有向ネットワークを介して伝播されます。適用による転送を使用すると、メッセージは中間データベースで適用および再取得され、競合解消、適用ハンドラまたは適用変換によって変更される場合があります。
-
キューによる転送を使用する場合、宛先データベースでは、各ソース・データベースからのメッセージを個別の適用プロセスで適用する必要があります。適用による転送を使用すると、中間データベースでメッセージが再取得されることによって、変更が宛先データベースに到達する時点でソース・データベースの数が減少する場合があるため、宛先データベースに必要な適用プロセスの数が少数で済む可能性があります。
-
キューによる転送を使用する場合は、ソース・データベースと宛先データベースの間に1つ以上の中間データベースが位置します。適用による転送を使用する場合、メッセージは中間データベースで再取得されるため、メッセージのソース・データベースは、宛先データベースと直接接続している中間データベースと同じでもかまいません。
単一のOracle Streams環境で、キューによる転送と適用による転送を併用できます。
3.3.4.1.1 キューによる転送の利点
キューによる転送には、適用による転送と比較して次の利点があります。
-
メッセージが1回のみ取得されるため、パフォーマンスを改善できます。
-
1つ以上の中間データベースでメッセージが適用および再取得されることがないため、メッセージを生成元データベースから宛先データベースへと伝播させる所要時間が短縮されます。つまり、キューによる転送を使用すると、待機時間を短縮できる場合があります。
-
メッセージの発生元は、メッセージに含まれているLCRに対して
GET_SOURCE_DATABASE_NAME
メンバー・プロシージャを実行すると簡単に判断できます。適用による転送を使用する場合は、メッセージの発生元を判断するために、Oracle Streamsタグおよび適用ハンドラを使用する必要があります。 -
別々の適用プロセスを使用すると、依存性が低減し、複数の適用コーディネータと適用リーダー・プロセスによって作業が実行されるため、パラレル適用によってスケーラビリティが向上し、スループットが増大します。
-
1つの中間データベースが停止した場合、キューを再度ルーティングし、取得サイトで開始SCNをリセットして、エンドツーエンドの取得、伝播および適用を再構成できます。
適用による転送を使用すると、使用不可能になった中間データベースから宛先データベースへのダウンストリームでは、この中間データベースのSCN情報が使用されているため、メッセージについてエンドツーエンドの取得、伝播および適用の再構成に必要な作業量が実質的に増大します。このSCN情報がないと、宛先データベースでは変更を正しく適用できません。
3.3.4.1.2 適用による転送の利点
適用による転送には、キューによる転送と比較して次の利点があります。
-
各データベースは、複数のリモート・ソース・データベースではなく、直接接続されているデータベースからのみ変更を適用できるため、Oracle Streams環境の構成が容易です。
-
中間データベースによって変更が適用される大規模なOracle Streams環境では、適用プロセスが少数で済むため、環境の監視と管理が容易です。変更を適用する中間データベースでは、変更を受信するソース・データベースごとに1つの適.用プロセスが必要です。適用による転送の環境では、中間データベースのソース・データベースは、直接接続されているデータベースのみです。キューによる転送環境では、中間データベースのソース・データベースは、中間データベースに直接接続されているかどうかに関係なく環境内の他のすべてのデータベースです。
関連項目:
-
キューによる転送を使用する環境の例については、『Oracle Streams拡張例』を参照
-
適用による転送を使用する環境の例については、『Oracle Streamsレプリケーション管理者ガイド』を参照