| Oracle® Databaseアドバンスト・キューイング・ユーザーズ・ガイド 12c リリース1 (12.1) B71332-03 |
|
 前 |
 次 |
この章では、Oracle Database Advanced Queuing (AQ)のパフォーマンスおよび拡張性に関する事柄について説明します。
この章の内容は次のとおりです。
Oracle Database 12cリリース1 (12.1)のAdvanced Queuingは、高いパフォーマンスと可用性を持つシャードJMSキューを導入しています。シャード・キューにより、異なるキュー・シャードにある2つのメッセージ間の順序付けがベスト・エフォートで実行されるため、エンキューおよびデキューのスループットが、特にOracle RACインスタンスで向上します。JMSシャード・キューの利点およびトレードオフは、次のとおりです。
特に各サブスクライバが各インスタンスに複数のデキュー元を持つ場合に、JMSシャード・キューにより、Oracle Real Application Clusters (Oracle RAC)上の単一のキューの拡張性が向上します。
JMSシャード・キューは、増加したメモリー使用量をトレードオフしてパフォーマンスを向上します。
永続メッセージは、エンキューされるとデータベース表に格納されます。永続メッセージに対するキュー操作のパフォーマンス特性は、基になるデータベース操作のパフォーマンス特性と同等です。エンキュー操作のコード・パスは、3つの索引構成表を持つ複数列のキュー表に対するSELECTおよびINSERTに相当します。デキュー操作のコード・パスは、複数列の表のSELECT操作およびデキュー索引構成表のDELETE操作に相当します。Oracle RACを使用しないで適切なストリーム・プール・メモリーが存在する場合などの多くの使用例で、デキュー操作は最適化され、複数列の表のSELECT操作に相当します。
|
注意: 表内のキューの数によって、パフォーマンスが影響を受けることはありません。 |
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に設定できます。
キュー操作の拡張性は、基になるデータベース操作の拡張性と同等です。waitオプションを指定して適用されたデキュー操作は、成功するかまたは待機期間が経過するまで戻れません。共有サーバー環境では、(待機時間を含めた)コールの期間中、共有サーバー・プロセスがデキュー操作にのみ占有されます。このようなプロセスが多数存在すると、パフォーマンスおよび拡張性に重大な問題が発生し、共有サーバー・プロセスがデッドロック状態となる可能性があります。そのため、waitオプションを指定したデキュー・リクエストを適用する場合は、専用のサーバー・プロセスを使用することをお薦めします。この制限は、強制ではありません。
|
関連項目: waitオプションの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDEQUEUE_OPTIONS_T型に関する項を参照してください。 |
Oracle Database Advanced Queuing表のレイアウトは、他のデータベース表および索引のレイアウトと同様です。
|
関連項目: チューニングの推奨事項は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
Oracle RACデータベース以外で、最適なマルチコンシューマ・デキュー・パフォーマンスを得るには、Streamsプール・サイズは20MB以上である必要があります。永続キューイング・デキュー操作は、特に同時処理の場合、パフォーマンスを最適化するためにストリーム・プールを使用します。ただし、これは要件ではなく、コードが自動的に最適度の低いコード・パスに切り替わります。
JMSシャード・キューは、高スループットなメッセージ・システムで最適なパフォーマンスを得るためにメッセージ・キャッシュを導入しています。理想として、Streamsプール・サイズは、JMSシャード・キュー内のメッセージの予想されるバックログをキャッシュするのに十分なサイズである必要があります。
格納パラメータを指定するには、キュー表の作成時にstorage_clauseパラメータを使用します。格納パラメータは、キュー表で作成される他のIOTおよび表に継承されます。キュー表の表領域には、そのキュー表に関連付けられたすべてのオブジェクトのデータを処理できるだけの空き領域が必要です。保存を指定すると、履歴表およびキュー表が相当な大きさになる可能性があります。
自動セグメント領域管理(ASSM)を使用することをお薦めします。使用しない場合、initrans、空きリストおよび空きリスト・グループを高度な同時処理のAQパフォーマンスにチューニングする必要があります。
PCTFREEを増やすと、キュー表/IOTブロック内のメッセージの数を削減できます。これにより、同時処理の際のブロック・レベルの競合が減ります。
キュー表の作成時に指定される格納パラメータは、キュー表、IOTおよび索引で共有されます。これは、DBMS_REDEFINITIONを使用してオンライン再定義で個別に変更できます。
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バックグラウンド・プロセスで自動的に結合されます。ただし、必要に応じて監視および結合を続ける必要があります。10.2の自動セグメント領域管理(ASSM)のオンライン縮小操作は、同様の目的で使用します。バランスの取れた索引は、キュー・モニターCPUの使用を削減し、エンキュー・デキューのパフォーマンスを最適化します。
バックグラウンド・タスクを実行できるよう、十分なキュー・モニター・プロセスが実行されていることを確認してください。キュー・モニターは、他の重大なバックグラウンド・アクティビティのためにも実行されている必要があります。複数のqmnプロセスが負荷を分担するため、十分な数があることを確認してください。これらは自動的にチューニングされますが、必要に応じて最小数に強制変更できます。
待機時間のあるデキューは、専用サーバー・プロセスでのみ使用することをお薦めします。共有サーバー環境では、(待機時間を含めた)コールの期間中、共有サーバー・プロセスがデキュー操作にのみ占有されます。このようなプロセスが多数存在すると、パフォーマンスおよび拡張性に重大な問題が発生し、共有サーバー・プロセスがデッドロック状態となる可能性があります。
デキュー・トランザクションを長時間実行するとキューのデキュー競合を悪化させるため、避ける必要があります。
1つのトランザクションへのマルチ・コンシューマ・キューの複数のデキュー操作のバッチ処理は、最適なスループットを提供します。
メッセージの優先順位を使用していない場合、NEXTをナビゲーション・モードとして使用してください。提供されるセマンティクスは同様ですが、パフォーマンスが向上します。
BROWSEモードのデキューの次がREMOVEの場合、REMOVE_NODATAデキュー・モードを使用してください。
伝播は、リモート(またはローカル)・キュー表に対して追加のINSERTを行う特殊なデキュー操作です。単一スケジュールからの伝播は、複数のジョブ・キュー・プロセスにパラレル化されません。かわりに、ロード・バランシングされます。拡張性を向上させるには、システム・リソース(CPU)の可用性に応じて伝播スケジュールの数を設定します。
トランザクション・キュー表からの伝播率と非トランザクション(デフォルト)キュー表からの伝播率は、多少異なります。これは、非トランザクション・キューのバッチ処理サイズはOracle Database Advanced Queuingが決定するのに対して、トランザクション・キューのバッチ・サイズは主にユーザー・アプリケーションが決定するためです。
伝播の最適化はバッチで行われます。リモート・キューが異なるデータベースに存在する場合、Oracle Database Advanced Queuingは、2フェーズ・コミットの必要性を回避するための順序アルゴリズムを使用します。メッセージが同じ宛先の複数のキューに送信される必要がある場合は、複数回送信されます。メッセージが宛先の同じキュー内のマルチ・コンシューマに送信される必要がある場合、1回のみ送信されます。
Oracle Real Application Clusters環境におけるバッファ済メッセージ操作が最も高速となるのは、キューのOWNER_INSTANCEを対象とする場合です。
Oracleでは、システム・パフォーマンスの監視およびトラブルシューティングのためのビューを提供します。
これらのビューは、自動ワークロード・リポジトリ(AWR)と統合されます。ユーザーは、2つのAWRスナップショットを元にレポートを生成し、エンキュー率、デキュー率およびその他のキュー/サブスクライバ別の統計を計算できます。
