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

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

• Transactional Event Queues

• AQキュー

• パフォーマンス・ビュー

• AQからTxEventQへの移行

• Prometheus/GrafanaによるTxEventQの監視

• データ・フローとUIフレームワーク設定の監視

• 測定対象の主要メトリック

Transactional Event Queues

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

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

• TxEventQは、特に、それぞれのスクライバが各インスタンスに複数のデキュー元を持つ場合に、Oracle RACの単一キューにスケーラビリティを提供します。

• Oracle Real Application Clusters (Oracle RAC)では、パフォーマンス向上の代償としてメモリー使用量が増加します。

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

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

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

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

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

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

• Transactional Event Queuesとメッセージ保存

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

• Transactional Event Queuesの制限事項

• Transactional Event Queuesのチューニング

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

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

関連項目:

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

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

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

• TxEventQは、新しいルール・エンジンの強化機能を活用します

• メッセージ・キャッシュ内にペイロードのあるメッセージは、デキュー中にディスクから再読取りする必要がありません。

• 相関IDによるデキューまたはその他のJMSプロパティは、ディスクにアクセスすることなく頻繁に評価できます。

• TxEventQに対するパーティション操作には、効率的な一括処理が実装されています。

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

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

• 非永続サブスクライバ

• JMSペイロード

• 優先順位

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

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

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

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

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

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

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

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

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

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

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

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

Transactional Event Queuesとメッセージ保存

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

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

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

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

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

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

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

シーク粒度

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

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

• 終わりへのシーク – このシーク・オプションでは、サブスクライバは既存のメッセージに関心がありません。サブスクライバは、シーク操作後に新しくエンキューされたメッセージのみをデキューできます。これは、新規サブスクライバを作成するときのデフォルトの動作です。

• 始まりへのシーク – このシーク・オプションでは、サブスクライバは「保存済」を含む既存のメッセージに関心があります。サブスクライバは、シーク操作後に新しくエンキューされたメッセージもデキューできます。

• 特定時刻へのシーク - このシーク・オプションでは、サブスクライバは、エンキュー時刻が入力時刻を上回る「保存済」を含む既存のメッセージに関心があります。シークは、始まりまたは終わりに達すると停止します。

• 特定メッセージへのシーク - このシーク・オプションでは、サブスクライバは、入力されたメッセージ以降の「保存済」を含む既存のメッセージに関心があります。この場合の入力は特定のメッセージIDであるため、このシークは常にイベント・ストリーム・レベルのシークになります。イベント・ストリームごとに一意のメッセージIDは、シークの実行が必要なすべてのイベント・ストリームに対する入力で指定します。

メッセージの順序

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

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

Transactional Event Queuesの制限事項

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

• グループ化トランザクション

• サブスクライバ通知およびOCIコールバック通知の匿名での転送はサポートされません。PL/SQLコールバック通知はサポートされます。

• メッセージ・ゲートウェイ

• JMS伝播およびリモート・サブスクライバなど、JMSのOracle拡張機能

• 1つのキュー表に複数のキュー。TxEventQは、CREATE_TRANSACTIONAL_EVENT_QUEUEインタフェースによって作成します。

• (JMS標準で指定されている)メッセージ優先順位、エンキュー時刻の順以外の順序付け。

• JDBC thick (OCI)ドライバ。

• TxEventQとAQのキュー間の伝播

• メッセージ変換

Transactional Event Queuesのチューニング

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

• 各サブスクライバのデキュー元が各インスタンス内にあります。

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

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

• パラメータSTREAMS_POOL_SIZEの設定

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

• TxEventQキューの手動チューニング

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

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

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

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

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

図adque_usershard1.pngの説明

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

図adque_usershard2.pngの説明

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

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

例8-1 クロス・インスタンス・エンキューのREMOTE_LISTENERパラメータの設定

TxEventQに対してクロス・インスタンス・エンキューを有効にするには、Oracle RACで使用可能な他のすべてのインスタンスのリスナー・アドレスを持つようにREMOTE_LISTENERを各インスタンスに設定する必要があります。

たとえば、4つのノードを持つOracle RACクラスタを考えてみます。このような設定では、各ノードのREMOTE_LISTSENERに、次のようにOracle RACの4つのノードすべてのリスナー・アドレスが必要です。

REMOTE_LISTENER = (DESCRIPTION= (ADDRESS_LIST=
  (ADDRESS= (PROTOCOL=TCP) (PORT=<node1 PORT>) (HOST=<node1 IP>))
  (ADDRESS= (PROTOCOL=TCP) (PORT=<node2 PORT>) (HOST=<node2 IP>))
  (ADDRESS= (PROTOCOL=TCP) (PORT=<node3 PORT>) (HOST=<node3 IP>))
  (ADDRESS= (PROTOCOL=TCP) (PORT=<node4 PORT>) (HOST=<node4 IP>))
))

または、TNS別名が次のようにtnsnames.oraのOracle RACノードのリスナー・アドレスで設定されている場合、

nd1=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=<node1 PORT>)(HOST=<node1 IP>)))
nd2=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=<node2 PORT>)(HOST=<node2 IP>)))
nd3=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=<node3 PORT>)(HOST=<node3 IP>)))
nd4=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=<node4 PORT>)(HOST=<node4 IP>)))

REMOTE_LISTENERは次のように設定できます。

REMOTE_LISTENER='nd1,nd2,nd3,nd4'

各ノードでREMOTE_LISTENERが正しく設定されると、AQJMSクライアント・ライブラリおよびJDBC Thinドライバを使用して任意のインスタンスで任意のキーを含むメッセージをエンキューできます(TxEventQ)。次の例では、任意のOracle RACインスタンスでキー"RED"をエンキューできます。すべての"RED"メッセージを格納する正しいイベント・ストリームでパブリッシュされます。メッセージ・パブリッシャは、高パフォーマンスを実現するためにイベント・ストリームの所有者インスタンスに接続することをお薦めします。

TopicConnectionFactory    tc_fact   = null;
TopicConnection           t_conn    = null;
TopicSession              jms_sess;
TopicPublisher            publisher1;
Topic                     shipped_orders;
int                       myport = 5521;

/* create connection and session */
tc_fact = AQjmsFactory.getTopicConnectionFactory(...);
t_conn = tc_fact.createTopicConnection();
jms_sess = t_conn.createTopicSession(true, Session.CLIENT_ACKNOWLEDGE);
shipped_orders = ((AQjmsSession )jms_sess).getTopic("OE", "Shipped_Orders_Topic");
publisher1 = jms_sess.createPublisher(shipped_orders);

/* Create TextMessage */
TextMessage     text_message = jms_sess.createTextMessage();

/* Set key as correlation */
text_message.setJMSCorrelationID("RED");

/* Publish  */
publisher1.publish(text_message);

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

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

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

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

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

関連項目:

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

AQキュー

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

• キューの永続メッセージのパフォーマンスの概要

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

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

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

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

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

関連項目:

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

メモリー要件

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

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

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

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

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

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

TxEventQのチューニングの詳細は、「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キューでホット・スポットが発生している場合は、かわりにTxEventQを使用することを検討してください。

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

関連項目:

• キュー表の作成

• キュー表の変更

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

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

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

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

関連項目:

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

パフォーマンス・ビュー

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

• V$AQ_MESSAGE_CACHE_STAT: シャード・キューのメモリー管理

• V$AQ_SHARDED_SUBSCRIBER_STAT: シャード・キュー・サブスクライバの統計

• V$AQ_MESSAGE_CACHE_ADVICE: シミュレートされたメトリック

• V$AQ_REMOTE_DEQUEUE_AFFINITY: デキュー・アフィニティ・インスタンス・リスト

• V$PERSISTENT_QUEUES: インスタンスにあるすべてのアクティブな永続キュー

• V$PERSISTENT_SUBSCRIBERS: インスタンスにある永続キューのすべてのアクティブなサブスクライバ

• V$PERSISTENT_PUBLISHERS: インスタンスにある永続キューのすべてのアクティブなパブリッシャ

• V$BUFFERED_QUEUES: インスタンスにあるすべてのバッファ済キュー。

• V$BUFFERED_SUBSCRIBERS: インスタンスにあるすべてのバッファ済キューのサブスクライバ

• V$BUFFERED_PUBLISHERS: インスタンスにあるすべてのバッファ済パブリッシャ

• V$PERSISTENT_QMN_CACHE: 永続キューのバックグラウンド・タスクのパフォーマンス統計

• V$AQ: データベース内の状態ごとのメッセージ数

• V$AQ_BACKGROUND_COORDINATOR: AQのマスター・バックグラウンド・コーディネータ・プロセス(AQPC)のパフォーマンス統計

• V$AQ_JOB_COORDINATOR: 1コーディネータ当たりのパフォーマンス統計

• V$AQ_NONDUR_REGISTRATIONS: 非永続登録

• V$AQ_SERVER_POOL: 全サーバーのパフォーマンス統計

• V$AQ_CROSS_INSTANCE_JOBS: クロス・プロセス・ジョブの説明

• V$AQ_NONDUR_REGISTRATIONS: 非永続登録

• V$AQ_NOTIFICATION_CLIENTS: セキュアなOCIクライアント接続

• V$AQ_SUBSCRIBER_LOAD: 永続サブスクライバ

• V$AQ_NONDUR_SUBSCRIBER: 非永続サブスクライバ

• V$AQ_NONDUR_SUBSCRIBER_LWM: 非永続サブスクライバのLWM

• V$AQ_MESSAGE_CACHE: パフォーマンス統計

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

AQからTxEventQへの移行

• フローチャート: AQからTxEventQへの移行

• ウォークスルーの例

• AQからTxEventQに移行するステップ

• 移行機能の概要

• 制限事項と回避策

Transactional Event Queues (TxEventQ)は、スケーラビリティ、パフォーマンス、キーベースのシャーディング、JavaクライアントとのKafka互換性など、アドバンスト・キューイング(AQ)を超える多くの利点と機能を提供するOracleによる次世代のメッセージング・システムです。オンライン移行ツールは、AQからTxEventQへの移行プロセスを合理化するように設計された、使いやすいインタフェースを提供します。直感的なユーザー・エクスペリエンスにより、最も複雑なシナリオでも簡素化されるため、ユーザーはAQオブジェクトの複雑さを掘り下げる必要がなくなります。このツールには、AQとTxEventQ間の互換性診断が組み込まれています。この診断にはAQメタデータとデータの検証が含まれ、発生した問題に対する対話型の解決策が可能になります。さらに、このツールは、障害の可能性がある場合にフォールバックおよびリカバリのシナリオに対処するための簡単な手順を提供しています。

AQのTxEventQへのアップグレードは、機能の格差、重要なデータ表現の変更およびその他の要因による一般的なアップグレードのような標準的な手順ではありません。手動で移行するには、システムの停止時間およびAQとTxEventQの両方の内部メカニズムを深く理解する必要があります。様々なバージョンのAQまたはTxEventQからの内部データを既存のメッセージとともに処理する複雑さは、重大な課題を引き起こす可能性があります。さらに、TxEventQを統合するためにアプリケーションを書き直すと、費用がかかる可能性があります。これらの複雑さに対処するために、Oracle Database 23aiでは、移行に関連する様々なステップを自動化するように設計されたPL/SQLパッケージDBMS_AQMIGTOOLが導入されています。このパッケージには、AUTOMATIC、INTERACTIVE、OFFLINE、ONLY_DEFINITIONなどの複数の移行モードがあり、特定の要件に柔軟に対応できます。

移行ツール・インタフェースには、次の機能があります。

• AQの定義とデータを検査し、サポートされていない機能を報告します。

• 検出されたサポートされていない機能に基づいて、移行を承認または阻止します。

• AUTOMATIC、INTERACTIVE、OFFLINE、ONLY_DEFINITIONのモードで移行を開始します。

• 移行インタフェースでユーザーが開始したプロシージャを介して移行コミットまたはAQフォールバックを提供します。

• AQおよびTxEventQの両方で、現在PROCESSED状態ではないメッセージを追跡します。

• 任意のキューの移行履歴レコード。

• 古いメッセージを消費しない場合にAQメッセージをパージするオプションを提供します。

• 移行手順では、ローリング・アップグレードがサポートされています。移行手順では、Oracle GoldenGate Replica (OGG)レプリケーションもサポートされています。

フローチャート: AQからTxEventQへの移行

図8-1 フローチャート: AQからTxEventQへの移行

ウォークスルーの例

DBMS_AQMIGTOOLプロシージャの使用方法の理解を深めるために、いくつかの仮想シナリオについて説明します。

シナリオ1

JSON_QUEUEという名前のAQを持つaquserというユーザーを含むシナリオを考えてみます。このAQは、顧客イベントをJSONペイロード形式で格納します。AQで使用される機能がTxEventQでサポートされていないかどうかをユーザーが判断する場合は、DBMS_AQMIGTOOL.CHECK_MIGRATION_TO_TXEVENTQプロシージャを実行できます。

SQL> DECLARE
  2    migration_report sys.TxEventQ_MigReport_Array := sys.TxEventQ_MigReport_Array();
  3  BEGIN
  4    DBMS_AQMIGTOOL.CHECK_MIGRATION_TO_TXEVENTQ('aquser', 'JSON_QUEUE', migration_report);
  5    dbms_output.put_line('Migration report unsupported events count: ' || migration_report.COUNT);
  6
  7  END;
  8  /
Migration report unsupported events count: 0

PL/SQL procedure successfully completed.

JSON_QUEUEを確認すると、サポートされていない機能が存在しないことがわかります。その結果、ユーザーはDBMS_AQMIGTOOL.INIT_MIGRATIONプロシージャを開始することで移行を続行できます。

SQL> EXECUTE DBMS_AQMIGTOOL.INIT_MIGRATION(cqschema => 'aquser', cqname => 'JSON_QUEUE');

PL/SQL procedure successfully completed.

SQL> SELECT name || ' -> ' || sharded AS "QueueName -> Sharded" FROM user_queues where queue_type = 'NORMAL_QUEUE';

QueueName -> Sharded
--------------------------------------------------------------------------------
JSON_QUEUE -> FALSE
JSON_QUEUE_M -> TRUE

移行プロセスは、AQと同じ構成で暫定TxEventQのJSON_QUEUE_M (デフォルトの接尾辞M付き)を作成することから始まります。このプロシージャを実行すると、ユーザーはエンキューやデキューなどのデータ操作を実行できます。

ノート:

エンキューおよびデキュー・コールでは調整は不要です。ワークロードは変更せずに続行できます。

ユーザーは、USER_TXEVENTQ_MIGRATION_STATUSビューで問い合せることで、成功した評価を確認できます。

SQL> SELECT event FROM USER_TXEVENTQ_MIGRATION_STATUS WHERE source_queue_name = 'JSON_QUEUE' AND event = 'Init_Migration';

EVENT
--------------------------------------------------------------------------------
Init_Migration

DBMS_AQMIGTOOL.COMMIT_MIGRATIONの前提条件は、AQが空であること(すべてのメッセージがPROCESSEDまたはEXPIRED状態であること)です。ユーザーは、DBMS_AQMIGTOOL.CHECK_MIGRATED_MESSAGESプロシージャを使用して、AQおよび暫定TxEventQ内のメッセージを監視できます。

SQL> DECLARE
     2    migrated_q_msg_cnt    number := 0;
     3    aq_msg_cnt            number := 0;
     4    BEGIN
     5        DBMS_AQMIGTOOL.CHECK_MIGRATED_MESSAGES(
     6                     cqschema                   => 'aquser',
     7                     cqname                     => 'JSON_QUEUE',
     8                     txeventq_migrated_message  => migrated_q_msg_cnt,
     9                     cq_pending_messages        => aq_msg_cnt);
    10       dbms_output.put_line('AQ ready state message count: ' || aq_msg_cnt);
    11       dbms_output.put_line('Migrated TxEventQ message count: ' || migrated_q_msg_cnt);
    12    END;
    13    /
AQ ready state message count: 1000
Migrated TxEventQ message count: 3500

PL/SQL procedure successfully completed.

AQのREADY状態メッセージ数がゼロに達すると、ユーザーはDBMS_AQMIGTOOL.COMMIT_MIGRATIONプロシージャを実行して移行を完了できます。

SQL> EXECUTE DBMS_AQMIGTOOL.COMMIT_MIGRATION(cqschema => 'aquser', cqname => 'JSON_QUEUE');

PL/SQL procedure successfully completed.

SQL> SELECT name || ' -> ' || sharded AS "QueueName -> Sharded" FROM user_queues where queue_type = 'NORMAL_QUEUE';

QueueName -> Sharded
--------------------------------------------------------------------------------
JSON_QUEUE -> TRUE

移行が成功した後、JSON_QUEUEはAQからTxEventQに変換されています。ユーザーは、通常どおりJSON_QUEUEで日常の操作をシームレスに進めることができます。

ユーザーは、USER_TXEVENTQ_MIGRATION_STATUSビューで問い合せることで、成功した評価を確認できます。

SQL> SELECT event FROM USER_TXEVENTQ_MIGRATION_STATUS WHERE source_queue_name = 'JSON_QUEUE' AND event = 'Commit_Migration';

EVENT
--------------------------------------------------------------------------------
Commit_Migration

シナリオ2

シナリオ1で説明した同じ例を考えて、DBMS_AQMIGTOOL.INIT_MIGRATIONが正常に実行されるまで続行します。

特定の状況では、ワークロードの実行後に、サポートされていない機能が検出される可能性があります。たとえば、ユーザーがエンキュー操作で変換を構成した場合です。このような場合、ユーザーはDBMS_AQMIGTOOL.CHECK_STATUSプロシージャを使用して、移行プロセスを正常に完了できるか、またはエラーをクリアするためのアプリケーション変更が必要かどうかを判断できます。

SQL> DECLARE
     2        mig_STATUS    VARCHAR2(128);
     3        mig_comments  VARCHAR2(1024);
     4    BEGIN
     5        DBMS_AQMIGTOOL.CHECK_STATUS(
     6                   cqschema                 => 'aquser',
     7                   cqname                   => 'JSON_QUEUE',
     8                   status                   => mig_STATUS,
     9                   migration_comment        => mig_comments);
   10        dbms_output.put_line('Migration Status: ' || mig_STATUS);
   11        dbms_output.put_line('Migration comments: ' || mig_comments);
   12    END;
   13    /
Migration Status: Compatibility Error: Transformation in Enq Unsupported Feature
Migration comments: Unsupported parameter in Enqueue

PL/SQL procedure successfully completed.

また、ユーザーは、USER_TXEVENTQ_MIGRATION_STATUSビューを問い合せて、取得されたサポートされていない機能のリストを確認することもできます。

SQL> SELECT event FROM USER_TXEVENTQ_MIGRATION_STATUS WHERE source_queue_name = 'JSON_QUEUE' AND event_status = 2;

EVENT
--------------------------------------------------------------------------------
Transformation in Enq

ユーザーが後でメッセージを失わずに移行プロセスを取り消すことにした場合は、デフォルトで設定されているDBMS_AQMIGTOOL.CANCEL_MIGRATIONプロシージャのDBMS_AQMIGTOOL.RESTOREオプションを使用できます。

SQL> SELECT count(*) FROM JSON_QUEUE_TABLE WHERE q_name = 'JSON_QUEUE';

  COUNT(*)
----------
      1000

1 row selected.

SQL> EXECUTE DBMS_AQMIGTOOL.CANCEL_MIGRATION(cqschema => 'aquser', cqname => 'JSON_QUEUE', cancelmode => DBMS_AQMIGTOOL.RESTORE);

PL/SQL procedure successfully completed.

SQL> SELECT name || ' -> ' || sharded AS "QueueName -> Sharded" FROM user_queues WHERE queue_type = 'NORMAL_QUEUE';

QueueName -> Sharded
--------------------------------------------------------------------------------
JSON_QUEUE -> FALSE

SQL> SELECT count(*) FROM JSON_QUEUE_TABLE WHERE q_name = 'JSON_QUEUE';

  COUNT(*)
----------
      4500

1 row selected.

明らかなように、DBMS_AQMIGTOOL.CANCEL_MIGRATIONの実行後のキュー表内のメッセージ数は、初期カウント(1000メッセージ)とTxEventQからリストアされたメッセージ(3500メッセージ)を反映しています。

AQからTxEventQに移行するステップ

AQからTxEventQに移行するには、次のステップを実行します。

1. ソースAQが移行と互換性があるかどうかを確認します。

   まず、ソースAQがTxEventQへの移行に適しているかどうかを確認します。次の手順により、AQで利用される機能でTxEventQでサポートされていないものを識別できます。

   DBMS_AQMIGTOOL.CHECK_MIGRATION_TO_TXEVENTQ(cqschema, cqname, migration_report, checkmode)

   checkmodeパラメータのDBMS_AQMIGTOOL.CURRENTオプションは、現在のキュー・メタデータと既存のメッセージのみを検査します。ただし、今後のキュー操作は検査されません。さらに、変換と同様に、特定の機能は永続キュー・データに依存せず、実行時エンキュー/デキュー操作なしでは識別できません。サポートされていないすべての機能を包括的に識別するには、checkmodeパラメータでDBMS_AQMIGTOOL.ENABLE_EVALUATIONオプションを使用し、その後ユーザー・アプリケーションを実行することをお薦めします。

   出力に互換性がある場合、migration_reportはデータを生成しません。非互換性がないことが確認されたら、DBMS_AQMIGTOOL.INIT_MIGRATIONに進むことができます。制限事項にリストされている機能のいずれかがアプリケーションで使用されている場合、ユーザーは移行APIを開始しないでください。これらは、ほとんどが、あまり一般的に使用されていません。

2. 移行を開始し、暫定TxEventQを作成します。

   移行プロセスを開始するには、次の方法を使用して暫定TxEventQを作成することから始めます。

   DBMS_AQMIGTOOL.INIT_MIGRATION(cqschema, cqname, txeventqschema, txeventqname, mig_mode, ordering, suffix)

   DBMS_AQMIGTOOL.INIT_MIGRATIONの実行を通して、互換性チェックがAQ定義とデータの両方を使用して実行されます。サポートされていない機能が検出されると、例外が発生します。このような場合、ユーザーはアプリケーションの変更、特定された非互換性への対処(ガイダンスについては制限事項と回避策の項を参照)を実行してから、INIT_MIGRATIONの実行を再試行できます。

   互換性が見つかった場合、このプロシージャは移行プロセスを開始し、キュー・プロパティ、ペイロード・タイプおよびサブスクライバ・データを包含する、AQの同じ構成で暫定TxEventQを作成します。このプロシージャの実行後、AQに対するすべての管理操作が制限されることに注意してください。

3. 移行をコミットまたは取り消すことによって移行を完了します。

   移行プロセスの終了には、移行をコミットするか取り消すかという2つの選択肢が伴います。

   • AQからのすべてのメッセージが消費され(すべてのメッセージがPROCESSED状態であることを示しています)、非互換性が見つからない場合、ユーザーは次を実行して移行を完了できます。

     DBMS_AQMIGTOOL.COMMIT_MIGRATION(cqschema, cqname, ignore_warning)

     このプロシージャはAQを削除し、暫定TxEventQの名前をAQの名前に変更します。さらに、TxEventQはすべての管理操作に対して有効になり、移行プロセスを完了します。

   • ユーザーがDBMS_AQMIGTOOL.INIT_MIGRATIONの後に互換性エラーを受け取った場合、その操作はブロックされ、ユーザーは互換性の問題を確認するよう求められます。サポートされていない機能は、USER_TXEVENTQ_MIGRATION_STATUSビューに記録されます。このような問題が発生しているユーザーには、非互換性に対処するようにアプリケーションを適切に変更するか、 プロシージャを起動してAQをリストアする選択肢があります。

     DBMS_AQMIGTOOL.CANCEL_MIGRATION(cqschema, cqname, cancelmode)

     DBMS_AQMIGTOOL.CANCEL_MIGRATIONを利用すると、ユーザーは、指定されたcancelmodeに基づいてTxEventQメッセージとその状態をAQに戻すことができます。このプロセスにより、データ損失がないことが保証されます。CANCEL_MIGRATIONを実行すると、メッセージとその状態がTxEventQからAQに移動するため、停止時間が長くなる可能性があることに注意してください。

   要約すると、この最終移行ステージには柔軟性があり、ユーザーは特定のニーズと状況に基づいてコミットメントとリストアを選択できます。

移行機能の概要

DBMS_AQMIGTOOLパッケージは、AQからTxEventQへのシームレスな移行に役立ちます。

• 移行プロセスを開始するために、DBMS_AQMIGTOOL.INIT_MIGRATIONは、ペイロード・タイプ、ルール、サブスクライバ、権限、PLSQL通知などを含むAQの構成をコピーする暫定TxEventQを設定します。移行が完了するか取り消されるまで、TxEventQ構成の整合性を維持するためにAQによる管理変更が制限されます。

• 移行中、新しいワークロードは徐々に暫定TxEventQに遷移します。新しいエンキュー・リクエストは暫定TxEventQに送られ、デキュー・リクエストは最初にAQ、次に暫定TxEventQをチェックし、順次AQを空にします。メッセージの順序付けは、INIT_MIGRATIONのordering構成に従って維持されます。

• 移行を完了するには、DBMS_AQMIGTOOL.COMMIT_MIGRATIONはAQを削除し、暫定TxEventQの名前をAQの名前に変更して、アプリケーションの互換性を確保します。

• 移行を取り消すには、RESTOREモードのDBMS_AQMIGTOOL.CANCEL_MIGRATIONが、メッセージとその状態を暫定TxEventQからAQに移動し、データが失われないようにしてから、暫定TxEventQを削除します。

• サポートされていない機能を取得するために、DBMS_AQMIGTOOL.CHECK_MIGRATION_TO_TXEVENTQ は、AQのメタデータおよびメッセージを調査して、サポートされていない機能を取得します。DBMS_AQMIGTOOL.ENABLE_EVALUATIONオプションは、実行時固有のサポートされていない機能を取得します。

制限事項と回避策

移行プロセスを開始する前に、次のサポートされていない機能のリストを確認することをお薦めします。

表8-1 サポートされていない機能と回避策

名前	機能タイプ	説明	回避策
再試行の遅延 関連項目: MESSAGE_PROPERTIES_T。	キューレベル	アプリケーションのロールバック後にメッセージをデキューできるまでの遅延を秒単位で指定します	DBMS_AQADM.ALTER_QUEUEを使用して、retry_delayをゼロに設定します。
変換	メッセージレベル	メッセージをエンキューする前またはサブスクライバがメッセージをデキューした後で、メッセージの変換を許可します	変換をアプリケーション・レイヤーに移動します。
listen 関連項目: リスニング・プロシージャ。	others	1つ以上のキューでエージェント/サブスクライバのリストをリスニングします	デキュー参照を使用して単一キュー・リスニングを実装します。
無効な優先度の値(有効な範囲 - 0から9)	メッセージレベル	TxEventQでは、0から9までの優先度値のみが許可されます。AQのデフォルトの優先度値は1で、TxEventQの優先度値は4です。また、AQは低い値を高い優先度と解釈しますが、TxEventQはその逆を解釈します。つまり、より高い値は高い優先度と解釈されます。	アプリケーションが有効な範囲(0から9)に準拠していることを確認します。また、AQおよびTxEventQの優先度値の解釈の違いにも注意してください。

移行前にAQで伝播がすでにスケジュールされている場合、非互換性エラーが発生します。これに対処するために、ユーザーはDBMS_AQADM.UNSCHEDULE_PROPAGATIONを使用して伝播をスケジュール解除できます。移行後、DBMS_AQADM.SCHEDULE_PROPAGATIONを使用してTxEventQに伝播をスケジュールできます。

表8-2 回避策のないサポートされていない機能

名前	機能タイプ
メッセージのグループ化(トランザクションのグループ化) 関連項目: CREATE_QUEUE_TABLEプロシージャ MESSAGE_PROPERTIES_Tタイプ	キューレベル
順序逸脱および相対メッセージID 関連項目: ENQUEUE_OPTIONS_Tタイプ	メッセージレベル
受信者リスト 関連項目: MESSAGE_PROPERTIES_Tタイプ	メッセージレベル

関連項目:

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

Prometheus/GrafanaによるTxEventQの監視

次に、高スループット・メッセージング・システムのリアルタイム監視フレームワークによって得られる利点の一部を示します。

• メッセージング・システムの正常性を一目で認識して、メッセージング・ワークロードの程度にあわせてリソースを増減できます。

• 全体的な主要パフォーマンス指標の監視: エンキュー率、デキュー率、キューの深さなど。

• メッセージング・アクティビティに由来するCPUの負荷、メモリーの使用状況、およびデータベース待機クラスを監視することで、データベースの負荷またはシステムの負荷によるメッセージングのボトルネックを見つけます。

• 各キューの正常性状態を確認して、パフォーマンスの低いキューをすばやく簡単に識別します。

• メッセージングのメトリックに場所を問わずにアクセスすることで、開発者はアプリケーションからオーバーヘッドを監視して、メッセージ関連の問題をデバッグできます。

• Grafanaで機能に問題が発生したときにアラートを設定することで迅速に対応します。

関連項目:

詳細は、Transactional Event Queuesの監視を参照してください。

データ・フローとUIフレームワーク設定の監視

TxEventQ Monitorシステムは、3つの個別のオープンソース・コンポーネントで構成されています。Dockerコンテナは、監視フレームワークがインストールされているマシンのすべての環境、サービス、および依存関係の管理を円滑にするために使用します。

• Oracle DBエクスポータ: Oracle Database用のPrometheusエクスポータ。データベースに接続し、メトリックを問い合せて、メトリックをPrometheus様式のメトリックに書式化します。

• Prometheus: 監視システムおよび時系列データベース。Oracle DBエクスポータから収集したメトリックを時系列形式で管理します。

• Grafana: Prometheusをデータ・ソースとして指定する、分析およびインタラクティブなビジュアライゼーション・プラットフォーム。

TxEventQ Monitorシステムは、Prometheus Oracle DBエクスポータ、PrometheusおよびGrafanaを含む3つのサービスで構成されています。このシステムは、Dockerで実行するように設計されています。これにより、ユーザーはシステムを軽量でポータブルな自己完結コンテナとして使用できるようになり、事実上あらゆる場所で実行できるようになります。ExporterはOracle DBへのコネクタで、問合せ結果をPrometheus様式のメトリックに書式化します。Prometheusは、時系列データベースであり、定期的にメトリックを問い合せて収集/保存するようにエクスポータを制御します。Grafanaは、データ・ソースとしてPrometheusを使用して、メトリックを表示し視覚化します。Grafanaは、チャート作成と計算が組み込まれたユーザー・インタフェースです。すべてのサービスは、Docker-composeによって構成、管理および処理されます。

図8-2 Transaction Event Queueの監視

「図8-2 Transaction Event Queueの監視」の説明

Grafanaを使用してTxEventQダッシュボードを監視するには、次のステップを実行します。

1. 管理ユーザー名とパスワードを使用して、Grafanaダッシュボードにログインします。「Welcome」ページが表示されます。

   図8-3 Welcomeページ

   
   

   

   
   
2. 「Welcome」ページの「TxEventQ Monitor」をクリックします。Grafanaが設定されると、4つの選択範囲内に表示されます。最上位の選択範囲は、インスタンス、キュー、サブスクライバおよびディスク・グループが対象です。次の4つの選択肢があります。

   • TxEventQ全体のすべてのサマリー

   • データベース・メトリックのサマリー

   • システム・メトリックのサマリー

   • TxEventQごとのサブスクライバのサマリー

   
   
   
   
   

3. 各サマリーをクリックすると、サマリーに関する情報が表示されます。

次の各図は、それぞれTxEventQサマリー、DBサマリー、データベース待機クラス待機時間、システム・サマリーのダッシュボードを示しています。

TxEventQサマリー・ダッシュボードには、全体的に集計されたTxEventQの統計情報(ステータス、キューの数、サブスクライバの数、エンキュー率/デキュー率、メッセージの数など)が示されます

データベース・サマリー・ダッシュボードには、全体的なDBのパフォーマンスと統計情報が示されます。

図8-4データベース・サマリー

「図8-4 データベース・サマリー」の説明

画面のタイルは、次のとおりです。

• Oracle DB Status – 「Up」または「Down」

• Active User Sessions – アクティブなユーザー・セッションの数

• Active Background sessions – アクティブなバックグラウンド・セッションの数

• Inactive user sessions – 非アクティブなユーザー・セッションの数

• Number of processes – データベース・プロセスの数

• ASM Disk Usage – ディスク・ボリュームごとのディスク空き領域の割合

• DB Activity – 実行数、合計解析数、ユーザー・コミット数、ユーザー・ロールバック数についてのSQLアクティビティ。

データベース待機クラスの待機時間は、「DB Wait Class Latency」ダッシュボードに示されます。待機クラス待機時間は、データベースの待機クラス・イベントの待機時間(ミリ秒単位)です。これは、より詳細なAWRレポート分析によるオーバーヘッド分析の指針として使用できます。

図8-5 データベース待機クラス待機時間

「図8-5 データベース待機クラス待機時間」の説明

「System Summary」ダッシュボードには、システム・レベルのメトリックとキュー・レベルのメトリックが示されます。CPU使用率と使用メモリーに基づいて、Oracle DBを実行しているシステムの全体的なパフォーマンスと状態を反映します。

図8-6システム・サマリー

「図8-6システム・サマリー」の説明

システム・レベルの統計

• Number of CPUs – システムに搭載されたCPUの合計数

• OS CPU Load - すべてのシステム・プロセスとユーザー・プロセスが現在使用しているCPU処理能力の割合

• CPU Usage: CPUビジーの割合(すべてのプロセス)と、ユーザー・プロセスのCPUビジーの割合

• Total Physical Memory: システム(Oracle RACデータベースの場合は1つのインスタンス)に搭載された合計メモリー

• Total Free Physical Memory: インスタンスの合計空きメモリー量

• System Physical Memory free: 空き物理メモリーの割合

TxEventQキュー・レベルの統計

1つの特定のキューの統計情報(率、合計メッセージ数、キューの深さ、消費の推定時間、前回のデキューからの経過時間)が表示されます。このキューは、ユーザーがドロップダウン・メニューから選択できます。

• Enqueue/Dequeue Messages: エンキューされたメッセージ数、デキューされたメッセージ数

• Enqueue/Dequeue rate: 1秒当たりにエンキューおよびデキューされたメッセージの数

• TxEventQ Depth – キューに残っているメッセージ数

• TxEventQ Name - キューの名前

• Subscriber Name – サブスクライバの名前

• Time to drain if no enq – 新規エンキューがないときにキューの排出にかかる推定時間

• Time since last dequeue – キューに対する前回のデキューからの経過時間

測定対象の主要メトリック

ここでは、前述のメトリックの補足的な詳細と、そうしたメトリックをGrafana画面から読み取る方法について説明します。ドロップダウン・メニューのオプションは、データベース・インスタンス、キュー、およびサブスクライバのレベルで使用できます。AQ/TxEventQサマリーのメトリックとデータベースのメトリックは、ユーザーがドロップダウン・メニューから選択したデータベース・インスタンスに関するものです。

• AQ/TxEventQサマリーのメトリック

  • TxEventQ Status: TxEventQが実行中かどうか

  • Total Number of TxEventQs: 実行中のTxEventQの数

  • Total TxEventQ Subscribers: すべてのTxEventQに対するサブスクライバの合計数

  • Overall Enq/Deq Rates: すべてのTxEventQに対する合計エンキュー率/デキュー率

  • Overall Enqueued Messages: キュー・システム全体でエンキューされたメッセージの合計数

  • Overall Dequeued Messages: キュー・システム全体でデキューされたメッセージの合計数

• データベース・サマリーのメトリック

  • Oracle DB Status: Oracle DBが実行中かどうか

  • Active User Sessions: アクティブなユーザー・セッションの数

  • Active Background Sessions: アクティブなバックグラウンド・セッションの数

  • Inactive User Sessions: 非アクティブなユーザー・セッションの数

  • Number of Processes: 実行中のOracleプロセスの数

  • ASM Disk Usage: Oracle Automatic Storage Managementディスク・グループのメモリー使用状況(+DATAや+RECOなど)

  • DB Activity: 発生した特定のDBアクティビティの数(実行数、ユーザー・コミット数、解析合計数、ユーザー・ロールバック数など)。

  • DB Wait Class Latency: DB待機クラス(管理、アプリケーション、コミット、同時処理、構成、アイドル、ネットワーク、その他、システムI/O、ユーザーI/O)の平均待機時間(ミリ秒単位)

• システム・サマリーのメトリック

  • Number of CPUs: Oracle DBを実行しているシステムのCPUの数

  • OS CPU Load: 現在動作中または準備完了状態で、オペレーティング・システムのスケジューラによる実行を待機しているプロセスの数。この統計値を見ると、通常、プラットフォームの平均ロードが分単位でわかる

  • CPU Usage (Busy + User): リアルタイムのCPU使用率(ビジー状態のCPUまたはユーザー・コードを実行しているCPU)

  • Total Physical Memory: システムの合計物理メモリー。

  • Total Free Physical Memory: システムの合計空き物理メモリー。

  • System Free Physical Memory: システムの空きメモリーの割合。

• キュー・レベルのメトリック

  • Enq/Deq Messages: TxEventQに対してエンキュー/デキューされたメッセージの合計数

  • Enq/Deq Rate: TxEventQのエンキュー率/デキュー率

  • TxEventQ Depth: キューに残っているメッセージの合計数。

  • TxEventQ Name: TxEventQの名前

  • Subscriber Name: TxEventQサブスクライバの名前

  • Time to Drain if No Enq: TxEventQにエンキューされたメッセージがない場合に、すべてのメッセージの消費にかかる合計時間

  • Time since Last Deq: 現在の時刻とTxEventQに対する前回のデキュー操作の時刻の時差

関連項目:

詳細は、Transactional Event Queuesの監視を参照してください。