| Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド 11gリリース1（11.1） E05782-01 |
|
 戻る |
 次へ |
この章では、Oracle Streams Advanced Queuing（AQ）、および統合環境での複雑な情報処理の要件について説明します。
この章の内容は次のとおりです。
Webベースのビジネス・アプリケーションが相互に通信する場合、プロデューサ・アプリケーションがメッセージをエンキューし、コンシューマ・アプリケーションがメッセージをデキューします。最も基本的なキューイングでは、1つのプロデューサが、1つのキューに1つ以上のメッセージをエンキューします。各メッセージは、1つのコンシューマによって1回のみデキューされ、処理されます。メッセージは、コンシューマによってデキューされるか、または期限が切れるまで、キュー内に保持されます。プロデューサは、メッセージが使用可能になるまでの遅延および期限切れを指定できます。同様に、デキュー時に使用可能なメッセージがない場合は、コンシューマは待機できます。エージェント・プログラムまたはアプリケーションは、プロデューサおよびコンシューマの両方で動作できます。
プロデューサは、メッセージをどのような順序でもエンキューできます。メッセージは、エンキューされた順序でデキューする必要はありません。メッセージは、デキューされなくてもエンキューできます。
やや複雑になると、多数のプロデューサがメッセージをキューにエンキューし、そのすべてのメッセージが1つのコンシューマによって処理されます。あるいは、多数のプロデューサがメッセージをエンキューし、個々のメッセージが型および相関識別子に応じて異なるコンシューマで処理されます。
エンキューされたメッセージは、別のキューで再生成されるときに伝播されると考えられています。別のキューは、同じデータベースまたはリモート・データベースに存在します。
アプリケーションでは一般に、様々なフォーマットのデータが使用されます。変換は、1つのデータ型から別のデータ型へのマッピングを定義します。変換は、ソース・データ型を入力として取得し、ターゲット・データ型のオブジェクトを戻すSQLファンクションによって表現されます。メッセージの変換は、メッセージがエンキューされるとき、デキューされるとき、またはリモート・サブスクライバに伝播されるときに行われるように設定できます。
Oracle Streams AQは、データベースと統合されたメッセージ・キューイング機能を提供します。これはOracle Streamsに組み込まれており、Oracle Databaseの機能を有効活用して、メッセージを永続的に格納し、異なるコンピュータやデータベース上のキュー間でメッセージを伝播し、Oracle Net ServicesとHTTP（S）を使用してメッセージを転送します。
Oracle Streams AQはデータベース表内に実装されるため、高可用性、拡張性および信頼性という操作上のすべてのメリットが、キュー・データに適用されます。Oracle Streams AQでは、リカバリ、再起動、セキュリティなどの標準のデータベース機能がサポートされます。Oracle Enterprise Managerなどのデータベース開発ツールおよびデータベース管理ツールを使用して、キューを監視できます。他のデータベース表と同様に、キュー表もインポートおよびエクスポートできます。
標準のSQLを使用してメッセージを問い合せることができます。ユーザーはSQLを使用して、メッセージのプロパティ、履歴およびペイロードにアクセスできます。また、SQLアクセスを使用すると、監査および追跡も行うことができます。索引機能などの使用可能なすべてのSQLテクノロジを使用してメッセージへのアクセスを最適化できます。
|
注意: Oracle Streams AQは、キュー表または対応する索引構成表（IOT）に対するデータ操作言語（DML）操作をサポートしていません。キュー表を修正するためにサポートされている唯一の手段は、提供されているAPIを使用することです。キュー表やIOTは、DML操作を行うと一貫性がなくなり、実質的に破損する可能性があります。 |
Oracle Streams AQは、あらゆるキューイング操作に対するシステム・レベルのアクセス制御に対応しているため、アプリケーション設計者またはDBAが、ユーザーをキュー管理者として指定できます。キュー管理者は、データベースのどのキューに対しても、Oracle Streams AQインタフェース（管理および操作）を起動できます。これによって、データベース上のキュー全体に対するすべての管理スクリプトを1つのスキーマで管理できるため、管理作業が容易になります。
Oracle Streams AQでは、エンキュー操作およびデキュー操作に対するキュー・レベルのアクセス制御がサポートされています。この機能によって、アプリケーション設計者は、あるスキーマに作成されたキューを、他のスキーマで実行中のアプリケーションから保護することができます。アプリケーション設計者は、キューのスキーマ外で実行中のアプリケーションに対して、最小限のアクセス権限のみを付与できます。
「サービスに対するリクエスト」と「サービスの供給」を分離することによって、効率を向上させ、複雑なスケジューリングを有効化する必要があります。Oracle Streams AQは、次の基準で測定した場合、高いパフォーマンスを示します。
1秒間にエンキューおよびデキューされるメッセージ数
メッセージ・ウェアハウスに対する複雑な問合せの評価にかかる時間
障害後にメッセージ処理のリカバリおよび再起動にかかる時間
キューイング・システムはスケーラブルである必要があります。Oracle Streams AQは、アプリケーションを使用するプログラム数が増加しても、メッセージ数が増加しても、またメッセージ・ウェアハウスのサイズが増加しても、高いパフォーマンスを実現します。
ネットワーク、コンピュータおよびアプリケーションに障害が発生したときに、遅延実行を正常に動作させるには、サービスに対するリクエストで構成されるメッセージを永続的に格納し、確実に1回のみ処理する必要があります。Oracle Streams AQは、次の場合に要件を満たすことができます。
アプリケーションに、外部クライアントまたは内部プログラムから同時に到着する、複数の未処理メッセージを処理するためのリソースがない場合。
データベース間の通信リンクが、常に使用可能なわけではなく、他の用途に確保されている場合。システム容量が不足しているためにメッセージをすぐに処理できない場合、アプリケーションは、処理可能になるまでそのメッセージを保存する必要があります。
外部クライアントまたは内部プログラムが、処理済メッセージを受信する準備ができていない場合。
キューイング・システムは、優先順位を処理する必要があります。この優先順位は、次のように変化する可能性があります。
後から到着したメッセージは、先に到着したメッセージより高い優先順位になります。
メッセージは、後のメッセージを待ってからアクションを実行できます。
同一のメッセージに異なるプロセスからアクセスできます。
特定のキューにあるメッセージがより重要になり、遅延や他のキューのメッセージからの介入を減らして処理する必要性が生じる場合もあります。
ある受信者へのメッセージ送信が、他の受信者への送信より優先順位が高くなる場合があります。
メッセージのメタデータがペイロード・データと同様に重要になる場合があるため、キューイング・システムはメッセージのメタデータを保存する必要があります。たとえば、メッセージの受信時刻またはディスパッチ時刻が、ビジネスや正当な理由から重要になることがあります。Oracle Streams AQの永続性機能を使用すると、最大需要の周期の分析、または注文を受信してから処理を完了するまでのタイムラグの評価を行うことができます。
Oracle Streams AQは、キュー・タイプが抽象データ型（ADT）のエンキュー、デキューおよび伝播操作をサポートします。型が基本ADTの継承型の場合は、エンキューおよびデキュー操作もサポートします。型が基本ADTから継承される2つのキュー間の伝播はサポートされていません。
Oracle Streams AQは、ANYDATAキューもサポートします。このキューを使用すると、アプリケーションは1つのキュー内で様々なメッセージ型をエンキューできます。
ユーザー定義型メッセージをエンキュー、伝播またはデキューする場合は、これらのメッセージで使用される各型が、メッセージをキューにエンキューできる各データベースに存在する必要があります。環境によっては有向ネットワークを使用して、中間データベースを介してメッセージをルーティングしてから宛先に配信する場合があります。そのような環境の場合は、対応する型のメッセージが特定の中間データベースにエンキューまたはデキューされない場合でも、各中間データベースにその型が存在する必要があります。
さらに、各型に対して次の要件が満たされる必要があります。
型名が各データベースで同じであること。
型が各データベースの同じスキーマにあること。
型の形状が各データベースで完全に一致していること。
どのデータベースにおいても、型に継承または型進化を使用できないこと。
型に、VARRAY、ネストした表、LOB、ROWIDまたはUROWIDが含まれないこと。
オブジェクト識別子は各データベースで一致する必要はありません。
ユーザーは、オブジェクト型を使用してメッセージ・ペイロードを構造化および管理できます。一般にリレーショナル・データベース・システムは、メッセージ・システムより豊富な型指定のシステムを備えています。Oracle Databaseはオブジェクト・リレーショナル・データベース・システムであるため、従来のリレーショナル型とユーザー定義型をサポートします。強力な型指定を持つ内容（外部の型指定システムによって定義されたフォーマットを持つ内容など）によって、多くの高性能な機能が使用できます。これらの機能には、次のものがあります。
内容ベースのルーティング
Oracle Streams AQで内容を調査し、その内容に基づいてメッセージを別のキューに自動的にルーティングできます。
内容ベースのサブスクリプション
パブリッシュ・サブスクライブ・システムがメッセージ・システム上に組み込まれているため、内容に基づいてサブスクリプションを作成できます。
問合せ
メッセージの内容を問い合せることができるため、メッセージ・ウェアハウスが可能です。
新しい不透明な型であるXMLTypeを使用するキューを作成できます。これらのキューは、XML文書であるメッセージを転送および格納するために使用できます。XMLTypeを使用すると、次の操作を実行できます。
任意の型のメッセージをキューに格納する。
ドキュメントをCLOBオブジェクトとして内部的に格納する。
複数の型のペイロードをキューに格納する。
ExistsNode()演算子を使用してXMLType列を問い合せる。
サブスクライバ・ルールまたはデキュー条件にその演算子を指定する。
キューに関するシステム・イベント、ユーザー・イベントおよび通知をOracle Internet Directoryに登録できます。システム・イベントは、データベースの起動、データベースの停止およびシステム・エラー・イベントです。ユーザー・イベントには、ユーザー・ログインとユーザー・ログオフ、DDL文（CREATE、DROP、ALTER）およびDML文トリガーがあります。キューに関する通知には、OCI通知、PL/SQL通知および電子メールによる通知があります。
Oracle Internet Directory内のOracle Streams AQエージェントに別名を作成することもできます。これらの別名は、Oracle Streams AQ操作（エンキュー、デキューおよび通知）の実行中に指定できます。これは、内部エージェント名を非公開にする必要があるときに有効です。
Oracle Real Application Clustersのサポート
Real Application Clustersを使用すると、異なるキューを別々のインスタンスによって管理できるようにすることでOracle Streams AQのパフォーマンスを改善できます。このためには、キューを格納するキュー表に様々なインスタンス・アフィニティ（作業環境）を指定します。これによって、様々なキューに対する操作（エンキューおよびデキュー）をパラレルで行うことができるようになります。
互換性をOracle8iリリース8.1.5以上に設定すると、アプリケーションはキュー表に対してインスタンス・アフィニティを指定できます。Oracle Streams AQをReal Application Clustersと複数のインスタンスで使用する場合、この情報を使用してインスタンス間のキュー表をパーティション化して、伝播用のみでなくキュー・モニターのスケジューリングも行うことができます。キュー表は、ユーザーが指定したインスタンスのキュー・モニターによって監視されます。キュー表の所有が終了すると、セカンダリ・インスタンスまたはいずれかの使用可能なインスタンスがキュー表の所有権を引き継ぎます。
インスタンス・アフィニティが指定されないと、キュー表は、使用可能なインスタンス間で任意にパーティション化されることになります。これにより、キュー表にアクセスするアプリケーションとそれを監視するキュー・モニターの間で、pingが発生する可能性があります。インスタンス・アフィニティを指定すると、これを回避できますが、そのアプリケーションが他のインスタンスから、キュー表とそのキューにアクセスできなくなることはありません。
Oracle Streams AQを使用すると、アプリケーションの統合に必要なメッセージ管理と通信が可能になります。統合環境では、図1-1に示すように、メッセージはOracle Databaseサーバーとアプリケーション間およびOracle Databaseサーバーとユーザー間を移動します。
メッセージは、Oracle Net Servicesを使用して、クライアントとOracle Databaseサーバー間または2つのOracle Databaseサーバー間で交換されます。Oracle Net Servicesはまた、あるOracle Databaseキューから別のOracle Databaseキューへのメッセージの伝播も行います。さらに、図1-1に示すように、Oracle Streams AQの操作は、HTTP（S）を使用してインターネット経由で行うこともできます。この場合、クライアント、ユーザーまたはインターネット・アプリケーションは構造化XMLメッセージを生成します。インターネット経由の伝播では、Oracle Databaseサーバーも構造化XMLを使用して通信します。
アプリケーションの統合には、異機種間のメッセージ・システムの統合も含まれます。Oracle Streams AQは、メッセージ・ゲートウェイを介して、IBM Websphere MQなどのOracle Database以外の既存のメッセージ・システムと透過的に統合されるため、既存のWebsphere MQベースのアプリケーションもOracle Streams AQ環境に統合できます。
内容は次のとおりです。
クライアント/サーバー・アプリケーションは通常同期方式で実行されます。図1-2は、Oracle Streams AQを使用した非同期での実行例を示しています。この例では、アプリケーションB（サーバー）は、リクエスト・キューまたはレスポンス・キューを使用して、アプリケーションA（クライアント）にサービスを提供しています。
アプリケーションAは、リクエストをリクエスト・キューにエンキューします。別のトランザクションで、アプリケーションBは、リクエストをデキューして処理します。アプリケーションBは、その結果をレスポンス・キューにエンキューし、アプリケーションAは引き続き別のトランザクションで、エンキューされた結果をデキューします。
クライアントはサーバーとのコネクションの確立を待つ必要はなく、サーバーは独自の処理タイミングでメッセージをデキューします。サーバーによるメッセージ処理が終了したとき、クライアントは結果を受け取るまで待つ必要はありません。このような二重遅延処理により、クライアントとサーバーはどちらも自由に処理を実行できます。
メッセージは、一度に1つのキューにしか入れることができません。複数のコンシューマに送信するために、プロデューサから同じメッセージを複数のキューに挿入する必要がある場合は、非常に大量のキューを管理する必要があります。複数のコンシューマが同じメッセージをデキューできるように、Oracle Streams AQにはキューのサブスクライバとメッセージの受信者が用意されています。
サブスクライバ・リストおよび受信者リストを可能にするために、複数のコンシューマ・オプションを使用して作成されたキュー表にキューを常駐させる必要があります。各メッセージは、所定のすべてのコンシューマによって処理されるまで、キュー内にとどまります。
複数のコンシューマ（アプリケーションまたはその他のキュー）は、サブスクライバとして1つのキューに関連付けることができます。これにより、キューにエンキューされたすべてのメッセージを、それぞれのキューのサブスクライバが使用できるようになります。キューに対応するサブスクライバは、メッセージまたはメッセージ・プロデューサを変更することなく、動的に変更できます。
シングル・コンシューマ・キューまたは例外キューには、サブスクリプションを追加できません。あるキューにサブスクライバとして追加されたコンシューマは、サブスクライバが追加された後にエンキューされたメッセージのみデキューできます。2つのサブスクライバが名前、アドレスおよびプロトコルに同じ値を持つことはできません。この3つの属性のうち少なくとも1つは、2つのサブスクライバに対して異なる値にする必要があります。
サブスクライバ間には優先順位がないため、どのサブスクライバがどのメッセージをどのような順番でデキューするかはわかりません。つまり、サブスクライバによるデキューの順序は予想できません。
サブスクライバをルールベースにすることもできます。SQL問合せのWHERE句の構文と同様、ルールはメッセージ・プロパティまたはメッセージ内容を示す属性によって表現されます。このようなサブスクライバ・ルールが、着信メッセージに対して評価され、一致したルールを使用してメッセージ受信者が判断されます。
図1-3は、アプリケーションBとアプリケーションCのそれぞれがアプリケーションAで生成されたメッセージを必要としているため、アプリケーションBとアプリケーションCにはキューのサブスクライバとして、マルチ・コンシューマ・キューが特別に構成されています。これにより、それぞれのアプリケーションで、キューに格納されたあらゆるメッセージを受信できるようになります。
メッセージ・プロデューサは、メッセージがエンキューされた時点で受信者リストを送ることができます。これによって、キュー内の各メッセージに、受信者の一意の集合を対応付けることができます。メッセージに対応付けられた受信者リストは、キューに対応付けられたサブスクライバ・リストが存在する場合には、それをオーバーライドします。受信者は、サブスクライバ・リストに含まれている必要はありません。ただし、受信者はサブスクライバの中から選択できます。
受信者は名前のみで指定できますが、この方法で指定された受信者は、メッセージがエンキューされたキューからメッセージをデキューする必要があります。プロトコルの値が0（ゼロ）の場合、名前およびアドレスで受信者を指定できます。アドレスは、同じデータベース内またはデータベース・リンクによって識別された他のOracle Database内の別のキューの名前になります。この場合、メッセージは指定されたキューに伝播され、指定された名前のコンシューマによってデキューされます。受信者の名前がNULLの場合、メッセージはアドレスに指定されたキューに伝播され、アドレスに指定されたキューのサブスクライバによってデキューされます。プロトコル・フィールドの値が0（ゼロ）でない場合、名前およびアドレスのフィールドはシステムにより無視され、メッセージは特定のコンシューマによってデキューされます。
キューのサブスクライブは雑誌の予約講読と類似しています。各雑誌の購読者がその雑誌のすべての記事にアクセスできるのと同様に、各サブスクライバは特定のキューに格納されたすべてのメッセージをデキューできます。一方、受信者は、手紙の受取人と類似しています。各受信者は、特定のメッセージの宛先として指定されます。
図1-4は、Oracle Streams AQによる両タイプのコンシューマへの対応方法を示しています。アプリケーションAはメッセージをエンキューします。アプリケーションBとアプリケーションCはサブスクライバです。ただし、メッセージは、キューのサブスクライバであるかどうかにかかわらず、アプリケーションDのような受信者に明示的に転送することもできます。このような特定のメッセージに関する受信者のリストは、そのメッセージのエンキュー・コールで指定されます。そして、そのキューのサブスクライバのリストをオーバーライドします。
|
注意: 複数のプロデューサによって、異なる受信者に宛てられたメッセージが同時にエンキューされる場合があります。 |
図1-5では、ワークフローの実装（連鎖したアプリケーション・トランザクションともいう）にOracle Streams AQが使用されています。
ワークフローは、アプリケーションAがメッセージ1をエンキューすることによって開始されます。
アプリケーションBはそのメッセージをデキューして、必要なアクティビティをすべて実行し、メッセージ2をエンキューします。
アプリケーションCはメッセージ2をデキューして、メッセージ3を生成します。
アプリケーションDはワークフローの最後のステップとして、メッセージ3をデキューします。
|
注意: メッセージ1、2および3の内容は同一の場合も異なる場合もあります。異なるメッセージの場合でも、あるメッセージに前のメッセージの内容が一部含まれることがあります。 |
キューは、ビジネス・プロセスの各段階での情報の流れをバッファするために使用されます。メッセージの遅延間隔および期限切れを指定することで、各アプリケーションに実行枠を設定できます。
ワークフローの観点から、メッセージ・フローのボリュームとタイミングに関する知識は、ペイロード・データの価値に加えて1つの業務資産となります。Oracle Streams AQでは、この知識を得るための手段として、メッセージを保存できるオプションを用意することで、過去の傾向を分析して今後の動向を予測できるようにしています。
Point-to-Pointメッセージは、特定のターゲットを対象としています。送信者および受信者は、メッセージ交換に使用する共通キューを決定します。各メッセージは、1人の受信者によってのみ処理されます。図1-6は、各アプリケーションにシングル・コンシューマ・キューと呼ばれる独自のメッセージ・キューがあることを示しています。
パブリッシュ・サブスクライブ・メッセージは、図1-7に示すように、複数の受信者によって使用される場合があります。パブリッシュ・サブスクライブ・メッセージ機能には、伝播範囲が広いブロードキャストと呼ばれるモードと、伝播範囲が狭いマルチキャストと呼ばれるモードがあります。
ブロードキャストは、番組の視聴者を正確に把握していないラジオ放送局と類似しています。デキューを行うのはマルチ・コンシューマ・キューのサブスクライバです。それとは対照的に、マルチキャストは、購読者を把握している雑誌の出版社に類似しています。マルチキャストは、1つのパブリッシャが複数の受信者にメッセージを送信するため、Point-to-Multipointとも呼ばれます。この受信者は、交換メカニズムとして機能するキューのサブスクライバである場合と、そうでない場合があります。
パブリッシュ・サブスクライブでは、パブリッシャ・アプリケーションが匿名で（受信者を指定せずに）キューにメッセージをエンキューする状況を記述します。エンキューされたメッセージは、アプリケーションごとに指定されたルールに基づいてサブスクライバ・アプリケーションに配信されます。ルールは、メッセージ・プロパティ、メッセージ・データの内容、またはその両方に対して定義できます。
Oracle Streams AQを使用した、パブリッシュ・サブスクライブ・モデルの通信を実装するには、次の手順に従います。
メッセージを保持するために1つまたは複数のキューを設定します。このキューは、関心がある領域またはサブジェクトを表しています。たとえば、あるキューは請求済注文を表すために使用される可能性があります。
ルールベースのサブスクライバを1組設定します。各サブスクライバは、受信を希望するメッセージの仕様（ルール）を指定できます。NULLルールは、サブスクライバがすべてのメッセージの受信を希望することを意味します。
パブリッシャ・アプリケーションが、エンキュー・コールをコールしてキューにメッセージをパブリッシュします。
サブスクライバ・アプリケーションは、DEQUEUEコールでメッセージを受信できます。これにより、サブスクリプションの基準に合うメッセージが取り出されます。
サブスクライバ・アプリケーションは、LISTENコールを使用して、様々なキューに対するサブスクリプションを複数のキューで監視することもできます。これは、サブスクライバ・アプリケーションが多数のキューにサブスクライブしていて、どのキューに届いたメッセージでも受信する場合には、非常にスケーラブルなソリューションです。
サブスクライバ・アプリケーションは、Oracle Call Interface（OCI）通知メカニズムを使用することもできます。これによって、プッシュ・モードのメッセージ配信が可能になります。サブスクライバ・アプリケーションは、メッセージの受信元となるキュー（およびサブスクライブ・エージェントとして指定されるサブスクリプション）を登録します。これによって、サブスクリプションに一致するメッセージが届いたときに、コールされるコールバックが登録されます。
図1-8は、Oracle Streams AQを使用して、パブリッシャ・アプリケーションAと、サブスクライバ・アプリケーションB、C、Dとの間にパブリッシュ・サブスクライブ関係を実装します。
アプリケーションBはルール「priority = 1」に基づいてサブスクライブします。
アプリケーションCはルール「priority > 1」に基づいてサブスクライブします。
アプリケーションDはルール「priority = 3」に基づいてサブスクライブします。
アプリケーションAがそれぞれ優先順位1、2および3に基づいて3つのメッセージをエンキューすると、各メッセージは次のように配信されます。
アプリケーションBは、1つのメッセージ（優先順位が1）を受信します。
アプリケーションCは、2つのメッセージ（優先順位が2、3）を受信します。
アプリケーションDは、1つのメッセージ（優先順位が3）を受信します。
バッファ済メッセージは、Oracle Streams AQ10gリリース2（10.2）の新機能であり、豊富な機能を組み合せることで、この製品で常により高速なキューイングが実装できます。バッファ済メッセージは、Oracle Streams AQ永続メッセージの信頼性とトランザクション・サポートを必要としないアプリケーションに理想的です。
バッファ済メッセージが永続メッセージよりも高速なのは、メッセージが共有メモリーに常駐するためです。通常、ディスクに書き込まれるのは、バッファ済メッセージのメモリー使用量合計が使用可能な共有メモリーの上限に達した場合のみです。
|
注意: メモリー内でバッファ済メッセージを格納するキューの部分は、バッファ済キューと呼ばれることもあります。 |
バッファ済メッセージでは、メッセージの保存はサポートされていません。
バッファ済メッセージを使用する場合は、次のいずれかを実行することをお薦めします。
このパラメータは、Oracle Streams AQに使用できる共有メモリーのサイズを制御します。指定しなかった場合は、共有プール・サイズの最大10%がデータベース・キャッシュからOracle Streams AQプールに割り当てられます。
SGA自動チューニングのオン
Oracle Streams AQの使用量およびSGAを使用するその他のコンポーネントの使用量に基づいて、SGAからOracle Streams AQに適切な量のメモリーが自動的に割り当てられます。その他のコンポーネントには、バッファ・キャッシュ、ライブラリ・キャッシュなどがあります。streams_pool_sizeを指定した場合は、下限として使用されます。
|
関連項目: 『Oracle Streams概要および管理』のStreamsに関連する初期化パラメータの設定に関する項 |
内容は次のとおりです。
バッファ済メッセージと永続メッセージは、同じシングル・コンシューマ・キューまたはマルチ・コンシューマ・キュー、および同じ管理インタフェースと操作インタフェースを使用します。バッファ済メッセージと永続メッセージは、メッセージをOracle Streams AQキューにエンキューするときにアプリケーションで設定される、配信モード・パラメータによって区別されます。
バッファ済メッセージ・エンキューでは、受信者リストがサポートされています。
バッファ済メッセージは、8.1以上と互換性がある作成済のすべてのキュー表でサポートされます。このリリースのバッファ済メッセージでは、グループ化トランザクション・キューおよび配列のエンキューはサポートされていません。配列エンキュー・プロシージャを使用してバッファ済メッセージをエンキューすることはできますが、配列サイズを1に設定する必要があります。
バッファ済メッセージは、AQ$Queue_Table_Nameビューを使用して問い合せることができます。バッファ済メッセージは、IN-MEMORYまたはSPILLED状態で表示されます。
バッファ済メッセージのキュー・タイプは、ADT、XML、ANYDATAまたはRAWです。LOB属性を持つADTタイプの場合、NULLのLOB属性を持つバッファ済メッセージのみエンキューできます。
永続メッセージに使用できる順序付けスキームはすべて、バッファ済メッセージにも使用できますが、使用できるのは各メッセージ・クラス内のみです。同じセッション内でエンキューされた永続メッセージとバッファ済メッセージ間の順序付けは、現在はサポートされていません。
バッファ済メッセージのエンキューおよびデキュー操作は、IMMEDIATE可視性モードで実行する必要があります。したがって、これらの操作は別のトランザクションの一部にはなりません。バッファ済メッセージをエンキューする場合、遅延を指定することはできません。
バッファ済メッセージでは、ルールベースのサブスクリプションがサポートされています。サブスクライバを追加する手順の拡張により、アプリケーションで永続メッセージのみ、バッファ済メッセージのみ、またはその両方を対象とするよう選択できます。
バッファ済メッセージの場合、配列のデキューはサポートされていませんが、配列サイズを1メッセージに設定すると、引き続き配列デキュー・プロシージャを使用できます。
アプリケーションのデキューでは、永続メッセージのみ、バッファ済メッセージのみ、または両方のデキューを選択できます。バッファ済メッセージをデキューする場合は、可視性をIMMEDIATEに設定する必要があります。次に示すすべてのデキュー・オプションがサポートされています。
デキュー・モードBROWSE、LOCK、REMOVEおよびREMOVE_NO_DATA
ナビゲーション・モードFIRST_MESSAGEおよびNEXT_MESSAGE
相関識別子
デキューの条件
メッセージ識別子
バッファ済メッセージの伝播がサポートされています。1つの伝播スケジュールで永続メッセージとバッファ済メッセージの両方が処理されます。DBA_QUEUE_SCHEDULESビューには、統計およびエラー情報が表示されます。
バッファ済メッセージは、リモート・サイトに伝播されると、Oracle Streams AQにより削除されます。メッセージが使用される前に受信サイトが失敗した場合、これらのメッセージは失われます。ソース・サイトはメッセージを再送信できません。メッセージの重複配信も可能です。
Oracle Streams AQは、アプリケーションの共有メモリーがメッセージで一杯にならないようにするフロー制御システムを実装します。メッセージ送信者によってエンキューされた未読メッセージの数が、システムで決定された制限を超えると、サブスクライバの1つがメッセージの一部を読み取るまでメッセージ送信者がブロックされます。メッセージ送信者は、エンキュー・オプションのsender_id.nameで識別されます。キューのフロー制御によってブロックされた送信者は、その他のメッセージ送信者には影響しません。
フロー制御を使用しても、マルチ・コンシューマ・キューのコンシューマが低速の場合、メモリー内に格納されるメッセージの数が無制限に増える可能性があります。この場合、メモリーを解放するために古いメッセージがディスクに移され、Oracle Streams AQプールから削除されます。これにより、低速のコンシューマがディスク・アクセスのコストを負担し、高速のサブスクライバは妨害されずに作業を続行できます。
Real Application Clusters（RAC）を持つバッファ済メッセージ
アプリケーションは、パスワード・ベースの認証を使用してデータベースに接続するかぎり、RACインスタンスからバッファ済メッセージをエンキューおよびデキューできます。バッファ済メッセージに必要な構造は、1つのRACインスタンスに実装されます。バッファ済メッセージ構造が実装されるインスタンスは、キューを格納するキュー表のOWNER_INSTANCEです。その他のインスタンスで受信されたエンキューおよびデキュー・リクエストは、インターコネクトによってOWNER_INSTANCEに転送されます。listener.oraのREMOTE_LISTENERパラメータも設定して、バッファ済メッセージ・リクエストを正しいインスタンスに転送できるようにする必要があります。
|
関連項目:
|
サービス名はRACの各キューに関連付けられ、DBA_QUEUESおよびUSER_QUEUESビューに表示されます。このサービス名は、常にバッファ済メッセージに最も効率的にアクセスできるインスタンスを指し、インスタンス間のping操作を最小限に抑えます。OCIクライアントは、サービス名を使用してバッファ済メッセージ操作を実行します。
キューからキューへの伝播でバッファ済メッセージを使用することをお薦めします。これにより、メッセージを宛先RACシステムに伝播するときに、透過的なフェイルオーバーが行われます。プライマリOracle Streams AQ RACインスタンスに障害が発生した場合に、データベース・リンクを再度指定する必要がありません。
現在、バッファ済メッセージでは、次のOracle Streams AQの機能はサポートされていません。
メッセージの保存
メッセージの遅延
グループ化トランザクション
配列のエンキュー
配列のデキュー
メッセージのエクスポートおよびインポート
サブスクライバの通知の転送
メッセージ・ゲートウェイ
バッファ済メッセージでは、再試行回数および再試行遅延はサポートされていません。メッセージの期限切れはサポートされています。バッファ済メッセージが有効期限をすぎてもキューに残っている場合、永続メッセージとして例外キューに移されます。
非同期通知によって、クライアントは、関心があるメッセージの通知を受信できます。このクライアントは、これらの通知を使用して複数のサブスクリプションを監視できます。クライアントは、自分自身のサブスクリプションに関する通知を受け取るためにデータベースと接続している必要はありません。バッファ済メッセージでは、非同期通知がサポートされています。メッセージの配信モードは、通知記述子のメッセージ記述子で使用できます。
|
注意: Oracle Database 10gリリース2（10.2）より前のリリースでは、31文字以上の名前を持つキューの場合、Oracle Streams AQの通知機能はサポートされませんでした。この制限は適用されなくなりました。ユーザー生成キューの名前には、引き続き24文字という制限が適用されます。「キューの作成」を参照してください。 |
クライアントは、各メッセージごとに実行されるコールバック関数を指定します。非同期通知を使用して実行可能ファイルを起動することはできませんが、コールバック関数でストアド・プロシージャを起動することはできます。
クライアントは、PL/SQL、Java Message Service（JMS）またはOCIコールバック関数を使用してプロシージャで通知を受信するか、電子メールまたはHTTPのPOSTを介して通知を受信できます。クライアントは、通知の表現をRAWまたはXMLのいずれかに指定することもできます。
JMSキューでは、通知の一部としてデキューが行われるため、明示的デキューの必要はありません。RAWキューでは、クライアントはペイロード配信を指定できますが、REMOVE_NO_DATAモードでメッセージをデキューする必要があります。その他のすべての永続キューでは、通知にはメッセージ・プロパティのみが含まれ、クライアントは明示的にデキューしてメッセージを受信します。
RAWキューの場合、Oracle Streams AQクライアントは、通知とともにメッセージ・ペイロードが配信されるように指定できます。
Oracle Streams AQの以前のリリースでは、メッセージ通知は共有メモリーに格納され、インスタンスが失敗した場合には失われていました。現在、クライアントは永続メッセージ通知を指定できます。RACインスタンスが失敗した場合は、別のRACノードによって通知が配信されます。スタンドアロン・インスタンスが失敗した場合は、インスタンスの再起動時に通知が配信されます。
|
注意: 通知の信頼性では、サーバーの障害のみを参照します。Oracle Streams AQがその他の理由でクライアント通知を配信できない場合、通知はクライアント登録とともにパージされます。 |
Oracle Streams AQクライアントは、OCIサブスクリプション・ハンドル属性OCI_ATTR_SUBSCR_PORTNOを使用して、通知が配信されるポートを指定できます。これは、ファイアウォールの背後にあるコンピュータ上のクライアントに対して特に有効です。リスナー・スレッドのポートは、最初の登録の前に環境ハンドル内の属性を使用して指定できます。スレッドは、初めてOCISubscriptionRegisterがコールされたときに開始されます。クライアントが別の環境ハンドルを使用して別のポートで別のスレッドを開始しようとすると、Oracle Streams AQはエラーを戻します。
|
注意: 指定ポート通知は、OCIクライアントにのみ適用されます。 |
|
関連項目: 『Oracle Call Interfaceプログラマーズ・ガイド』のOCIのパブリッシュ・サブスクライブ登録機能に関する項 |
Oracle Streams AQの以前のリリースでは、通知の登録は、クライアントによって明示的に削除されるか、拡張クライアントの障害によりパージされるまで保持されていました。Oracle Streams AQ 10gリリース2（10.2）では、クライアントは一定期間登録した後、登録は自動的にパージされます。
登録がパージされると、Oracle Streams AQはクライアントに通知を送信するため、クライアントはコールバックを起動して、必要なアクションを実行できます。
クライアントは、最初の通知のみ受信するように登録することもできます。その後、登録は自動的にパージされます。
通知のパージが有効な場合の例は、エンキューの開始を待機しているクライアントです。この場合、最初の通知のみが有効であり、後続の通知は追加情報を提供しません。以前は、このクライアントはエンキューの開始後に登録解除する必要がありました。現在は、登録は自動的に解除されるように構成できます。
クライアントは、バッファ済メッセージの通知を登録できます。登録リクエストは、バッファ済メッセージと永続メッセージの両方に適用されます。PL/SQLまたはOCI通知とともに配信されるメッセージ・プロパティは、メッセージがバッファ済か永続かどうかを指定します。
|
関連項目:
|
信頼できる通知はサポートされていません。
ディクショナリ・ビューDBA_SUBSCR_REGISTRATIONSおよびUSER_SUBSCR_REGISTRATIONSは、システム内の各種登録を示します。診断ビューGV$SUBSCR_REGISTRATION_STATSは、通知統計およびパフォーマンスの監視に使用されます。
イベント・ベースの通知は、コーディネータ（EMNC）および下位プロセス（EXXX）のセットで処理されます。イベント通知ロードはこのプロセス間に配置されます。このプロセスはシステム通知でパラレルに機能して、より大量な通知をより迅速なレスポンス時間で処理し、ステージング通知で使用する共有メモリーを削減する機能を提供します。
通知アプリケーションは、指定された間隔内に発生するすべてのイベントに対する1つの通知を受信するように登録できます。通知クライアントは、通知の開始時間を指定することもできます。また、グループ化のクラスとして時間およびグループ化の値として間隔を指定する必要があります。繰返し件数を使用すると、配信される通知の数を制限できます。クライアントは、2つのタイプのグループ化イベント、サマリーまたは最終を受信します。サマリー通知は、サブスクリプションに対するメッセージすべてのメッセージ識別子のリストです。グループ化タイプに最終を指定すると、通知間隔内の最後のメッセージに関する情報を通知に含めりことができます。間隔内のメッセージ件数も送信できます。PLSQLおよびOCI内の登録インタフェースを使用すると、AQ$_REGISTRATION_INFO内のSTART_TIME、REPEAT_COUNT、GROUPING CLASS、GROUPING VALUE、GROUPING TYPEおよびOCIサブスクリプション・ハンドルを指定できます。
AQ通知クライアントで受信した通知記述子は、メッセージ識別子のグループおよびグループ内の通知数に関する情報を提供します。
|
関連項目:
|
次の機能は、メッセージのエンキューに適用されます。
複数のメッセージをキューにエンキューすると、1つのメッセージを1回ずつ操作するのではなく、1つの配列の複数メッセージを同時に操作できます。これにより、エンキュー操作のパフォーマンスが向上します。メッセージの配列をキューにエンキューする場合、エンキュー・オプションは各メッセージで共有されますが、メッセージ・プロパティはメッセージごとに個別に指定できます。配列のエンキュー操作は、PL/SQLまたはOCIを使用して実行できます。
このリリースのバッファ済メッセージでは、配列のエンキューはサポートされていません。
各メッセージには識別子を割り当てることができるため、後で特定のメッセージを取り出せます。
エンキューされたメッセージの優先順位およびキュー内での正確な位置を指定できます。つまり、ユーザーはメッセージが使用される順序を次の3つの方法で指定できます。
各メッセージに優先順位を割り当てます。
ソート順序では、どのプロパティを使用してキューのすべてのメッセージを順序付けるかを指定します。これは、キュー表の作成時に設定され、変更できません。優先順位、エンキュー時刻またはコミット時刻でメッセージをソートすることもできます。commit-timeオプションは、Oracle Streams AQ 10gリリース2（10.2）の新機能で、トランザクションごとに計算された近似CSCNに基づいてメッセージを並べ替えます。
commit-time順序付けは、トランザクションが相互に依存している場合、またはキュー内のメッセージを参照するときに一貫した結果が必要な場合に便利です。
順序逸脱では、メッセージの位置を他のメッセージとの関連で指定します。
|
注意: 10gリリース2（10.2）では、順序逸脱機能は廃止されました。 |
複数のコンシューマが同じキューを操作している場合、各コンシューマはすぐに使用できる最初のメッセージを取得します。別のコンシューマが使用中のメッセージはスキップされます。
メッセージの優先順位による順序付けは、優先順位およびエンキュー時刻でソート順序を指定することによって実行されます。優先順位による順序付けを選択すると、各メッセージがエンキューされるときにエンキュー・エージェントによって優先順位が割り当てられます。デキューのときには、割り当てられた優先順位でデキューされます。2つのメッセージに同じ優先順位が割り当てられた場合、両者のデキュー順序はエンキュー時刻によって決定されます。先入れ先出し（FIFO）優先順位のキューも、エンキュー時刻および優先順位でメッセージのソート順序を指定することによって作成できます。
1つのキューに属しているメッセージをグループ化して1つのセットにし、一度に1ユーザーのみが使用できるようにできます。このためには、メッセージのグループ化を使用可能にしたキュー表に、キューを作成する必要があります。1つのグループに属するすべてのメッセージは、同じトランザクションで作成される必要があります。また、1つのトランザクションで作成されるすべてのメッセージは、同じグループに属します。
この機能によって、複雑なメッセージを、複数の単純なメッセージにセグメント化できます。たとえば、あるキュー宛てのメッセージに請求書情報が含まれている場合、そのメッセージは、最初にヘッダーのメッセージ、次に詳細情報のメッセージ、その次にフッターのメッセージというような順番で構成されるグループとして作成できます。
小さいオブジェクトにセグメント化できるイメージやビデオなどの複合ラージ・オブジェクトがメッセージ・ペイロードにある場合は、メッセージのグループ化が有効です。
グループ・メッセージ・プロパティ（優先順位、遅延、期限切れ）は、単にグループの最初のメッセージのプロパティによってのみ判断され、グループの他のメッセージのプロパティは無視されます。
グループ化メッセージのプロパティは、伝播されても保持されます。ただし、メッセージの伝播先キューも、トランザクション処理でグループ化可能な状態にする必要があります。トランザクション処理でグループ化可能なキューからメッセージをデキューするときにメッセージ・グループのプロパティを保持する場合、他にも注意する必要がある制限があります。
アプリケーションは、送信メッセージにユーザー定義の識別マークを付加できます。Oracle Streams AQでは、メッセージがデキューされたキューを自動的に識別することもできます。これにより、アプリケーションで、伝播されたメッセージや同じデータベース内の文字列メッセージの追跡が可能になります。
メッセージをエンキューするときに、そのメッセージがいつまで使用可能かという期限切れを指定できます。デフォルトでは、期限切れはありません。期限切れになったメッセージは、例外キューに移されます。期限切れ処理を行うには、キュー・モニターを起動しておく必要があります。
次の機能は、メッセージのデキューに適用されます。
シングル・コンシューマ・キューからデキューするプロセスまたはマルチ・コンシューマ・キューから同じコンシューマでデキューするプロセスが複数ある場合、同時プロセスで処理中のメッセージは別のプロセスではスキップされます。このため、複数のプロセスが同一コンシューマの異なるメッセージを同時に処理できます。
次のいずれかの方法で、メッセージをデキューできます。
相関識別子の指定
相関識別子はユーザー定義のメッセージ・プロパティです。1つのキューに同じ相関識別子を持つメッセージが複数存在することがあります。これは、メッセージ同士の順序付け（エンキュー順序）がデキュー・コールでは変更される可能性があることを意味します。
メッセージ識別子の指定
メッセージ識別子はシステムによって割り当てられる値（RAWデータ型）です。同じメッセージ識別子を持つメッセージがキュー内に複数存在することはありません。
デキュー条件の指定
デキュー条件は、メッセージ・プロパティまたはメッセージ内容を使用して表現され、SQL問合せのWHERE句の構文に類似しています。キュー内のメッセージは、条件に対して評価され、指定した条件を満たすメッセージが戻されます。デキュー条件が使用される場合、デキューされるメッセージの順序は予想できません。また、キューのソート順序は無視されます。
デフォルトのデキュー
デフォルトのデキューは、最初の使用可能なメッセージを取り出します。
|
注意: 相関識別子、メッセージ識別子またはデキュー条件を使用してメッセージをデキューすると、グループ化メッセージのプロパティが変更されます。 |
デキュー・リクエストは、メッセージをブラウズして削除するか、データを伴わないメッセージを削除できます。メッセージが参照されると、そのメッセージは引き続き処理できます。メッセージは、削除されるか、データを伴わずに削除されると、デキュー・リクエストには使用できなくなります。キュー・プロパティによっては、取り消されたメッセージがキュー表に保持されることもあります。キューに保存時間が指定されている場合、メッセージは削除された後でもキュー表に保存されます。
BROWSEモードには3つのリスクがあります。まず、一度ブラウズしたメッセージを、再度デキューできる保証はありません。これは、同時ユーザーのデキュー・コールによってそのメッセージが削除される可能性があるためです。一度参照したメッセージが同時ユーザーによってデキューされないようにするには、LOCKEDモードでメッセージを参照する必要があります。
次に、待機時間が0（ゼロ）以外に指定されていて、ナビゲート位置がキューの最後に到達した場合、BROWSEモードのデキュー位置は自動的にそのキューの先頭に変更されます。BROWSEモードでNEXT_MESSAGEナビゲーション・オプションおよび0（ゼロ）以外の待機時間を指定してデキューを繰り返すと、何度も同一メッセージをデキューすることがあります。キューに対する最初のデキューに待機時間を0（ゼロ）以外で指定して、それ以降のデキュー・コールには待機時間0（ゼロ）のNEXT_MESSAGEナビゲーション・オプションを使用することをお薦めします。デキュー・コールで「end of queue」エラー・メッセージが戻された場合は、デキュー位置をFIRST_MESSAGEナビゲーション・オプションを使用して明示的にキューの先頭に設定できます。このようにすると、そのキューのメッセージを再度ブラウズできます。
さらに、キューのソート順序がENQ_TIME、PRIORITYまたはこの2つの組合せの場合、ブラウズからブラウズへ結果を繰返しできない場合があります。一貫したブラウズ結果が必要な場合は、commit-timeキューを使用する必要があります。
REMOVE_NODATAモードでメッセージがデキューされた場合、メッセージのペイロードは取り出されません。このモードは、ユーザーが先にBROWSEモードでデキューしてペイロードを調べてあるときに有効です。
複数のメッセージをキューからデキューすると、メッセージを1つずつ操作するのではなく、1つの配列の複数メッセージを同時に操作できます。これにより、デキュー操作のパフォーマンスが向上します。トランザクション処理用のキューからデキューする場合は、1回のコールでトランザクションに関するすべてのメッセージをデキューできます。そのため、アプリケーションのプログラミングが容易になります。
キューからメッセージの配列をデキューする場合、デキュー・オプションは各メッセージで共有されますが、メッセージ・プロパティはメッセージごとに個別に指定できます。配列のエンキュー操作とデキュー操作は、PL/SQLまたはOCIを使用して実行します。
このリリースのバッファ済メッセージでは、配列のデキューはサポートされていません。
複数のプロセスまたはスレッドが、1つのキューから同じコンシューマ名を使用して同時にデキューできます。そのような場合、Oracle Streams AQはキューの先頭にあるロックされていない最初のメッセージをコンシューマに提供します。デキュー中に特定のメッセージのメッセージ識別子が指定されないかぎり、コンシューマはREADY状態のメッセージをデキューできます。
メッセージがPROCESSED（処理済）とみなされるのは、所定のコンシューマ全員がメッセージのデキューに成功したときのみです。メッセージがEXPIRED（期限切れ）とみなされるのは、1つまたは複数のコンシューマがEXPIRATION時刻までにそのメッセージをデキューしなかったときです。期限切れになったメッセージは、例外キューに移されます。
マルチ・コンシューマ・キューから移された期限切れメッセージは、受信者を指定してデキューできません。ただし、デキュー・オプションのコンシューマ名にNULLを指定することによって、REMOVEモードで1回のみデキューできます。
|
注意: マルチ・コンシューマ例外キューが、compatibleパラメータを8.0に設定してキュー表に作成された場合は、期限切れメッセージはメッセージ識別子を指定する方法でのみデキューできます。
|
Oracle Streams AQリリース8.1.6以上では、マルチ・コンシューマ・キューからメッセージを削除できるのはキュー・モニターのみです。これによって、デキュー元はキュー表のメッセージをロックすることなくデキュー操作を完了できます。キュー・モニターは、すべてのコンシューマが処理を完了したメッセージをマルチ・コンシューマ・キューから削除する作業を毎分約1回行うため、メッセージが完全に処理された後キューから物理的に削除されるまでの遅延があります。
キューからメッセージを選択するには、いくつかのオプションがあります。FIRST_MESSAGEナビゲーション・オプションを使用して、最初のメッセージを選択できます。メッセージを選択してキュー内での位置を設定した後、NEXT_MESSAGEナビゲーション・オプションを使用して次のメッセージを選択することもできます。
FIRST_MESSAGEナビゲーション・オプションでは、キューに対してSELECTが実行されます。NEXT_MESSAGEオプションでは、FIRST_MESSAGEナビゲーションで実行されたSELECTの結果からフェッチが実行されます。このように、後続のデキューではSELECT全体を再度実行する必要がないため、パフォーマンスが最適化されます。
キューがトランザクション処理でグループ化できる場合は、ナビゲーション・オプションは少し違った動作をします。FIRST_MESSAGEが要求されると、デキュー位置はキューの最初にリセットされます。ただし、NEXT_MESSAGEが要求されると、位置は同一トランザクション内の次のメッセージに設定されます。グループ化トランザクションは、NEXT_TRANSACTIONオプションも提供します。このオプションは、位置を次のトランザクションの最初のメッセージに設定します。
相関識別子またはメッセージ識別子を指定してデキューするか、トランザクションのメッセージの一部をデキューしてコミットする場合は、グループ化トランザクションは無効です。
NEXT_MESSAGEまたはNEXT_TRANSACTIONオプションの使用中にキューの最後に到達し、待機時間を0（ゼロ）以外に指定していた場合、ナビゲート位置は自動的にそのキューの先頭に変更されます。待機時間を0（ゼロ）に指定した場合、キューの最後に到達すると例外が発生することがあります。
Oracle Streams AQでは、新しくエンキューされるメッセージまたはREADY状態になるメッセージのどちらかに、1つ以上のキューでアプリケーションを待機させることができます。DEQUEUE操作によって、1つのキューへのメッセージ到着を待機でき、LISTEN操作によって複数のキューへのメッセージ到着を待機できます。
|
注意: アプリケーションは例外キューのブロッキング・デキューを実行して、EXPIREDメッセージを待機することもできます。
|
ブロック（待機）しているDEQUEUEコールが戻るとき、メッセージ・プロパティおよびメッセージ・ペイロードが戻されます。ブロックしているLISTENコールが戻るときは、メッセージが届いたキューの名前のみが戻ります。メッセージをデキューするためには、その後にDEQUEUE操作をする必要があります。
エージェント・リストの複数のエージェントに向けたメッセージがいくつかある場合、LISTENはメッセージの宛先になっている最初のエージェントとともに戻ります。あるエージェントが他のエージェントに対してメッセージの欠乏状態を引き起こさないように、アプリケーションはエージェント・リストのエージェント順序を変更できます。
|
注意: Visual Basic（OO4O）では、現在この機能はサポートされていません。 |
アプリケーションは、必要に応じてOracle Streams AQのメッセージ到着待機時間を示すタイムアウトを0（ゼロ）または任意の秒数に指定できます。デフォルトでは、そのキューにメッセージが到着するまで、待機することになっています。これにより、アプリケーションからメッセージをポーリングし続けるという負担がなくなり、新しいメッセージがエンキューされるか、DELAY時間がすぎてREADY状態になるまでブロックし続けるため、CPUおよびネットワーク・リソースの節約になります。
デキューによってブロックされたアプリケーションは、新しいメッセージにDELAYが指定されていない場合はエンキュー元が直接アクティブにし、DELAYまたはEXPIRATION時間が経過した場合はキュー・モニター・プロセスがアクティブにします。アプリケーションがリモート・キューでメッセージの到着を待機している場合、Oracle Streams AQのプロパゲータにより、メッセージの伝播後に、ブロックされたデキュー元がアクティブになります。
キューからメッセージをデキューするトランザクションが失敗した場合、そのメッセージを使用する試行に失敗したとみなされます。Oracle Streams AQは、メッセージ使用の試行に失敗した回数をメッセージ履歴に記録します。アプリケーションは、キュー表ビューのRETRY_COUNT列を問い合せて、メッセージに対する試行の失敗回数を参照できます。さらに、Oracle Streams AQでは、アプリケーションがキュー内のメッセージに対する再試行の最大回数を、キュー・レベルで指定できます。再試行の最大回数のデフォルト値は5です。メッセージ削除がこの数より多く失敗した場合、メッセージは例外キューに移動されるか、またはアプリケーションで使用できなくなります。
|
注意: サーバー・プロセスがインスタンスで停止した（ALTER SYSTEM KILL SESSIONまたはSHUTDOWN ABORTなど）ためにデキュー・トランザクションが失敗した場合、RETRY_COUNTは増分されません。
|
条件が不適切な場合、メッセージを受信するトランザクションが終了する場合があります。Oracle Streams AQでは、WAITING状態のときに、指定された再試行の遅延間隔で、不適切なメッセージを隠すことができます。再試行の遅延後、失敗したメッセージが再度デキュー可能になります。Oracle Streams AQのタイム・マネージャは、再試行遅延プロパティを強制的に適用します。再試行の遅延のデフォルト値は0（ゼロ）です。
複数のセッションが1つのキューから同時にメッセージをデキューしている場合、RETRY_COUNT情報が常に正しく更新されるとはかぎりません。セッション1がメッセージをデキューしてトランザクションをロールバックすると、Oracle Streams AQでは、このメッセージのRETRY_COUNT情報を更新する必要があることが認識されます。ただし、セッション1がロールバックを完了するまではRETRY_COUNTを増分できません。セッション1がロールバックを完了してからRETRY_COUNTを増分するまでの間に、セッション2が同じメッセージをデキューしようとすると、セッション2によるデキューは成功します。セッション1がRETRY_COUNTを増分しようとすると、メッセージがセッション2によりロックされていることが検出され、RETRY_COUNTは増分されません。インスタンスのUSER_DUMP_DESTINATIONに、次のメッセージを含むトレース・ファイルが生成されます。
Error on rollback: ORA-25263: no message in queue schema.qname with message ID ...
|
注意: 再試行の最大回数および再試行の遅延は、8.0形式のマルチ・コンシューマ・キューでは使用できません。
|
エンキュー・リクエストおよびデキュー・リクエストでは、通常は複数のリクエストを含むトランザクションの一部として、必要なトランザクション処理が提供されます。ただし、特定のリクエストをそれ自身でトランザクションに指定して、そのリクエストの結果をすぐに他のトランザクションから参照できるようにできます。つまり、エンキュー文またはデキュー文が適用されたとき、またはそのトランザクションがコミットされた後、メッセージを外部から参照できるようにできます。
|
注意: バッファ済メッセージでは、トランザクション保護はサポートされていません。 |
例外キューは、期限切れまたは処理できないメッセージのリポジトリになります。アプリケーションから例外キューには直接エンキューできません。また、マルチ・コンシューマの例外キューに、サブスクライバを対応付けることはできません。ただし、期限切れまたは処理できないメッセージを処理するアプリケーションは、REMOVE（削除）モードを使用する例外キューから1回のみデキューできます。デキュー中のコンシューマ名はNULLに指定する必要があります。メッセージ識別子を指定すると、メッセージも例外キューからデキューできます。
|
注意: 期限切れまたは処理できないバッファ済メッセージは、永続メッセージとして例外キューに移されます。シングル・コンシューマ・キューまたは8.0形式のマルチ・コンシューマ・キューを指定したメッセージが例外キューに移された場合は、メッセージ識別子を指定してデキューできます。
|
メッセージが例外キューに移動した後、例外キューに移動する前にメッセージが常駐していたキューを識別する方法はありません。この情報が重要な場合、アプリケーションはこの情報をメッセージ自体に保存する必要があります。
例外キューは、エンキュー時に指定可能なメッセージ・プロパティです。例外キューが指定されていないと、デフォルトの例外キューが使用されます。デフォルトの例外キューは、キュー表が作成されるときに自動的に作成されます。
メッセージは、次の条件が成立するときに例外キューに移されます。
指定された期限内にデキューされなかった場合。
複数の受信者を指定したメッセージの場合、指定されていながら指定された期限切れまでにそのメッセージをデキューできない受信者が1つでもあると、メッセージは例外キューに移されます。デフォルトの期限切れはなしで、そのメッセージは期限切れになりません。
メッセージは正常にデキューされたものの、その処理でエラーが発生したために、メッセージをデキューしたアプリケーションがトランザクションをロールバックした場合。デキューされても、ロールバック回数が再試行制限の指定回数を超過したメッセージは例外キューに移されます。
複数の受信者を指定したメッセージの場合、受信者ごとにそれぞれの再試行回数が保持されます。すべての受信者の再試行回数が再試行制限の指定を超えたときのみ、そのメッセージは例外キューに移されます。
シングル・コンシューマ・キューと8.1形式のマルチ・コンシューマ・キューの場合、デフォルトの再試行制限は5回です。8.0形式のマルチ・コンシューマ・キューでは、再試行制限はサポートされていません。これは、Oracle Streams AQ 10gリリース2（10.2）では廃止されました。
|
注意: サーバー・プロセスがインスタンスで停止した（ALTER SYSTEM KILL SESSIONまたはSHUTDOWN ABORTなど）ためにデキュー・トランザクションが失敗した場合、RETRY_COUNTは増分されません。
|
クライアントによって処理された文に含まれているデキューは成功したが、文自体は後で例外処理のために取り消された場合。
デキュー・プロシージャに成功してPL/SQLプロシージャに例外が発生した場合、Oracle Streams AQは、デキュー・プロシージャにより戻されたメッセージの再試行回数を増分します。
クライアント・プログラムはメッセージのデキューに成功したが、トランザクションをコミットする前に終了した場合。
メッセージは、あるキューから別のキューに伝播できます。これにより、同じデータベースまたは同じキューに接続しなくても、アプリケーション同士が互いに通信できます。宛先キューは、同じデータベースまたはリモート・データベースに設定できます。
伝播により、すべてのサブスクライバに1つのキューからメッセージをデキューするよう要求しなくても、多くの受信者にメッセージを展開できます。伝播を使用すると、異なるキューのメッセージを1つのキューに結合することもできます。これは、メッセージのコンポジットまたはファネリングと呼ばれます。
|
注意: マルチ・コンシューマ・キューからシングル・コンシューマ・キューにメッセージを伝播できます。シングル・キューからマルチ・コンシューマ・キューへの伝播は不可能です。 |
伝播されたメッセージがリモート・キューからデキューされていなくても、ソース・キューでは、伝播された直後に処理済とマークされます。同様に、伝播されたメッセージがリモート・キューで期限切れになると、そのメッセージはローカル・キューの例外キューではなく、リモート・キューの例外キューに移されます。現状では、Oracle Streams AQは、例外をソース・キューに伝播しません。
伝播を有効化するために、メッセージ伝播の送信元のキューに1つ以上のサブスクライバが定義され、そのキューからメッセージを伝播する宛先ごとに、スケジュールが定義されます。
Oracle Streams AQによって、リモート・キューの型が、それが作成されたキャラクタ・セットのコンテキストで、ローカル・キューの型と構造的に同等であるかが自動的に確認されます。ソース・キューでエンキューされたメッセージが伝播され、自動的に宛先キューでデキューできるようになります。
メッセージが宛先キューに届くと、ソース・キューのスキーマ名に基づいたセッションによって、新しく届いたメッセージが宛先キューにエンキューされます。つまり、ソース・キューのスキーマに、宛先キューに対するエンキュー権限を付与する必要があります。
伝播は、Oracle Schedulerジョブとして実行されます。バックグラウンド・プロセス、JOB_QUEUE_PROCESSがジョブを実行します。伝播のスケジューリングは、継続的に終了せずに実行される専用のプロセス、または伝播するメッセージがある場合にのみ実行されるイベント・ドリブンのプロセスです。
Oracle Streams AQは、2種類の伝播を提供しています。
キューからdblinkへの伝播
キューからキューへの伝播
キューからdblinkへの伝播では、ソース・キューから、dblinkで識別される宛先データベースのすべてのサブスクライブ・キューにメッセージまたはイベントが配信されます。
1つの伝播スケジュールを使用して、すべてのサブスクライブ・キューにメッセージが伝播されます。したがって、このスケジュールを変更すると、すべてのサブスクライブ・キューへのメッセージ配信に影響します。
キューからキューへの伝播では、ソース・キューから、dblinkで識別される特定の宛先キューにメッセージまたはイベントが配信されます。これにより、メッセージ配信の伝播スケジュール制御の自由度を高めることができます。
この新しい伝播モードは、宛先RACシステムに伝播する場合、透過的なフェイルオーバーもサポートします。キューからキューへの伝播では、RACでキューの所有者インスタンスが失敗した場合、データベース・リンクを再指定する必要はなくなります。
Oracle Streams AQには、伝播されたメッセージおよびそのスケジュールに関する詳細な統計を取得する機能があります。この情報は、最高のパフォーマンスが得られるようにスケジュールを調整するために使用できます。
マルチ・コンシューマ・キュー内のメッセージのコンシューマは、ローカルまたはリモートです。ローカル・コンシューマは、プロデューサがそのメッセージをエンキューしたキューからデキューします。ローカル・コンシューマのエージェント説明には名前はありますが、アドレスまたはプロトコルはありません。
リモート・コンシューマは、メッセージがエンキューされたキューとは異なるキューからデキューします。リモート・コンシューマは、3つのカテゴリに分類されます。
アドレスが同一データベース内のキューを参照しているもの。
この場合、コンシューマは同一データベースにある別のキューからメッセージをデキューします。アドレスの形式は[schema].queue_nameです。スキーマが指定されていない場合は、現在のユーザーのスキーマが使用されます。
アドレスが別のデータベース内のキューを参照しているもの。
この場合の別のデータベースは、データベース・リンクを使用して到達でき、プロトコルがNULLまたは0（ゼロ）である必要があります。アドレスの形式は、[schema].queue_name@dblinkになります。スキーマが指定されていない場合は、現在のユーザーのスキーマが使用されます。データベース・リンクにドメイン名が指定されていない場合は、DB_DOMAIN init.oraパラメータで指定されたデフォルトのドメインが使用されます。
アドレスがサード・パーティのプロトコルによって到達できる宛先を参照しているもの。
サード・パーティ・ソフトウェアのドキュメントを参照してデータベース・リンクのアドレスおよびプロトコルの指定方法、および伝播のスケジューリング方法を決定する必要があります。
リモート・サブスクライバへの伝播
Oracle Streams AQは、スケジュールの作成時ではなく、スケジュールの実行時に、伝播スケジュールで指定されたデータベース・リンクを評価します。したがって、関連するデータベース・リンクを作成する前に、キューからdblinkへの伝播またはキューからキューへの伝播を作成できます。また、データベース・リンクを削除する場合、伝播スケジュールは使用不可になりません。
Oracle Streams AQは、2種類の伝播を提供しています。
A）キューからdblinkへの伝播: （ソース）キューおよび（宛先）データベース・リンクによって指定されます。dblinkで指定された宛先のすべてのキューに対するソース・キューのメッセージは、この伝播で処理されます。
この使用例では、dblinkが同一のデータベースに接続しているため、1つのソース・キューでは複数の伝播を持つことはできません。したがって、（q1、dblink1）と（q1、dblink2）は、両方のdblinkが同一のデータベースに接続している場合、同時に存在できません。一方、（q1、dblink1）と（q2、dblink2）または（q1、dblink1）と（q2、dblink2）は、ソース・キューが異なるため同時に存在できます。
B）キューからキューへの伝播: （ソース）キュー、（宛先）dblinkおよび（宛先）キューによって指定されます。宛先dblinkで示されるキューに対するソース・キューのメッセージは、この伝播で処理されます。ここでは、（q1、dblink1、dq1）と（q1、dblink1、dq2）または（q1、dblink1、dq1）と（q1、dblink2、dq2）は、成功します。これは、ソース・キューが同一でdblinkが同一のデータベースに接続されている場合でも、宛先キューが異なるためです。
この使用例では、dblink1およびdblink2が同一のデータベースを指している場合、（q1、dblink1、q2）と（q1、dblink2、q2）のように異なるdblinkを使用していても、1つのソース・キューと宛先キューの間では複数の伝播を持つことはできません。
遅延、期限切れおよび優先順位パラメータは、キューからdblinkへの伝播とキューからキューへの伝播の両方で、ローカル・コンシューマにもリモート・コンシューマにも同様に適用されます。Oracle Streams AQは伝播による遅延を見込んで、遅延および期限切れパラメータを調整します。たとえば、期限切れが1時間で、メッセージが15分後に伝播された場合、リモート・キューでの期限切れは45分に設定されます。
図1-9は、Oracle Streams AQを使用して通信する異なるデータベース上のアプリケーションを示しています。各アプリケーションには、受信メッセージを処理する受信ボックスと、送信メッセージを処理する送信ボックスがあります。アプリケーションがメッセージをエンキューするたびに、メッセージはその宛先にかかわらず送信ボックスに入ります。同様に、アプリケーションは、メッセージの送信元に関係なく、受信ボックスにあるメッセージをデキューします。
キューからdblinkへの伝播スケジュールは、1組のソース（伝播元のキュー）および宛先データベース・リンクに対して定義されます。キューからキューへの伝播スケジュールは、1組のソース（伝播元のキュー）および宛先キューに対して定義されます。あるキューにいくつかのキューに伝播されることになっている複数のメッセージがある場合、宛先キューごとにスケジュールを定義する必要があります。キューからdblinkへの伝播では、特定のリモート・データベースのすべてのスケジュールが同じ頻度で行われます。キューからキューへの伝播では、各スケジュールの頻度は、その他のスケジュールに関係なく調整されます。
スケジュールは時間の枠を示し、メッセージはその枠内にソース・キューから伝播されます。この時間枠は、ネットワーク通信量、ソース・データベースの負荷、接続先データベースの負荷などの多くの要因に左右されます。存続時間が指定されない場合、時間枠は無制限の単一枠になります。枠を定期的に繰り返す必要がある場合、連続する枠の間の周期的間隔を定義するNEXT_TIME機能を使用して有限の存続時間を指定します。
スケジュールが作成されると、ジョブは自動的にジョブ・キューの機能に発行され、伝播が処理されます。
あるキューに定義された伝播スケジュールは、そのキューの有効期間中いつでも変更または削除できます。スケジュールを削除するかわりに一時的に使用不可にすることもできます。すべての管理コールは、スケジュールがアクティブかどうかに関係なく実行されます。スケジュールがアクティブの場合、コールが処理されるまでに数秒かかります。
Oracle Streams AQを使用したラージ・オブジェクトの伝播には、2通りの方法があります。
RAWキューからの伝播
RAWキューでは、メッセージ・ペイロードはBLOBとして保存されます。これによって、PL/SQLインタフェースを使用したときには32KBまでのデータを格納でき、OCIを使用したときには、クライアントが同じ容量のデータを連続して割り当てることができます。この方法は、リリース8.0.4以上でサポートされています。
LOB属性を伴うオブジェクト・キューからの伝播
ユーザーは、Oracle DatabaseのLOB処理ルーチンを使用して、LOBを移入することもLOBから読み込むこともできます。LOB属性は、BLOBまたはCLOB（NCLOBではなく）です。属性がCLOBの場合、Oracle Streams AQはソース・キューと宛先キュー間で必要なすべてのキャラクタ・セットの変換を自動的に実行します。この方法は、リリース8.1.3以上でサポートされています。
|
注意: LOBを含むペイロードの場合、エンキューおよびデキュー操作を実行するには、キュー表に対する明示的なSelect、InsertおよびUpdate権限を付与する必要があります。
|
|
関連項目: 『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』 |
伝播に関する詳細なランタイム情報が収集され、伝播スケジュールごとにDBA_QUEUE_SCHEDULESビューに格納されます。この情報はキューのデザイナおよび管理者によって、問題の解決やパフォーマンス・チューニングのために使用できます。同様に、ビューによって報告されたエラーは、問題の診断および解決に使用できます。ビューには、伝播処理をしたセッションのID、ジョブ・キュー・プロセスの名前などの追加情報も示されます。
各スケジュールには、次の伝播の詳細情報が保持されます。
スケジュールで伝播されたメッセージ合計数
スケジュールの中で伝播されたバイト合計数
伝播枠の中で伝播されたメッセージの最大数
伝播枠の中で伝播されたバイトの最大値
伝播枠の中で伝播されたメッセージの平均数
伝播済メッセージの平均サイズ
伝播済メッセージの平均時間
伝播機能には、障害対処およびエラー・レポートが組み込まれています。たとえば、指定されたデータベース・リンクが無効な場合、リモート・データベースが使用できない場合、またはリモート・キューにエンキューできない場合、適切なエラー・メッセージがレポートされます。伝播は指数バックオフ・スキームを使用して、障害が発生したスケジュールからの伝播を再試行します。
あるスケジュールで続けて障害が発生したときは、最初の再試行は30秒後、次の再試行は60秒後、3回目の再試行は120秒後、というように続きます。再試行時間が現行の伝播枠の期限切れ時刻を超える場合は、次の再試行は、次の伝播枠の開始時刻に行われます。最大16回の再試行が行われた後、そのスケジュールは自動的に使用不可になります。
|
注意: 再試行が次の伝播枠にずれ込むと、常にずれ込むようになります。再試行スケジュールは指数バックオフ・スキームでは制御されなくなります。DBMS_AQADM.SCHEDULE_PROPAGATION()のnext_timeパラメータに指定した日付関数により伝播枠間の間隔が短くなると、再試行の失敗回数がすぐに16を超えてスケジュールが使用不可になります。
|
障害のためにスケジュールが自動的に使用不可になると、関連情報がアラート・ログに書き込まれます。スケジュール障害の確認項目は次のとおりです。
連続的な障害の発生回数
障害の原因を示すエラー・メッセージ
直前の障害の発生時刻
この情報を調べることで、キュー管理者は障害を回復し、スケジュールを使用可能にできます。再試行の間に伝播が成功したときは、障害の数は0（ゼロ）にリセットされます。
キューからデータベース・リンクへの伝播中のアプリケーション・エラーを示している状況では、Oracle Streams AQはそのメッセージにUNDELIVERABLEというマークを付けてalert.logに記録します。このようなエラーは、リモート・キューが存在しない場合、またはソース・キューおよびリモート・キューの型が一致しない場合に発生します。background_dump_destディレクトリのトレース・ファイルには、そのエラーに関する追加情報があります。
新しいジョブ・キュー・プロセスが開始されると、型が一致しないエラーは、型を再検証できるように削除されます。ジョブ・キュー・プロセス数に上限を設定して、伝播のビジー状態が続く場合、ジョブ・キュー・プロセスが終了して再開するまで待つ必要はありません。キューの型は、必要に応じてDBMS_AQADM.VERIFY_QUEUE_TYPESを使用して再検証できます。
|
注意: キューからキューへの伝播中に型の不一致が検出されると、伝播は停止してエラーが発生します。このような場合は、DBA_SCHEDULESビューを問い合せて、特定の宛先への伝播中に発生した最後のエラーを判断する必要があります。このメッセージには、UNDELIVERABLEマークは付いていません。
|
Real Application Clustersを使用した伝播
伝播には、Oracle Real Application Clustersサポートが組み込まれています。ただし、ユーザーおよびキュー管理者には透過的です。伝播を処理するジョブは、キューが常駐しているキュー表の所有者と同じインスタンスに送られます。
あるインスタンスに障害があって、ソース・キューを保存しているキュー表が他のインスタンスに移行される場合は、伝播ジョブも新しいインスタンスに移行されます。これによって、インスタンス間のping操作は最小限に抑えられ、パフォーマンスが向上します。
宛先は、データベース・リンクまたは宛先キュー名によって識別されます。宛先データベースを指定すると、キューからdblinkへの伝播が行われます。別のデータベースにある複数のキューにメッセージを伝播する場合、キューからdblinkへのすべての伝播が同じ頻度で行われます。Oracle Streams AQ 10gリリース2（10.2）の新機能では、宛先キュー名を指定すると、キューからキューへの伝播が行われます。別のデータベース内の複数のキューにメッセージを伝播すると、キューからキューへの伝播により、他のスケジュールに関係なく、各スケジュールの頻度を調整できます。個別の伝播を有効化または無効化することもできます。
この新しいキューからキューへの伝播モードは、宛先RACシステムに伝播する場合、透過的なフェイルオーバーもサポートします。キューからキューへの伝播では、RACでキューの所有者インスタンスが失敗した場合、データベース・リンクを再指定する必要はなくなります。
伝播は、同時スケジュールをいくつでも処理できるように設計されています。ジョブ・キュー・プロセスの最大数は1000で、その一部は伝播に関連しないジョブの処理に使用できます。このように、伝播にはマルチタスキングおよびロード・バランスのサポートが組み込まれています。
伝播アルゴリズムは、複数スケジュールが単一ジョブ・キュー・プロセスによって処理できるように設計されています。ジョブ・キュー・プロセスに対する伝播の負荷は、異なるソース・キューのメッセージ到着の割合に基づいて偏りが発生する場合があります。
あるプロセスが数個のアクティブ・スケジュールによって過負荷になっている一方で、別のプロセスは受動的なスケジュールが多いために余力がある場合、伝播は負荷が均等になるようにスケジュールを自動的に再分散します。
受信者のプロトコル番号が128〜255の範囲にある場合、Oracle Streams AQは受信者のアドレスを無視するため、メッセージがOracle Streams AQシステムによって伝播されることはありません。かわりに、サード・パーティ製のプロパゲータが、コンシューマ名として予約済の名前をデキュー操作に指定して、メッセージをデキューできます。予約済のコンシューマ名は、AQ$_Pprotocol_numberという書式で表されます。たとえば、AQ$_P128というコンシューマ名は、プロトコル番号128の受信者に対してメッセージをデキューするために使用されます。特定のプロトコル番号を伴うメッセージの受信者リストは、デキュー時にrecipient_listメッセージ・プロパティによって戻されます。
Oracle Streams AQは、メッセージ・ゲートウェイを使用して、サード・パーティ製のメッセージ・システム間でメッセージを伝播することもできます。メッセージ・ゲートウェイは、メッセージをOracle Streams AQキューからデキューして、サポートされるサード・パーティ製のメッセージ・システムに確実に配信します。メッセージ・ゲートウェイは、これらのシステムからメッセージをデキューして、Oracle Streams AQキューにエンキューすることもできます。
Oracle Database 10g以上では、HTTPおよびHTTPS（SSLによるHTTP）経由のOracle Streams AQ伝播を設定できます。HTTP伝播では、インターネット・アクセス・インフラストラクチャが使用され、接続先データべースに接続するOracle Streams AQサーブレットをデプロイする必要があります。データべース・リンクは、接続文字列にWebサーバーのアドレスとポートを指定し、HTTPをプロトコルとすることを指定して作成する必要があります。JavaおよびXMLを実行するためのソース・データベースを作成する必要があります。作成しないと、HTTP伝播の設定は、Oracle Net Services伝播の設定と同じになります。
アプリケーションでは一般に、様々なフォーマットのデータが使用されます。変換は、1つのOracleデータ型から別のデータ型へのマッピングを定義します。変換は、ソース・データ型を入力として取得し、ターゲット・データ型のオブジェクトを戻すSQLファンクションによって表現されます。1対1のメッセージ変換のみがサポートされます。
エンキュー中にメッセージを変換するには、エンキュー・オプションでマッピングを指定します。デキュー中にメッセージを変換するには、デキュー・オプションまたはサブスクライバの追加時にマッピングを指定します。デキュー・マッピングは、サブスクライバ・マッピングをオーバーライドします。伝播中にメッセージを変換するには、サブスクライバの追加時にマッピングを指定します。
変換を作成するには、単一のPL/SQLファンクションを作成するか、各ターゲット型の属性の式を作成します。PL/SQLファンクションでは、ターゲット型のオブジェクトまたはコンストラクタが戻されます。この表現は、単純な変換または各属性の個別の変換が困難なものに適しています。
ターゲット型の属性ごとに別々の式を作成すると、変換マッピングの作成および宛先タイプの各属性の管理が簡素化されます。これは、宛先タイプに多数の属性がある場合に有効です。
図1-10に示すとおり、キューイング機能、ルーティング機能および変換機能は、統合アプリケーション・アーキテクチャに不可欠な構成ブロックです。この図は、CRMアプリケーションのOutキューのデータが統合ハブで転送および変換され、その後、WebアプリケーションのInキューに伝播される方法を示しています。変換エンジンは、メッセージをOutキューのフォーマットからInキューのフォーマットにマップします。
XMLTypeでサポートされるextract()メソッドを使用してXMLデータを変換し、指定されたXPath式を適用した後に、XMLTypeのオブジェクトを戻すことができます。XSLPROCESSORパッケージを使用して、XSLT変換を適用することによってXMLTypeオブジェクトを変換するPL/SQLファンクションを作成することもできます。
内容は次のとおりです。
10gリリース1（10.1）より前のリリースでは、Oracle Streams AQのタイム・マネージャ・プロセスは、キュー・モニター（QMNn）と呼ばれるバックグラウンド・プロセスとして、init.oraファイルの動的なAQ_TM_PROCESSESパラメータの設定によって制御されていました。10gリリース1（10.1）以降は、時間管理をはじめとする他の多くのバックグラウンド・プロセスは、キュー・モニター・コーディネータ（QMNC）と呼ばれるコーディネータ対スレーブのアーキテクチャによって自動的に制御されています。QMNCは、システムの負荷に応じて、qXXXというスレーブを動的に起動します。このスレーブは、次のメカニズムを提供します。
メッセージの遅延
メッセージの期限切れ
再試行の遅延
キュー表のガーベージ・コレクション
バッファ済メッセージのメモリー管理タスク
プロセス数は自動的に決定されて絶えず調整されるため、AQ_TM_PROCESSESパラメータで設定する手間が省けます。
init.oraパラメータAQ_TM_PROCESSESの設定の必要性はなくなりましたが、引き続きサポートされています。このパラメータを設定しても（最大値は10）、プロセス数はQMNCによって自動的に調整されます。しかし、永続キューに設定したプロセス数だけは保証されます。ただし、バッファ・キューと他のOracle Streamsタスクのプロセスには、このパラメータ値は反映されません。
|
注意: キュー・モニター・コーディネータを無効にするには、pfileまたはspfileでAQ_TM_PROCESSES = 0を設定する必要があります。AQ_TM_PROCESSESパラメータはゼロ（0）に設定しないでください。Oracle Streamsを使用している場合、このパラメータをゼロに設定すると、Oracle Databaseに影響を及ぼす重大な問題を引き起こす可能性があります。
|
Oracle Internet Directoryは、Oracle Databaseに組み込まれたシステム固有のLDAPv3ディレクトリ・サービスで、電子メール・アドレス、電話番号、パスワード、セキュリティ証明書、様々なタイプのネットワーク・デバイスの構成データなど、多様な情報を集中管理します。企業全体のキューイング情報（キュー、サブスクリプションおよびイベント）は、Oracle Internet Directoryという1つの場所から検索できます。詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。
Oracle Enterprise Managerを使用すると、次の処理を実行できます。
キュー、キュー表、伝播スケジュールおよび変換の作成および管理。
データベース・レベルおよびキュー・レベルでのOracle Streams AQトポロジの使用、およびキュー・エラー、キュー統計およびセッション統計の参照によるOracle Streams AQ環境の監視。
システム管理者は、処理済のメッセージの保存期間を指定します。Oracle Streams AQは、各メッセージの履歴情報を格納し、キューおよびメッセージのプロパティ（遅延、期限切れ、およびローカルまたはリモートの受信者に対するメッセージの保存）を保存します。この情報には、エンキューおよびデキュー時刻、および各リクエストを実行したトランザクションの識別子が含まれます。これによって、ユーザーは関連するメッセージの履歴を保持できます。この履歴は、追跡、データ・ウェアハウスおよびデータ・マイニングの各操作の他に、特定の監査機能で使用できます。
バッファ済メッセージでは、メッセージの保存はサポートされていません。
Oracle Streams AQの保存機能では、処理後のユーザー指定の有効期限が経過するとメッセージが自動的にクリーン・アップされます。
メッセージが不適切なサブスクライバのキューに誤って挿入された場合、サブスクライバ名またはメッセージ識別子を使用してデキューできます。これはメッセージを使用し、保存期間が過ぎた後にクリーン・アップされます。
特定のサブスクライバに対するメッセージをクリーン・アップするには、そのサブスクライバを削除して、その後再び追加します。サブスクライバを削除すると、そのサブスクライバに対するすべてのメッセージが削除されます。
保存されたメッセージを相互に関連付けて、順序を付けることができます。これらの順序はイベント・ジャーナルを表しており、一般にはアプリケーションによって作成されます。Oracle Streams AQは、アプリケーションが自動的にイベント・ジャーナルを作成できるように設計されています。
Oracle Streams AQでは、メッセージ自体とともに、メッセージ情報のすべての履歴が保持されます。この情報によって、メッセージの送受信が証明され、送信者および受信者の否認防止に使用できます。
エンキュー時には、エンキュー元の否認防止のために次の情報が保持されます。
エンキューを実行するOracle Streams AQエージェント
エンキューを実行するデータベース・ユーザー
エンキュー時刻
エンキューを実行するトランザクションのID
デキュー時には、デキュー元の否認防止のために次の情報が保持されます。
デキューを実行するOracle Streams AQエージェント
デキューを実行するデータベース
デキュー時刻
デキューを実行するトランザクションのID
伝播後は、伝播の宛先キューのORIGINAL_MSGIDフィールドが、ソース・メッセージのメッセージIDに対応します。このフィールドは、伝播されたメッセージを相互に関連付けるために使用できます。これは、伝播されたメッセージのデキュー元の否認防止に有効です。
エンキュー時にメッセージとともに送信者のデジタル署名をエンキューし、デキュー時にデキュー元のデジタル署名を格納することによって、より強力な否認防止を実現できます。
Simple Object Access Protocol（SOAP）を使用して、インターネット上でOracle Streams AQにアクセスできます。Internet Data Access Presentation（iDAP）は、Oracle Streams AQ操作のためのSOAP仕様です。iDAPによってSOAPリクエストの本体にXMLメッセージ構造が定義されます。
iDAPメッセージでは、Oracle Streams AQリクエストおよびレスポンスがXMLにカプセル化されます。iDAPは、エンキュー、デキュー、通知送信、通知登録、インターネットの標準転送プロトコルであるHTTP（S）や電子メールによる伝播などのOracle Streams AQ操作の実行に使用されます。さらに、iDAPでは、トランザクション、セキュリティ、変換、およびリクエストに対するキャラクタ・セットIDがカプセル化されます。
Oracle Internet Directory内のOracle Streams AQエージェントに別名を作成し、この別名を、インターネット経由で送信されたiDAPドキュメントで使用して、Oracle Streams AQ操作を実行できます。別名を使用することで、Oracle Streams AQエージェントの内部名を非公開にできます。
図1-11は、HTTP上でOracle Streams AQ操作を実行するためのアーキテクチャを示しています。主要コンポーネントは次のとおりです。
Oracle Streams AQクライアント・プログラム
Oracle Streams AQサーブレットのホストWebサーバー/サーブレット・コンテナ
Oracle Databaseサーバー
Oracle Streams AQクライアント・プログラムは、XMLメッセージ（iDAP準拠）をOracle Streams AQサーブレットに送信します。Oracle Streams AQサーブレットは、そのXMLメッセージを認識し、Oracle Streams AQ操作を実行します。Webブラウザなど、任意のHTTPクライアントを使用できます。たとえば、Oracle Streams AQサーブレットのホストWebサーバー/サーブレット・コンテナ、Apache/JservまたはTomcatは、着信XMLメッセージを解析します。Oracle Streams AQサーブレットはOracle Databaseサーバーに接続し、ユーザー・キューに対して操作を実行します。
|
注意: この機能は、TomcatまたはJServサーブレット実行エンジンの他に、Apacheでの動作も保証されています。サーブレットは、Java Servlet 2.0以上のインタフェースをサポートする他のWebサーバーおよびサーブレット実行エンジンでも動作します。 |
Oracle Streams AQ機能は、次のインタフェースを介して使用できます。
DBMS_AQ、DBMS_AQADMおよびDBMS_AQELMを使用したPL/SQL
Oracle Objects for OLEを使用したVisual Basic
oracle.jms Javaパッケージを使用したJava Message Service（JMS）
HTTP（S）を使用したインターネット・アクセス
|
注意: oracle.AQ Javaパッケージは、Oracle Streams AQ 10gリリース1（10.1）でサポートが廃止されました。既存のJava AQアプリケーションをOracle JMSに移行し、新しく設計するJava AQアプリケーションにはOracle JMSを使用することをお薦めします。
|
|
関連項目:
|
Oracle Streams AQのデモは、Oracle Database Companion CDからインストールできます。インストールされたデモは、$ORACLE_HOME/rdbms/demoディレクトリに保存されます。詳細は、demoディレクトリのaqxmlREADME.txtおよびaqjmsREADME.txtを参照してください。
表1-1に、PL/SQLおよびOCIのデモを示します。表1-2に、JMSのデモを示します。表1-3に、XMLのデモを示します。
| デモと格納先 | トピック |
|---|---|
aqjmsREADME.txt
|
Oracle Streams AQのJava APIデモおよびJMSデモの説明 |
aqjmsdmo.sql
|
Oracle Streams AQのJMSデモの設定 |
aqjmsdemo01.java
|
テキスト・メッセージのエンキューおよびメッセージ・プロパティに基づくデキュー |
aqjmsdemo02.java
|
メッセージ・リスナーのデモ（エンキュー・メッセージ） |
aqjmsdemo03.java
|
メッセージ・リスナーのデモ（リスナーの設定とメッセージのデキュー） |
aqjmsdemo04.java
|
Oracleタイプ・ペイロード: ペイロードの内容に対するデキュー |
aqjmsdemo05.java
|
キュー・ブラウザの例 |
aqjmsdemo06.java
|
データベース内のキュー間でのスケジュール伝播 |
aqjmsdemo07.java
|
XMLデータを含むADTメッセージの送受信 |
aqjmsdemo08.java
|
JMS 1.1ドメイン結合のデモ |
aqjmsdemo09.java
|
JMSバルク配列エンキューおよびデキュー |
aqjmsdemo10.java
|
JMSメッセージ型およびADTメッセージを持つANYDATAメッセージ |
aqjmsdrp.sql
|
AQ JMSデモのクリーン・アップ |
aqoradmo.sql
|
Oracle Streams AQのJava APIデモの設定 |
aqorademo01.java
|
RAWメッセージのエンキューおよびデキュー |
aqorademo02.java
|
ORADataインタフェースを使用したオブジェクト型メッセージのエンキューおよびデキュー |
aqoradrp.sql
|
AQ Java APIデモのクリーン・アップ |
aqjmskprb01.java
|
データベース内のメッセージのエンキューおよびデキュー |
aqjmskprb01a.sql
|
kprbドライバのデモの設定 |
aqjmskprb01b.sql
|
ストアド・プロシージャとしてのJavaプログラムaqjmskprb01.javaの定義
|
aqjmskprb01c.sql
|
ストアド・プロシージャとしてのaqjmskprb01.javaの実行
|
aqjmskprb01d.sql
|
AQ kprbドライバのデモのクリーン・アップ |
| デモと格納先 | トピック |
|---|---|
aqxmlREADME.txt
|
インターネット・アクセス・デモの説明 |
aqxmldmo.sql
|
ユーザー、キュー表およびキューの作成 |
aqxml01.xml
|
AQXmlSend: 伝達（ピギーバック）コミットによるADTシングル・コンシューマ・キューへの3つのメッセージのエンキュー |
aqxml02.xml
|
AQXmlReceive: 伝達（ピギーバック）コミットによるADTシングル・コンシューマ・キューからのメッセージのデキュー |
aqxml03.xml
|
AQXmlPublish: ADTマルチ・コンシューマ・キューへの2つのメッセージのエンキュー |
aqxml04.xml
|
AQXmlReceive: ADT（LOBを含む）マルチ・コンシューマ・キューからのメッセージのデキュー |
aqxml05.xml
|
AQXmlCommit: 前の操作のコミット |
aqxml06.xml
|
AQXmlSend: 伝達（ピギーバック）コミットによるJMS TEXTシングル・コンシューマ・キューへのメッセージのエンキュー |
aqxml07.xml
|
AQXmlReceive: 伝達（ピギーバック）コミットによるJMS TEXTシングル・コンシューマ・キューからのメッセージのデキュー |
aqxml08.xml
|
AQXmlPublish: 受信者を指定したマルチ・コンシューマ・キューへのJMS MAPメッセージのエンキュー |
aqxml09.xml
|
AQXmlReceive: マルチ・コンシューマ・キューからのJMS MAPメッセージのデキュー |
aqxml10.xml
|
AQXmlRollback: 前の操作のロールバック |
aqxmlhtp.sql
|
HTTP伝播 |
AQDemoServlet.java
|
Oracle Streams AQのXMLファイルを転送するサーブレット（Jserv用） |
AQPropServlet.java
|
Oracle Streams AQのHTTP伝播用サーブレット |
aqxmldrp.sql
|
AQ XMLデモのクリーン・アップ |
