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