12 ロギング ラスト リソースのチューニング

以下の節では、ロギング ラスト リソース (LLR) のトランザクションの最適化に関する背景知識とチューニングについて説明します。

• LLR とは

• LLR チューニング ガイドライン

LLR とは

JDBC データ ソースを通じてロギング ラスト リソース (LLR) のトランザクションの最適化を行うと、データベースの挿入、更新、削除などを含む 2 フェーズ トランザクションに関するオーバーヘッドを、安全に軽減できます。2 フェーズ トランザクションは、別の 2 つのリソースが同じグローバル トランザクション (「XA」または「JTA」トランザクションとも呼ばれる) に参加する場合に発生します。以下のことを考慮してください。

• JMS アプリケーションでの一般的な 2 フェーズ トランザクションには、通常、JMS サーバとデータベース サーバの両方が関与する。LLR オプションを使用すると XA の 2 倍のパフォーマンスを実現できます。

• WebLogic をはじめ他のベンダでも利用できる「最後のエージェント」、「最後の参加者」、「2 フェーズ コミットのエミュレート」といった広く知られた XA 最適化に比べ、JDBC LLR オプションは安全性が高い。

• JDBC LLR では、2 フェーズ トランザクションのレコードをトランザクション マネージャのログ (TLOG) ではなく、データベース テーブルに保存する。

『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。

LLR チューニング ガイドライン

この節では、LLR のチューニングのガイドラインを示します。

• 『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」および『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「トランザクション オプション」に目を通して理解を深めておくことを推奨。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 コマンドを使用して定期的なデフラグを行います。