Oracle Transactional Event QueuesおよびAdvanced Queuingのパフォーマンスとスケーラビリティ

9 Oracle Transactional Event QueuesおよびAdvanced Queuingのパフォーマンスとスケーラビリティ

次のトピックでは、Transactional Event Queues (TEQ)およびAdvanced Queuing (AQ)に関連するパフォーマンスとスケーラビリティの問題について説明します。

Transactional Event Queues

Transactional Event Queue (TEQ)では、エンキュー/デキューのスループットが向上します。Oracle Real Application Clusters (Oracle RAC)インスタンス間では、異なるエンキュー・セッションのメッセージをパラレルにデキューできるため、このスループットが特に向上します。キューの各イベント・ストリームは、エンキュー時刻に基づいてセッションの範囲内で順序付けされます。また、イベント・ストリーム間の順序付けはベストエフォート方式で実施されます。TEQは、エンキュー元およびデキュー元がそれら同士で競合しないように、表のパーティションを自動的に管理します。さらに、TEQは、インメモリーのメッセージ・キャッシュを使用することで、パフォーマンスを最適化し、エンキューとデキューのディスクおよびCPUのオーバーヘッドを低減します。

TEQには、次のような長所と短所があります。

TEQは、特に、それぞれのスクライバが、各インスタンスに複数のデキュー元を持つ場合に、Oracle RACの単一キューにスケーラビリティを提供します。
Oracle Real Application Clusters (Oracle RAC)では、パフォーマンス向上の代償としてメモリー使用量が増加します。

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

Transactional Event Queuesとメッセージ・キャッシュ

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

Transactional Event Queuesとメッセージのエンキュー/デキュー

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

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

Transactional Event QueuesとネイティブJMSサポート

TEQには、次のネイティブ・サポートがあります。

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

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

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

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

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

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

Transactional Event Queuesとパーティション化

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

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

Transactional Event QueuesとOracle Real Application Clusters (Oracle RAC)

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

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

Transactional Event Queuesとメッセージ保存

Oracle Databaseリリース20c以降、メッセージの保存はTEQでサポートされます。AQキューは、この機能を以前から備えています。

メッセージ保存期間は、要求に応じてエンキューまたはデキューされた後でメッセージがTEQに保存される時間です。デフォルトは0で、これは、すべてのサブスクライバによってデキューされたメッセージが、可能なかぎり早く削除されることを意味します。これにより、処理後もメッセージをキューに保持できます。

アプリケーションでは、TEQの作成時に保存期間を指定できます。保存期間とそのタイプは、TEQの作成後に、アプリケーションで必要に応じて変更できます。

TEQは、デキュー時刻ベースの保存のみをサポートします。イベント・ストリーム・パーティションに、メッセージのセットを保存します。イベント・ストリーム・パーティションは、そのイベント・ストリーム・パーティション内のメッセージとサブスクライバのペアのうち最大のデキュー時刻に保存期間を加えた時間の経過後にキューから削除されます。このスキームにより、保存の実行前にメッセージの処理が保証されます。これは、AQキューで使用可能な唯一の保存ポリシーでもあります。

Transactional Event Queuesとシーク可能サブスクライバ

サブスクライバについてのシーク操作は、すべてのイベント・ストリーム(キュー・レベル・シーク)または特定の選択イベント・ストリームのセット(シャード・レベルのシーク)を対象にできます。

シーク操作後のすべてのデキュー・コールでは、シーク・ポイント以降のメッセージがデキューされます。シーク・ポイントを下回るメッセージはすべて、サブスクライバが再度要求しないかぎり、サブスクライバによってデキューまたは参照されることはありません。

シーク粒度

サブスクライバは、すべてのイベント・ストリームをシークすることも、キュー内の選択ストリーム・イベントのセットをシークすることもできます。シークするメッセージの選択は、シーク操作で明示的に指定することも、シーク操作の入力から導出することもできます。

様々なタイプのシーク・オプション入力を次に示します。

終わりへのシーク – このシーク・オプションでは、サブスクライバは既存のメッセージに関心がありません。サブスクライバは、シーク操作後に新しくエンキューされたメッセージのみをデキューできます。これは、新規サブスクライバを作成するときのデフォルトの動作です。
始まりへのシーク – このシーク・オプションでは、サブスクライバは「保存済」を含む既存のメッセージに関心があります。サブスクライバは、シーク操作後に新しくエンキューされたメッセージもデキューできます。
特定時刻へのシーク - このシーク・オプションでは、サブスクライバは、エンキュー時刻が入力時刻を上回る「保存済」を含む既存のメッセージに関心があります。シークは、始まりまたは終わりに達すると停止します。
特定メッセージへのシーク - このシーク・オプションでは、サブスクライバは、入力されたメッセージ以降の「保存済」を含む既存のメッセージに関心があります。この場合の入力は特定のメッセージIDであるため、このシークは常にイベント・ストリーム・レベルのシークになります。イベント・ストリームごとに一意のメッセージIDは、シークの実行が必要なすべてのイベント・ストリームに対する入力で指定します。

メッセージの順序

シーク・アクションがメッセージの順序を分割した結果として不正な順序のデキューになることがあります。新しいシーク・ポイントがエンキュー・トランザクションまたはエンキュー・セッションの最初のメッセージではないメッセージであり、新しいシーク・ポイント以降のメッセージがデキューされている場合、残りのメッセージが新しいシーク・ポイントの前にエンキューされたためにエンキュー・セッションまたはエンキュー・トランザクションの一部のメッセージしかアプリケーションで取得できない可能性があります。

正しいシーク・ポイントを選択するか、このような動作を許容するかは、アプリケーションの責任です。

Transactional Event Queuesの制限事項

現在、TEQでは、次のOracle Databaseの機能はサポートされていません。

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

Transactional Event Queuesのチューニング

TEQのパフォーマンスは、次の条件で最適になります。

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

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

パラメータSTREAMS_POOL_SIZEの設定

このパラメータは、Oracle DatabaseでTEQメッセージ・キャッシュに使用可能な共有メモリーのサイズを制御します。指定されていない場合は、共有プール・サイズの最大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を指定した場合は、下限として使用されます。
TEQキューの手動チューニング

TEQは、メッセージ・キャッシュにSTREAMS_POOLメモリーを割り当てることでチューニングできます。GV$AQ_MESSAGE_CACHE_ADVICEビューには、現在のメッセージング負荷のスナップショットに基づいて、TEQへの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推奨値より大幅に大きい場合は、TEQに孤立したサブスクライバがないこと、またはデキュー元がエンキュー・ロードに追い付くことができるように、さらにデキュー元をインスタンスに追加する必要があるかどうかを確認します。STREAMS_POOLのチューニングは、高負荷である期間に複数回行い、メッセージ・ロードの特性が変化したときにも行う必要があります。

ユーザー・イベント・ストリーミング

アプリケーションでは、TEQでメッセージをイベント・ストリーム化する方法を決定できます。その場合、アプリケーションでは、特定のイベント・ストリーム内のメッセージのエンキューを明示的に指定します。

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

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

図adque_usershard1.pngの説明

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

図adque_usershard2.pngの説明

Oracle RACデータベースでは、イベント・ストリームは常にインスタンスによって所有されます。初期状態のイベント・ストリームは、そのイベント・ストリームに最初のメッセージがエンキューされたインタンスによって所有されます。イベント・ストリームの所有者インスタンスは、データベース・インスタンスが停止されたときに変更されることがあります。

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

ユーザー・イベント・ストリーミングの制限

ユーザー・イベント・ストリーミングには、次の制限があります。

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

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

関連項目:

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

AQキュー

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

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

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

関連項目:

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

メモリー要件

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

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

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

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

格納パラメータを指定するには、キュー表の作成時に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があり、バランスに欠けるため、パフォーマンスに影響します。

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

TEQのチューニングの詳細は、「Transactional Event Queuesのチューニング」を参照してください。

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

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

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

キュー表の索引の作成

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

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

基になるキュー表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つを使用することで、そのメッセージの即時処理が可能になります。AQキューでホット・スポットが発生している場合は、かわりにTEQを使用することを検討してください。

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スナップショットを元にレポートを生成し、エンキュー率、デキュー率およびその他のキュー/サブスクライバ別の統計を計算できます。