Oracle Database Advanced Queuingのパフォーマンスおよび拡張性

5 Oracle Database Advanced Queuingのパフォーマンスおよび拡張性

次のトピックでは、Oracle Database Advanced Queuing (AQ)のパフォーマンスおよび拡張性に関する事柄について説明します。

シャード・キュー

シャード・キューでは、異なるエンキュー・セッションからのメッセージを並列でデキューできるため、エンキュー・デキューのスループットが特にOracle RACインスタンス間で向上します。キューの各シャードは、セッション内のエンキュー時刻に基づいて順序付けされ、シャード間の順序付けはベストエフォートです。シャード・キューは、エンキュー元およびデキュー元がそれら同士で競合しないように、表のパーティションを自動的に管理します。また、シャード・キューは、インメモリーのメッセージ・キャッシュを使用して、パフォーマンスを最適化し、エンキューおよびデキューのディスクおよびCPUのオーバーヘッドを削減します。

シャード・キューの利点およびトレードオフは、次のとおりです。

特に各サブスクライバが各インスタンスに複数のデキュー元を持つ場合に、シャード・キューにより、Oracle Real Application Clusters (Oracle RAC)上の単一のキューの拡張性が向上します。
シャード・キューは、増加したメモリー使用量をトレードオフしてパフォーマンスを向上します。

この項では、次の項目について説明します。

シャード・キューおよびメッセージ・キャッシュ

シャード・キューは、専用のメッセージ・キャッシュを導入しており、これを使用すると、SGAの使用量をトレードオフでき、スループットの向上、待ち時間の削減、同時処理の向上を図れます。パーティション化と組み合せると、メッセージ・キャッシュで、一部の問合せ、DML操作および索引に対する必要性が低くなります。メッセージ・キャッシュは、デキュー元の処理がエンキュー元に追いついている場合、およびメッセージ・キャッシュが、各シャード・キューのエンキュー元およびデキュー元に対して、メッセージ(ペイロードを含む)を十分に格納できる大きさである場合に最も効果的です。メッセージ・キャッシュでは、Streamsプールが使用されます。シャード・キューが、Streamsのレプリケーション機能と同じインスタンスでStreamsプールを共有する場合、SET_MIN_STREAMS_POOLおよびSET_MAX_STREAMS_POOLなどのDBMS_AQADMプロシージャを使用して、Streamsプールのメモリー割当てを微調整できます。

シャード・キューおよびエンキュー/デキュー・メッセージ

スループットを向上させ、オーバーヘッドおよび待ち時間を削減するために、エンキューおよびデキューは、メッセージ・キャッシュ、ルール・エンジン、および可能な場合はバックグラウンド処理を使用するように最適化されています。次に例を示します。

シャード・キューは、新しいルール・エンジンの改善点を利用します。
メッセージ・キャッシュ内にペイロードのあるメッセージは、デキュー中にディスクから再読取りする必要がありません。
相関IDによるデキューまたはその他のJMSプロパティは、ディスクにアクセスすることなく頻繁に評価できます。
シャード・キューにおけるパーティション操作により、効率的な一括処理が実装されます。

シャード・キューおよびネイティブJMSサポート

シャード・キューは、次のネイティブ・サポートを有しています。

非永続サブスクライバ
JMSペイロード
優先順位

シャード・キューでは、永続メッセージと非永続メッセージの両方がサポートされます。非永続メッセージはメッセージ・キャッシュ内のメモリーに格納され、ディスクには格納されません。そのため、非永続メッセージは、インスタンスのクラッシュ時や停止時に失われます。

シャード・キューは、JMS要件を満たす2種類のサブスクライバをネイティブにサポートしています。

非永続サブスクライバ: これらのサブスクライバは、サブスクライバがアクティブ中にメッセージがパブリッシュされた場合のみ、選択されたトピックについてのメッセージを受信します。このサブスクリプションは、異なるセッション間で共有できません。
永続サブスクライバ: これらのサブスクライバは、サブスクライバが非アクティブ中にパブリッシュされたメッセージを含めて、トピックについてパブリッシュされたすべてのメッセージを受信します。複数のデータベース・セッションで、同じサブスクリプションを共有できます。

シャード・キューは、ADTを使用してJMSペイロードを格納しません。JMSメッセージは、データベースのスカラー列に格納されます。TEXT、BYTES、MAP、STREAM、OBJECTなどのJMSメッセージ・タイプは、ペイロードのサイズとタイプに応じて、キュー表のTEXT/RAWまたはCLOB/BLOBのスカラー列にJMSペイロードを格納します。JMSメッセージ・プロパティは、ユーザー定義プロパティに属性アクセス機能が定義されているキュー表のCLOB (SecureFile)列に格納されます。ペイロードおよびユーザー・プロパティは、ADTとして格納されずに、RAW、VARCHAR2または保護ファイル列に格納されます。JMSヘッダー・プロパティおよびJMSプロバイダ情報は、それ自体のスカラー列に格納されます。

シャード・キューでは、0 (最も低い優先度)から9 (最も高い優先度)の範囲で整数の優先順位の値がサポートされており、JMS標準で定義されているように、デフォルトは4です。

シャード・キューおよびパーティション化

シャード・キューは、キュー表に使用される、基礎となるパーティション化された表を自動的に管理します。このようなパーティション管理は、フォアグラウンドまたはバックグラウンドで実行されます。各シャードは、エンキューされたメッセージのセッションレベルの順序付けを提供します。各エンキュー・セッションにはシャードが割り当てられます。各シャードは、一連のサブシャードで構成されます。各サブシャードは、1つのパーティションにマップされます。メッセージは、エンキュー時に表パーティションに自動的に割り当てられます。

新しいパーティションは、デキュー元がエンキュー元の処理に追いついておらず、キュー表を大きくする必要がある場合など、必要に応じて自動的に作成されます。パーティション内のすべてのメッセージがデキューされて必要がなくなった場合、パーティションは切り捨てられ再利用されます。メッセージ・キャッシュは、デキュー元による要求に応じて、メッセージをパーティションからメモリーに自動的にロードします。グローバル索引は、シャード・キューの基礎となる、パーティション化された表に作成できません。ローカル索引も、パーティション化された表では通常推奨されません。これらの索引が必要であるがパフォーマンスが低下する場合は、非シャード・キューの使用を検討してください。

シャード・キューおよびOracle Real Application Clusters (Oracle RAC)

シャード・キューは、可能な場合にはインスタンス間通信を回避しながら、自動的にエンキュー・セッションの順序付けを行います。インスタンス間通信が必要な場合もあります。たとえば、シャード・キューで、1つのOracleインスタンス上に単一のエンキュー・セッションがあり、別のインスタンスに単一のデキュー・セッションがある場合、シャード・キューはOracle RACインスタンス間でメッセージを転送します。パフォーマンスを向上させるため、メッセージの転送は、エンキュー・トランザクションに対してアトミックではありません。シャードにメッセージがないインスタンスに接続している場合、デキュー元でORA-25228が発生する場合があります。

ほとんどの場合、スループットを改善し、インスタンス間のオーバーヘッドを削減するために、各サブスクライバに対し複数のデキュー元を持つか、各Oracle RACインスタンスに単一のコンシューマ・キューを持つことを検討します。単一メッセージを指定するデキュー・セレクタを使用している場合は例外です。Oracle RACデータベースのメッセージ識別子により、共有キューからメッセージをデキューする場合、メッセージを含む共有キューのデキュー所有権を割り当てられたインスタンスに接続する必要があります。そうしないと、メッセージはデキュー・セッションへのデキューで使用できません。すべてのデキューが単一インスタンスで実行される場合、メッセージはこのインスタンスに自動的に転送されます。そのため、メッセージIDで広くデキューする共有単一コンシューマ・キューの場合は、共有キューのすべてのデキュー・セッションが単一インスタンスに接続することを検討してください。同様に、メッセージIDで広くデキューする共有複数コンシューマ・キューの場合は、各サブスクライバのすべてのデキュー・セッションが単一インスタンスに接続することを検討してください。サービスを使用してデキュー・セッションの特定のインスタンスへの接続を簡略化することができます。

シャード・キューの制限事項

現在、シャード・キューでは、次のOracle Databaseの機能はサポートされていません。

メッセージの保存
グループ化トランザクション
サブスクライバ通知およびOCIコールバック通知の匿名での転送はサポートされません。PL/SQLコールバック通知はサポートされます。
メッセージ・ゲートウェイ
JMS伝播およびリモート・サブスクライバなど、JMSのOracle拡張機能
1つのキュー表に複数のキュー。シャード・キューは、CREATE_SHARDED_QUEUEインタフェースを介して作成されます。
(JMS標準で指定されている)メッセージ優先順位、エンキュー時刻の順以外の順序付け。
JDBC thick (OCI)ドライバ。
シャード・キューおよび非シャード・キュー間の伝播
メッセージ変換

シャード・キューのチューニング

シャード・キューは次の状態のときに最適に機能します。

各サブスクライバのデキュー元が各インスタンス内にあります。
サブスクライバがエンキュー元の速度に追いついています。各Oracle RACインスタンス上の各サブスクライバに対して複数のデキュー元を設定することを検討してください。

メッセージ・キャッシュは、デキュー元の処理がエンキュー元に追いついている場合、およびキャッシュが、各シャード・キューのエンキュー元およびデキュー元に対して、メッセージ(ペイロードを含む)を十分に格納できる大きさである場合に最も効果的です。シャード・キューを使用する場合、次のいずれかを行う必要があります。

パラメータSTREAMS_POOL_SIZEの設定

このパラメータは、Oracle Databaseでシャード・キュー・メッセージ・キャッシュに使用可能な共有メモリーのサイズを制御します。指定されていない場合は、共有プール・サイズの最大10%までがStreamsプールに割り当てられます。

SGA_TARGET初期化パラメータに0以外の値を設定すると、Oracleの自動共有メモリー管理機能によってStreamsプールのサイズが管理されます。STREAMS_POOL_SIZE初期化パラメータにも0以外の値を設定した場合、この値は、Streamsプールの最小値として自動共有メモリー管理によって使用されます。

STREAMS_POOL_SIZE初期化パラメータに0以外の値を設定し、SGA_TARGETパラメータに0(ゼロ)を設定した場合、StreamsプールのサイズはSTREAMS_POOL_SIZEパラメータによって設定された値(バイト)です。

STREAMS_POOL_SIZEとSGA_TARGETの初期化パラメータがどちらも0に設定されている場合は、デフォルトにより、データベースで最初にStreamsプールを使用したときに、バッファ・キャッシュから共有プールの10%に相当する容量のメモリーがStreamsプールに割り当てられます。
関連項目:
- Streams処理を使用したSTREAMS_POOL共有の詳細な制御は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_AQADM.set_min_streams_pool()およびDBMS_AQADM.set_max_streams_pool()に関する項を参照してください。
SGA自動チューニングの有効化

Streamsプールの使用量およびSGAを使用するその他のコンポーネントの使用量に基づいて、SGAからStreamsプールに適切な量のメモリーが自動的に割り当てられます。その他のコンポーネントには、バッファ・キャッシュ、ライブラリ・キャッシュなどがあります。STREAMS_POOL_SIZEを指定した場合は、下限として使用されます。
シャード・キューの手動チューニング

シャード・キューは、メッセージ・キャッシュにSTREAMS_POOLメモリーを割り当てることによってチューニングできます。GV$AQ_MESSAGE_CACHE_ADVICEビューは、現在のメッセージ・ロードのスナップショットに基づいて、STREAMS_POOLの割当量に関するアドバイスを提供します。高負荷である期間中に、列INST_ID、SIZE_FOR_ESTIMATEおよびESTD_SIZE_TYPEを選択します。ESTD_SIZE_TYPEは3つの値(MINIMUM、PREFERREDまたはMAXIMUM)のいずれかです。各ESTD_SIZE_TYPE値について複数のOracle RACインスタンスにおけるSIZE_FOR_ESTIMATEの最大値を見つけます。メッセージ・キャッシュのパフォーマンスをよくするために、STREAMS_POOLに少なくともMINIMUM推奨値を設定することをお薦めします。STREAMS_POOLにMAXIMUM推奨値より大きい値を設定すると、パフォーマンスが少しよくなります。STREAMS_POOLにPREFERRED推奨値を設定すると、領域とパフォーマンスの適度なトレードオフが提供されるように試みられます。MAXIMUMサイズ推奨値がPREFERRED推奨値より大幅に大きい場合は、シャード・キューに孤立したサブスクライバがないこと、またはデキュー元がエンキュー・ロードに追いつくことができるように、さらにデキュー元をインスタンスに追加する必要があるかどうかを確認します。STREAMS_POOLのチューニングは、高負荷である期間に複数回行い、メッセージ・ロードの特性が変化したときにも行う必要があります。

ユーザー・シャーディング

アプリケーションは、シャード・キューのメッセージの共有方法を決定できます。このような場合、特定のシャードでメッセージをエンキューするように、アプリケーションで明示的に指定します。

たとえば、アプリケーションに、赤色、緑色、青色およびピンク色の異なるキーを持つ4種類のメッセージがあるとします。各エンキュー・セッションは、トランザクションでそれらのメッセージをエンキューできます。シャードAは、赤色および青色のメッセージを格納するように設定されています。シャードBは、緑色およびピンク色のメッセージを格納するように設定されています。また、各シャードには、シングル・コンシューマ・キューまたはJMSキューのためのアクティブなデキュー・セッションが1つのみ設定されています。同様に、各シャードには、マルチ・コンシューマ・キューまたはJMSトピックのためのデキュー・セッションがサブスクライバごとに1つのみ設定されています。そのデキュー・セッションは、デキュー元セッションの存続期間中はそのシャードに固定されたままになります。

次の例では、エンキュー・トランザクションがパラレルでエンキューを実行します。

図adque_usershard1.epsの説明

アプリケーションは実行時に新しいシャードを追加できます。アプリケーションは、新しいキーを追加することによって、新しいタイプのメッセージを実行時に追加することもできます。たとえば、オレンジ色と紫色のキーを持つ新しい2つのタイプが導入されて、3番目のシャードCが追加されます。シャードBは、オレンジ色のメッセージを格納するように設定されます。シャードCは、紫色のメッセージを格納するように設定されます。

図adque_usershard2.epsの説明

Oracle RACデータベースでは、シャードは常にインスタンスが所有します。最初は、そのシャードで最初のメッセージがエンキューされるインスタンスがシャードを所有します。データベース・インスタンスが停止すると、シャードの所有者インスタンスが変わる可能性があります。

ユーザー・シャーディングでは、セッションが実行されているインスタンスが所有していないシャードに、ユーザーがメッセージをエンキューできます。そのような場合は、クロス・インスタンス・エンキューがトリガーされます。クロス・インスタンス・エンキューをサポートするために、他のインスタンスで受信されたエンキュー・リクエストは、RACインターコネクトを介してシャードのOWNER INSTANCEに転送されます。listener.oraのREMOTE_LISTENERパラメータも設定して、クロス・インスタンス・エンキュー・リクエストを正しいインスタンスに転送できるようにする必要があります。内部的には、Oracle RACデータベースのシャード・キューで、インスタンス間のデータベース・リンクが使用される場合があります。Oracle RACデータベースのシャード・キューでクロス・インスタンス・エンキューを実行する定義者権限のPL/SQLパッケージでは、パッケージのユーザーにINHERIT REMOTE PRIVILEGESを付与する必要があります。

ユーザー・シャーディングの制限事項

ユーザー・シャーディングには次の制限事項があります。

PL/SQLエンキュー・コールでは、クロス・インスタンス・エンキューは有効にされません。
配列のエンキューでは、クロス・インスタンス・エンキューは有効にされません。

クロス・インスタンス・エンキューは、JavaおよびOCIクライアントを介して実行できます。

関連項目:

詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスのDBMS_AQADMを参照してください。

非シャード・キュー

この項には次のトピックが含まれます:

永続メッセージの基本的なチューニングのヒント

Oracle Database Advanced Queuing表のレイアウトは、他のデータベース表および索引のレイアウトと同様です。

関連項目:

チューニングの推奨事項は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

メモリー要件

Oracle RACデータベース以外で、最適なマルチコンシューマ・デキュー・パフォーマンスを得るには、Streamsプール・サイズは20MB以上である必要があります。

永続キューイング・デキュー操作は、特に同時処理の場合、パフォーマンスを最適化するためにストリーム・プールを使用します。ただし、これは要件ではなく、コードが自動的に最適度の低いコード・パスに切り替わります。

シャード・キューは、高スループットなメッセージ・システムで最適なパフォーマンスを得るためにメッセージ・キャッシュを導入しています。理想として、Streamsプール・サイズは、シャード・キュー内のメッセージの予想されるバックログをキャッシュするのに十分なサイズである必要があります。

格納パラメータの使用方法

格納パラメータを指定するには、キュー表の作成時にstorage_clauseパラメータを使用します。

格納パラメータは、キュー表で作成される他のIOTおよび表に継承されます。キュー表の表領域には、そのキュー表に関連付けられたすべてのオブジェクトのデータを処理できるだけの空き領域が必要です。保存を指定すると、履歴表およびキュー表が相当な大きさになる可能性があります。

自動セグメント領域管理(ASSM)を使用することをお薦めします。使用しない場合、initrans、空きリストおよび空きリスト・グループを高度な同時処理のAQパフォーマンスにチューニングする必要があります。

PCTFREEを増やすと、キュー表/IOTブロック内のメッセージの数を削減できます。これにより、同時処理の際のブロック・レベルの競合が減ります。

キュー表の作成時に指定される格納パラメータは、キュー表、IOTおよび索引で共有されます。これは、DBMS_REDEFINITIONを使用してオンライン再定義で個別に変更できます。

I/O構成

Oracle Database Advanced Queuingでは、I/Oが非常に頻繁に行われるため、通常、あらゆるボトルネックが解消されるよう、I/Oをチューニングする必要があります。

関連項目:

『Oracle Databaseパフォーマンス・チューニング・ガイド』のI/O構成および設計に関する項を参照してください。

単一の非シャード・キュー表でのエンキュー・プロセスとデキュー・プロセスの同時実行

メッセージを一定のフローで処理する環境では、エンキュー・プロセスとデキュー・プロセスの両方を同時に実行する必要が生じる場合があります。キュー表とキューが1つずつしか存在しないメッセージ配信システムの場合、すべてのプロセスが同じセグメントを同時に処理する必要があります。これでは適切なパフォーマンス・レベルで、多数のメッセージを配信することはできません。

最適な同時プロセス数は、システム・リソースの可用性によって異なります。たとえば、CPUを4つ持つシステムでは、2つの同時エンキュー・プロセスおよび2つの同時デキュー・プロセスから始めるのが妥当です。必要な数のメッセージを配信できないシステムでは、プロセス数を増やすのではなく、複数のサブスクライバを使用して、ロード・バランシングを実行します。

キューのエンキューおよびデキュー率をチューニングすると、通常、キュー・サイズを小さく制限できます。大幅に拡大および縮小するキューには索引およびIOTがあり、バランスに欠けるため、パフォーマンスに影響します。

マルチ・コンシューマ・キューでは、プロセス数を増やすのではなく、ロード・バランシングの複数のサブスクライバを使用して競合を減らします。水平拡張性を実現するには、複数のキュー表を使用します。

シャード・キューのチューニングの詳細は、シャード・キューのチューニングを参照してください。

単一の非シャード・キュー表でのエンキュー・プロセスとデキュー・プロセスのシリアル実行

エンキュー・プロセスとデキュー・プロセスをシリアルに実行すると、同一のデータ・セグメントにおける競合が、同時プロセスの場合よりも少なくなります。ただし、システムからのメッセージ配信にかかる合計時間は、両プロセスを同時実行する場合よりも長くなります。

プロセス数を増加させることは、エンキュー・プロセスおよびデキュー・プロセスの両方に効果的です。特にシングル・コンシューマ・キューでプロセス数を増加すると、メッセージのスループット率はデキュー元よりエンキュー元で高くなる場合があります。マルチ・コンシューマ・キューのデキュー・プロセスはさらに拡張されます。

キュー表の索引の作成

次の条件が満たされる場合は、非シャード・キュー表に索引を作成すると役に立ちます。

相関識別子を使用したデキュー

基になるキュー表AQ$_QueueTableNameの列corr_idの索引を作成すると、デキューが迅速に処理されます。
条件を使用したデキュー

これは、基になるキュー表で、SELECTのwhere句に対する条件の追加に相当します。QueueTableNameの索引を作成すると、このSELECT文のパフォーマンスが向上します。

非シャード・キューに関するその他のヒント

永続メッセージの基本的なチューニングに関するその他のヒントを示します。

統計が収集済で、メッセージ取得の最適な問合せ計画が選択されていることを確認してください。デフォルトでは、キュー表は統計の自動収集からロックされています。統計を代理キュー・メッセージ・ロードで収集して、ロックすることをお薦めします。
キュー表索引およびIOTは、AQバックグラウンド・プロセスで自動的に結合されます。ただし、必要に応じて監視および結合を続ける必要があります。自動セグメント領域管理(ASSM)のオンライン縮小操作は、同様の目的で使用します。バランスの取れた索引は、キュー・モニターCPUの使用を削減し、エンキュー・デキューのパフォーマンスを最適化します。
バックグラウンド・タスクを実行できるよう、十分なキュー・モニター・プロセスが実行されていることを確認してください。キュー・モニターは、他の重大なバックグラウンド・アクティビティのためにも実行されている必要があります。複数のqmnプロセスが負荷を分担するため、十分な数があることを確認してください。これらは自動的にチューニングされますが、必要に応じて最小数に強制変更できます。
待機時間のあるデキューは、専用サーバー・プロセスでのみ使用することをお薦めします。共有サーバー環境では、(待機時間を含めた)コールの期間中、共有サーバー・プロセスがデキュー操作にのみ占有されます。このようなプロセスが多数存在すると、パフォーマンスおよび拡張性に重大な問題が発生し、共有サーバー・プロセスがデッドロック状態となる可能性があります。
デキュー・トランザクションを長時間実行するとキューのデキュー競合を悪化させるため、避ける必要があります。
1つのトランザクションへのマルチ・コンシューマ・キューの複数のデキュー操作のバッチ処理は、最適なスループットを提供します。
メッセージの優先順位を使用していない場合、NEXTをナビゲーション・モードとして使用してください。提供されるセマンティクスは同様ですが、パフォーマンスが向上します。
BROWSEモードのデキューの次がREMOVEの場合、REMOVE_NODATAデキュー・モードを使用してください。

伝播のチューニングのヒント

伝播は、リモート(またはローカル)・キュー表に対して追加のINSERTを行う特殊なデキュー操作です。単一スケジュールからの伝播は、複数のジョブ・キュー・プロセスにパラレル化されません。そうではなく負荷分散されます。伝播は、リモート(またはローカル)・キュー表に対して追加のINSERTを行う特殊なデキュー操作です。単一スケジュールからの伝播は、複数のジョブ・キュー・プロセスにパラレル化されません。かわりに、ロード・バランシングされます。

拡張性を向上させるには、システム・リソース(CPU)の可用性に応じて伝播スケジュールの数を設定します。

トランザクション・キュー表からの伝播率と非トランザクション(デフォルト)キュー表からの伝播率は、多少異なります。これは、非トランザクション・キューのバッチ処理サイズはOracle Database Advanced Queuingが決定するのに対して、トランザクション・キューのバッチ・サイズは主にユーザー・アプリケーションが決定するためです。

伝播の最適化はバッチで行われます。リモート・キューが異なるデータベースに存在する場合、Oracle Database Advanced Queuingは、2フェーズ・コミットの必要性を回避するための順序アルゴリズムを使用します。メッセージが同じ宛先の複数のキューに送信される必要がある場合は、複数回送信されます。メッセージが宛先の同じキュー内のマルチ・コンシューマに送信される必要がある場合、1回のみ送信されます。

バッファ済メッセージのチューニング

Oracle Real Application Clusters環境におけるバッファ済メッセージ操作が最も高速となるのは、キューのOWNER_INSTANCEを対象とする場合です。

非シャード・キューの永続メッセージのパフォーマンスの概要

永続メッセージは、エンキューされるとデータベース表に格納されます。永続メッセージに対するキュー操作のパフォーマンス特性は、基になるデータベース操作のパフォーマンス特性と同等です。

エンキュー操作のコード・パスは、3つの索引構成表を持つ複数列のキュー表に対するSELECTおよびINSERTに相当します。デキュー操作のコード・パスは、複数列の表のSELECT操作およびデキュー索引構成表のDELETE操作に相当します。Oracle RACを使用しないで適切なストリーム・プール・メモリーが存在する場合などの多くの使用例で、デキュー操作は最適化され、複数列の表のSELECT操作に相当します。

注意:

表内のキューの数によって、パフォーマンスが影響を受けることはありません。

非シャード・キューとOracle Real Application Clusters

Oracle Real Application Clusters(Oracle RAC)を使用することで、キュー・データに対する高可用性のアクセスを実現できます。

キューの入口点および出口点(先頭および末尾)は、かなりのホット・スポットになる可能性があります。ホット・スポットが存在すると、Oracle RACを十分に拡張できない場合があるため、1つのキューに通常アクセスするインスタンスは1つに限定します。メッセージを管理しているインスタンスに障害が発生しても、障害の発生していない別のインスタンスの1つを使用することで、そのメッセージの即時処理が可能になります。非シャード・キューでホット・スポットが発生している場合は、かわりにシャード・キューを使用することを検討してください。

Oracle RACのインスタンス・アフィニティを8.1互換のキュー表に対応付けることができます。様々なインスタンスでq1およびq2を使用する場合は、キュー表にALTER_QUEUE_TABLEまたはCREATE_QUEUE_TABLEを使用して、primary_instanceを適切なinstance_idに設定できます。

関連項目:

共有サーバー環境でのOracle Database Advanced Queuing

キュー操作の拡張性は、基になるデータベース操作の拡張性と同等です。

waitオプションを指定して適用されたデキュー操作は、成功するかまたは待機期間が経過するまで戻れません。共有サーバー環境では、(待機時間を含めた)コールの期間中、共有サーバー・プロセスがデキュー操作にのみ占有されます。このようなプロセスが多数存在すると、パフォーマンスおよび拡張性に重大な問題が発生し、共有サーバー・プロセスがデッドロック状態となる可能性があります。そのため、waitオプションを指定したデキュー・リクエストを適用する場合は、専用のサーバー・プロセスを使用することをお薦めします。この制限は、強制ではありません。

関連項目:

waitオプションの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDEQUEUE_OPTIONS_T型に関する項を参照してください。

パフォーマンス・ビュー

Oracleでは、システム・パフォーマンスの監視およびトラブルシューティングのための次のビューを提供します。

これらのビューは、自動ワークロード・リポジトリ(AWR)と統合されます。ユーザーは、2つのAWRスナップショットを元にレポートを生成し、エンキュー率、デキュー率およびその他のキュー/サブスクライバ別の統計を計算できます。