WebLogic JDBC プログラマーズ ガイド
|
 |
 |
|
バックエンド システムのスケーラビリティや可用性をより高めるソリューションがますます求められています。こうした要求に応え、WebLogic Server では Oracle Real Application Clusters (RAC) の使用がサポートされています。
以下の節では、WebLogic Server で Oracle Real Application Clusters を使用する場合の要件およびコンフィグレーション タスクについて説明します。
Oracle RAC および WebLogic Server はどちらも複雑なシステムです。これらを一緒に使用するには、クラスタ化ソフトウェアおよび共有ストレージ ソリューションに加え、両方のシステム上での固有のコンフィグレーションが必要になります。ここでは、高度なレベルで要求されるコンフィグレーションについて説明します。Oracle RAC のコンフィグレーション、使用しているクラスタ化ソフトウェア、オペレーティング システム、およびストレージ ソリューションに関する詳細は、各ベンダが提供するマニュアルを参照してください。
Oracle Real Application Clusters (RAC) は、複数のマシンから単一のデータベースに高いパフォーマンスでアクセスできる高可用性ソリューションに追加できるソフトウェア コンポーネントです。RAC は、複数のクラスタ化されたマシン上で実行され、クラスタ技術を介して共有ストレージ デバイスにアクセスする、複数の Oracle データベース インスタンスから構成されます。このアーキテクチャをサポートするため、データベース インスタンスをホストするマシンは高速な相互接続でリンクされて、クラスタを形成します。相互接続とは、クラスタのノード間を通信する手段として使用される物理的なネットワークです。クラスタ機能は、オペレーティング システムまたは互換性のあるサード パーティのクラスタリング ソフトウェアで提供されます。図 A-1 に Oracle RAC のコンフィグレーションを示します。
図 A-1 Oracle Real Application Clusters のコンフィグレーション
インストールされている Oracle RAC は、単一の標準的なオラクル データベースのように見え、同じツールと慣行を使用して管理されます。クラスタのすべてのノードで同じデータベースに対してトランザクションを実行すると、RAC により各ノードから共有データへのアクセスが調整されて一貫性が維持され、整合性が確保されます。クラスタにはノードを簡単に追加でき、追加時にデータを分割する必要もありません。つまり、RAC ノード、ストレージ、またはその両方を追加することで、処理と要求の増加に伴い、データベース層を水平方向に拡張できます。その後、新しいノードにマップされる接続プールを追加することによって、WebLogic Server の規模を調整できます。
クラスタ内の各 RAC ノードには同等のアクセスと権限があるので、ノードがなくなった場合、パフォーマンスに影響することはあっても、ダウンタイムが発生することはありません。RAC ノードに障害が発生した場合には、指定したコンフィグレーションに応じて WebLogic Server または Oracle Thin Driver により、処理中のトランザクションがクラスタ内の別のノードにリダイレクトされます。Oracle RAC も WebLogic Server も、データベース接続のフェイルオーバを提供していません。しかし、トランザクションは、障害が発生した時点に基づいて、ヒューリスティックに完了させられるという点では、フェイルオーバされます。
グローバル トランザクション (XA) の使用時に、アプリケーションで RAC ノード間のロード バランシングが必要な場合には、JDBC マルチプールを Oracle RAC ノードと併用して実現する方法がサポートされています。マルチプールを構成する接続プールは、ラウンドロビン方式でアクセスされます。接続を切り替えるとき、WebLogic Server はリストの順序で次の接続プールから接続を選択します。どのバージョンの WebLogic Server が JDBC マルチプールをサポートするかについては、『サポート対象のコンフィグレーション』を参照してください。Oracle RAC でのマルチプールの使用の詳細については、「Oracle RAC でのマルチプールの使用」を参照してください。
マルチプールを使用しないコンフィグレーションでは、Oracle Thin Driver で提供される接続時フェイルオーバ機能を使用して、Oracle RAC と連携します。Oracle の Technical Note 235118.1 で説明されているように、Oracle Thin Driver でロード バランシングをコンフィグレーションした場合、トランザクションの開始と終了が同じ Oracle RAC インスタンスで行われるかどうかは保証されません。Oracle RAC では、グローバル トランザクション内のすべてのデータベース操作が同じ Oracle インスタンスにルーティングされる必要があるため、この確認済みの制限があることで、XA と Oracle RAC を併用する場合にドライバ レベルのロード バランシングは使用できないことになります。結果として、プライマリ/プライマリの RAC コンフィグレーションは使用できません。
Oracle RAC には、JDBC 接続時フェイルオーバ機能が用意されていますが、ほとんどのコンフィグレーションでは、フェイルオーバの処理には、代わりに WebLogic JDBC マルチプールを使用することをお勧めします。
注意 : Transparent Application Failover (TAF) では Oracle OCI Driver を使用する必要があります。BEA では Oracle Thin Driver を使用する必要があるため、TAF はサポートされていません。
WebLogic Server で Oracle RAC を使用するには、次の要件を考慮する必要があります。
注意 : WebLogic Server でサポートされるハードウェア プラットフォームやオペレーティング システム、および WebLogic Server の各バージョンやサービス パックでサポートされる Oracle RAC のバージョンの最新情報については、『サポート対象のコンフィグレーション』を参照してください。Oracle RAC ソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracle のマニュアルを参照してください。
WebLogic Server および Oracle RAC の標準的なシステムには、WebLogic Server クラスタ、Oracle RAC クラスタ、および共有ストレージ用のハードウェアが含まれます。
WebLogic Server クラスタは、さまざまハードウェア オプションを使用して多くの方法でコンフィグレーションできます。WebLogic Server クラスタのコンフィグレーションの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
Oracle RAC に関する最新のハードウェア要件については、Oracle RAC のマニュアルを参照してください。ただし、WebLogic Server で Oracle RAC を使用するには、堅牢なプロダクション レベルのハードウェア上で Oracle RAC インスタンスを実行する必要があります。Oracle RAC のコンフィグレーションでは、アプリケーションの負荷要件を適切に予想し、それに見合ったデータベース処理性能を実現する必要があります。データベースの応答が著しく遅れると、データベースのフェイルオーバ処理の間に予期しない動作が生じるおそれがあります。
Oracle RAC のコンフィグレーションでは、データ ファイル、制御ファイル、およびパラメータ ファイルはすべて、各 RAC インスタンスで共有されて使用されます。次のいずれかのアーキテクチャを使用する高可用性 (HA) ストレージ ソリューションが推奨されます。
サポートされているストレージ ソリューションの全リストについては、Oracle のマニュアルを参照してください。
WebLogic Server を Oracle RAC と共に使用するには、各 RAC ノードに次のソフトウェアをインストールする必要があります。
注意 : WebLogic Server でサポートされるハードウェア プラットフォームやオペレーティング システム、および WebLogic Server の各バージョンやサービス パックでサポートされる Oracle RAC のバージョンの最新情報については、『サポート対象のコンフィグレーション』を参照してください。Oracle RAC ソフトウェアを実行する上でのハードウェア要件およびソフトウェア要件については、Oracle のマニュアルを参照してください。
Oracle RAC をインストールしてコンフィグレーションしたら、以下の節で説明するように各 RAC インスタンスに対してリスナ プロセスをコンフィグレーションする必要があります。Oracle RAC ノードに対して、オペレーション システムおよび Oracle ソフトウェアをインストールおよびコンフィグレーションする方法については、Oracle のマニュアルを参照してください。
リスナ プロセスは、Oracle RAC に、ユーザ プロセスと Oracle インスタンス間で通信経路を確立します。WebLogic Server で Oracle RAC を使用する場合、ユーザ プロセスは通常、JDBC 接続プールです。
接続プールは作成されると、アプリケーションが使用するデータベース接続のプールを作成しようとします。プールされたデータベース接続が操作できなくなったり、接続プール容量が増えるようにコンフィグレーションされている場合、接続プールは、コンフィグレーション ファイルに指定されている最大値になるまで、データベース接続を追加作成しようとします。こうしたすべてのケースにおいて、Oracle リスナ プロセスは Oracle RAC インスタンスに対する接続リクエストを処理します。
図 A-2 に Oracle リスナ プロセスの機能を示します。
この機能を有効化するには、Oracle クラスタにおいて各 RAC インスタンスのリスナ プロセスをコンフィグレーションする必要があります。各 RAC インスタンスについてローカル リスナのコンフィグレーションが必要です。各データベース インスタンスは、そのローカル リスナのみ登録するようにコンフィグレーションする必要があります。
Oracle インスタンスのリスナ登録は、listener.ora ファイルで静的にコンフィグレーションしたり、インスタンスの初期化パラメータ local_listener を使用して動的に登録できます (両方で登録可能)。動的に登録することをお勧めします。
リスナは、共有ディスパッチ プロセスまたは専用プロセスのいずれかを起動できます。WebLogic Server を使用する場合、専用プロセスの使用をお勧めします。
Oracle RAC ではリモート リスナをコンフィグレーションして接続フェイルオーバを処理できますが、一般的に処理が遅すぎるため、リモート リスナの使用はサポートされていません。リモート リスナを無効化するには、各 RAC ノードで spfile.ora にリストされているすべてのリモート リスナを削除します。以下に例を示します。
*.remote_listener=''
代わりに、次のメソッドのいずれかを使用することをお勧めします。
Oracle 9i RAC または Oracle 10g RAC と共に WebLogic Server を使用する場合、RAC インスタンスと対話でき、期待通りに動作するように WebLogic ドメインをコンフィグレーションする必要があります。以下では、コンフィグレーションのオプションと要件について説明します。
Oracle RAC と WebLogic Server を併用するために、数種のコンフィグレーション オプションがサポートされています。
以下の表を、特定のアプリケーションに適したコンフィグレーションを判断する際の指標としてご利用ください。
WebLogic Server を Oracle RAC と共に使用するには、WebLogic JDBC 接続プールで Oracle JDBC Thin Driver 10g を使用して、データベース接続を作成する必要があります。
フェイルオーバをコンフィグレーションする際には、次の情報について考慮する必要があります。
マルチプールを使用するとグローバル トランザクションでフェイルオーバ機能を利用でき、この場合、接続プールのコンフィグレーションで接続時フェイルオーバ機能を使用することに関連した制限や確認済みの問題がありません。マルチプールのフェイルオーバ機能の説明については、「マルチプールのコンフィグレーションと使い方」を参照してください。
図 A-3、マルチプールのコンフィグレーション に示すこのコンフィグレーションでは、次の機能が実現します。
RAC ノードが利用できなくなった場合、マルチプールによってデータベース接続のフェイルオーバが処理されます。WebLogic Server で接続をテストした結果、失敗した場合には、その接続の再作成が試行されます。その試行に失敗すると、サーバでは接続プールが無効化され、接続リクエストはマルチプール内の (他の RAC ノードに対応する) 他の接続プールにルーティングされます。WebLogic Server では、無効化された接続プール内のデータベース接続の再作成が定期的に試行されます。WebLogic Server による接続の再作成が成功すると、次に接続プールが再び有効化され、改めてその接続プールへの接続リクエストのルーティングが開始されます。接続リクエストのルーティングと自動ヘルス チェック機能を実施するため、Oracle Thin Driver の接続時フェイルオーバを利用するコンフィグレーションに比べて、障害後、接続リクエストに対応するまでにわずかな遅延が生じます。
マルチプールの使用を選択できない場合 WebLogic Server では、RAC インスタンスが利用できなくなり、プライマリ/プライマリ コンフィグレーションが選択できなければ、Oracle Thin Driver の接続時フェイルオーバ機能を使用して接続のフェイルオーバが処理されます。WebLogic Server で接続をテストした結果、失敗した場合には、サーバで取得した新しい接続でその接続が置き換えられ、ドライバによって改めてどの RAC インスタンスを使用するかが、インスタンスの可用性に基づいて決定されます。属性 CountOfTestFailuresTillFlush="1" によって、テスト タスクによって生じるアプリケーションに対する接続の配信における遅延を最小限に抑えることができます。この属性を設定すると、接続が最初に接続テストに失敗した際に、WebLogic Server によって接続プール内のすべての接続が自動的に閉じられます。WebLogic Server は、接続を新しい接続と置き換えます。その際、どのノードに接続するかは、ドライバによって決まります。この場合では、プライマリ RAC ノードで障害が発生しているため、新しい接続はセカンダリ RAC ノードに対してのものとなります。WebLogic Server は新しい接続をテストしてから、リクエストに対応します。
ある RAC ノードが別の RAC ノードにフェイルオーバした場合、現在、障害の発生しているノードの処理中のトランザクション ブランチに関連するデータがクラスタ全体で利用可能になるまでに、遅延が発生することがあります。これにより、未完了のトランザクションが適切に完了できなくなり、さらにはデータベース内でデータのロックが発生することがあります。このような遅延発生の可能性を防ぐために、WebLogic Server には Oracle RAC に対する XA 呼び出しの再試行を有効にする 2 つのコンフィグレーション属性、XARetryDurationSeconds と XARetryIntervalSeconds が用意されています。
XARetryDurationSeconds では、保留中のトランザクションの XA 操作 (回復、コミット、ロールバックなど) の再試行を繰り返す間隔を指定します。XARetryIntervalSeconds では、設定した期間内に再試行する頻度を指定します。
XA 呼び出しの再試行を有効にするには、Oracle RAC インスタンスに接続する WebLogic ドメイン内のすべての JDBC 接続プールに、XARetryDurationSeconds の値を追加します。たとえば、次のように指定します。
<JDBCConnectionPool
Name="oracleRACPool"
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
...
XARetryDurationSeconds=480
/>
注意 : XARetryDurationSeconds は、Administration Console で設定できます。この機能を有効にするには、手動で config.xml ファイルを編集するか、weblogic.Admin コマンドライン ユーティリティまたは JMX プログラムを使用してコンフィグレーションを変更します。
XARetryDurationSeconds: の値は、以下の公式に従って決定します。
XARetryDurationSeconds = (接続プールからの接続を利用するトランザクション群のトランザクション タイムアウトのうち最長の時間) + (XID がすべての RAC ノードで利用可能になるまでの遅延時間、通常 5 分未満)
たとえば、アプリケーションで設定されている最長のトランザクション タイムアウトが 180 秒の場合には、XARetryDurationSeconds を 180 秒 + 300 秒の合計、つまり 480 秒に設定します。
注意 : 一般に XARetryDurationSeconds は、すべてのトランザクションが適切に完了するように、必要とされる最小限の時間よりも長めに設定した方がよいでしょう。最小限必要な時間より大きな値を設定しても、通常の運用時であればアプリケーションのパフォーマンスには影響しません。この追加された処理は、準備状態にあるが完了に失敗したトランザクションにのみ影響します。
必要に応じて、XARetryIntervalSeconds 属性にも値を設定できます。この値は、XA 呼び出しの再試行の間隔を決定します。デフォルトでは、この値は 60 秒です。値を小さくすると、XA の再試行の間隔が短くなります。ほとんどの場合は、デフォルト値で十分です。
ノードに障害が発生した場合、データベースに対する処理中のトランザクションには何が起こるのでしょう。プライマリ Oracle RAC ノードに障害が発生した場合はどうでしょうか。WebLogic Server では、透過的なフェイルオーバはサポートされていますか。こうした疑問や WebLogic Server での障害処理に関するその他の質問への回答として、トランザクション処理の段階を順を追って説明し、その中で各段階での障害の処理方法について解説します。
最初に障害が発生する可能性のある段階は、アプリケーションでトランザクションをコミットする呼び出しを行う前です。データベースまたは RAC ノードにこの段階で障害が発生すると、アプリケーションは例外を受け取ります。アプリケーションでは新しい接続を取得して、新たにトランザクションの処理を試行する必要があります。WebLogic Server では透過的なフェイルオーバはサポートされていません。
アプリケーションでトランザクションをコミットする呼び出しを行った後で障害が発生した場合、処理中の任意のトランザクション処理は PREPARE 操作が完了しているかどうかによって変わります。PREPARE 操作が完了していない場合、トランザクション マネージャによってトランザクションはロールバックされ、アプリケーションにトランザクション障害の例外が送出されます。PREPARE 操作が完了している場合、トランザクション マネージャでは別のノードを使用して処理中のトランザクションを完了しようとします。
COMMIT 操作の間に障害が発生した場合、トランザクション マネージャでは COMMIT 操作を複数回、再試行します。この複数回の試行中、接続はブロックされます。COMMIT 操作が再試行の最初のセットで成功しない場合、アプリケーションは例外を受け取ります。トランザクション マネージャでは、成功するまで定期的に COMMIT 操作の再試行が続けられます。破棄までの期間中にトランザクションが正常に完了できない場合、トランザクションはヒューリスティックに完了させられます。
マルチプールを使用して WebLogic Server と複数の Oracle RAC ノードを接続するには、まず RAC クラスタ内の各 RAC インスタンスに、Oracle Thin Driver と共に JDBC 接続プールをコンフィグレーションします。続いて、ロード バランシングのアルゴリズムまたは高可用性のアルゴリズムを使用してマルチプールをコンフィグレーションし、そのマルチプールに接続プールを追加します。
注意 : WebLogic Server ではマルチプールと JMS JDBC ストアの併用はサポートされていません。アプリケーションで JMS JDBC ストアを利用する場合は、接続時フェイルオーバで Oracle RAC を使用するように JMS JDBC ストアをコンフィグレーションする必要があります。詳細については、「Oracle RAC での接続時フェイルオーバの使用」を参照してください。
図 A-3 に一般的なマルチプールのコンフィグレーションを示します。
Administration Console、または、ドメインのコンフィグレーションによく用いる他の方法 (weblogic.Admin コマンドライン ユーティリティ、Weblogic Scripting Tool (WLST)、JMX プログラムなど) を使用できます。WebLogic JDBC マルチプールのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「マルチプールのコンフィグレーション」を参照してください。
このコンフィグレーションでデータベース接続を使用するには、アプリケーションで JNDI ツリー上のデータ ソースをルックアップして、そのデータ ソースから接続を要求します。データソースではマルチプールと通信し、そのマルチプールによって、コンフィグレーションで指定されたアルゴリズムの種類 (高可用性またはロード バランシング) に基づき、接続リクエストに応えるために使用する接続プールが決定されます。
マルチプールには、使用するシステムでの RAC の役割 (ロード バランシングまたはフェイルオーバ) によって、次の属性のいずれかを指定できます。
AlgorithmType="Load-Balancing" または AlgorithmType="High-Availability" FailoverRequestIfBusy="true" HealthCheckFrequencySeconds="240" このコンフィグレーションでは、マルチプールによってトランザクションが必ず 1 つの Oracle RAC インスタンスに「固定」され、RAC インスタンスが利用不可能になった場合には、マルチプール レベルでフェイルオーバが処理されます。PREPARE 操作の前に、RAC インスタンスに障害があった場合、再試行の期間が時間切れになるまでこの操作が再試行されます。PREPARE 操作の後に障害があった場合は、トランザクションは別のインスタンスにフェイルオーバされます。
マルチプール内の XA 接続プールには、以下のルールが適用されます。
マルチプール内の各接続プールには以下の属性を指定する必要があります。
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
URL="jdbc:oracle:thin:@db_server1:1521:SNRAC1"
KeepXAConnTillTxComplete="true" XARetryDurationSeconds="300"CountOfTestFailuresTillFlush="1" TestConnectionsOnReserve="true"TestTableName="name_of_small_table" 物理データベース接続のテストに使用されるテーブルの名前。この属性の詳細については、Administration Console オンライン ヘルプの「[JDBC 接続プール] --> [コンフィグレーション] --> [接続]」を参照してください。 config.xml ファイルにおける、接続プール、WebLogic JDBC マルチプール、および関連データ ソースの例は次のようになります。
<JDBCConnectionPool
CapacityIncrement="1"
ConnLeakProfilingEnabled="true"
CountOfTestFailuresTillFlush="1"
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
InitialCapacity="5"
KeepXAConnTillTxComplete="true"
MaxCapacity="100"
Name="jdbcXAPool1"
PasswordEncrypted="{3DES}lBifoTsg8fc="
Properties="user=wlsqa"
RefreshMinutes="1" SupportsLocalTransaction="true"
Targets="WLSCluster"
TestConnectionsOnReserve="true"
TestTableName="dual"
URL="jdbc:oracle:thin:@db_server1:1521:SNRAC1"
XAEndOnlyOnce="true"
XARetryDurationSeconds="300"
XASetTransactionTimeout="true"/>
XATransactionTimeout="302"/>
<JDBCConnectionPool
CapacityIncrement="1"
ConnLeakProfilingEnabled="true"
CountOfTestFailuresTillFlush="1"
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
InitialCapacity="5"
KeepXAConnTillTxComplete="true"
MaxCapacity="100"
Name="jdbcXAPool2"
PasswordEncrypted="{3DES}lBifoTsg8fc="
Properties="user=wlsqa"
RefreshMinutes="1"
SupportsLocalTransaction="true"
Targets="WLSCluster"
TestConnectionsOnReserve="true"
TestTableName="dual"
URL="jdbc:oracle:thin:@db_server2:1521:SNRAC2"
XAEndOnlyOnce="true"
XARetryDurationSeconds="300"
XASetTransactionTimeout="true"/>
XATransactionTimeout="302"/>
<JDBCMultiPool
Name="jdbcXAMultiPool1"
PoolList="jdbcXAPool1,jdbcXAPool2"
Targets="WLSCluster"
AlgorithmType="Load-Balancing"/>
<JDBCTxDataSource
JNDIName="jdbcXADataSource1"
Name="jdbcXADataSource1"
PoolName="jdbcXAMultiPool1"
Targets="WLSCluster"/>
以下の節では、グローバル トランザクションを必要としないアプリケーションにおいて、マルチプールで Oracle RAC を使用するコンフィグレーションについて説明します。
DriverName="oracle.jdbc.OracleDriver"
URL="jdbc:oracle:thin:@db_server1:1521:SNRAC1"
TestConnectionsOnReserve="true"TestTableName="name_of_small_table" config.xml ファイルにおける、接続プール、WebLogic JDBC マルチプール、および関連データ ソースの例は次のようになります。
<JDBCConnectionPool
Name="oracleRACPool_1"
DriverName="oracle.jdbc.OracleDriver"
InitialCapacity="5"
MaxCapacity="100"
Password="{3DES}I5fj3vh4+nI="
Properties="user=SCOTT"
RefreshMinutes="5"
TestConnectionsOnReserve="true"
TestTableName="dual"
Targets="myWebLogicCluster"
URL="jdbc:oracle:thin:@dbhost1:1521:dbservice"
/>
<JDBCConnectionPool
Name="oracleRACPool_2"
DriverName="oracle.jdbc.OracleDriver"
InitialCapacity="5"
LoginDelaySeconds="1"
MaxCapacity="5"
Password="{3DES}I5fj3vh4+nI="
Properties="user=SCOTT"
RefreshMinutes="5"
TestConnectionsOnReserve="true"
TestTableName="dual"
PreparedStatementCacheSize="15"
Targets="myWebLogicCluster"
URL="jdbc:oracle:thin:@dbhost2:1521:dbservice"
/>
<JDBCMultiPool
AlgorithmType="Load-Balancing"
Name="MyJDBCMultiPool"
HealthCheckFrequencySeconds="300"
PoolList="oracleRACPool_1,oracleRACPool_2"
Targets="myWebLogicCluster"
/>
<JDBCDataSource
JNDIName="oracleRACDataSource"
Name="oracleRACDataSource"
PoolName="MyJDBCMultiPool"
Targets="myWebLogicCluster"
/>
使用しているアプリケーションでマルチプールを選択できず (マルチプールの利用をサポートしていない JMS JDBC ストアの使用時など)、ロード バランシングが必要でない場合は、接続時フェイルオーバを使用するように接続プールをコンフィグレーションできます。
接続時フェイルオーバを行うようにコンフィグレーションされた接続プールを使用して、WebLogic Server と複数の Oracle RAC ノードを接続するには、RAC クラスタ内の各 RAC インスタンスに、Oracle Thin Driver と共に JDBC 接続プールをコンフィグレーションします。以下の節の説明に従い、接続時フェイルオーバを使用するように各接続プールをコンフィグレーションします。図 A-4 に、システムの概要を示します。
図 A-4 Oracle Thin Driver の接続時フェイルオーバを使用した接続プールのコンフィグレーション
JDBC 接続プールは、Administration Console を使用して作成するか、普段ドメインをコンフィグレーションしている方法 (weblogic.Admin コマンドライン ユーティリティ、Weblogic Scripting Tool (WLST)、JMX プログラムなど) で作成できます。
接続プールに接続が作成されると、Oracle Thin Driver によって使用する Oracle RAC インスタンスが決定されます。アプリケーションでは接続を取得すると、JNDI ツリーでデータ ソースをルックアップして、データ ソースから接続を要求します。基底の接続プールから、利用可能な接続が 1 つ提供されます。
以下の節では、コンフィグレーションのオプションと要件について説明します。
以下の節では、Oracle RAC の接続時フェイルオーバ機能を使用して接続の失敗を処理するコンフィグレーションについて説明します。このコンフィグレーションでは、障害のケースによって、フェイルオーバにかかる時間が TCP タイムアウトと同じ長さになる場合もあります。これは環境により数分間に及ぶ場合があります。
このコンフィグレーションを使用するには、以下の属性で WebLogic ドメインに JDBC 接続プールを作成します。
DriverName="oracle.jdbc.OracleDriver"
URL="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost1)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost2)(PORT=1521))
(FAILOVER=on)(LOAD_BALANCE=off))(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=dbservice)))"
CountOfTestFailuresTillFlush="1" TestConnectionsOnReserve="true"TestTableName="name_of_small_table" 物理データベース接続のテストに使用されるテーブルの名前。この属性の詳細については、Administration Console オンライン ヘルプの「[JDBC 接続プール] --> [コンフィグレーション] --> [接続]」を参照してください。必要に応じて、ConnectionReserveTimeoutSeconds 属性を使用してタイムアウト値を設定できます。この値により、接続が利用可能になるまでアプリケーションが待機する時間の上限を決定できます。たとえば、次の文では、タイムアウト値が 120 秒に設定されます。
ConnectionReserveTimeoutSeconds="120"
<JDBCConnectionPool Name="jdbcPool2"
Targets="JdbcRacCluster"
DriverName="oracle.jdbc.OracleDriver"
URL="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST=dbhost1)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost2)(PORT=1521))
(FAILOVER=on) (LOAD_BALANCE=off))
(CONNECT_DATA = (SERVER=DEDICATED) (SERVICE_NAME =dbservice)))"
InitialCapacity="10"
MaxCapacity="100"
CapacityIncrement="1"
Password="tiger"
Properties="user=scott"
PreparedStatementCacheSize="15"
ConnLeakProfilingEnabled="true"
TestTableName="dual"
TestConnectionsOnReserve="true"
CountOfTestFailuresTillFlush="1" />
<JDBCDataSource Name="jdbcDataSource2"
Targets="JdbcRacCluster" `
JNDIName="jdbcDataSource2"
PoolName="jdbcPool2" />
XA を接続時フェイルオーバのコンフィグレーションと共に使用するには、Oracle 9i RAC を使用している必要があります。接続プールに接続が作成されると、Oracle Thin Driver によって使用する Oracle 9i RAC インスタンスが決定されます。アプリケーションでは接続を取得すると、JNDI ツリーでデータ ソースをルックアップして、データ ソースから接続を要求します。基底の接続プールから、利用可能な接続が 1 つ提供されます。
このコンフィグレーションでは、障害のケースによって、フェイルオーバにかかる時間が TCP タイムアウトと同じ長さになる場合もあります。これは環境により数分間に及ぶ場合があります。
このコンフィグレーションを使用するには、以下の属性で WebLogic ドメインに JDBC 接続プールを作成します。
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
URL="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost1)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost2)(PORT=1521))
(FAILOVER=on)(LOAD_BALANCE=off))(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=dbservice)))"
KeepXAConnTillTxComplete="true" XARetryDurationSeconds="300"注意 : この属性は今のところ Administration Console では利用できません。weblogic.Admin コマンドライン ユーティリティ、Weblogic Scripting Tool (WLST)、JMX プログラムなどの方法を使用して設定する必要があります。
CountOfTestFailuresTillFlush="1" TestConnectionsOnReserve="true"TestTableName="name_of_small_table" 物理データベース接続のテストに使用されるテーブルの名前。この属性の詳細については、Administration Console オンライン ヘルプの「[JDBC 接続プール] --> [コンフィグレーション] --> [接続]」を参照してください。必要に応じて、ConnectionReserveTimeoutSeconds 属性を使用してタイムアウト値を設定できます。この値により、接続が利用可能になるまでアプリケーションが待機する時間の上限を決定できます。たとえば、次の文では、タイムアウト値が 120 秒に設定されます。
ConnectionReserveTimeoutSeconds="120"
config.xml ファイルの接続プールおよび関連データ ソースの例は次のようになります。
<JDBCConnectionPool
Name="oracleRACPool"
DriverName="oracle.jdbc.xa.client.OracleXADataSource"
InitialCapacity="5"
LoginDelaySeconds="1"
MaxCapacity="5"
Password="{3DES}I5fj3vh4+nI="
Properties="user=SCOTT"
CountOfTestFailuresTillFlush="1"
KeepXAConnTillTxComplete="true"
XARetryDurationSeconds="300"RefreshMinutes="5"
TestConnectionsOnReserve="true"
TestTableName="dual"
XASetTransactionTimeout="true"
StatementCacheSize="15"
Targets="myWebLogicCluster"
URL="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost1)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost2)(PORT=1521))
(FAILOVER=on)(LOAD_BALANCE=off)(CONNECT_DATA=(SERVER=DEDICATED)
(SERVICE_NAME=dbservice)))"
/>
<JDBCTxDataSource
JNDIName="oracleRACDataSource"
Name="oracleRACDataSource"
PoolName="oracleRACPool"
Targets="myWebLogicCluster"
/>
Oracle 9i RAC で XA (グローバル トランザクション) を使用する際は、以下の要件および制限を考慮する必要があります:
このコンフィグレーションでは、Oracle Thin Driver の接続時フェイルオーバを使用して「グローバル トランザクションを利用しない場合の接続時フェイルオーバの使用」に説明されているようにデータベース接続を作成する必要があります。
XA を使用する場合には、Oracle 9i RAC が以下の要件を満たしている必要があります。
グローバル トランザクションは、RAC クラスタの同じインスタンスで開始、準備、終了する必要があります。これは、JDBC 接続プールのコンフィグレーションで KeepXAConnTillTxComplete="true" を設定すると、WebLogic Server の接続プールによって管理されます。
注意 : WebLogic Server では、Oracle RAC を使用できるようにするため、Oracle Thin Driver の接続時フェイルオーバ機能を使用しています。Oracle の Technical Note 235118.1 で説明されているように、Oracle Thin Driver でロード バランシングをコンフィグレーションした場合、トランザクションの開始と終了が同じ RAC インスタンスで行われるかどうかは保証されません。Oracle RAC では、グローバル トランザクション内のすべてのデータベース操作が同じ Oracle インスタンスにルーティングされる必要があるため、この確認済みの制限があることで、XA と Oracle RAC を併用する場合に接続レベルのロード バランシングは使用できないことになります。結果として、プライマリ/プライマリの RAC コンフィグレーションは使用できません。
グローバル トランザクションを利用する場合は、トランザクション ID (XID) が RAC クラスタ内でユニークになっている必要があります。しかし、Oracle Thin ドライバや Oracle RAC インスタンスでは、RAC クラスタ内で XID がユニークになっているかどうかを識別できません。同じ XID のトランザクションが複数存在すると、SQL コードが RAC クラスタの別々のインスタンスで実行されるおそれがあり、その場合でも例外は送出されません。
WebLogic Server トランザクション マネージャは、ユニークなトランザクション ID を生成します。しかし、フェイルオーバが発生した場合には、トランザクションが発信側インスタンスでなく RAC インスタンスで継続されてデータに矛盾が生じるおそれがあります。「障害発生時に、完了したトランザクションに矛盾 (データの消失) が生じる可能性」を参照してください。
以下の節では、Oracle RAC と共に XA および WebLogic Server を使用する場合の既知の問題や制限について説明します。
注意 :これらの制限事項の一部は、Oracle バグ番号 3428146 および 395790 でも説明されています。これらの問題の詳細については、Oracle にお問い合わせください。
マルチプールが使用されていない場合、障害発生時に、トランザクションを開始したインスタンス以外の RAC インスタンスで発生したトランザクション処理 (データの変更) が、通知や例外が送出されることなく消失することがあります。
たとえば、次のような WebLogic Server コンフィグレーションを考えてみます。
server1 と server2) がある。ds1 がこのクラスタに割り当てられている (このデータ ソースと同一のインスタンスが、クラスタ内のすべてのインスタンス上に存在している)。cp1 が Oracle RAC クラスタに接続するようにコンフィグレーションされていて、接続時フェイルオーバが有効になっている。RAC1 がプライマリ RAC インスタンスとして、RAC2 がセカンダリ RAC インスタンスとして設定されている。cp1 がこのクラスタに割り当てられている (この接続プールと同一のインスタンスが、WebLogic クラスタ内のすべてのノード上に存在している)。結果 : RAC1 でのデータ変更はコミットされます。RAC 2 でのデータ変更は無視されます。WebLogic Server トランザクション マネージャは、このリソースに対して prepare と commit を呼び出します。このケースでは、接続プールの名前が同じであるためこれらが同じリソースとみなされ、呼び出しは接続プールの 1 つのインスタンスに対してのみ行われます。これらの接続プールには別々の RAC インスタンスへの接続が含まれているため、一方の RAC インスタンスでのデータ変更はコミットされますが、もう一方の RAC インスタンスでのデータ変更は消失します。
回避策 : ネットワーク障害を回避するため、WebLogic Server インスタンスと Oracle RAC インスタンスの間に余分なネットワーク ハードウェアを供給します。
RAC クラスタにおいてトランザクション ID が利用できなくなる時間帯があります。これは Oracle の既知の制限です。この制限が原因で、障害発生時に一部の未完了トランザクションが正しく完了されない場合があり、結果としてデータベースでデッドロックが発生するおそれがあります。BEA では、8.1 SP4 でこの問題を回避するためのパッチを提供しています。WebLogic Server および XA と共に Oracle RAC を使用する場合は、WebLogic Server 8.1 SP4 に移行してこのパッチを使用することをお勧めします。
Oracle データベース コントロールを使用する場合、トランザクション処理の順番は保証されていません。たとえば、データベース コントロールを使用するウェブ サービスを実装する場合、次のトランザクション シーケンスに従います：
表の作成後にプライマリ ノードが一時的に停止する場合、データ ベースに送信されたトランザクションがシーケンス通りに実行されない可能性があります。
トランザクションの処理中に、PREPARE 操作は完了したがその結果がトランザクション ログに書き込まれていない時点で、データベース サーバ インスタンスがクラッシュした場合、そのトランザクションに対するクライアントからの COMMIT 呼び出しが数分間に渡ってハングすることがあります (TCP タイムアウト期間が経過するまでハングが続く場合もあります)。この事態が発生する時間帯は短く、問題が起こることはまれです。現時点でこの問題の回避策はありません。
JMS JDBC ストアと Oracle RAC を併用している場合、Oracle RAC ノードのフェイルオーバに関して考慮する必要のある機能と制限があります。以下の節を参照してください。
JMS JDBC ストアのしくみでは、Oracle RAC で使用するためにコンフィグレーションできるオプションが制限されています。JMS JDBC ストアは接続を失敗するまで保持し、失敗した時点で次の接続を取得し、その処理を繰り返します。したがって、JMS JDBC ストアではロード バランシングを実装できません。また、JMS JDBC ストアは、マルチプールをサポートしません。唯一残る、選択可能なコンフィグレーションは、グローバル トランザクションを利用しない接続時フェイルオーバを使用するものです。このコンフィグレーション オプションの詳細については、「グローバル トランザクションを利用しない場合の接続時フェイルオーバの使用」を参照してください。
JMS には制限された接続再試行のメカニズムがあります。このメカニズムによって、JMS はそのデータベース接続をホストする RAC ノードの障害に対して、特に通知することなく対応できます。データベースで、ネットワークの軽微な「一時的中断」、または別のノードにフェイルオーバした RAC データベースに遭遇した場合、2 度目の接続の試み (再試行) によって次の RAC ノードの対応が引き継がれます。
再試行が行われる時間、および実施される再試行の数は、制限されています。これは、接続の再試行時間が長期化することによるネガティブな影響を最小限に抑えるためです。長い期間、データベース接続が利用できない状態のままだと、遅延により JMS 機能の適切な処理 (たとえば、正しいメッセージの順序の維持など) の続行が妨げられることがあります。さらに、この期間内の処理の進行が不十分な場合、トランザクション マネージャによってトランザクションの JMS リソースが応答なしと判断されることがあり、メモリ不足の状態が発生することもあります。RAC のフェイルオーバ時間の単位を最小限に抑えるために役立つシステム レベルのチューニング ガイドラインがあります。このガイドラインは、自動での再試行を成功させるために重要です。
自動での再試行を緊密なループで行うことは、JMS の処理にトランザクションを伴う場合に特に重要です。JMS JDBC ストアで I/O 障害が発生すると、ストア レコードが不明な状態になり、それによってメッセージ自体も不明な状態に置かれます。メッセージがこの不明な状態のままコミットされないように、JMS ではそのメッセージに関連するトランザクションを「failedTransaction」とマークします。トランザクション マネージャで、これ以降にこのメッセージのコミットを完了するどのような試みがなされた場合にも、JMS では javax.transaction.xa.XAException が送出され、errorCode が XAException.XAER_RMERR に設定されます。この例外は、トランザクション マネージャに対して、リソース マネージャ (JMS) に一時的なエラーが発生していること、およびトランザクション マネージャでコミット処理を再試行する必要があることを示すものです。この再試行ロジックにより、JMS が上部レイヤに (RMERR に変化する) どのような障害をも通信する以前に、接続を確立するための 2 番目の試行が実施されます。RMERR が生成された場合、その後でメッセージを回復してトランザクションを完了するには、JMS サーバを手動で再起動するのが唯一の方法です。「手動での再試行」を参照してください。
注意 : 実行中には JMS サーバを再起動できないので、WebLogic サーバを再起動しなければならない場合もあります.WebLogic サーバの再起動が好ましくない状況では、JDBC ストアのかわりにファイル ストアを選択できます。詳細ついては、Administration Console オンライン ヘルプの「JMS: コンフィグレーション」で「JMS ストアのタスク」を参照してください。
自動での再試行ロジックは、現在の WebLogic Server では次のようなオプションで管理されています。
-Dweblogic.jms.store.JMSJDBCIORetryDelay=X
ここで、X は、データベースへの接続が再試行されるまでに経過する必要のある秒数です。デフォルトでは 1 秒です。この値は、0 から 15 に制限されていて、再試行は 1 回だけ行われます。2 番目の試行で障害が発生すると、例外がコール スタックに伝播されます。この場合、失敗したトランザクションに関連するメッセージを回復するには手動での再起動が必要になります。
注意 : XAException.XAER_RMERR が引き続き送出される場合は、JMSJDBCIORetryDelay を大きい数字に設定してみてください。
ある種のテスト シナリオのデータでは、特定のノードに障害が発生した際に、新しい RAC ノードで (トランザクション データを含む) すべてが完全に転送され操作可能になるためには、さらに長い時間が必要になる場合があると示されています。この時間が JMS の自動再試行ロジックの最大経過時間を超過している場合、現在の設計ではある種の手動による介入が発生することを想定しています。手動による介入で JMS サーバを再起動することで、JMS サーバで再び処理が開始され、その仕様とコンフィグレーションに従ってメッセージが配信および回復されます。以下に、JMS サーバを手動で再起動できる 2 つの方法を示します。
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic get -type JMSServer -property Name
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic invoke -mbean "Server mbean name from above command" -method removeDeployment "jms server mbean name from above command"
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic invoke -mbean "Server mbean name from above command" -method addDeployment "jms server mbean name from above command"
汎用ファイル システムの異常が、ファイル ストアの可用性に影響する場合があります (たとえば、ディスク クラッシュ、ディスク フルなど)。こうした問題の発生を軽減するには、デュアル ポート SCSI ディスク、RAID 配列、場合によっては SAN などの、データ冗長性のスキームを使用します。
|
|
|