Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11gリリース1 (10.3.6) B61002-04 |
|
![]() 前 |
![]() 次 |
この章では、トランザクションの最適化に関する背景知識とチューニングについて説明します。
JDBCデータ・ソースを通じてロギング・ラスト・リソース(LLR)のトランザクションの最適化を行うと、データベースの挿入、更新、削除などを含む2フェーズ・トランザクションに関するオーバーヘッドを、安全に軽減できます。2フェーズ・トランザクションは、別の2つのリソースが同じグローバル・トランザクション(「XA」または「JTA」トランザクションとも呼ばれる)に参加する場合に発生します。次のことを考慮してください。
JMSアプリケーションでの一般的な2フェーズ・トランザクションには、通常、JMSサーバーとデータベース・サーバーの両方が関与します。LLRオプションを使用するとXAの2倍のパフォーマンスを実現できます。
WebLogicをはじめ他のベンダーでも利用できる「最後のエージェント」、「最後の参加者」、「2フェーズ・コミットのエミュレート」といった広く知られたXA最適化に比べ、JDBC LLRオプションは安全性が高くなります。
JDBC LLRでは、2フェーズ・トランザクションのレコードをトランザクション・マネージャのログ(TLOG)ではなく、データベース表に保存します。
『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。
この項では、LLRのチューニングのガイドラインを示します。
『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクションの最適化に関する項、および『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のLLRデータ・ソースに関するプログラミング上の考慮事項と制限事項に関する項を読んで理解することをお薦めします。LLRを使用すると、管理および設計に重要な影響を与える場合があります。
JDBC LLRを使用すると、SQLのupdate、delete、またはinsertを含んだ2フェーズ・トランザクションのパフォーマンスは通常、向上します。
LLRを使用すると、SQLがすべて読取り(select)のみの2フェーズ・トランザクションのパフォーマンスは通常、低下します。
JDBC LLRのプールはWebLogic JDBCストアに対しパフォーマンス上の利点を持たません。WebLogic JDBCストアはトランザクションに完全に対応していますが、その内部のJDBC接続ではJTA (XA)トランザクションが使用されません。
コネクタ用の「最後のエージェント」による最適化や、JDBC接続プール用の「2フェーズ・コミットのエミュレート」オプション(従来の名称は、非XAドライバを使用するプール用の「2フェーズ・コミットを有効化」)といった比較的安全性の低い手法の代わりに、LLRの使用を検討します。
OracleデータベースではLLR表を多用すると長期的に断片化が起こる場合があり、未使用範囲の発生につながることがあります。これは、LLR表のデータが一時的な性質を持つことにより発生していると考えられます。この問題を回避するには、LLR表においてPCT_FREE
を5、PCT_USED
を95に設定します。または、ALTER TABLESPACE [tablespace-name ] COALESCE
コマンドを使用して定期的なデフラグを行います。
Oracle Database (Oracle AQやOracle RACを含む)などのリソース・マネージャが、読取り専用の最適化を提供するとき、Oracle WebLogicは読取り専用の1フェーズ・コミットの最適化を提供します。同一のXAトランザクションの複数接続を有効化するときでさえも、Oracle WebLogicやリソース・マネージャの両方でXAResource.prepare
ネットワーク呼出しやトランザクション・ログの書込みを削除するなど、これにはかなりのメリットがあります。
『Oracle WebLogic Server JTAのプログラミング』の読取り専用の1フェーズ・コミットの最適化に関する項