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