ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JTAのプログラミング
11g リリース1 (10.3.6)
B61631-07
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

7 ロギング・ラスト・リソース・トランザクションの最適化

この章では、WebLogic Serverで、JDBCデータ・ソースを通じてロギング・ラスト・リソース(LLR)トランザクションの最適化をサポートする方法を説明します。LLRは、1つのXA以外のリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。

LLRは、「最後のエージェントによる最適化」を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるということです。LLRリソースは、トランザクション処理にローカル・トランザクションを使用します。WebLogic Serverトランザクション・マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLRリソースのローカル・トランザクションの結果に基づいて、グローバル・トランザクションに対するコミットの決定を下します。

LLR参加リソースによるグローバルな2フェーズ・コミット(2PC)トランザクションでは、WebLogic Serverトランザクション・マネージャは次の基本的な手順に従います。

以下の節は、WebLogic ServerにおけるLLRトランザクション処理の詳細を説明します。

LLRの特長に関する詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のロギング・ラスト・リソースのトランザクション・オプションに関する項を参照してください。

LLR最適化トランザクションの最適化について

多くの場合、グローバル・トランザクションが2フェーズ・コミット(2PC)トランザクションになるのは、データベース操作(JDBCを使用)と、メッセージ・キュー操作(JMSを使用)などの非データベース操作が関与しているためです。このように、2PCトランザクション内のデータベースへの参加リソースが1つの場合、ロギング・ラスト・リソース(LLR)最適化トランザクション・オプションは、データベース処理のXAオーバーヘッドの一部を除去し、JDBC XAドライバ(通常は非XAドライバよりも効率が悪い)の使用を回避することにより、トランザクションのパフォーマンスを著しく向上させられます。LLRトランザクション・オプションでは、「2フェーズ・コミットのエミュレート」JDBCデータ・ソース・オプションやNonXAResourceリソース・アダプタ(コネクタ)オプションの場合のようにデータがリスクを受けることはありません。

ロギング・ラスト・リソース処理の詳細

サーバー起動時またはデータ・ソースのデプロイメント時に、LLRデータ・ソースは、データベース接続のプールを行うデータベース上に、表をロードまたは作成します。表は、データベース接続を作成するよう指定されたユーザーが決定したスキーマ内に作成されます。データベース表が作成またはロードできない場合、サーバーの起動は失敗します。

グローバル・トランザクション内で、LLRデータ・ソースから最初に取得された接続が、そのトランザクション専用の内部JDBC接続を予約します。内部JDBC接続は、トランザクションのコーディネータでもある特定のサーバー上で予約されます。任意のサーバーにある同名のデータ・ソースから取得された接続に対する後続のトランザクション操作は、すべてこの同じ単一の内部JDBC接続にルーティングされます。

LLRトランザクションがコミットされると、WebLogic Serverトランザクション・マネージャはその処理を透過的に扱います。アプリケーション側から見ると、トランザクション・セマンティクスは同じままですが、内部から見ると、トランザクションには標準的なXAトランザクションとは異なった処理が行われています。アプリケーションがグローバル・トランザクションをコミットすると、WebLogic Serverトランザクション・マネージャは、他のトランザクション参加リソースに対してトランザクション作業をコミットする前に、LLR接続に対して原子性を維持しつつローカル・トランザクションをコミットします。2フェーズ・コミット・トランザクションの場合、トランザクション・マネージャは同じローカル・トランザクションの一部として、データベース上に2PCレコードの書込みも行います。ローカル・トランザクションが正常に完了した後、トランザクション・マネージャは他のすべてのグローバル・トランザクション参加リソースに対しcommitを呼び出します。他のすべてのトランザクション参加リソースがコミット・フェーズを完了させると、関連のLLR 2PCトランザクション・レコードは、解放されて削除できるようになります。トランザクション・マネージャは、短い間隔を置いて、または別のローカル・トランザクションで、トランザクション・レコードを遅れて削除します。

アプリケーションがグローバル・トランザクションをロールバックするか、トランザクションがタイムアウトした場合、トランザクション・マネージャはローカル・トランザクションの作業をロールバックし、データベースに2PCレコードを格納しません。

LLRトランザクションの最適化を有効化するには、JDBCデータ・ソースをロギング・ラスト・リソース・トランザクション・プロトコルで作成して、アプリケーション内のデータ・ソースからデータベース接続を使用します。WebLogic Serverは、データベース上に必要な表を自動作成します。

Oracle WebLogic Server管理コンソール・ヘルプLLRを利用可能なJDBCデータ・ソースの作成に関する項を参照してください。また、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のロギング・ラスト・リソースのトランザクション・オプションに関する項も参照してください。

データ・ソースの構成および使用上の要件と制限事項のリストについては、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の次のトピックを参照してください。

LLRデータベース表の詳細

各WebLogicサーバー・インスタンスは、JDBC LLRデータ・ソースがデータベース接続をプールするデータベース上に、データベース「LLR」表を保持します。これらの表は、トランザクション・ログ・レコードの格納に使用されるもので、自動的に作成されます。複数のLLRデータ・ソースが同じWebLogicサーバー・インスタンス上にデプロイされて同じデータベース・インスタンスおよびデータベース・スキーマに接続されている場合、これらのデータ・ソースも同じLLR表を共有します。

LLR表名は、管理者が構成することを選択しない限り、自動的に生成されます。デフォルトの表名は、WL_LLR_SERVERNAMEです。一部のDBMSシステムでは、表名の長さが最大18文字に制限されます。環境を構成する際には、表名の最大長を考慮に入れてください。

LLRデータベース表に関しては、次の制限事項があります。

リソースのトランザクション・ログ・レコードの格納に使用される表名を変更するには、次の手順に従います。

  1. 管理コンソール画面の左上の隅にある「チェンジ・センター」で、「ロックして編集」をクリックして、構成編集セッションを開始します。

  2. 「サーバー: 構成: 全般」ページで、「詳細」をクリックして、詳細構成のオプションを表示します。次を参照

  3. 「JDBC LLR表名」に、リソースのトランザクション・レコードの格納に使用する表の名前を入力し、その後「保存」をクリックします。Oracle WebLogic Server管理コンソール・ヘルプ「サーバー: 構成: 全般」を参照してください。

  4. LLRが有効化されたデータ・ソースがデプロイされている各サーバーに対して、ステップ2および3を繰り返します。

  5. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。


    注意:

    変更を有効にするには、すべてのサーバーを再起動する必要があります。


LLR表のトランザクション・ログ・レコード

コミットされた各2PC LLRトランザクションについて、トランザクション・マネージャはLLRデータベース表にトランザクション・レコードを自動的に挿入します。LLRトランザクションが完了すると、トランザクション・マネージャはトランザクション・レコードを遅れて削除します。LLR表トランザクション・ログ・レコードの削除が失敗した場合、サーバーは警告メッセージをログに記録し、後で削除を再試行します。

LLRトランザクション・レコードが格納されたデータベースを移動する必要がある場合は、トランザクションが正しく完了できるよう、必ずLLR表のコンテンツを新しいデータベースに移動してください。


注意:

本番システムでは、LLRトランザクション・レコードまたはLLR表を手動で削除しないでください。削除すると、暗黙のヒューリスティックなトランザクションが失敗します。


LLRの障害とリカバリ処理

一般に、WebLogicトランザクション・マネージャは、次のようにしてトランザクションの失敗を処理します。

サーバー・クラッシュの調整

LLRリソースがトランザクション・ログ・レコードを格納する前、またはLLRリソースがコミットする前に、トランザクションの調整サーバーがクラッシュした場合、トランザクションはロールバックされます。LLRリソースがコミットされた後にサーバーがクラッシュした場合、トランザクションは最終的には完全にコミットされます。サーバー起動中、トランザクション・コーディネータはLLRリソースを使用してデータベースからトランザクション・ログ・レコードを読み取り、その後、リカバリされた情報を使用して、参加しているすべての非LLR XAリソース上の未完了の作業をすべてコミットします。

JDBC接続障害

LLRリソースのJDBC接続が、2PCトランザクション・レコードの挿入中に失敗した場合、トランザクション・マネージャはトランザクションをロールバックします。

LLRリソースのJDBC接続が、ローカル・トランザクションのコミット中に失敗した場合の結果は、トランザクションが1フェーズ・コミット(LLRリソースが唯一の参加リソースである、1PC)であるか2PCであるかによって異なります。

  • 1PCトランザクションの場合、トランザクションは完全にコミットされるか、完全にロールバックされるか、ローカル・トランザクションの解決の待機をブロックします。トランザクションは最終的に完全にコミットされるか、完全にロールバックされるので、その結果は完全にACIDです。

  • 2 PCトランザクションの場合の結果は、「LLRの障害とリカバリ処理」で説明したようになります。

サーバー起動時のLLRトランザクション・リカバリ

各WebLogicサーバーのトランザクション・マネージャは、サーバー起動時に、サーバーによって調整される未完了のトランザクション(LLRトランザクションを含む)をリカバリする必要があります。これを行うには、各サーバーは各LLRデータ・ソースのLLRデータベース表から、トランザクション・レコードを読み取ろうとします。サーバーがLLRデータベース表にアクセスできない場合、またはリカバリが失敗した場合、サーバーは起動せず、トランザクション・マネージャによりヘルス状態が不良(HealthState.HEALTH_FAILED)としてマークされます。

リカバリの途中でタイムアウトが生じたとすれば、それはLLRログ表内の行をロックした未解決のローカル・トランザクションが原因である場合があります。そのようなローカル・トランザクションを解決して、レコードがロックされた行に格納されているグローバル・トランザクションの状態をトランザクション・マネージャが判断できるようにする必要があります。ローカル・データベース・トランザクションは診断および解決するには、各データベースの固有のツールを使用する必要があります(コマンドはデータベースごとに違います)。

LLRのフェイルオーバーに関する考慮事項

LLRでのフェイルオーバーに関する次の注意事項および制限事項を考慮してください。

  • トランザクション・ログ(TLog)は、LLRトランザクションでも必要です。

    • TLogは引続きトランザクション・マネージャの「チェックポイント」レコードを格納します。

    • TLogはフェイルオーバーでも引続きアクセス可能である、またはコピーされます。

  • LLRは、サーバーの移行およびトランザクション・リカバリ・サービスの移行をサポートします。トランザクション・リカバリ・サービスの移行を使用するには、クラスタまたはクラスタ内の候補サーバーのセットのいずれかに各LLRリソースがターゲット指定されていることを確認します。「クラスタリングされたサーバーで障害が発生した場合のトランザクションのリカバリ」を参照してください。

LLRでのパフォーマンス最適化

この節の内容は、以下のとおりです。

トランザクション・コーディネータの場所の最適化

LLR参加リソースでのグローバル・トランザクション内では、WebLogic Serverはすべての接続操作をトランザクションの調整サーバーに自動的にルーティングします。このルーティングが大きな負荷になる場合があります。可能であれば、アプリケーションが調整サーバー上で直接実行されるように、またコーディネータ上で直接ホストされる接続インスタンスを使用するように、最適化を行うと、パフォーマンスが向上すると考えられます。

トランザクションを開始するクライアント・アプリケーションに関しては、トランザクションのコーディネータは、クライアントがそのトランザクションの下で呼出し(RMI、EJB、JDBC、またはJMS呼出しのどれでも可)を行う最初のWebLogicサーバーとなります。JMSの場合、これはクライアントのJMS接続をホストするサーバーです。JMS宛先をホストするサーバーと同じである必要はありません。

サーバー側アプリケーションの場合、トランザクションのコーディネータは、ローカル・リソースが最初に呼び出されたのであれば(JMS宛先、JDBC接続など)ローカル・サーバーとなります。ただし、先にリモート・サーバーが呼び出されていた場合(リモートでホストされるJDBC接続、EJB、RMI呼び出し、またはJMS接続のいずれか)は、その限りではありません。これには、他のクラスタまたはドメインのリモート・サーバーが含まれます。

LLRデータ・ソースを使用した読取り専用操作のパフォーマンスの変動

LLRの最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLRでの読取り操作では、XAでの読取り操作と比べて、幾分パフォーマンスが低下します。最高のパフォーマンスを得るためには、読取り専用操作のためのLLRではないJDBCデータ・ソースを構成する必要があります。

データ・ソース別のLLR表の指定

Oracle RACを使用する環境のパフォーマンスを改善するには、各サーバーに対してではなく各データ・ソースに対してLLR表を指定することで、Oracle RACクラスタでのローカル・ノード・キャッシュの利用効率が上がります。

WebLogic Serverインスタンスの起動時にデータ・ソースごとにLLR表の指定を設定するには、次のシステム・プロパティを使用します。

-Dweblogic.llr.table.datasourcename=tablename

ここで、datasourcenameはデータ・ソースの名前、tablenameは、datasourcenameにマップするLLR表の名前です。

たとえば、次のシステム・プロパティを使用するとします。

-Dweblogic.llr.table.LLRDS1=myllrtable1

サーバーが起動すると、次の操作が行われます。

  • INFOメッセージがstdoutに書き込まれます。

    LLR data source LLRDS1 using LLR table myllrtable1

  • データ・ソースLLRDS1を使用するサーバー用のすべてのLLRエントリは、mylltable1というLLR表に格納されます。

データ・ソースがターゲット指定される各サーバーの各データ・ソースに対して1つの表を定義します。異なるWLSインスタンスで同じ表を共有することはできません。LLRDS1が2つのWebLogic ServerインスタンスS1およびS2にターゲット指定される場合、2つの表S1_LLRDS1とS2_LLRDS1を作成し、各サーバーに適切なシステム・プロパティを指定します。

例:

S1の場合、-Dweblogic.llr.table.LLRDS1=S1_LLRDS1を使用します。

S2の場合、-Dweblogic.llr.table.LLRDS1=S2_LLRDS1を使用します。


注意:

次のリリースのWebLogic Serverでは、node-idは、拡張されたLLR表で自動的に捕捉されるため、データはそれぞれのWebLogic Serverノードにパーティション化されます。データ・ソースごとに表を手動で割り当てる必要はありません。


制限事項

JTAサービス移行では、データ・ソース専用のLLR表はサポートされません。