WebLogic Server パフォーマンス チューニング ガイド
ロギング ラスト リソースのチューニング
以下の節では、ロギング ラスト リソース (LLR) のトランザクションの最適化に関する背景知識とチューニングについて説明します。
LLR とは
JDBC データ ソースを通じてロギング ラスト リソース (LLR) のトランザクションの最適化を行うと、データベースの挿入、更新、削除などを含む 2 フェーズ トランザクションに関するオーバーヘッドを、安全に軽減できます。2 フェーズ トランザクションは、別の 2 つのリソースが同じグローバル トランザクション (「XA」または「JTA」トランザクションとも呼ばれる) に参加する場合に発生します。以下のことを考慮してください。
JMS アプリケーションでの一般的な 2 フェーズ トランザクションには、通常、JMS サーバとデータベース サーバの両方が関与する。LLR オプションを使用すると XA の 2 倍のパフォーマンスを実現できます。 BEA WebLogic をはじめ他のベンダでも利用できる「最後のエージェント」、「最後の参加者」、「2 フェーズ コミットのエミュレート」といった広く知られた XA 最適化に比べ、JDBC LLR オプションは安全性が高い。 JDBC LLR では、2 フェーズ トランザクションのレコードをトランザクション マネージャのログ (TLOG) ではなく、データベース テーブルに保存する。
『WebLogic JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。
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 コマンドを使用して定期的なデフラグを行います。
