| Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド 11gリリース1（11.1） E05782-01 |
|
 戻る |
 次へ |
この章では、Oracle Streams Advanced Queuing（AQ）のパフォーマンスおよび拡張性に関する事柄について説明します。
この章の内容は次のとおりです。
永続メッセージは、エンキューされるとデータベース表に格納されます。永続メッセージに対するキュー操作のパフォーマンス特性は、基になるデータベース操作のパフォーマンス特性と同等です。エンキュー操作のコード・パスは、3つの索引構成表を持つ複数列のキュー表に対するSELECTおよびINSERTに相当します。デキュー操作のコード・パスは、同様の表に対するSELECT、DELETEおよびUPDATEに相当します。
|
注意: 表内のキューの数によって、パフォーマンスが影響を受けることはありません。 |
Real Application Clusters（RAC）を使用することで、キュー・データに対する高可用性のアクセスを実現できます。キューの入口点および出口点（先頭および末尾）は、かなりのホット・スポットになる可能性があります。ホット・スポットが存在すると、RACを十分に拡張できない場合があるため、1つのキューに通常アクセスするインスタンスは1つに限定します。メッセージを管理しているインスタンスに障害が発生しても、障害の発生していない別のインスタンスの1つを使用することで、そのメッセージの即時処理が可能になります。
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 Streams AQ表のレイアウトは、他のデータベース表および索引のレイアウトと同様です。
|
関連項目: チューニングの推奨事項は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
格納パラメータを指定するには、キュー表の作成時にstorage_clauseパラメータを使用します。格納パラメータは、キュー表で作成される他のIOTおよび表に継承されます。キュー表の表領域には、そのキュー表に関連付けられたすべてのオブジェクトのデータを処理できるだけの空き領域が必要です。保存を指定すると、履歴表およびキュー表が相当な大きさになる可能性があります。
自動セグメント領域管理（ASSM）を使用することをお薦めします。使用しない場合、initrans、空きリストおよび空きリスト・グループを高度な同時処理のAQパフォーマンスにチューニングする必要があります。
PCTFREEを増やすと、キュー表/IOTブロック内のメッセージの数を削減できます。これにより、同時処理の際のブロック・レベルの競合が減ります。
キュー表の作成時に指定される格納パラメータは、キュー表、IOTおよび索引で共有されます。これは、DBMS_REDEFINTIONを使用してオンライン再定義で個別に変更できます。
Oracle Streams AQでは、I/Oが非常に頻繁に行われるため、通常、あらゆるボトルネックが解消されるよう、I/Oをチューニングする必要があります。
|
関連項目: 『Oracle Databaseパフォーマンス・チューニング・ガイド』のI/O構成および設計に関する項を参照してください。 |
メッセージを一定のフローで処理する環境では、エンキュー・プロセスとデキュー・プロセスの両方を同時に実行する必要が生じる場合があります。キュー表とキューが1つずつしか存在しないメッセージ配信システムの場合、すべてのプロセスが同じセグメントを同時に処理する必要があります。これでは適切なパフォーマンス・レベルで、多数のメッセージを配信することはできません。
最適な同時プロセス数は、システム・リソースの可用性によって異なります。たとえば、CPUを4つ持つシステムでは、2つの同時エンキュー・プロセスおよび2つの同時デキュー・プロセスから始めるのが妥当です。必要な数のメッセージを配信できないシステムでは、プロセス数を増やすのではなく、複数のサブスクライバを使用して、ロード・バランシングを実行します。
キューのエンキューおよびデキュー率をチューニングすると、通常、キュー・サイズを小さく制限できます。大幅に拡大および縮小するキューには索引およびIOTがあり、バランスに欠けるため、パフォーマンスに影響します。
マルチ・コンシューマ・キューでは、プロセス数を増やすのではなく、ロード・バランシングの複数のサブスクライバを使用して競合を減らします。水平拡張性を実現するには、複数のキュー表を使用します。
エンキュー・プロセスとデキュー・プロセスをシリアルに実行すると、同一のデータ・セグメントにおける競合が、同時プロセスの場合よりも少なくなります。ただし、システムからのメッセージ配信にかかる合計時間は、両プロセスを同時実行する場合よりも長くなります。プロセス数を増加させることは、エンキュー・プロセスおよびデキュー・プロセスの両方に効果的です。プロセス数を増加すると、メッセージのスループット率はデキュー元よりエンキュー元で高くなります。デキュー操作では、SELECT、DELETEおよびUPDATEが実行されるため、通常、デキュー操作のスループットはエンキュー操作（INSERT）のスループットより大幅に劣ります。
キュー表の索引を作成することは、次の操作を行う上で有効です。
相関識別子を使用したデキュー
基になるキュー表AQ$_QueueTableNameの列corr_idの索引を作成すると、デキューが迅速に処理されます。
条件を使用したデキュー
これは、基になるキュー表で、SELECTのwhere句に対する条件の追加に相当します。QueueTableNameの索引を作成すると、このSELECT文のパフォーマンスが向上します。
統計が収集済で、メッセージ取得の最適な問合せ計画が選択されていることを確認してください。デフォルトでは、キュー表は統計の自動収集からロックされています。統計を代理キュー・メッセージ・ロードで収集して、ロックすることをお薦めします。
キュー表索引およびIOTは、周期的に結合する必要があります。10.2の自動セグメント領域管理（ASSM）またはオンライン縮小操作は、同様の目的で使用します。これにより、キュー・モニターCPUの使用を削減し、エンキュー・デキューのパフォーマンスを最適化します。
バックグラウンド・タスクの実行に十分なキュー・モニター・プロセスが実行されていることを確認してください。キュー・モニターは、その他の重要なバックグラウンド・アクティビティでも実行される必要があります。複数のqmnプロセスがロードを共有します。これらが十分にあることを確認してください。これは自動チューニングされますが、必要に応じ、最小数に設定できます。
待機時間のあるデキューは、専用サーバー・プロセスでのみ使用することをお薦めします。共有サーバー環境では、（待機時間を含めた）コールの期間中、共有サーバー・プロセスがデキュー操作にのみ占有されます。このようなプロセスが多数存在すると、パフォーマンスおよび拡張性に重大な問題が発生し、共有サーバー・プロセスがデッドロック状態となる可能性があります。
デキュー・トランザクションを長時間実行するとキューのデキュー競合を悪化させるため、避ける必要があります。
通常、デキュー操作はエンキューよりも時間がかかります。全体的なデキュー・エンキュー率は、アプリケーション設計によって異なります。
メッセージの優先順位を使用していない場合、NEXTをナビゲーション・モードとして使用してください。提供されるセマンティクスは同様ですが、パフォーマンスが向上します。
BROWSEモードのデキューの次がREMOVEの場合、REMOVE_NODATAデキュー・モードを使用してください。
伝播は、リモート（またはローカル）・キュー表に対して追加のINSERTを行う特殊なデキュー操作です。単一スケジュールからの伝播は、複数のジョブ・キュー・プロセスにパラレル化されません。かわりに、ロード・バランス化されます。拡張性を向上させるには、システム・リソース（CPU）の可用性に応じて伝播スケジュールの数を設定します。
トランザクションをサポートするキュー表からの伝播率とトランザクションをサポートしない（デフォルト）キュー表からの伝播率は、多少異なります。これは、非トランザクション・キューのバッチ処理サイズはOracle Streams AQが決定するのに対して、トランザクション・キューのバッチ・サイズは主にユーザー・アプリケーションが決定するためです。
伝播の最適化はバッチで行われます。リモート・キューが異なるデータベースに存在する場合、Oracle Streams AQは、2フェーズ・コミットの必要性を回避するための順序アルゴリズムを使用します。メッセージが同じ宛先の複数のキューに送信される必要がある場合は、複数回送信されます。メッセージが宛先の同じキュー内のマルチ・コンシューマに送信される必要がある場合、1回のみ送信されます。
Real Application Clusters環境におけるバッファ済メッセージ操作が最も高速となるのは、キューのOWNER_INSTANCEを対象とする場合です。
Oracleでは、システム・パフォーマンスの監視およびトラブルシューティングのためのビューを提供します。
これらのビューは、自動ワークロード・リポジトリ（AWR）と統合されます。ユーザーは、2つのAWRスナップショットを元にレポートを生成し、エンキュー率、デキュー率およびその他のキュー/サブスクライバ別の統計を計算できます。
