Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11g リリース1 (10.3.4) B60997-02 |
|
前 |
次 |
Oracleは、Oracle Real Application Clusters (RAC)形式で、レガシー・アプリケーション環境のマルチ・データ・ソースの構成を引き続きサポートします。次の項では、WebLogic Server上でのOracle RAC 形式でのマルチ・データ・ソースの構成使用方法について説明します。
Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを一緒に使用するには、クラスタリング・ソフトウェアおよび共有ストレージ・ソリューションに加え、両方のシステム上での固有の構成が必要になります。この節では、要求される構成について概要レベルで説明します。Oracle RAC、使用しているクラスタリング・ソフトウェア、使用しているオペレーティング・システム、および使用しているストレージ・ソリューションの構成に関する詳細は、それぞれのベンダーが提供するドキュメントを参照してください。
注意: 新規のOracle RACアプリケーションを開発する場合、レガシー・アプリケーションがマルチ・データ・ソースを使用していない場合、GridLinkデータ・ソースの使用をお薦めします。「WebLogic ServerでのOracle RACの使い方」を参照してください。 |
Oracle Real Application Clusters (Oracle RAC)は、複数のマシンのユーザーが単一のデータベースに高いパフォーマンスでアクセスすることを可能にする高可用性ソリューションに追加できるソフトウェア・コンポーネントです。Oracle RACは、複数のクラスタリングされたマシン上で実行され、クラスタ技術によって共有ストレージ・デバイスにアクセスする複数のOracleデータベース・インスタンスで構成されます。このアーキテクチャをサポートするため、データベース・インスタンスをホストするマシンは高速のインターコネクトでリンクされて、クラスタを形成します。インターコネクトとは、クラスタのノード間の通信手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサード・パーティのクラスタリング・ソフトウェアによって提供されます。図B-1にOracle RACの構成を示します。
Oracle RACでは次の領域の機能が提供されます。
インストールされているOracle RACは、単一の標準的なOracleデータベースのように見え、同じツールと実行方法で管理されます。クラスタのすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACにより各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、Oracle RACノード、ストレージ、またはその両方を追加することで、処理とリクエストの増加に伴い、データベース層を水平方向に拡張できます。
Oracle RACのノード数が増加すると、Oracle RACに追加されたノード数分汎用データ・ソース数を増加します。これには、Oracle RACトポロジを変更した場合、管理的な介入を必要とする複合的な構成(n+1データ・ソースが要求されます。nは汎用データ・ソース数+マルチ・データ・ソースを示します)が必要です。
マルチ・データ・ソースは、接続リクエストに応じるために使用するデータ・ソースの順序付けされたリストを提供します。通常、このタイプのマルチ・データ・ソースへのすべての接続リクエストは、リストの最初のデータ・ソースによって処理されます。データベース接続テストが失敗し、かつその接続を置き換えられない場合、またはデータ・ソースが中断されている場合、そのリストの次のデータ・ソースから順番に接続が選択されます。「フェイルオーバー」および「マルチ・データ・ソース管理フェイルオーバーおよびロード・バランシング」を参照してください。
マルチ・データ・ソースで、XAや非XA環境のロード・バランシングが可能になります。マルチ・データ・ソースを構成する汎用データ・ソースは、ラウンドロビン・スキームでアクセスされます。接続を切り替えると、WebLogic Serverは、注文リストの次の汎用データ・ソースから接続を選択します。Oracle RACでのマルチ・データ・ソースの使用方法の詳細は、「Oracle RACでのマルチ・データ・ソースの使用方法」を参照してください。
WebLogic ServerをOracle RACで使用するには、各Oracle RACノードに次のソフトウェアをインストールする必要があります。
Oracle RACのサポートに必要なオペレーティング・システムのパッチ。詳細は、Oracleが提供するリリース・ノートを参照してください。
Oracle 10gまたは11gのデータベース管理システム
使用しているオペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアおよびクラスタ構成については、Oracleのドキュメントを参照してください。
Veritas Cluster File Systemなどの共有ストレージ・ソフトウェア。一部のクラスタリング・ソフトウェアには、ファイル・ストレージ・ソリューションが含まれています。その場合は、共有ストレージ・ソフトウェアは必要ありません。
注意: WebLogic Serverでサポートされるハードウェア・プラットフォームやオペレーティング・システム、およびWebLogic Serverの各バージョンやサービス・パックでサポートされるOracle RACのバージョンの最新情報については、「Oracle Fusion Middleware Supported System Configurations」ページ(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html )を参照してください。Oracle RACソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracleのドキュメントを参照してください。 |
WebLogic ServerをOracle RACとともに使用するには、WebLogic JDBCデータ・ソースでOracle JDBC Thin Driver 11gを使用して、データベース接続を作成する必要があります。
WebLogic ServerおよびOracle RACの標準的なシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが含まれます。
WebLogic Serverクラスタを構成する複数の方法および様々なハードウェア・オプションがあります。WebLogic Serverクラスタの構成については、『Oracle WebLogic Serverクラスタの使い方』を参照してください。
Oracle RACに関する最新のハードウェア要件については、Oracle RACのドキュメントを参照してください。ただし、WebLogic ServerでOracle RACを使用するには、堅牢な本番レベルのハードウェア上でOracle RACインスタンスを実行する必要があります。Oracle RACの構成では、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースのレスポンスが著しく遅れると、データベースのフェイルオーバー処理の間に予期しない動作が生じるおそれがあります。
Oracle RACでマルチ・データ・ソースを使用する場合、Oracle RACインスタンスと対話でき、期待どおりに動作するようにWebLogicドメインを構成する必要があります。次の項では、構成のオプションと要件について説明します。
WebLogic Serverマルチ・データ・ソースは、Oracle RACの使用に当たり、いくつかの構成オプションをサポートします。
グローバル・トランザクション(XA)を使用している場合、複数のOracle RAC 10gまたはOracle RAC 11gに接続するには、「グローバル・トランザクションでのマルチ・データ・ソースの使用」を参照してください。
XAを使用していない場合、複数のOracle RAC 10gまたはOracle RAC 11gに接続するには、「グローバル・トランザクション以外でのマルチ・データ・ソースの使用」を参照してください。
マルチ・データ・ソースを、Oracle RACノードで実行中の特定のサービスに接続するように構成できます。XAおよび非XAドライバの両方をサポートします。「Oracle RACノードでのサービスへの接続の構成」を参照してください。
マルチ・データ・ソースを使用してWebLogic Serverと複数のOracle RACノードを接続するには、まずOracle RACクラスタ内の各Oracle RACインスタンスに、Oracle Thin DriverとともにJDBCデータ・ソースを構成します。次に、ロード・バランシングのアルゴリズムとフェイルオーバーのアルゴリズムのどちらかを使用してマルチ・データ・ソースを構成し、データ・ソースを追加します。
図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つの構成属性、XARetryDurationSeconds
とXARetryIntervalSeconds
が用意されています。
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
を有効化するには、次の手順を使用します。
管理コンソールのチェンジ・センターでロックして変更をクリックします(まだ行っていない場合)。
「ドメイン構造」ツリーで「サービス」>「JDBC」を展開し、「データ・ソース」を選択します。
「JDBCデータ・ソースの概要」ページでデータ・ソース名をクリックします。
構成: 接続プールタブを選択します。
画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。
「XA再試行期間」
]および「XA再試行間隔」
を更新します。
「保存」をクリックします。
オプションで、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インスタンス間で通信経路を確立します。WebLogic ServerでOracle RACを使用する場合、ユーザー・プロセスは通常、JDBCデータ・ソースです。
マルチ・データ・ソースは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、データ・ソース容量が増えるように構成されている場合、データ・ソースは、構成ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。
図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_time
、tcp_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"
アプリケーションがデータ・ソースにある接続を予約する際に、データベース接続がテストされるようにします。この属性の詳細は、「予約時の接続テストによるフェイルオーバーの有効化」を参照してください。
別のOracle RACノードのフェイルオーバーを有効にする必要があります。
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サービスに依存してワークロード管理をする場合は、サービスID (SID)を使用するかわりにマルチ・データ・ソースを使用して、それらのサービスに接続する必要があります。WebLogic Serverのデータ・ソースは特定のOracle RACノード上の特定のサービスにのみ接続するように構成でき、ワークロード管理とロード・バランシングの両方を提供します。
一般に、Oracle RACサービスに接続するには、次を行う必要があります。
接続する各サービスごとにマルチ・データ・ソースを作成します。
各ノードでサービスがアクティブに実行されているかどうかに関係なく、各マルチ・データ・ソース内で、サービスを構成するクラスタにある各Oracle RACノードに対して1つのデータ・ソースを作成します。
「サービスに接続するためのデータ・ソースの構成」では、これらのデータ・ソースを構成する際の特別な考慮事項について説明します。「サービス接続の構成」では、ロード・バランシングまたはワークロード管理に関するサンプル構成を示します。
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ノード上でサービスが使用できない場合、接続テストに失敗します。
この例では、サービス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つのアクティブな接続プールがあります。このシナリオでは、ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成する必要があります。
この例では、サービス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になります。
この式はデータ・ソースの構成に関する一般的なガイドラインにすぎないことに留意してください。多くの構成は非常に複雑なため、このような単純な計算は使えません。
使用する必要がある最大容量の値を計算する際は、常に構成全体での最悪のケースのシナリオを考慮する必要があります。最悪の状況が発生したときのために大きすぎる値を設定するよりも、通常のオペレーションのために低めの値を設定するのが良い方法です。常にOracle RACノードを監視して、データ・ソースの最大容量値を増やしても安全かどうかを決定することができます。
Oracle RACのマルチ・データ・ソースでXA (グローバル・トランザクション)を使用する際は、次の要件および制限を考慮する必要があります。
グローバル・トランザクションでマルチ・データ・ソースを使用する場合のOracle RACの要件を次に示します。
Oracle RACで、マルチ・データ・ソースのXAトランザクションを使用する場合、常にマルチ・データ・ソースを使用します。
グローバル・トランザクションはOracle RACクラスタの同じインスタンスで開始、作成および終了する必要があります。WebLogicサーバーでは、JDBCデータ・ソースの構成でKeepXAConnTillTxComplete="true"
と設定した場合、そのようにできます。
グローバル・トランザクションを利用する場合は、トランザクションID (XID)がOracle RACクラスタ内で一意である必要があります。しかし、Oracle ThinドライバやOracle RACインスタンスでは、Oracle RACクラスタ内でXIDが一意であるかどうかを識別できません。同じXIDのトランザクションが複数存在すると、SQLコードがOracle RACクラスタの別々のインスタンスで実行されるおそれがあり、その場合でも例外はスローされません。
次の項では、Oracle RACとともにXAおよびマルチ・データ・ソースを使用する場合の既知の問題や制限について説明します。
注意: これらの制限事項の一部は、Oracleバグ番号3428146および395790でも説明されています。これらの問題の詳細については、Oracleにお問い合わせください。 |
Oracle RACクラスタ全体でトランザクションIDが利用できなくなる時間帯があります。これは既知の制限が原因で、障害発生時に一部の未完了トランザクションが正常に完了できない場合があり、結果としてデータベースでデッドロックが発生するおそれがあります。このような障害が発生することを防ぐために、WebLogic ServerにはOracle RACに対するXA呼出しの再試行を有効にする2つの構成属性、XARetryDurationSeconds
とXARetryIntervalSeconds
が用意されています。これらの構成オプションの詳細は、「フェイルオーバー中の遅延」を参照してください。
Oracle DataBase Controlを使用した場合、トランザクション処理の順番は保証されません。たとえば、DataBase Controlを使って、次のトランザクション・シーケンスを実行するWebサービスを実装する場合を考えます。
表を作成
レコード1を挿入
レコード2を挿入
レコード3を挿入
レコードを選択
表を作成した後でプライマリ・ノードが一時的に停止すると、データベースに送信されたトランザクションが、順序どおりに実行されない可能性があります。
トランザクションの処理中に、PREPARE
操作は完了したがその結果がトランザクション・ログに書き込まれていない時点で、データベース・サーバー・インスタンスがクラッシュした場合、そのトランザクションに対するクライアントからのCOMMIT
呼出しが数分間に渡ってハングすることがあります(TCPタイムアウト期間が経過するまでハングが続く場合もあります)。この事態が発生する時間帯は短く、問題が起こることはまれです。現時点でこの問題の回避策はありません。
JDBCストアとOracle RACを併用している場合、Oracle RACノードのフェイルオーバーに関して考慮する必要のある機能と制限があります。以下の節を参照してください。
JDBCストアを使用する主なサービスのリストについては、『Oracle WebLogic Serverサーバー環境の構成』のストア接続の監視に関する項を参照してください。
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を再起動する必要があります。 |