| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理の構成と管理 11gリリース1 (10.3.6) B60997-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理の構成と管理 11gリリース1 (10.3.6) B60997-10 |
|
前 |
次 |
この章では、WebLogic ServerでOracle Real Application Clusters (RAC)を使用する際のマルチ・データ・ソースの構成および使用方法について説明します。Oracleでは、RACを使用するレガシー・アプリケーション環境に対してマルチ・データ・ソース構成を引き続きサポートしています。
Oracle RACとWebLogic Serverはどちらも複雑なシステムです。これらを同時に使用するには、それぞれのシステムで特定の構成が必要なだけでなく、ソフトウェアと共有ストレージ・ソリューションのクラスタ化も必要になります。この項では、高水準で必要とされる構成について説明します。Oracle RACの構成、クラスタリング・ソフトウェア、オペレーティング・システム、およびストレージ・ソリューションの詳細は、それぞれのベンダーのドキュメントを参照してください。
|
注意: 新規のOracle RACアプリケーションを開発する場合、および従来のアプリケーションでマルチ・データ・ソースが使用されない場合は、GridLinkデータ・ソースの使用をお薦めします。「Oracle RACでのWebLogic Serverの使用」を参照してください。 |
Oracle Real Application Clusters (Oracle RAC)は高可用性ソリューションに追加できるソフトウェア・コンポーネントであり、複数のマシンを使用しているユーザーは単一のデータベースにアクセス可能になり、さらにパフォーマンスの向上も実現できます。Oracle RACは、2台以上のクラスタ化マシンで実行しており、クラスタ・テクノロジを使用して共有ストレージ・デバイスにアクセスする2つ以上のOracleデータベース・インスタンスで構成されています。このアーキテクチャをサポートするために、これらのデータベース・インスタンスをホストするマシンが高速のインターコネクトによってリンクされてクラスタを構成します。インターコネクトは、クラスタのノード間の通信手段として使用される物理ネットワークです。クラスタ機能は、オペレーティング・システムまたは互換性のあるサードパーティのクラスタリング・ソフトウェアが提供しています。図C-1は、Oracle RAC構成を示しています。
Oracle RACには、次の領域の機能が備わっています。
Oracle RACインストールは単一の標準Oracleデータベースのような外観であり、同じツールと手法でメンテナンスが行われます。クラスタ内のすべてのノードは同じデータベースに対してトランザクションを実行し、Oracle RACは共有データへの各ノードのアクセスを調整して一貫性を維持し、整合性を確保します。クラスタへのノードの追加は簡単であり、ノードを追加する際にデータをパーティション化する必要がありません。つまり、Oracle RACのノード、ストレージ、またはその両方を追加することによって、使用率と需要の増加に伴うデータベース層のスケーラビリティを水平に設定できます。
Oracle RACのノード数の増加に伴い、汎用データ・ソースの数をOracle RACに追加されたノード数に応じて拡大します。これには複雑な構成が必要であり(n+1データ・ソースが必要です。この場合のnは汎用データ・ソース数にマルチ・データ・ソース1つを加えた値です)、Oracle RACトポロジが変更された場合は管理者操作が必要になります。
マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。「フェイルオーバー」および「マルチ・データ・ソースで管理されるフェイルオーバーおよびロード・バランシング」を参照してください。
マルチ・データ・ソースは、XA環境と非XA環境に対するロード・バランシングとして機能します。マルチ・データ・ソースを構成する汎用データ・ソースへのアクセスには、ラウンドロビン・スキームが使用されます。接続を切り替える際に、WebLogic Serverは、一覧表示されている順に次の汎用データ・ソースから接続を選択します。Oracle RACでのマルチ・データ・ソースの使用の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
Oracle RACによってWebLogic Serverを使用するには、Oracle RACのノードごとに次のソフトウェアをインストールする必要があります。
Oracle RACのサポートに必要なオペレーティング・システムのパッチ。詳細は、Oracleのリリース・ノートを参照してください。
Oracle 11gデータベース管理システム
オペレーティング・システム用のクラスタリング・ソフトウェア。サポートされるクラスタリング・ソフトウェアとクラスタ構成については、Oracleドキュメントを参照してください。
Veritas Cluster File Systemなどの共有ストレージ・ソフトウェア。クラスタリング・ソフトウェアの中にはファイル・ストレージ・ソリューションが組み込まれているものがあり、その場合は共有ストレージ・ソフトウェアを追加する必要がありません。
|
注意: 最新のWebLogic Serverハードウェア・プラットフォームとオペレーティング・システムのサポート、およびWebLogic Serverの各種バージョンとサービス・パックによりサポートされるOracle RACバージョンについては、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。Oracle RACソフトウェアの実行に必要なハードウェア要件およびソフトウェア要件については、Oracleドキュメントを参照してください。 |
WebLogic ServerでOracle RACを使用するには、WebLogic JDBCデータ・ソースでOracle JDBC Thinドライバ11gを使用してデータベース接続を作成する必要があります。
標準的なWebLogic Server/Oracle RACシステムには、WebLogic Serverクラスタ、Oracle RACクラスタ、および共有ストレージ用のハードウェアが組み込まれています。
WebLogic Serverクラスタの構成方法は多数あり、様々なハードウェア・オプションも使用できます。WebLogic Serverクラスタの構成の詳細は、Oracle WebLogic Serverのクラスタの使用に関する項を参照してください。
Oracle RACの最新のハードウェア要件については、Oracle RACドキュメントを参照してください。ただし、Oracle RACをWebLogic Serverで使用するには、Oracle RACインスタンスを強力な、本番品質のハードウェア上で実行する必要があります。Oracle RAC構成によって、合理的に予想されるアプリケーション・ロード要件に適したデータベース処理パフォーマンスが生成される必要があります。データベース応答に異常な遅延が生じると、データベース・フェイルオーバー・シナリオの際に予想外の動作が発生する可能性があります。
Oracle RACでマルチ・データ・ソースを使用する際、WebLogic DomainがOracle RACインスタンスと相互作用して、予想どおりに実行できるようにWebLogic Domainを構成する必要があります。次の各項では、構成オプションと要件について説明します。
WebLogic Serverのマルチ・データ・ソースは、Oracle RACで使用できるようにいくつかの構成オプションをサポートしています。
グローバル・トランザクション(XA)を使用する場合に複数のOracle RAC 11gインスタンスに接続する方法については、「グローバル・トランザクションを使用したマルチ・データ・ソースの使用」を参照してください。
グローバル・トランザクション(XA)を使用しない場合に複数のOracle RAC 11gインスタンスに接続する方法については、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。
また、Oracle RACノード上で実行している特定のサービスに接続するようにマルチ・データ・ソースを構成することもできます。XAドライバと非XAドライバはどちらもサポートされています。「Oracle RACノード上のサービスへの接続の構成」を参照してください。
WebLogic Serverをマルチ・データ・ソースを使用した複数のOracle RACノードに接続するには、Oracle Thinドライバを使用したOracle RACクラスタの各Oracle RACインスタンスのJDBCデータ・ソースを最初に構成します。次に、ロード・バランシング用アルゴリズムまたはフェイルオーバー用アルゴリズムを使用してマルチ・データ・ソースを構成し、データ・ソースを追加します。
図C-2に、標準的なマルチ・データ・ソース構成を示します。
管理コンソール、またはドメインの構成に優先的に使用したいその他の手段、たとえばWebLogic Scripting Tool (WLST)またはJMXプログラムが使用できます。WebLogic JDBCマルチ・データ・ソースの構成については、「JDBCマルチ・データ・ソースの構成」を参照してください。Oracle RACノード上で実行するサービスに接続するためにマルチ・データ・ソースにデータ・ソースを構成する方法については、「Oracle RACノード上のサービスへの接続の構成」を参照してください。
この構成でデータベース接続を使用するには、アプリケーションでJNDIツリー上のマルチ・データ・ソースを1つ検索してから、接続をリクエストします。マルチ・データ・ソースによって、接続リクエストへの対応に使用するデータ・ソースが、構成で指定されたアルゴリズムのタイプ(フェイルオーバーまたはロード・バランシング)に基づいて決定されます。
マルチ・データ・ソースには、システム・ロード・バランシングまたはフェイルオーバーでのOracle RACのロールに応じて、次の属性を割り当てることができます。
AlgorithmType="Load-Balancing"またはAlgorithmType="Failover"
Load-Balancingオプションを指定した場合、接続リクエストは使用可能なデータ・ソースの間で配信されます。高可用性オプションを指定した場合、接続リクエストはリスト内で最初に使用可能なプールにより対応されます。データ・ソースが使用不能になると、接続リクエストはリストの次のデータ・ソースで処理されます。
FailoverRequestIfBusy="true"
フェイルオーバー・アルゴリズムを使用している場合、この属性により、データ・ソース内のすべての接続が使用中のときにフェイルオーバーが有効になります。
TestFrequencySeconds="120"
この属性は、接続が再作成可能かどうか、およびデータ・ソースが再有効化できるかどうかを判別するために、以前に異常とマークされたデータ・ソースのヘルスをWebLogic Serverがチェックする頻度を制御します。詳細は、「JDBCマルチ・データ・ソースの構成」を参照してください。
Oracle RACノードの高速フェイルオーバーを実現するには、この値をより小さい間隔、たとえば10 (秒)に設定します。
フェイルオーバーを構成する際は、次の情報を考慮してください。
マルチ・データ・ソースは、グローバル・トランザクションに対してフェイルオーバー機能およびロード・バランシング機能を提供します。マルチ・データ・ソースのフェイルオーバー機能の説明は、「マルチ・データ・ソース・フェイルオーバー機能の拡張」を参照してください。
図C-2に示す構成により、次の機能を取得できます。
マルチ・データ・ソースにより制御される高速フェイルオーバー
WebLogic Serverヘルス・モニターによる自動フェイルバック
マルチ・データ・ソースは、Oracle RACノードが使用できなくなった場合にデータベース接続に対するフェイルオーバーを処理します。WebLogic Serverが接続をテストして接続が失敗した場合は、接続を再作成しようと試みます。この試みが失敗すると、サーバーはデータ・ソースを無効にして、接続リクエストをマルチ・データ・ソース内の他のデータ・ソース(他のOracle RACノードに対応するもの)にルーティングします。WebLogic Serverは、無効になったデータ・ソース内でデータベース接続の再作成を定期的に試行します。接続の再作成に成功すると、WebLogic Serverは次にデータ・ソースを再有効化して、そのデータ・ソースへの接続リクエストのルーティングを開始します。接続リクエストのルーティングと自動ヘルス・チェック機能により、失敗後の接続リクエストへの対応の遅延が最小限に抑えられます。
Oracle RACノードが別のOracle RACノードに対してフェイルオーバーを起こした際、失敗したノード上で進行中のトランザクション・ブランチに関連しているデータがクラスタ全体で使用可能になるまでに、遅延が生じる場合があります。このため、不完全なトランザクションが適切に完了することができず、データベースでさらにデータのロックが生じる可能性があります。このような遅延による潜在的影響を防ぐために、WebLogic Serverには、Oracle RACに対するXAコールの再試行を有効にする2つの構成属性、XARetryDurationSecondsおよびXARetryIntervalSecondsが用意されています。
XARetryDurationSecondsは、保留中のトランザクションに対してリカバリ、コミット、ロールバックなどのXA操作が繰り返し再試行される期間を制御します。XARetryIntervalSecondsは、設定された期間内での再試行の頻度を制御します。
XAコールの再試行を有効にするには、XARetryDurationSecondsの値を、Oracle RACインスタンスに接続している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>oracleRACXAPool</name>
...
<jdbc-xa-params>
...
<xa-retry-duration-seconds>300</xa-retry-duration-seconds>
</jdbc-xa-params>
</jdbc-data-source>
次の式を使用して、XARetryDurationSecondsの値を決定します。
XARetryDurationSeconds = (データ・ソースからの接続を使用するトランザクションの最長トランザクション・タイムアウト) + (すべてのOracle RACノード上でXIDが使用可能になるまでの遅延、通常は5分以下)
たとえば、アプリケーションで最長トランザクション・タイムアウトを180秒に設定している場合は、XARetryDurationSecondsを180秒+300秒、合計480秒に設定します。
|
注意: 通常は、すべてのトランザクションが適切に完了できるのに必要な最低値よりも少し高めに |
オプションとして、XARetryIntervalSecondsの値を設定することもできます。この値によって、XA再試行コールの間隔が決定します。デフォルトでは、この値は60秒です。値を低くすると、XA再試行の間隔も短くなります。ほとんどの場合、デフォルト値で十分です。
管理コンソールからXARetryDurationSecondsおよびXARetryIntervalSecondsを有効にするには、次の手順を実行します。
まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
「ドメイン構造」ツリーで「サービス」→「JDBC」を展開し、「データ・ソース」を選択します。
「データ・ソースのサマリー」ページで、データ・ソース名をクリックします。
「構成: 接続プール」タブを選択します。
画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。
「XA再試行期間」および「XA再試行間隔」を更新します。
「保存」をクリックします。
オプションとして、WebLogic Scripting Tool (WLST)またはJMXプログラムを使用できます。
そのノードが失敗すると、そのデータベース・ノードに対する処理中のトランザクションはどうなるか?プライマリOracle RACノードはいつ失敗するのか?WebLogic Serverは、透過的フェイルオーバーをサポートしているか?WebLogic Serverの失敗処理に関するこれらの質問や、その他の質問に答えるために、トランザクションの処理手順を1つずつ実行し、それぞれのステージで失敗がどのように処理されるかを説明します。
失敗が起こる可能性のある最初のステージは、アプリケーションがコミット対象のトランザクションをコールする前です。このステージでデータベースまたはOracle RACノードが失敗した場合、アプリケーションは例外を受け取るため、新規接続を取得し、トランザクション処理時に新しく試行する必要があります。WebLogic Serverでは、透過的フェイルオーバーをサポートしていません。
アプリケーションがコミット対象のトランザクションをコールした後で失敗が発生した場合、処理中のトランザクションの処理方法は、PREPARE操作が完了したかどうかによって異なります。PREPARE操作が完了していない場合は、トランザクション・マネージャがそのトランザクションをロールバックして、失敗したトランザクションに関する例外がアプリケーションに送信されます。PREPARE操作が完了している場合、トランザクション・マネージャは別のノードを使用して処理中のトランザクションを完了させようとします。
COMMIT操作中に失敗が発生した場合、トランザクション・マネージャはCOMMIT操作の再試行を数回試みます。この試行中、接続はブロックされることに注意してください。最初の再試行セットの間にCOMMIT操作が成功しなかった場合、アプリケーションは例外を受け取ります。その後、トランザクション・マネージャは成功するまでCOMMIT操作の再試行を定期的に続行します。トランザクションが中止期間内に正常に終了できなかった場合、トランザクションはヒューリスティックに完了させられます。
Oracle RACでは、リスナー・プロセスによってユーザー・プロセスとOracleインスタンスとの間に通信経路が設定されます。Oracle RACをWebLogic Serverで使用する場合、ユーザー・プロセスは通常はJDBCデータ・ソースです。
マルチ・データ・ソースが作成されると、アプリケーションで流用できるようにデータベース接続プールの作成が試みられます。プールされたデータベース接続が操作不能になったり、データ・ソースが容量が増加するように構成されている場合、データ・ソースは、構成ファイルで指定された最大値まで追加のデータベース接続を作成しようと試みます。これらのすべてのインスタンスで、Oracleリスナー・プロセスはOracle RACインスタンスに対する接続リクエストを処理します。
図C-3は、Oracleリスナー・プロセスの機能を示しています。
この機能を有効にするには、次の2つのオプションが使用できます。
ローカル・リスナーの使用。Oracleクラスタ内のOracle RACインスタンスごとにリスナー・プロセスを構成します。WLSでは、Oracle RACインスタンスごとにローカル・リスナーを構成する必要があります。各データベース・インスタンスは、そのローカル・リスナーのみに登録されるように構成します。
Oracleインスタンスは、listener.oraファイル内で静的にリスナーに登録されるか、インスタンス初期化パラメータlocal_listenerを使用して動的に登録されるか、またはその両方で登録されるように構成できます。動的登録の使用をお薦めします。
リスナーは、共有ディスパッチャ・プロセスまたは専用プロセスのいずれかを開始できます。WebLogic Serverで使用する場合は、専用プロセスの使用をお薦めします。
リモート・リスナーの使用。WLSでは、マルチ・データ・ソース内のデータ・ソースのJDBC URLに、SERVICE_NAMEおよびINSTANCE_NAMEの両方を指定する必要があります。「リモート・リスナー有効時または無効時のマルチ・データ・ソースの構成」を参照してください。
サーバー側のロード・バランシング機能が(remote_listenersを使用して)Oracle RACバックエンドで有効になっている場合、マルチ・データ・ソース構成のデータ・ソースで使用される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プロパティの値をオペレーティング・システム・レベルでより小さい値に設定します。
|
注意:
|
たとえば、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.myco.com)(INSTANCE_NAME=orcl1)))
次のコード・スニペットは、データ・ソース構成の一例です。
<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.us.myco.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.myco.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 JDBC Thinドライバ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 JDBC Thinドライバ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つずつ作成します。
「サービスに接続するようにデータ・ソースを構成」では、これらのデータ・ソースの構成で特に考慮すべき点を説明しています。「サービス接続の構成」では、ロード・バランシングまたはワークロード管理のいずれかの構成例を示しています。
任意のデータ・ソースを構成する場合と同じ方法で(WLST、管理コンソール、または構成ウィザードを使用)、Oracle RACノード上で稼働中のサービスに接続するようにデータ・ソースを構成します。ただし、次の例外があります。
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)))"
管理コンソールを使用して構成する場合は、「データベース・ドライバ」ドロップダウン・リストからRACサービス・インスタンス接続用のOracleのドライバ(Thin)を選択し、「サービス名」フィールドでサービスを指定します。
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)))"
管理コンソールを使用して構成する場合は、「データベース・ドライバ」ドロップダウン・リストからRACサービス・インスタンス接続用のOracleのドライバ(Thin XA)を選択し、「サービス名」フィールドでサービスを指定します。
|
注意: SERVICE_NAMEは、指定されたマルチ・データ・ソースのすべてのデータ・ソースに対して同じである必要があります。 指定されたマルチ・データ・ソース内のデータ・ソースごとに異なるHOST NAMEおよびポート(またはその一方)を指定します。 |
接続プールに対してmax-capacity (管理コンソールでは「最大容量」)を指定する際、構成内の各Oracle RACノードの接続容量と、すべてのデータ・ソースからの接続総数を考慮に入れる必要があります。詳細は、「接続プールのキャパシティ・プランニング」を参照してください。
適切なマルチ・データ・ソース・アルゴリズムの選択
サービス接続のシナリオでは、マルチ・データ・ソースの構成にロード・バランシング・アルゴリズムを使用することをお薦めします。ロード・バランシング・アルゴリズムを使用してマルチ・データ・ソースを構成した場合、その接続プールはラウンドロビン方式で使用されます。この場合、関連するサービスが現在アクティブになっているすべてのOracle RACノードにわたって、ワークロードがロード・バランシング処理されます。
マルチ・データ・ソースの構成にフェイルオーバー・アルゴリズムを使用した場合は、接続の試行が失敗するまで(たとえば、Oracle RACノードが使用できなくなったり、使用可能な接続がデータ・ソースになくなるなどの理由で)、関連するOracle RACノード上のサービスへの接続に最初のデータ・ソースが使用されます。失敗した時点で、関連するOracle RACノード上のサービスへの接続に2番目のデータ・ソースが使用され、これが順次続行されます。この場合、最初のデータ・ソースの接続先であるOracle RACノードは、サービスが稼働中であるその他のノードよりも多く使用されることになります。
次の機能を提供できるように構成を設計できます。
ワークロード管理構成では、接続しているサービスが特定のOracle RACノードでアクティブか、または非アクティブかどうかに関係なく、各マルチ・データ・ソースでは、それぞれ1つのデータ・ソースが各Oracle RACノードの特定のサービス用に構成されています。このため、計画外ダウンタイムやスケジュールされたメンテナンスなどにより別のノードが使用できなくなった場合に、ノード上で非アクティブなサービスをすばやく開始して、そのサービスへの接続を作成できます。また、ワークロード需要に基づいて、指定されたサービスの使用可能容量をすばやく増加または削減することもできます。
ノード上でサービスが開始すると、関連付けられたデータ・ソースはサービスがアクティブになっていることを検出し、必要に応じてそのノードへの接続を開始します。指定されたノード上のサービスが停止すると、関連付けられたデータ・ソースはそのノードへの接続ができなくなり、サービスが再開始されるまで非アクティブになります。
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ノードの接続容量を超過することがあります。データ・ソース別にこの値を設定する際、次の要因を考慮する必要があります。
1つのOracle RACノードでサポートできる同時接続の最大数。これは、1つのOracle RACノードで使用可能なメモリーと、各サービス接続の消費メモリー量(これはサービスごとに異なる場合があります)に基づきます。各接続のメモリー消費量は、WLSサーバーから生成できる作業量に対する主な制約要因です。WLSデータ・ソースからOracle RACノードへの接続が多すぎるために使用可能メモリー量を超えた場合、Oracle RACノードのパフォーマンスが低下し、接続失敗につながることがあります。
ノードの使用可能メモリーは、PGAターゲット属性(セッション・メモリーごと)に基づいていることが望ましいです。
特定のOracle RACノードに対して潜在的に接続を作成できるデータ・ソースの最大数、および各汎用データ・ソース/マルチ・データ・ソースをターゲットに指定するWebLogicサーバー・インスタンス数。たとえば、3つのWLSサーバーのターゲットとして指定されたデータ・ソースが1つある場合、各サーバーはデータ・ソースの中でそれぞれ専用のインスタンスを使用するため、そのデータ・ソースは3つのデータ・ソースとしてカウントされます。これは、サーバーがクラスタの一部であるか、または独立したサーバー・インスタンスであるかどうかのケースです。
特定のOracle RACノードでアクティブに稼働中であると思われるサービスの最大数、および各サービスへの接続ごとにノードで消費されるメモリー。
特定のノード上のサービスごとに予想される相対的なワークロード。たとえば、サービス1の予想ワークロードは、サービス2の予想ワークロードの2倍になる場合があります。
サービスが常にノードでアクティブであるかどうかに関係なく、ノード上でそのサービスを開始する必要がある場合は、そのサービスに対してリソースを割り当てることをお薦めします。
データ・ソースに最大容量値を設定する場合は、常に最悪ケースのシナリオを使用してください。たとえば、各データ・ソースに関連付けられたOracle RACノードで、使用可能なすべてのサービスがアクティブに稼働するものと想定します。
次の例で、各データ・ソースの最大容量値を決定する方法について説明します。これは問題の概念をわかりやすく示すための非常に簡単な例であり、実際の状況ははるかに複雑であることを念頭においてください。一般に、低い最大容量値を使用してデータ・ソースを過少構成し、メモリー使用率とパフォーマンスに関してOracle RACノードをモニターし、その後で、関連付けられたOracle RACノードの最大容量に近づくまで最大容量値を上方に調整するのが最もよい方法です。
例
次の基本構成を使用しているとします。
それぞれが16GBのメモリーを持つ5つのOracle RACノード。
各Oracle RACノードでアクティブに稼働している2つのサービス。サービス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つ存在することになります。したがって、1つのデータ・ソースからの接続に使用可能なメモリーは1GB (5GB/5)になります。各接続では10MBのメモリーが必要なため、クラスタ1のターゲットとなるデータ・ソースごとの最大容量値は100以下になります。
クラスタ2には4つのWLSサーバーがあるため、このOracle RACノードに対して接続リクエストを作成するデータ・ソースが4つ存在することになります。したがって、1つのデータ・ソースからの接続に使用可能なメモリーは2.5GB (10GB/4)になります。各接続では20MBのメモリーが必要なため、クラスタ2のターゲットとなるデータ・ソースごとの最大容量値は125以下になります。
サービス2がサービス1よりも多くのワークロードを生成する場合は、これらの値を適切に調整する必要があります(サービス2に接続しているデータ・ソースの最大容量値を増やし、サービス1に接続しているデータ・ソースの値を減らします)。次の状況であるかぎり:
(サービス1の最大接続数 x 接続ごとに使用するメモリー) + (サービス2の最大接続数 x 接続ごとに使用するメモリー) < 利用可能なメモリー
パフォーマンス低下または接続失敗の可能性を回避できます。
あるいは、図C-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クラスタである場合、これはクラスタ内のサーバー数になります。
図C-6の例では、次のようになっています。
Oracle RACノード1つごとに使用可能なメモリーが8GB、接続ごとの使用メモリーが10MBであるとして、Oracle RACノードのグループに接続できる接続総数が最大4000であると仮定します。
データ・ソースをターゲットとするサーバー・インスタンスが合計5つあります。
各サーバー・インスタンスのターゲットとなるデータ・ソースが5つあります。
各Oracle RACノードで稼働している2つのサービスがあります。
5つのOracle RACノードがあります。
この構成では、データ・ソースごとに入力する最大容量値は次のようになります。
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クラスタの同一インスタンスで開始、準備、および完結させる必要があります。JDBCデータ・ソース構成でKeepXAConnTillTxComplete="true"を設定すると、WebLogic Serverのデータ・ソースがこのタスクに対応します。
グローバル・トランザクションを使用する際、トランザクションID (XID)はOracle RACクラスタ内で一意である必要があります。ただし、Oracle ThinドライバもOracle RACインスタンスも、XIDがOracle RACクラスタ内で一意であるかどうかを判別することはできません。同じXIDを持つトランザクションは、例外がスローされることなく、Oracle RACクラスタの異なるインスタンス上でSQLコードを実行できます。
次の各項では、Oracle RACでXAおよびマルチ・データ・ソースを使用する際の既知の問題と制限事項について説明します。
|
注意: これらの制限事項の中には、Oracleのバグ番号3428146および395790で説明しているものもあります。これらの問題の詳細は、オラクル社にお問い合せください。 |
Oracle RACクラスタ全体にわたってトランザクションIDが使用できなくなる時間帯があります。この既知の制約により、失敗状況の後で一部の不完全なトランザクションが適切に終了できなくなり、その結果、データベースにデッドロックが生じる場合があります。このような失敗状況の発生を防ぐために、WebLogic Serverには、Oracle RACに対するXAコールの再試行を有効にする2つの構成属性、XARetryDurationSecondsおよびXARetryIntervalSecondsが用意されています。これらの構成オプションの詳細は、「フェイルオーバー時の遅延」を参照してください。
Oracle DataBase Controlを使用する場合、トランザクションの処理順序は保証されません。たとえば、DataBase Controlを使用するWebサービスを実装する場合は、次のトランザクション順序を実行します。
表を作成します。
レコード1を挿入します。
レコード2を挿入します。
レコード3を挿入します。
レコードを選択します。
表の作成後にプライマリ・ノードが一瞬停止した場合、データベースに送信されたトランザクションが順序外で実行される可能性があります。
トランザクションの処理中に、PREPARE操作の終了後、ただしその操作結果がトランザクション・ログに書き込まれる前にデータベース・サーバー・インスタンスがクラッシュした場合、そのトランザクションに対するクライアントからのCOMMITコールが数分間、あるいはTCPタイムアウト期間が期限切れになるまでハングする可能性があります。これが発生する時間帯は短いため、問題が起こることはほとんどありません。この時点でこの問題の回避策はありません。
Oracle RACとともにJDBCストアを使用している場合は、Oracle RACノードのフェイルオーバーに関連して検討すべき機能と制限事項があります。次の各項を参照してください。
JDBCストアを使用する主要なサービスのリストは、『Oracle WebLogic Serverサーバー環境の構成』のストア接続のモニタリングに関する項を参照してください。
JDBCストアの動作方法により、Oracle RACで使用するJDBCストアの構成に使用できるオプションが制限されます。グローバル・トランザクションのサポートが構成されたJDBCデータ・ソースを使用するようにJDBCストアを構成することはできません。JDBCストアは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があります。この構成オプションの詳細は、「グローバル・トランザクションを使用しないマルチ・データ・ソースの使用」を参照してください。
JDBCストアは接続が失敗するまでその接続を保持しており、失敗した時点で次の接続に移動して、プロセスを繰り返します。したがって、ロード・バランシングのマルチ・データ・ソースも含め、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.IORetryDelayMillis=x
この場合、xはデータベースへの接続が再試行されるまでの経過時間(ミリ秒)です。デフォルト値は、1000ミリ秒です。この値は0から15000ミリ秒の範囲に制限されており、再試行は1回のみ試みられます。2回目の試みで失敗すると、コール・スタックまで例外が伝播され、失敗したトランザクションに関連するメッセージをリカバリするには手動での再起動が必要になります。
|
注意: 自動再試行が成功しない場合は、WebLogic Serverを再起動する必要があります。 |
