| Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11g リリース1 (10.3.6) B60997-05 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 11g リリース1 (10.3.6) B60997-05 |
|
前 |
次 |
この章では、アプリケーションおよびシステムのパフォーマンスを向上させるために、WebLogic ServerドメインのJDBCデータ・ソース内の接続プール属性を適切にチューニングする方法について説明します。
以下の節では、JDBCデータ・ソースの接続プールのチューニング・オプションについて説明します。
アプリケーションまたはEJBでプリペアド文や呼出し可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信およびデータベース・サーバー自体においてかなりの処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WebLogic Serverではアプリケーションで使用するプリペアド文および呼出し可能文をキャッシュできます。アプリケーションまたはEJBが、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Serverはキャッシュ内に格納されている文を再利用します。プリペアド文や呼出し可能文を再利用することで、データベース・サーバーのCPUの使用率が下がり、現在の文のパフォーマンスが向上するため、CPUサイクルを他のタスクに割り当てることができます。
データ・ソースの各接続には、接続に使用するプリペアド文および呼出し可能文のキャッシュが個別に備わっています。しかし、文キャッシュの構成は、データ・ソースごとに行います。つまり、データ・ソース内の各接続の文キャッシュは、そのデータ・ソースについて指定された文キャッシュ・オプションを使用しますが、各接続は、独自に文をキャッシュします。文キャッシュの構成オプションには、次のようなものがあります。
「文キャッシュの種類」 - 文キャッシュ内に格納する文を決定するアルゴリズム。「文キャッシュのアルゴリズム」を参照してください。
文キャッシュ・サイズ - 各接続のキャッシュに格納する文の数。デフォルト値は10です。「文キャッシュ・サイズ」を参照してください。
管理コンソールを使用してデータ・ソース用の文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの文キャッシュの構成を参照してください。
文キャッシュのタイプ(つまりアルゴリズム)は、データ・ソースの各接続のキャッシュに格納するプリペアド文と呼出し可能文を決定します。次のオプションから選択できます。
「LRU」 (Least Recently Used、デフォルト)を文キャッシュのタイプとして選択すると、WebLogic Serverは接続で使用されるプリペアド文および呼出し可能文を、文キャッシュ・サイズに到達するまでキャッシュします。アプリケーションがConnection.prepareStatement()を呼び出すと、WebLogic Serverはその文が文キャッシュに格納されているかどうかを確認します。格納されている場合、WebLogic Serverはキャッシュされていた文を(それがすでに使用されていない場合)戻します。文がキャッシュ内に存在せず、キャッシュが満杯(キャッシュ内の文の数 = 文キャッシュ・サイズ)の場合、WebLogic Serverはキャッシュ内で最近の使用頻度が最も低い既存の文を特定し、キャッシュ内のその文を新しい文と入れ替えます。
WebLogic ServerのLRU文キャッシュ・アルゴリズムは、近似LRU方式を使用します。
「固定」を文キャッシュのタイプとして選択すると、WebLogic Serverは接続で使用されるプリペアド文および呼出し可能文を、文キャッシュのサイズに到達するまでキャッシュします。追加の文が使用された場合、これらはキャッシュされません。
この文キャッシュ・アルゴリズムでは、ほとんど使われない文を意図せずキャッシュしてしまうことがあります。多くの場合、LRUアルゴリズムが使用されます。ほとんど使われない文が、キャッシュ内で最終的には頻繁に使われる文に置き換えられるからです。
「文キャッシュ・サイズ」属性は、データ・ソースの各インスタンスの各接続にキャッシュするプリペアド文と呼出し可能文の総数を決定します。文をキャッシュすることで、システムのパフォーマンスが向上します。ただし、DBMSでオープンなプリペアド文と呼出し可能文がどのように処理されるかを考慮する必要があります。多くの場合、DBMSは開いている各文について、カーソルを保持します。これは、文キャッシュ内のプリペアド文および呼出し可能文に対して適用されます。キャッシュされた文の数が多すぎると、データベース・サーバー上のオープン・カーソル数の上限を超えてしまうことがあります。
たとえば、10個の接続があるデータ・ソースが2つのサーバーにデプロイされている場合、「文キャッシュ・サイズ」を10 (デフォルト値)に設定すると、キャッシュされた文に対してデータベース・サーバー上で200個(10 x 2 x 10)のカーソルを開く可能性があります。
文キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。文キャッシュを使用する場合は、以下の制限に留意してください。
ここに示す以外にも、文のキャッシングに関連した問題が存在する可能性があります。プリペアド文または呼出し可能文に関連するシステムでエラーが見つかった場合は、文キャッシュのサイズを0に設定して文のキャッシングをオフにし、問題がプリペアド文のキャッシングに起因するものかどうかをテストする必要があります。
キャッシュ内に格納されたプリペアド文は、プリペアド文のキャッシュ時に特定のデータベース・オブジェクトを参照します。キャッシュに格納されたプリペアド文で参照されるデータベース・オブジェクトに対して、何らかのDDL (データ定義言語)処理を実行すると、それらの文は次に実行したときに失敗する可能性があります。たとえば、select * from empなどの文をキャッシュしてから、emp表を削除して再作成した場合、その文が準備されたときに存在したemp表はなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。
同様に、プリペアド文は、キャッシュされた時点でデータベース内の表の各列のデータ型にバインドされます。表の列を追加、削除、または再配列すると、キャッシュに格納されているプリペアド文は、再び実行されたときに失敗するおそれがあります。
これらの制限は、DBMSの動作に依存します。
setNullバインド変数を使用するプリペアド文をキャッシュする場合、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、null以外の値で実行したときにデータが切り捨てられたり、文が失敗したりするおそれがあります。
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)
かわりに、次を使用します。
if (sal == null)
setNull(2,long)//This is correct
else
setLong(2,sal)
データ・ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Serverには、2種類の基本的なテスト方法があります。
WebLogic Serverがデータベース接続の正常な状態を確認できるよう、データ・ソースのオプションで構成する、自動テスト。
データ・ソースのトラブルシューティング用に行える、手動テスト。
次の節では、自動接続テストのオプションについて説明します。手動接続テストの詳細については、「データ・ソースおよびデータベース接続のテスト」を参照してください。
データ・ソースの自動テスト・オプションを構成するには、JDBCConnectionPoolParamsBeanを使用してWLSTから、または管理コンソールから次のオプションを設定します。
「テスト頻度」: (JDBCConnectionPoolParamsBeanのTestFrequencySeconds)この属性では、未使用の接続がテストされる秒間隔を指定します。WebLogic Serverは未使用の接続をテストし、フォルトのある接続を閉じ、別の接続に置き換えます。「テスト対象の表名」も設定しておく必要があります。
Test Reserved Connections: (JDBCConnectionPoolParamsBean内のTestConnectionsOnReserve)このオプションを有効にすると、クライアントに与える前に各接続をテストできます。これにより、リクエストに多少の遅延が発生する場合がありますが、接続が正常であることは保証します。「テスト対象の表名」も設定する必要があります。
「テスト対象の表名」: (JDBCConnectionPoolParamsBeanのTestTableName)この属性では、接続テストで使用される表名を指定します。標準的なテストのかわりに、テストとして実行するSQLコードを指定することもできます。「SQL」と入力し、その直後にスペース、次に実行するSQLコードを入力します。「テスト対象の表名」は、データベース接続のテストを有効にするための必須の属性です。
「アイドル・プール接続を信頼する秒数」: (JDBCConnectionPoolParamsBeanのSecondsToTrustAnIdlePoolConnection)このオプションは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であるとWebLogic Serverが信頼し、接続テストをスキップしてもよいと証明されてからの秒数を指定するのに使用します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
接続のテスト・オプションの設定に関する指示については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。
WebLogic Serverはデータ・ソースのデータベース接続をテストする際、データ・ソースからの接続を予約し、接続に対して小さな問合せを実行し、その後データ・ソースのプールに接続を戻します。サーバー・インスタンスは、プールのステータスに関する統計情報(接続テストの所要時間、接続を待機している接続数、テストされた接続数など)を追跡します。最近実施された接続動作テストの履歴は、接続テストが失敗したとサーバー・インスタンスが判断するまでの待機時間を計算するために使用されます。
スレッドの接続に通常よりも時間がかかっている場合、サーバー・インスタンスはそのテストが完了するまで、他のスレッドのテストを遅延させる場合があります。接続テスト中(デフォルトでは10秒)のスレッドのハングが長すぎる場合、プールはDBMSの接続失敗を宣言して自身を無効にし、予約されてない接続も、アプリケーションが使用中の接続も、すべての接続を強制終了します。
これは非常にまれなケースですが、ネットワーク・ケーブルの切断によって引き起こされる無限のハング状態や、ソケット読取りで呼出しを行っているJVMスレッドがロックされ、OSのTCP制限(通常は10分間)に達するまでJVMが解除されなくなるような問題を解決することを意図しています。この方法でプールが自身を無効化した場合、プールは定期的に(デフォルトでは5秒おきに)DBMSに再接続しようとします。新しい接続を作成できた場合、プールは自身を再び有効にして、以降の接続リクエストは通常通りに処理します(プールは負荷の必要性に応じて再び接続を格納します)。
テストで使用する問合せは、「テスト対象の表名」の値によって決定されます。値が表名の場合、問合せはselect 1 from table_nameとなります。「テスト対象の表名」に、先頭がSQLで直後にスペースと問合せが続く完全な問合せが含まれていれば、WebLogic Serverはデータベース接続のテスト時に、その問合せを使用します。
接続がテストに失敗すると、WebLogic Serverは接続を閉じて再作成し、その後、新しい接続をテストします。
接続テストのセマンティクスの詳細については、以下の節で説明しています。
データ・ソース内に接続が作成されると、WebLogic Serverは「テスト対象の表名」の値で定義された問合せを使用して、各接続をテストします。接続の作成は、サーバー起動時かデータ・ソース作成時にデータ・ソースがデプロイされる場合、接続のリクエストを満たすために容量を増大させる場合、または接続テストに失敗した接続を再作成する場合に、行われます。
このテストの目的は、アプリケーションが接続をリクエストしたときに、必ず新しい有効な接続がすぐに使用できるようにしておくことです。
「テスト頻度」が0より大きい場合、WebLogic Serverは現在アプリケーションで予約されていないプール済みの接続を定期的にテストします。テストは、「テスト対象の表名」で定義された問合せに基づいています。接続がテストに失敗した場合、WebLogic Serverは接続を閉じ、接続を再作成し、新しい接続をテストしてから、その接続をプールに戻します。
「予約時に接続をテスト」が有効になっているとき、アプリケーションにデータ・ソースからの接続がリクエストされると、WebLogic Serverはアプリケーションに接続を与える前に「テスト対象の表名」に指定された問合せを使用して接続をテストします。デフォルト値は「無効」です。
「予約された接続のテスト」は、接続リクエストに応じるにあたり遅延を生じさせる可能性がありますが、アプリケーションが接続を取得した時点で、その接続は確実に有効です。「アイドル・プール接続を信頼する秒数」をチューニングすることで、「予約された接続のテス」トの影響を最小限に抑えることができます。「アイドル・プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。
DBMSへの接続がたとえ一瞬でも失われると、通常、データ・ソースにおけるJDBC接続の一部またはすべてが切断されます。データ・ソースが予約時の接続テストを行うように構成されている場合、あるアプリケーションによってデータベース接続がリクエストされると、WebLogic Serverはその接続をテストし、その接続が切断されていることが分かると、リクエストに応えるため、新しい接続と置き換えようとします。通常、DBMSがオンラインに復帰すると、リフレッシュ・プロセスが引き継がれます。ただし、場合によっては、いくつかの障害モードで、切断された接続のテストによって長い遅延状態になる可能性があります。
この遅延を最小限に抑えるため、WebLogicデータ・ソースには、何度か連続してテストが失敗すると、データ・ソース内のすべての接続を切断されているものと見なして閉じるロジックが含まれています。すべての接続が閉じられた後に、アプリケーションが接続をリクエストすると、データ・ソースは先に切断された接続のテストを行うことなく、接続を作成します。この動作によって、データ・ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小化されます。
WebLogic Serverは、データ・ソースの「テスト頻度」の設定に基づいてすべての接続を閉じるまでのテストの失敗回数を決定します。
「テスト頻度」が0より大きければ、すべての接続を閉じるまでのテスト失敗回数は2に設定されます。
「テスト頻度」が0に設定されている(定期テストが無効化されている)場合、すべての接続を閉じるまでのテスト失敗回数は、データ・ソースの「最大容量」の25%に設定されます。
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ・ソースが迅速に対処できるため、有効です。ただし、切断されたデータベースをテストすることによって、ネットワークのタイムアウトが生じ、クライアントに長時間の遅延を強いる可能性があります。
この遅延を最小限に抑えるため、WebLogicデータ・ソースには、2回連続して失敗が生じたらデータ・ソースを無効化して、切断されている接続を置き換えるロジックが含まれています。アプリケーションが、無効化されたデータ・ソースから接続をリクエストすると、即座にPoolDisabledSQLExceptionがスローされ、接続が使用できないことがクライアントに知らされます。
この方法で無効化されたデータ・ソースについては、定期的にリフレッシュ・プロセスが実行されます。リフレッシュ・プロセスでは、次のことが実行されます。
サーバー・インスタンスによる、データベース・サーバーに対する5秒ごとのヘルス・チェック。この設定は構成できません。
サーバー・インスタンスは、データベースが回復されたことを認識すると、新しいデータベース接続を作成してデータ・ソースを有効化します。
また、管理コンソールを使用して手動でデータ・ソースを有効化することもできます。
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ・ソースが迅速に対処できるため、有効です。ただし、切断されたデータベース接続をテストして、無駄に置き換えようとすると、場合によってはOSネットワーク・タイムアウト(分単位)と同程度の時間がかかり、予期される失敗メッセージを取得するまでにクライアントで長時間の遅延を引き起こす可能性があります。
|
注意: データ・ソースをマルチ・データ・ソースに追加している場合は、マルチ・データ・ソースがデータ・ソースの無効化と再有効化を引き継ぎます。デフォルトでは、マルチ・データ・ソースは2分おきにチェックして(この時間は構成可能)、接続を再確立できるデータ・ソースがあれば再有効化します。 |
DBMS接続を非常に短いサイクルで使用するアプリケーションの場合(例:reserve-do_one_query-close)、データ・ソースの接続のテストは各使用サイクルに大量のオーバーヘッドをもたらす可能性があります。接続テストの影響を最小化するには、JDBCデータ・ソース構成の「アイドル・プール接続を信頼する秒数」属性を設定して、最近使用またはテストしたデータベース接続を信頼して接続テストをスキップします。
データ・ソース上で「予約時に接続をテスト」が有効化されている場合、アプリケーションがデータベース接続をリクエストすると、WebLogic Serverはアプリケーションに渡す前にその接続をテストします。接続がテストされるかアプリケーションで正常に使用されてから、「アイドル・プール接続を信頼する秒数」に指定した時間内にこのリクエストが送信された場合は、その接続は接続テストなしでアプリケーションに渡されます。
データ・ソースに対する「テスト頻度」が0より多い(定期テストが有効化されている)場合も、WebLogic Serverは接続が正常に使用されて、「アイドル・プール接続を信頼する秒数」で指定した時間内にデータ・ソースに戻されていれば、接続テストをスキップします。
アイドル・プール接続を信頼する秒数の設定方法については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。
「アイドル・プール接続を信頼する秒数」は、特に大量のトラフィックが発生している場合のデータベース接続テストによる遅延を最小化することで、アプリケーションのパフォーマンスを向上させるチューニング機能です。ただし、あまり高い値を設定した場合などには、接続テストの有効性が失われるおそれがあります。どの程度の値が適切かは、使用している環境や、接続が切断される可能性の高さによって異なります。
接続テストの属性は、環境に最もよく適合するように設定する必要があります。たとえば、アプリケーションがデータベース接続の失敗を許容できない場合は、「アイドル・プール接続を信頼する秒数」を0に設定して確実に「予約時に接続をテスト」を有効化しておき、WebLogic Serverが接続をアプリケーションに渡す前に、毎回その接続のテストを行うようにします。アプリケーションがデータ・ソースから接続を取得する際の遅延に影響を受けやすく、切断された接続の使用によるアプリケーション失敗の可能性を許容できるのであれば、「アイドル・プール接続を信頼する秒数」をより高い数値に、「テスト頻度」を低い数値に設定し、「予約時に接続をテスト」を有効化する必要があります。
これらの設定によりアプリケーションは、アプリケーションが接続をリクエストしたときよりも、プール内の接続が使用されていないときのデータ・ソースの接続テストに依存するようになります。
|
注意: 結局は、WebLogicが最善を尽くした場合でも、WebLogicが接続を正常にテストした後で、アプリケーションがその接続を使用する前に、接続が失敗する可能性はあります。したがって、どのアプリケーションも、切断された接続から予期しない例外が発生した場合に適切に対応するように記述しておく必要があります。 |
管理コンソールを使用してデータ・ソースを作成する場合、管理コンソールは、選択したDBMSに基づき、データ・ソースの「テスト対象の表名」属性を自動的に設定します。「テスト対象の表名」属性は接続テストで使用されます。接続テストは必要に応じて、テスト・オプションの構成により定期的に、または接続を作成、予約、解放したときに実行されます。データベースのテストを正常に実行するためには、データ・ソースのデータベース接続を作成するユーザーが、該当するデータベース表にアクセスできる必要があります。アクセスできない場合には、DBMSを使用してそのユーザーにアクセスを付与するか、WebLogic Server管理コンソールを使用して「テスト対象の表名」属性をユーザーがアクセスを持つ表の名前に変更する必要があります。
「テスト対象の表名」はオーバーロードされるパラメータです。最も単純な形式は、WLSが接続のテストを要求する表を指定することです。Oracleの場合の「DUAL」など、任意の表に設定すると、データ・ソースは「select count(*) from DUAL」のような問合せを実行することになります。このモードで使用する場合は、小さく、頻繁には更新されない表(DUALのような擬似表が望ましい)を選ぶことをお薦めします。
このパラメータを定義するときの2番目の方法は、特定のSQL文字列に接続のテストを実行させることです。この方法を使用するには、パラメータとして、「SQL」 に必要なSQL文字列を加えたもの設定します。たとえば、SQLServerの場合は「SQL select 1」が使用できます(定数を選択する問合せに表を含める必要はありません)。この方法は、WLSのプール接続テストにDBMS側の制御を加えて、テストをできる限り速く行うには便利です。
表10-1 DBMSによる、デフォルトのテスト対象の表名
| DBMS | デフォルトのテスト対象の表名(問合せ) |
|---|---|
|
Adabas for z/OS |
SQL call shadow_adabas('select * from employees') |
|
Cloudscape |
SQL SELECT 1 |
|
DB2 |
SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES |
|
FirstSQL |
SQL SELECT 1 |
|
IMS/TM for z/OS |
SQL call shadow_ims('otm','/dis','cctl') |
|
Informix |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Microsoft SQL Server |
SQL SELECT 1 |
|
MySQL |
SQL SELECT 1 |
|
Oracle |
SQL SELECT 1 FROM DUAL |
|
PostgreSQL |
SQL SELECT 1 |
|
Progress |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Sybase |
SQL SELECT 1 |
WebLogic JDBCデータ・ソースには、データベースへの接続確立を試行する間隔の秒数を指定するのに使用できる、「接続作成の再試行間隔」オプション(JDBCConnectionPoolParamsBeanのConnectionCreationRetryFrequencySeconds)があります。この値を設定して、データ・ソースの作成時にデータベースが使用できない場合、WebLogic Serverは指定した秒数が経過するたびにプール内における接続の作成を再試行し、成功するまで継続します。このオプションは、サーバー起動時にデータ・ソースが作成されたとき、データ・ソースがデプロイされたとき、または初期容量が増大されたときに作成される接続に適用されます。プールを拡張したり、プール内の機能しない接続を置き換えたりする場合に作成される接続には適用されません。
デフォルトでは、「接続作成の再試行間隔(秒)」は0秒です。この値を0に設定すると、接続作成の再試行は無効化され、データベースが使用できなければデータ・ソースの作成は失敗します。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
JDBCデータ・ソースには、データ・ソースからの接続を待機する接続リクエストを有効化するために設定できる、2つの属性があります。「接続予約のタイムアウト」 (ConnectionReserveTimeoutSeconds)および「接続の最大待機数」 (HighestNumWaiters)です。これら2つの属性を一緒に使うと、ブロックするスレッドが多すぎるためにシステムが無効になることなく、接続を待機する接続リクエストを有効化できます。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
また、管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化に関する項も参照してください。
アプリケーションがデータ・ソースからの接続をリクエストしたときにデータ・ソース内の接続がすべて使用中であり、かつデータ・ソースが最大容量まで拡張済みだった場合には、アプリケーションは接続使用不可SQL例外を受け取ります。これを避けるために、接続が利用できるようになるまで接続リクエストが待機するよう、「接続予約のタイムアウト」の値(秒単位)を構成することができます。「接続予約のタイムアウト」の有効期限が切れた後も、利用可能になった接続がなければ、リクエストは失敗し、アプリケーションはPoolLimitSQLException例外を受け取ります。
「接続予約のタイムアウト」を-1に設定すると、利用できる接続がなかった場合、接続リクエストは直ちにタイムアウトします。「接続予約のタイムアウト」を0に設定すると、接続リクエストは無期限に待機します。デフォルト値は、10秒です。
Oracle WebLogic Server管理コンソール・ヘルプの接続を待機する接続リクエストの有効化に関する項を参照してください。
接続を待機する接続リクエストは、スレッドをブロックします。あまりに多くの接続リクエストが同時に接続を待機してスレッドをブロックすると、システムのパフォーマンスが低下する可能性があります。これを回避するには、「接続の最大待機数」 (HighestNumWaiters)属性を設定して、同時に接続を待機できる接続リクエスト数を制限します。
「接続の最大待機数」 (HighestNumWaiters)をMAX-INT (デフォルト)に設定すると、事実上、接続を待機できる接続リクエストに制限はなくなります。「接続の最大待機数」を0に設定すると、接続リクエストは接続を待機できなくなります。最大リクエスト数に到達した場合、アプリケーションが接続をリクエストするとSQLExceptionがスローされます。
リークされた接続とは、適切にデータ・ソースの接続プールに戻されなかった接続のことです。リークされた接続を自動的に回復するには、管理コンソールの「JDBCデータ・ソース」>「構成」>「接続プール」ページで「非アクティブ接続タイムアウト」の値を指定します。「非アクティブ接続タイムアウト」に値を指定すると、予約された接続に対して指定した秒数間アクティビティがない場合、WebLogic Serverは強制的に接続をデータ・ソースに戻します。0 (デフォルト値)に設定すると、この機能は無効になります。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
実際のタイムアウト時間は、「非アクティブ接続タイムアウト」に構成した値より長くなります。内部のデータ・ソース保守スレッドは5秒ごとに実行されます。「非アクティブ接続タイムアウト」値(たとえば30秒)が経過すると、スレッドは非アクティブな接続をチェックします。今回のチェック直前や前回のチェック直後に予約された接続のタイムアウトを回避するため、非アクティブな接続は2回チェックを受けることになっています。2回目のチェック時でも接続がまだ非アクティブである場合、その接続はタイムアウトしたと見なされ、強制的にデータ・ソースに返されます。タイムアウト時間は、構成した値より、平均して約50%遅延します。
アプリケーションで、データ・ソースから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外がスローされます。このエラーを避けるには、データ・ソースのサイズを接続リクエストの最大負荷に対応できるサイズに拡大するようにしてください。データ・ソース内の使用できる接続の最大数を増やすには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページでデータ・ソースの「最大容量」の値を増やします。
JDBCデータ・ソースで「文タイムアウト」オプションを使用すると、データ・ソースからの予約されたデータベース接続に対する文の実行にかかる時間を制限できます。「文タイムアウト」に値を設定すると、WebLogic Serverでは、java.sql.Statement.setQueryTimeout()メソッドを使用して、指定された時間をJDBCドライバに渡します。WebLogic Serverが呼出しを行い、ドライバが例外をスローした場合は、この値は無視されます。場合によっては、ドライバは暗黙的にこの呼出しをサポートしていないか、制限されたサポートがドキュメントに記載されていることがあります。ドライバのドキュメントを確認して、予期しないエラーを検証することをお薦めします。
「文タイムアウト」を -1 (デフォルト値)に設定した場合には、文はタイムアウトしません。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページまたはOracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Threadプロパティを追加し、その値をtrueに設定します。
Pinned-To-Threadが有効化されている場合、WebLogic Serverでは、データ・ソースから実行スレッドまでのデータベース接続が固定されます。これは、アプリケーションでそのスレッドが接続の予約のために最初に使用されるときに実行されます。また、アプリケーションでその接続を利用し終えてconnection.close()が呼び出されたときに、実行スレッドとの接続が保持され、接続はデータ・ソースに返されませんそして、アプリケーションが引続き同じ実行スレッドを使用して接続をリクエストしたときに、すでにそのスレッドで予約されている接続が提供されます。このような方法を取ると、複数のスレッドが同時に接続の予約を試行したときに起こる、データ・ソースでのロックの競合が発生しなくなります。また、限られた数のデータベース接続から同じ接続を予約しようとするスレッド間に競合が発生することもありません。
|
注意: このリリースでは、Pinned-To-Thread機能はマルチ・データ・ソース、Oracle RAC、およびIDプールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続IDが一致しなかった場合に、その接続を再取得する機能に依存しています。 |
Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」を参照してください。
PinnedToThreadを有効にすると接続プーリングの動作の性質が変更されるため、一部の接続プールの属性や機能は、動作の変更に適合するように、通常と異なる動作をしたり、無効化されたりします。
最大容量が無視されます。接続プール内の接続の数は、接続プールから予約されている接続の数または初期容量のいずれか大きな方の値に等しくなります。
接続が接続プールに返されないため、PinnedToThreadが有効化されている場合、縮小は接続プールに適用されません。接続は、効率上、常に予約されます。
接続プールをリセットすると、接続プールからリセットされた接続は、「テストが必要」とマークされます。次に各接続が予約されるときに、その接続は必要に応じてテストおよび再作成されます。接続は、接続プールのリセット時に同期的にテストされません。この機能は、「予約時に接続のテスト」を有効化し、「表名のテスト」または問合せを指定しておく必要があります。
PinnedToThreadを有効にすると、接続プールの最大容量(接続プールに作成されるデータベース接続の最大数)は、接続のリクエストに使われる実行スレッドの数に、各スレッドによって予約される同時接続の数を乗じた数になります。この数は、接続プールに指定された「最大容量」を超える場合があります。システム設計では接続のこの大きな数を考慮し、オープン・カーソルなど、追加の関連リソースについてデータベースで許容されるようにすべき場合があります。
また、接続が接続プールに返されない点にも注意する必要があります - これは、接続プールを縮小して、使用される関連リソースおよび接続の数を減らすことができないことを意味します。このコストは、追加のドライバ・パラメータonePinnedConnectionOnlyを設定することによって最小限に抑えることができます。onePinnedConnectionOnly=trueの場合、リクエストされた最初の接続のみがスレッドに固定されます。スレッドで必要なその他の接続はすべて、必要に応じて接続プールから取得されたり、接続プールに返されます。次に示すように、Properties属性を使用してonePinnedConnectionOnlyを設定します。
Properties="PinnedToThread=true;onePinnedConnectionOnly=true;user=examples"
システムで追加のリソース要件を処理できる場合、PinnedToThreadオプションを使ってパフォーマンスを向上させることをお薦めします。
現在のシステムでは追加のリソース要件を処理できない、またはPinnedToThreadを有効化するとデータベース・リソースでエラーが発生する場合は、PinnedToThreadは使用しないことをお薦めします。
WebLogic Serverから戻されるドライバからのJDBCオブジェクトのいくつかは、デフォルトでラップされています。データ・ソース・オブジェクトをラップすると、WebLogic Serverは次のことができるようになります。
すべてのメソッド呼出しからデバッグ出力を作成します。
接続の適切なタイムアウトのために接続の使用を追跡します。
透明な自動トランザクション登録とセキュリティ認証を提供します。
WebLogic Serverでは、ラッピングを無効にすることが可能です。そのメリットは次のとおりです。
WebLogic Serverは、ラッパーを通して表示するインタフェースを実装するベンダー・メソッドのダイナミック・プロキシを生成しますが、一部インタフェースを実装しないデータ型もあります。たとえば、Oracleデータ型のArray、Blob、Clob、NClob、Ref、SQLXML、およびStructは、インタフェースを実装しないクラスです。ラッピングを無効に設定すると、アプリケーションはネイティブ・ドライバ・オブジェクトを直接使用できるようになります。
ラッピング・オーバーヘッドの削除により、パフォーマンスを著しく向上できます。
ラッピングが無効(wrap-types要素がfalse)の場合、次のデータ型はラップされません。
Array
Blob
Clob
NClob
Ref
SQLXML
Struct
ParameterMetaData
接続テストが実行されません。
ResultSetMetaData
接続テストが実行されません。
結果セット・テストが実行されません。
JDBC MTプロファイリングが実行されません。
管理コンソールやWLSTを使用して、データ型のラッピングを無効にできます。
JDBCデータ型オブジェクトのラッピングを無効にするには:
まだそうしていない場合、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
「ドメイン構造」ツリーで「サービス」を展開し、「データ・ソース」を選択します。
「データ・ソースのサマリー」ページでデータ・ソース名をクリックします。
「構成: 接続プール」タブを選択します。
画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。
Wrap Data Typesで、ラップを無効にするチェックボックスを選択解除します。
「保存」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
この変更はすぐには反映されません。データ・ソースの再デプロイやサーバーの再起動が必要です。
