ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理
11gリリース1 (10.3.6)
B60997-04
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

B Oracle RACでのマルチ・データ・ソースの使用

この章では、WebLogic ServerでOracle Real Application Clusters (RAC)を使用する際にマルチ・データ・ソースを構成して使用する方法について説明します。Oracleは、RACを使用したレガシー・アプリケーション環境用のマルチ・データ・ソース構成を引き続きサポートします。

Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを一緒に使用するには、クラスタリング・ソフトウェアおよび共有ストレージ・ソリューションに加え、両方のシステム上での固有の構成が必要になります。この節では、要求される構成について概要レベルで説明します。Oracle RAC、使用しているクラスタリング・ソフトウェア、使用しているオペレーティング・システム、および使用しているストレージ・ソリューションの構成に関する詳細は、それぞれのベンダーが提供するドキュメントを参照してください。


注意:

新規のOracle RACアプリケーションを開発する場合、レガシー・アプリケーションがマルチ・データ・ソースを使用していない場合、GridLinkデータ・ソースの使用をお薦めします。「WebLogic ServerでのOracle RACの使い方」を参照してください。

Oracle Real Application Clustersの概要

Oracle Real Application Clusters (Oracle RAC)は、複数のマシンのユーザーが単一のデータベースに高いパフォーマンスでアクセスすることを可能にする高可用性ソリューションに追加できるソフトウェア・コンポーネントです。Oracle RACは、複数のクラスタ化マシン上で実行され、クラスタ技術によって共有ストレージ・デバイスにアクセスする複数のOracleデータベース・インスタンスで構成されます。このアーキテクチャをサポートするため、データベース・インスタンスをホストするマシンは高速のインターコネクトでリンクされて、クラスタを形成します。インターコネクトとは、クラスタのノード間の通信手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサード・パーティのクラスタリング・ソフトウェアによって提供されます。図B-1にOracle RACの構成を示します。

図B-1 Oracle Real Application Clustersの構成

図B-1の説明が続きます
「図B-1 Oracle Real Application Clustersの構成」の説明

Oracle RACでは次の領域の機能が提供されます。

WebLogic Serverマルチ・データ・ソースでのOracle RACの拡張性

インストールされているOracle RACは、単一の標準的なOracleデータベースのように見え、同じツールと実行方法で管理されます。クラスタのすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACにより各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、Oracle RACノード、ストレージ、またはその両方を追加することで、処理とリクエストの増加に伴い、データベース層を水平方向に拡張できます。

Oracle RAC内のノード数が増加するに連れて、Oracle RACに追加されたノード数ごとに汎用データ・ソースの数をスケールします。これには、Oracle RACトポロジが変更するときに管理者の介入が必要な複雑な構成(n+1個のデータ・ソースが必要。ここで、nは一般データ・ソース+マルチ・データ・ソースの数)が求められます。

WebLogic Serverマルチ・データ・ソースでのOracle RACの可用性

マルチ・データ・ソースは、接続リクエストに応じるために使用するデータ・ソースの順序付けされたリストを提供します。通常、このタイプのマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ・ソースが中断されている場合、そのリストの次のデータ・ソースから順番に接続が選択されます。「フェイルオーバー」および「マルチ・データ・ソース管理フェイルオーバーおよびロード・バランシング」を参照してください。

WebLogic Serverマルチ・データ・ソースでのOracle RACのロード・バランシング

マルチ・データ・ソースで、XAや非XA環境のロード・バランシングが可能になります。マルチ・データ・ソースを構成する汎用データ・ソースは、ラウンドロビン・スキームでアクセスされます。接続を切り替えると、WebLogic Serverは、注文リストの次の汎用データ・ソースから接続を選択します。Oracle RACでのマルチ・データ・ソースの使用方法の詳細は、「Oracle RACでのマルチ・データ・ソースの使用方法」を参照してください。

ソフトウェア要件

WebLogic ServerをOracle RACで使用するには、各Oracle RACノードに次のソフトウェアをインストールする必要があります。

JDBCドライバ要件

WebLogic ServerをOracle RACとともに使用するには、WebLogic JDBCデータ・ソースでOracle JDBC Thin Driver 11gを使用して、データベース接続を作成する必要があります。

ハードウェア要件

WebLogic ServerおよびOracle RACの標準的なシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが含まれます。

WebLogic Serverクラスタ

WebLogic Serverクラスタは、さまざまハードウェア・オプションを使用して多くの方法で構成できます。WebLogic Serverクラスタの構成については、『Oracle WebLogic Serverクラスタの使い方』を参照してください。 

Oracle RACクラスタ

Oracle RACに関する最新のハードウェア要件については、Oracle RACのドキュメントを参照してください。ただし、WebLogic ServerでOracle RACを使用するには、堅牢な製品レベル品質のハードウェア上でOracle RACインスタンスを実行する必要があります。Oracle RACの構成では、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースのレスポンスが著しく遅れると、データベースのフェイルオーバー処理の間に予期しない動作が生じるおそれがあります。

共有ストレージ

Oracle RACの構成では、データ・ファイル、制御ファイル、およびパラメータ・ファイルはすべて、各Oracle RACインスタンスで共有されて使用されます。次のいずれかのアーキテクチャを使用するHAストレージ・ソリューションをお薦めします。

  • デュアル・ポート・ディスク配列などのダイレクト・アタッチド・ストレージ(DAS)またはストレージ・エリア・ネットワーク(SAN)

  • ネットワーク・アタッチド・ストレージ(NAS)

サポートされているストレージ・ソリューションの全リストについては、Oracleのドキュメントを参照してください。

Oracle RACでのマルチ・データ・ソースの構成

Oracle RACでマルチ・データ・ソースを使用する場合、Oracle RACインスタンスと対話でき、期待どおりに動作するようにWebLogicドメインを構成する必要があります。次の項では、構成のオプションと要件について説明します。

Oracle RACで使用するマルチ・データ・ソースの構成の選択

WebLogic Serverマルチ・データ・ソースは、Oracle RACの使用に当たり、いくつかの構成オプションをサポートします。

Oracle RACで使用するマルチ・データ・ソースの構成

マルチ・データ・ソースを使用してWebLogic Serverと複数のOracle RACノードを接続するには、まずOracle RACクラスタ内の各Oracle RACインスタンスに、Oracle Thin DriverとともにJDBCデータ・ソースを構成します。次に、ロード・バランシングのアルゴリズムとフェイルオーバーのアルゴリズムのどちらかを使用してマルチ・データ・ソースを構成し、データ・ソースを追加します。

図B-2に、一般的なマルチ・データ・ソースの構成を示します。

図B-2 マルチ・データ・ソースの構成

図B-2の説明が続きます
「図B-2 マルチ・データ・ソースの構成」の説明

ドメインを構成するには、管理コンソールか、または、WebLogic Scripting Tool (WLST)やJMXプログラムなどのお好きな方法を使用できます。WebLogic JDBCマルチ・データ・ソースの構成については、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。データ・ソースのマルチ・データ・ソースを、Oracle RACノードで実行中のサービスに接続できるように構成する方法については、「Oracle RACノードのサービスに対する接続の構成」を参照してください。

この構成でデータベース接続を使用するには、アプリケーションでJNDIツリー上のマルチ・データ・ソースを1つルックアップしてから、接続をリクエストします。マルチ・データ・ソースは、構成で指定されたアルゴリズムの種類に基づいて、接続リクエストに応じるためにどちらのデータ・ソース(つまり、フェイルオーバーまたはロード・バランシング)を使用するかを決定します。

マルチ・データ・ソースの属性

マルチ・データ・ソースは、システム内のOracle RACの役割(ロード・バランシングまたはフェイルオーバー)によっては、次の属性を持ちます。

  • AlgorithmType="Load-Balancing"またはAlgorithmType="Failover"

    Load-Balancingを指定すると、接続リクエストは利用可能なデータ・ソース群に渡って分散されます。High-Availabilityを指定した場合、接続リクエストはリストの最初にある利用可能なプールで処理されます。データ・ソースが切断された場合、接続リクエストはリスト内の次のデータ・ソースで処理されます。

  • FailoverRequestIfBusy="true"

    フェイルオーバー・アルゴリズムとともにこの属性を指定すると、データ・ソース内の接続がすべて使用中の場合にフェイルオーバーできるようになります。

  • TestFrequencySeconds="120"

    この属性は、WebLogic Serverが以前に「異常」としてマークしたデータ・ソースのヘルス状態をチェックして、接続を再作成できるかどうか、およびデータ・ソースを再有効化できるかどうかを確認する頻度を制御します。詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。

    Oracle RACノードの高速フェイルオーバーのためには、この値に短い間隔 - たとえば、10(秒) - を設定します。

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

フェイルオーバーを構成する際には、次の情報について考慮する必要があります。

マルチ・データ・ソースが管理するフェイルオーバーとロード・バランシング

マルチ・データソースでは、グローバル・トランザクションのフェイルオーバーおよびロード・バランシングが可能になります。マルチ・データ・ソースのフェイルオーバー機能の説明は、「マルチ・データ・ソースのフェイルオーバー・エンハンスメント」を参照してください。

図B-2に示すこの構成を使用すると、次の利点があります。

  • マルチ・データ・ソース制御による、高速なフェイルオーバー

  • WebLogic Serverヘルス・モニターによる、自動フェイルバック

マルチ・データ・ソースは、Oracle RACノードが利用不可能な場合にデータベース接続用フェイルオーバーを処理します。WebLogic Serverで接続テストに失敗した場合、接続の再作成を試みます。それに失敗した場合、サーバーでは、マルチ・データ・ソースの他のデータ・ソース(他のOracle RACノードに対応)に対するルート接続リクエストとデータ・ソースが無効に設定されます。WebLogic Serverは、無効化されたデータ・ソースのデータベース接続の再作成を定期的に試みます。接続が正常に再作成された場合、次にデータ・ソースを再有効化し、データ・ソースへの接続リクエストのルーティングを開始します。接続リクエストのルーティングおよび正常性チェックの機能により、最小時間で失敗後の接続リクエストを満たします。

フェイルオーバー中の遅延

あるOracle RACノードが別のOracle RACノードにフェイルオーバーした場合、現在障害の発生しているノードの処理中のトランザクション・ブランチに関連するデータがクラスタ全体で利用可能になるまでに、遅延が発生することがあります。これにより、未完了のトランザクションが適切に完了できなくなり、さらにはデータベース内でデータのロックが発生することがあります。このような遅延発生の可能性を防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSecondsXARetryIntervalSecondsが用意されています。

XARetryDurationSecondsは、保留中のトランザクションのXA操作(回復、コミット、ロールバックなど)の再試行を繰り返す間隔を指定します。XARetryIntervalSecondsでは、設定した期間内に再試行する頻度を指定します。

XA呼出しの再試行を有効化するには、Oracle RACインスタンスに接続するWebLogicドメイン内のすべてのJDBCデータ・ソースに対して、XARetryDurationSecondsの値を追加で指定します。例:

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>oracleRACXAPool</name> 
  ...
  <jdbc-xa-params>
    ...
    <xa-retry-duration-seconds>300</xa-retry-duration-seconds> 
  </jdbc-xa-params>
</jdbc-data-source>

XARetryDurationSecondsの値は、次の式で決定します。

XARetryDurationSeconds = (データ・ソースからの接続を使用するトランザクションの最長トランザクション・タイムアウト) + (XIDがすべてのOracle RACノードで利用可能になるまでの遅延、通常は5分未満)

たとえば、アプリケーションで設定されている最長のトランザクション・タイムアウトが180秒の場合には、XARetryDurationSecondsを180秒+ 300秒の合計、つまり480秒に設定します。


注意:

一般にXARetryDurationSecondsは、すべてのトランザクションが適切に完了するように、必要とされる最小限の時間よりも長めに設定した方がよいでしょう。最小限必要な時間より大きな値を設定しても、通常の運用時であればアプリケーションのパフォーマンスには影響しません。この追加された処理は、準備状態にあるが完了に失敗したトランザクションにのみ影響します。

必要に応じて、XARetryIntervalSecondsにも値を設定できます。この値は、XA呼出しの再試行の間隔を決定します。デフォルトでは、この値は60秒です。値を小さくすると、XAの再試行の間隔が短くなります。ほとんどの場合は、デフォルト値で十分です。

管理コンソールからXARetryDurationSecondsおよびXARetryIntervalSecondsを有効化するには、次の手順を使用します。

  1. 管理コンソールのチェンジ・センターでロックして変更をクリックします(まだ行っていない場合)。

  2. 「ドメイン構造」ツリーで「サービス」>「JDBC」を展開し、「データ・ソース」を選択します。

  3. 「データ・ソースのサマリー」ページでデータ・ソース名をクリックします。

  4. 構成: 接続プールタブを選択します。

  5. 画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。

  6. 「XA再試行期間」]および「XA再試行間隔」を更新します。

  7. 「保存」をクリックします。

オプションで、WebLogic Scripting Tool (WLST)またはJMXプログラムを使用できます。

グローバル・トランザクションにおける障害処理の段階的な説明

ノードに障害が発生した場合、データベースに対する処理中のトランザクションには何が起こるのでしょう。プライマリOracle RACノードに障害が発生した場合はどうでしょうか。WebLogic Serverでは、透過的なフェイルオーバーはサポートされていますか。こうした疑問やWebLogic Serverでの障害処理に関するその他の質問への回答として、トランザクション処理の段階を順を追って説明し、その中で各段階での障害の処理方法について解説します。

障害が発生する最初の段階は、アプリケーションがコミットするトランザクションを呼び出す前である可能性があります。この段階でデータベースまたはOracle RACノードに障害が発生した場合、アプリケーションは例外を受け取り、新しい接続を取得してトランザクションの処理を新たに試行する必要が生じます。WebLogic Serverは、透過的フェイルオーバーをサポートしていません。

アプリケーションがトランザクションをコミットする呼出しを行った後で障害が発生した場合、処理中のトランザクションの扱いはPREPARE操作が完了しているかどうかによって変わります。PREPARE操作が完了していない場合、トランザクション・マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外がスローされます。PREPARE操作が完了している場合、トランザクション・マネージャは別のノードを使用して処理中のトランザクションを完了しようとします。

COMMIT操作の間に障害が発生した場合、トランザクション・マネージャではCOMMIT操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。その後トランザクション・マネージャは、成功するまで定期的にCOMMIT操作を再試行し続けます。トランザクションが破棄時間までの間に正常に完了できなかった場合、トランザクションはヒューリスティックな完了を余儀なくされます。

各Oracle RACインスタンスのリスナー・プロセスの構成

リスナー・プロセスは、Oracle RACに、ユーザー・プロセスとOracleインスタンス間で通信経路を確立します。WebLogic ServerでOracle RACを使用する場合、ユーザー・プロセスは通常、JDBCデータ・ソースです。

マルチ・データ・ソースは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、データ・ソース容量が増えるように構成されている場合、データ・ソースは、構成ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。

図B-3にOracleリスナー・プロセスの機能を示します。

図B-3 Oracleリスナー・プロセスの機能

図B-3の説明が続きます
「図B-3 Oracleリスナー・プロセスの機能」の説明

この機能を有効にするには、2つのオプションがあります。

  • ローカル・リスナーを使用します。Oracleクラスタ内の各Oracle RACインスタンスごとにリスナー・プロセスを構成します。各Oracle RACインスタンスについてローカル・リスナーの構成が必要です。各データベース・インスタンスは、そのローカル・リスナーのみ登録するように構成する必要があります。

    Oracleインスタンスのリスナー登録は、listener.oraファイルで静的に構成したり、インスタンスの初期化パラメータlocal_listenerを使用して動的に登録できます(両方で登録可能)。動的に登録することをお薦めします。

    リスナーは、共有ディスパッチ・プロセスまたは専用プロセスのいずれかを起動できます。WebLogic Serverを使用する場合、専用プロセスの使用をお勧めします。

  • リモート・リスナーを使用します。WLSでは、マルチ・データ・ソース内のデータ・ソースのJDBC URLでSERVICE_NAMEとINSTANCE_NAMEの両方を指定する必要があります。「リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成」を参照してください。

リモート・リスナーが有効または無効になっている場合のマルチ・データ・ソースの構成

Oracle RACバックエンドに対して、サーバー側のロード・バランシング機能が(remote_listenersを使用して)有効化されている場合は、マルチ・データ・ソース構成のデータ・ソースに使用されたJDBC URLには、INSTANCE_NAMEを含める必要があります。たとえば、次の形式でURLを指定できます。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))

URLにINSTANCE_NAMEを指定できない場合、リモート・リスナーを無効に設定する必要があります。リモート・リスナーを無効に設定するには、各Oracle RACノード上のspfile.ora内にリストされている任意のリモート・リスナーを削除します。例:

*.remote_listener="

この場合、マルチ・データ・ソース構成のデータ・ソースで使用するには次のURLをお薦めします。

jdbc:oracle:thin:@host-vip:port/dbservice

または

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(
CONNECT_DATA=(SERVICE_NAME=dbservice)))

構成の追加考慮

Oracle RACの一部のデプロイメントでは、Oracle RAC構成のデータ・ソースの初期構成以外にパラメータを追加する必要があります。追加するパラメータを次に示します。

  • データ・ソース毎にoracle.jdbc.ReadTimeout=300000 (300000ミリ秒)を設定します。

    実際に使用するReadTimeoutパラメータの値は、アプリケーションの環境によって異なる場合があります。

  • 信頼性がないネットワークでは、サーバーが突然切断されることで発生する頻度の高い切断を検出するのがクライアントにとって困難になります。デフォルトでは、Linux稼働中のクライアントは、突然の切断を検出できるのに7200秒(2時間)かかります。これは、tcp_keepalive_timeプロパティと同等の値です。早期に切断を検出できるようにアプリケーションを構成するには、tcp_keepalive_timetcp_keepalive_interval、およびtcp_keepalive_probesプロパティの値を、OSレベルで低い値に設定してください。


    注意:

    tcp_keepalive_intervalプロパティに低い値を設定すると、パケットのプローブが高い頻度で発生するようになり、その結果、システムの速度が遅くなります。このプロパティの値は、ご使用のアプリケーション環境のシステム要件に応じて設定してください。

    たとえば、WebLogic Server管理対象サーバーが実行中のシステムでは、tcp_keepalive_time=600と設定します。

  • 接続記述子のDESCRIPTION句で、ENABLE=BROKENパラメータを指定します。例:

    jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.mycompany.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))

次に示すコードの抜粋は、データ・ソース構成の例です。

<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>oracle.jdbc.ReadTimeout</name>
<value>300000</value>
</property>
<property>
<name>user</name>
<value>jmsuser</value>
</property>
<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>
</properties>

グローバル・トランザクションを利用する場合のマルチ・データ・ソースの使用

この構成では、マルチ・データ・ソースによってトランザクションが必ず1つのOracle RACインスタンスに固定されます。個々のトランザクションはトランザクションに対する最初の接続リクエスト時にロード・バランシングされます。Oracle RACインスタンスが使用できなくなった場合は、マルチ・データ・ソース・レベルでフェイルオーバーが処理されます。PREPARE操作の前にOracle RACインスタンスに障害があった場合、再試行の期間が時間切れになるまでこの操作が再試行されます。PREPARE操作の後に障害があった場合は、トランザクションは別のインスタンスにフェイルオーバーされます。

グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースのルール

マルチ・データ・ソース内のXAデータ・ソースには、以下のルールが適用されます。

  • すべてのデータ・ソースが均一である必要があります。つまり、すべてのデータ・ソースがXAドライバを使用することが必要であるか、またはXAドライバを使用できるデータ・ソースはありません。

  • すべてのXA関連の属性について、指定する場合には、各データ・ソースに同じ値を設定する必要があります。こうした属性には以下のものがあります。

    • XARetryDurationSeconds

    • SupportsLocalTransaction

    • KeepXAConnTillTxComplete

    • NeedTxCtxOnClose

    • XAEndOnlyOnce

    • NewXAConnForCommit

    • RollbackLocalTxUponConnClose

    • RecoverOnlyOnce

    • KeepLogicalConnOpenOnRelease


      注意:

      GridLinkデータ・ソースを使用していない場合、XAまたは非XAの環境にかかわらず、Oracle RACインスタンス全体でフェイルオーバーやロード・バランシングに対してマルチ・データ・ソースの使用をお薦めします。非XA環境でのマルチ・データ・ソースの使用方法の詳細は、「グローバル・トランザクション以外でのマルチ・データ・ソースの使用方法」を参照してください。

グローバル・トランザクションを利用するマルチ・データ・ソース内のデータ・ソースで必要な属性

マルチ・データ・ソース内の各データ・ソースには、以下の属性が必要です。

  • Oracle Thin JDBC Driver 11g。例:

    <url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url> 
    <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
    
  • KeepXAConnTillTxComplete="true"

    • 分散トランザクションが完了するまでのトランザクション処理の間中、必ずデータ・ソースで物理データベース接続を予約し、アプリケーションに同じ接続を提供するようにします。

    • これは、Oracle RACでの適切なトランザクション処理のためには必須です。

  • XARetryDurationSeconds="300"

    • WebLogic Serverのトランザクション・マネージャによる、指定された時間内でのXAの回復、コミット、ロールバック呼出しの再試行を有効にします。

  • TestConnectionsOnReserve="true"

  • TestTableName="name_of_small_table"。物理データベース接続のテストに使用される表の名前です。この属性の詳細については、「データ・ソースの接続テスト・オプション」を参照してください。

サンプル構成コード

マルチ・データ・ソース、および関連する2つのデータ・ソースのサンプル構成コードを以下に示します。

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>oracleRACXAPool</name> 
  <jdbc-driver-params>
    <url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url> 
    <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name> 
    <properties>
      <property>
        <name>user</name> 
        <value>wlsqa</value> 
      </property>
    </properties>
    <password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted> 
  </jdbc-driver-params>
  <jdbc-connection-pool-params>
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name> 
    <profile-type>0</profile-type> 
  </jdbc-connection-pool-params>
  <jdbc-data-source-params>
    <jndi-name>oracleRACXAJndiName</jndi-name>
    <global-transactions-protocol>TwoPhaseCommit
        </global-transactions-protocol>
  </jdbc-data-source-params>
  <jdbc-xa-params>
    <keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete> 
    <xa-end-only-once>true</xa-end-only-once> 
    <xa-set-transaction-timeout>true</xa-set-transaction-timeout> 
    <xa-transaction-timeout>120</xa-transaction-timeout> 
    <xa-retry-duration-seconds>300</xa-retry-duration-seconds> 
  </jdbc-xa-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>oracleRACXAPool2</name> 
  <jdbc-driver-params>
    <url>jdbc:oracle:thin:@lcqsol25:1521:SNRAC2</url> 
    <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name> 
    <properties>
      <property>
        <name>user</name> 
        <value>wlsqa</value> 
      </property>
    </properties>
    <password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted> 
  </jdbc-driver-params>
  <jdbc-connection-pool-params>
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name> 
    <profile-type>0</profile-type> 
  </jdbc-connection-pool-params>
  <jdbc-data-source-params>
    <jndi-name>oracleRACXAJndiName2</jndi-name> 
    <global-transactions-protocol>TwoPhaseCommit
        </global-transactions-protocol> 
  </jdbc-data-source-params>
  <jdbc-xa-params>
    <keep-xa-conn-till-tx-complete>true</keep-xa-conn-till-tx-complete> 
    <xa-end-only-once>true</xa-end-only-once> 
    <xa-set-transaction-timeout>true</xa-set-transaction-timeout> 
    <xa-transaction-timeout>120</xa-transaction-timeout> 
    <xa-retry-duration-seconds>300</xa-retry-duration-seconds> 
  </jdbc-xa-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>oracleRACXAMDS</name> 
  <jdbc-data-source-params>
    <jndi-name>oracleRACMDSJndiName</jndi-name> 
    <algorithm-type>Load-Balancing</algorithm-type> 
    <data-source-list>oracleRACXAPool,oracleRACXAPool2</data-source-list> 
  </jdbc-data-source-params>
</jdbc-data-source>

グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用

以下の節では、グローバル・トランザクションを必要としないアプリケーション内のマルチ・データ・ソースと共にOracle RACを使用する構成について説明します。

グローバル・トランザクションを利用しないマルチ・データ・ソース内のデータ・ソースの属性

データ・ソースには以下の属性を指定する必要があります。

  • Oracle Thin JDBC Driver 11g。例:

     <url>jdbc:oracle:thin:@lcqsol24:1521:SNRAC1</url> 
     <driver-oracle.jdbc.OracleDriver/driver-name>
    
  • TestConnectionsOnReserve="true"

    • アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。

    • マルチ・データ・ソース内にフェイルオーバーおよび接続リクエスト・ルーティング(事実上、別のOracle RACノードへのフェイルオーバー)を有効化するために、必須です。

  • TestTableName="name_of_small_table"

サンプル構成コード

WebLogic JDBCマルチ・データ・ソース、および関連するデータ・ソースのサンプル構成コードを以下に示します。

<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>jdbcPool</name> 
  <jdbc-driver-params>
    <url>jdbc:oracle:thin:@lcqsol24:1521:snrac1</url> 
    <driver-name>oracle.jdbc.OracleDriver</driver-name> 
    <properties>
      <property>
        <name>user</name> 
        <value>wlsqa</value> 
      </property>
    </properties>
    <password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted> 
  </jdbc-driver-params>
  <jdbc-connection-pool-params>
    <test-connections-on-reserve>true</test-connections-on-reserve> 
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name> 
  </jdbc-connection-pool-params>
  <jdbc-data-source-params>
    <jndi-name>jdbcDataSource</jndi-name> 
  </jdbc-data-source-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>jdbcPool2</name> 
  <jdbc-driver-params>
    <url>jdbc:oracle:thin:@lcqsol25:1521:SNRAC2</url> 
    <driver-name>oracle.jdbc.OracleDriver</driver-name> 
    <properties>
      <property>
        <name>user</name> 
        <value>wlsqa</value> 
      </property>
    </properties>
    <password-encrypted>{3DES}aP/xScCS8uI=</password-encrypted> 
  </jdbc-driver-params>
  <jdbc-connection-pool-params>
    <test-connections-on-reserve>true</test-connections-on-reserve> 
    <test-table-name>SQL SELECT 1 FROM DUAL</test-table-name> 
  </jdbc-connection-pool-params>
  <jdbc-data-source-params>
    <jndi-name>jdbcDataSource2</jndi-name> 
    <global-transactions-protocol>OnePhaseCommit
         </global-transactions-protocol> 
  </jdbc-data-source-params>
</jdbc-data-source>
<jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source"
  xmlns:sec="http://xmlns.oracle.com/weblogic/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:wls="http://xmlns.oracle.com/weblogic"
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/domain/1.0/domain.xsd">
  <name>jdbcNonXAMultiPool</name> 
  <jdbc-data-source-params>
    <jndi-name>jdbcDataSource</jndi-name> 
    <algorithm-type>Failover</algorithm-type> 
    <data-source-list>jdbcPool,jdbcPool2</data-source-list> 
    <failover-request-if-busy>true</failover-request-if-busy> 
  </jdbc-data-source-params>
</jdbc-data-source>

注意:

読みやすくするために改行が追加されています。

Oracle RACノード上のサービスに対する接続の構成

Oracle RACクラスタ内のOracleサービスに依存してワークロード管理をする場合は、サービスID (SID)を使用するかわりにマルチ・データ・ソースを使用して、それらのサービスに接続する必要があります。WebLogic Serverのデータ・ソースは特定のOracle RACノード上の特定のサービスにのみ接続するように構成でき、ワークロード管理とロード・バランシングの両方を提供します。

一般に、Oracle RACサービスに接続するには、次を行う必要があります。

「サービスに接続するためのデータ・ソースの構成」では、これらのデータ・ソースを構成する際の特別な考慮事項について説明します。「サービス接続の構成」では、ロード・バランシングまたはワークロード管理に関するサンプル構成を示します。

サービスに接続するためのデータ・ソースの構成

Oracle RACノード上で実行されるサービスに接続するためのデータ・ソースの構成は、他のデータ・ソースの構成と同じ方法で(WLST、管理コンソール、または構成ウィザードを使用して)行いますが、以下の例外があります。

  • initial-capacity="0"

    この設定は、WLSの起動時に非アクティブなプールに関するプール作成失敗を防ぎ、ノード上のサービスに接続できない場合でもWLSがデータ・ソースを作成できるようにします。このオプションを0に設定しない場合、データ・ソースの作成が失敗して、サービスの正常な起動が失敗する可能性があります。

    管理コンソールでは、データ・ソースを作成した後で編集し、「初期容量」を0に設定します。

  • 11gのOracle JDBC Thin (またはThin XA)ドライバ。例:

    非XAの場合:

    driver-name="oracle.jdbc.OracleDriver"
    url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service_1)(INSTANCE_NAME=DB_02)))"
    

    管理コンソールで構成する場合は、「データベース・ドライバ」ドロップダウンから「Oracles's Driver (Thin) for RAC Service-Instance connections」を選択し、「サービス名」フィールドでサービスを指定します。

    XAの場合:

    driver-name="oracle.jdbc.xa.client.OracleXADataSource"
    url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=RAC1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=Service1)(INSTANCE_NAME=DBase1)))"
    

    管理コンソールで構成する場合は、「データベース・ドライバ」ドロップダウンから「Oracle's Driver (Thin XA) for RAC Service-Instance connections」を選択し、「サービス名」フィールドでサービスを指定します。


    注意:

    SERVICE_NAMEは特定のマルチ・データ・ソース内のすべてのデータ・ソースで同じにする必要があります。

    特定のマルチ・データ・ソース内では各データ・ソースごとに異なるホスト名とポートを指定します。


  • 接続プールに対してmax-capacity (管理コンソールの「最大容量」)を指定する場合は、構成内の各Oracle RACノードの接続容量およびすべてのデータ・ソースからの接続の総数を考慮する必要があります。詳細は、「接続プールのキャパシティ・プランニング」を参照してください。

適切なマルチ・データ・ソース・アルゴリズムの選択

サービス接続のシナリオでは、マルチ・データ・ソースをロード・バランシング・アルゴリズムで構成することをお薦めします。マルチ・データ・ソースがロード・バランシング・アルゴリズムで構成されている場合、接続プールはラウンド・ロビン方式で使用されます。この場合、関連付けられたサービスが現在アクティブになっているすべてのOracle RACノード間で、ワークロードがロード・バランシングされます。

マルチ・データ・ソースがフェイルオーバー・アルゴリズムで構成された場合、最初のデータ・ソースは、なんらかの理由によって接続に失敗するまで、関連付けられたOracle RACノード上のサービスに接続するために使用されます(たとえば、Oracle RACノードが使用できないようになるか、またはデータ・ソースでそれ以上接続できなくなります)。その時点では、第2のデータ・ソースが関連付けられたOracle RACノード上のサービスなどに接続するために使用されます。この場合、最初のデータ・ソースに接続しているOracle RACノードは、サービス実行中の残りのノードより多く使用されます。

サービス接続の構成

次の機能を提供するように構成を設計できます。

ワークロード管理

ワークロード管理の構成では、各マルチ・データ・ソースには、指定したOracle RACノード上の接続対象のサービスがアクティブかまたは非アクティブであるかどうかに関係なく、各Oracle RACノードの指定したサービスに対して1つのデータ・ソースが構成されています。これにより、未計画の停止時間またはスケジュール済メンテナンスによって別のノードが使用されなくなる場合、ノードで非アクティブなサービスを迅速に開始し、そのサービスの接続を作成できます。また、ワークロードの要請に基づいて、使用可能な容量を迅速に増減できます。

ノード上のサービスが起動されると、関連付けられているデータ・ソースはサービスが現在アクティブであることを検出します。データ・ソースは必要に応じて、そのサービスへの接続を確立し始めます。特定のノード上のサービスを停止した場合、関連付けられているデータ・ソースはそのノードへの接続を確立できなくなり、そのノード上でサービスが再起動されるまで、データ・ソースは非アクティブになります。

WLSデータ・ソースでは、接続のテストを行います。これにより、データベースがOracle RAC構成のトポロジの変更によって調整できます。データ・ソースは、ポーリングを行って、関連付けられたサービスがアクティブか非アクティブであるかを判断します。Oracle RACノード上でサービスが使用できない場合、接続テストに失敗します。

図B-4 マルチ・データ・ソースでのワークロード管理

図B-4の説明が続きます
「図B-4 マルチ・データ・ソースでのワークロード管理」の説明

この例では、サービス1はOracle RACノードの1、2および3でアクティブで、サービス2は同じノード上で非アクティブです。サービス2は、Oracle RACノードの4および5でアクティブで、サービス1は、同じノード上で非アクティブです。

Oracle RACノード1は、なんらかの理由で使用不可になる場合、サービス1をOracle RACノード4上で開始できます。WebLogic Serverはサービスがノード4上で実行されていることを検出し、必要に応じて関連付けられたバックアップ・データ・ソースからの接続をノード4に作成し始めます。

ロード・バランシング

ロード・バランシング構成では、各Oracle RACノード上で同時に複数のサービスが実行しています。各WLSマルチ・データ・ソースには、各ノードの指定したサービスに接続するために構成する1つのアクティブな接続プールがあります。このシナリオでは、ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成する必要があります。

図B-5 マルチ・データ・ソースでのロード・バランシング

図B-5の説明が続きます
「図B-5 マルチ・データ・ソースでのロード・バランシング」の説明

この例では、サービス1およびサービス2はそれぞれ使用可能なすべてのOracle RACノード上でアクティブに実行されています。その結果、各マルチ・データ・ソースのすべての接続プールは、5つのノード間のワークロードのバランスを取って、アクティブにラウンド・ロビン方式で接続を作成します。

接続プールのキャパシティ・プランニング

特に注意すべき点は、データ・ソースに対して指定した最大容量の値によっては、特定のOracle RACノードの接続容量を超える可能性があることです。各データ・ソースに対してこの値を設定する方法を決定するときに、次の要素を考慮する必要があります。

  • Oracle RACノードでサポートできる最大同時接続数。これは、特定のOracle RACノードでの使用可能なメモリーおよび各サービス接続が消費するメモリー量(サービスごとに異なります)に基づきます。各接続によるメモリー消費は、WLSサーバーから生成される作業の量を制限する主要素です。WLSデータ・ソースから特定のOracle RACノードへの接続をあまりに多く作成して使用可能なメモリー量を超えると、Oracle RACノード上のパフォーマンスが低下するかまたは接続が失敗する可能性があります。

    1つのノードで使用可能なメモリー量は(セッション・メモリーごとの) PGAターゲット属性に基づく必要があります。

  • 特定のOracle RACノードへの接続を作成できるデータ・ソースの最大数、および単一データ・ソースまたはマルチ・データ・ソースがターゲットとするWebLogicサーバーのインスタンス数。たとえば、1つのデータ・ソースが3つのWLSサーバーをターゲットとする場合、各サーバーはそれぞれデータ・ソースの固有のインスタンスを使用するため、データ・ソースの個数が3になります。これは、サーバーがクラスタの一部である場合または独立したサーバー・インスタンスである場合も同じです。

  • 特定のOracle RACノードでアクティブに実行しているサービスの最大数および各サービスへの各接続によってノード上で使用されるメモリー。

  • 特定のノード上の各サービスごとに予想される相対的なワークロード。たとえば、サービス1で予想されるワークロードがサービス2で予想されるワークロードの2倍になる場合もあります。

    サービスがノード上で常にアクティブになるかどうかにかかわらず、そのノードでサービスを起動する必要がある場合に備えて、そのサービス用のリソースを割り当てる必要があります。

  • データ・ソースの最大容量の値を設定するときは、常に最悪のケースのシナリオを使用します。たとえば、すべての使用可能なサービスが各データ・ソースに関連付けられたOracle RACノード上でアクティブに実行していると想定します。

次の例では、各データ・ソースの最大容量の値を決定する方法について説明します。これは、問題を概念的に説明するための簡単な例であり、現実の状況ははるかに複雑であることに注意してください。一般的に、一番良い方法は、データ・ソースの最大容量の値を低めに設定し、Oracle RACノードのメモリー使用量およびパフォーマンスを監視して、関連付けられたOracle RACノードの最大容量に達成するまで最大容量の値を増やすことです。

以下のような基本の構成があると仮定します。

  • Oracle RACノードが5つで、各ノードはメモリーが16GBです。

  • 2つのサービスは、各Oracle RACノード上でアクティブに実行しています。サービス1は、接続当たり10MBのメモリーを使用し、サービス2は接続当たり20MBのメモリーを使用します。

  • 各サービスのワークロードは同じです。つまり、各サービスは、指定したOracle RACノード上に同じ接続数を生成します。

  • 2つのWebLogic Serverクラスタ。クラスタ1には5つのサーバーがあります。クラスタ2には4つのサーバーがあります。

  • 指定したOracle RACノードにおいて、1つのデータ・ソースはクラスタ1をターゲットとし、サービス1に接続するように構成されています。

  • 指定したOracle RACノードにおいて、1つのデータ・ソースはクラスタ2をターゲットとし、サービス2に接続するように構成されています。

サービス2は1接続あたりでサービス1の2倍のメモリーを使用するため、サービス2にはノードのメモリーを約10GB、サービス1には約5GBを割り当てる必要があります。

クラスタ1では、5つのWLSサーバーがあるので、このOracle RACノードに接続リクエストを作成するデータ・ソースが5つあります。これにより、指定したデータ・ソースからの接続に対して1GBのメモリーが使用可能になります(5GB/5)。各接続に対して10MBのメモリーが必要であるため、クラスタ1をターゲットとする各データ・ソースの最大容量値が100以下である必要があります。

クラスタ2では4つのWLSサーバーがあるため、このOracle RACノードに接続リクエストを作成するデータ・ソースが4つあります。これにより、指定したデータ・ソースからの接続に対して2.5GBのメモリーが使用可能になります(10GB/4)。各接続に対して20MBのメモリーが必要であるため、クラスタ2をターゲットとする各データ・ソースの最大容量値が125以下である必要があります。

サービス2がサービス1より多くのワークロードを生む場合は、これらの値を適切に調整する必要があります(サービス2に接続しているデータ・ソースの最大容量の値を増やして、サービス1に接続しているデータ・ソースの値を減らします)。次である間は:

(サービス1への最大接続数x 1つの接続で使用されるメモリー) + (サービス2への最大接続数x 1つの接続で使用されるメモリー) <使用可能なメモリー

パフォーマンス低下や接続障害の可能性を回避することができます。

または、図B-6で示すような単純な構成では、各データ・ソースに指定する「最大容量」値を以下の公式で大まかに決定することができます。

Maximum connection pool capacity = Maximum number of connections to Oracle RAC nodes/(Number of WebLogic Server instances x Nmber of data sources targeted to each instance x Number of active Oracle RAC services configured x Number of Oracle RAC Nodes)

説明:

Oracle RACノードへの最大接続数は、すべてのノード上の使用可能なメモリーの合計を、各接続が消費するメモリーで除算することによって決まります。

WebLogic Serverインスタンス数は、データ・ソースがターゲットとするサーバー・インスタンスの数です。データ・ソースがWLSクラスタをターゲットとする場合は、クラスタ内のサーバーの数になります。

図B-6の例では:

  • Oracle RACノード当たりの使用可能なメモリーが8GB、1接続当たりの消費メモリーが10MBであることに基づき、Oracle RACノードのグループに作成できる接続の合計数を最大4000個と想定します。

  • データ・ソースがターゲットとするサーバー・インスタンスは合計で5つです。

  • 各サーバー・インスタンスをターゲットとするデータ・ソースは5つです。

  • 各Oracle RACノードで2つのサービスが実行されます。

  • Oracle RACノードは5つです。

この構成では、各データ・ソースに対して入力する最大容量の値は次のようになります。

Maximum connection pool capacity = 4000/(5 server instances x 5 data sources x 2 services x 5 Oracle RAC nodes)

したがって、各データ・ソースの「最大容量」値は16になります。

図B-6 マルチ・データ・ソースの接続構成の例

図B-6については周囲のテキストで説明しています

この式はデータ・ソースの構成に関する一般的なガイドラインにすぎないことに留意してください。多くの構成は非常に複雑なため、このような単純な計算は使えません。

使用する必要がある最大容量の値を計算する際は、常に構成全体での最悪のケースのシナリオを考慮する必要があります。最悪の状況が発生したときのために大きすぎる値を設定するよりも、通常のオペレーションのために低めの値を設定するのが良い方法です。常にOracle RACノードを監視して、データ・ソースの最大容量値を増やしても安全かどうかを決定することができます。

Oracle RACでマルチ・データ・ソースを使用する場合のXAの考慮事項と制限事項

Oracle RACのマルチ・データ・ソースでXA (グローバル・トランザクション)を使用する際は、次の要件および制限を考慮する必要があります。

マルチ・データ・ソースを使用する場合のOracle RAC XA要件

グローバル・トランザクションでマルチ・データ・ソースを使用する場合のOracle RACの要件を次に示します。

マルチ・データ・ソースの使用

Oracle RACで、マルチ・データ・ソースのXAトランザクションを使用する場合、常にマルチ・データ・ソースを使用します。

グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了する必要があります

グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了する必要があります。WebLogicサーバーでは、JDBCデータ・ソースの構成でKeepXAConnTillTxComplete="true"と設定した場合、そのようにできます。

Oracle RACクラスタ内では一意のトランザクションIDを使用する必要があります

グローバル・トランザクションを利用する場合は、トランザクションID (XID)がOracle RACクラスタ内で一意である必要があります。しかし、Oracle ThinドライバやOracle RACインスタンスでは、Oracle RACクラスタ内でXIDが一意であるかどうかを識別できません。同じXIDのトランザクションが複数存在すると、SQLコードがOracle RACクラスタの別々のインスタンスで実行されるおそれがあり、その場合でも例外はスローされません。

マルチ・データ・ソースでOracle RACを使用する場合の既知制限

次の項では、Oracle RACとともにXAおよびマルチ・データ・ソースを使用する場合の既知の問題や制限について説明します。

障害発生時にデータ・デッドロックが発生する可能性

Oracle RACクラスタ全体でトランザクションIDが利用できなくなる時間帯があります。これは既知の制限が原因で、障害発生時に一部の未完了トランザクションが正常に完了できない場合があり、結果としてデータベースでデッドロックが発生するおそれがあります。このような障害が発生することを防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSecondsXARetryIntervalSecondsが用意されています。これらの構成オプションの詳細は、「フェイルオーバー中の遅延」を参照してください。

トランザクションが順序どおりに完了しない可能性

Oracle DataBase Controlを使用した場合、トランザクション処理の順番は保証されません。たとえば、DataBase Controlを使って、次のトランザクション・シーケンスを実行するWebサービスを実装する場合を考えます。

  1. 表を作成

  2. レコード1を挿入

  3. レコード2を挿入

  4. レコード3を挿入

  5. レコードを選択

表を作成した後でプライマリ・ノードが一時的に停止すると、データベースに送信されたトランザクションが、順序どおりに実行されない可能性があります。

データベース・サーバーのクラッシュ後に発生する既知の問題

トランザクションの処理中に、PREPARE操作は完了したがその結果がトランザクション・ログに書き込まれていない時点で、データベース・サーバー・インスタンスがクラッシュした場合、そのトランザクションに対するクライアントからのCOMMIT呼出しが数分間に渡ってハングすることがあります(TCPタイムアウト期間が経過するまでハングが続く場合もあります)。この事態が発生する時間帯は短く、問題が起こることはまれです。現時点でこの問題の回避策はありません。

Oracle RACでのJDBCストアのリカバリ

JDBCストアとOracle RACを併用している場合、Oracle RACノードのフェイルオーバーに関して考慮する必要のある機能と制限があります。以下の節を参照してください。

JDBCストアを使用する主なサービスのリストについては、『Oracle WebLogic Serverサーバー環境の構成』のストア接続の監視に関する項を参照してください。

Oracle RACと併用するためのJDBCストアの構成

JDBCストアのしくみでは、Oracle RACと併用するための構成のオプションが限られています。JDBCストアは、グローバル・トランザクションをサポートするように構成されたJDBCデータ・ソースを使用するように構成することはできません。JDBCストアは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があります。この構成オプションの詳細については、「グローバル・トランザクションを利用しない場合のマルチ・データ・ソースの使用」を参照してください。

JDBCストアは、1つの接続が失敗するまでその接続を保持し、失敗した時点で次の接続に移って、プロセスを繰り返します。したがって、JDBCストアでは、ロード・バランシング・マルチ・データ・ソースを使用することを含めて、ロード・バランシングを実装することができません。フェイル・オーバー・アルゴリズムを使用するには、JDBCストアに対してマルチ・データ・ソースを構成する必要があります。

つまり、JDBCストアについては次のようにします。

  • 非XAドライバを使用します

  • マルチ・データ・ソースをフェイルオーバー・モードで構成します。

自動再試行

JMSには、制限された接続再試行メカニズムがあり、これらのメカニズムを使用すると、そのデータベース接続を持つOracle RACノードで発生する障害に対して、サイレントに対応できます。データベースに対してネットワークが一時中断するかまたはOracle RACデータベースが別のノードにフェイルオーバーした場合、第2の接続の試行(再試行)が次のOracle RACノードを継承します。

接続再試行時間の拡張による負の効果を最小化するために、再試行時間および再試回数は制限されています。データベース接続が長時間にわたり使用不可能な場合、遅延によって、JMSが処理を適切に続行する(たとえば、メッセージの正しい順序を保持する)機能が妨害されるおそれがあります。また、この時間内に、処理が十分に進行しない場合、トランザクション・マネージャによってトランザクションのJMSリソースが失効を宣言されるか、メモリー不足が発生する可能性があります。自動再試行が成功するために重要なOracle RACフェイルオーバー時間を最小化する方法については、システム・レベルのチューニングのガイドラインが役立ちます。

自動再試行を緊密なループで行うことは、トランザクションでJMSの処理が発生する場合に特に重要です。JDBCストアでI/O障害が発生すると、ストア・レコードが不明な状態になり、それによってメッセージ自体も不明な状態に置かれます。メッセージがこの不明な状態のままコミットされないように、JMSではそのメッセージに関連するトランザクションを「failedTransaction」とマークします。トランザクション・マネージャで、これ以降にこのメッセージのコミットを完了するどのような試みがなされた場合にも、JMSではjavax.transaction.xa.XAExceptionがスローされ、errorCodeがXAException.XAER_RMERRに設定されます。この例外は、トランザクション・マネージャに対して、リソース・マネージャ(JMS)に一時的なエラーが発生していること、およびトランザクション・マネージャでコミット処理を再試行する必要があることを示すものです。この再試行ロジックにより、JMSが上部レイヤーに(RMERRに変化する)どのような障害をも通信する以前に、接続を確立するための2番目の試行が実施されます。RMERRが生成された場合、その後でメッセージを回復してトランザクションを完了するには、WebLogic Serverを再起動するのが唯一の方法です。

自動での再試行ロジックは、現在のWebLogic Serverでは次のようなオプションで管理されています。

-Dweblogic.store.jdbc.IORetryDelaySeconds=X

ここで、Xは、データベースへの接続が再試行されるまでに経過する必要のある秒数です。デフォルトでは1秒です。この値は、0から15に制限されていて、再試行は1回だけ行われます。2番目の試行で障害が発生すると、例外がコール・スタックに伝播されます。この場合、失敗したトランザクションに関連するメッセージを回復するには手動での再起動が必要になります。


注意:

自動再試行が成功しない場合は、WebLogic Serverを再起動する必要があります。