| Oracle® Fusion Middleware Oracle WebLogic Server 10.3.6 JDBCデータ・ソースの構成と管理 11gリリース1 (10.3.6) B60997-14 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server 10.3.6 JDBCデータ・ソースの構成と管理 11gリリース1 (10.3.6) B60997-14 |
|
前 |
次 |
この章では、WebLogic Server 10.3.6ドメインにあるJDBCデータ・ソースの接続プール属性を適切にチューニングして、アプリケーションおよびシステムのパフォーマンスを向上させる方法について説明します。
この章には次の項が含まれます:
アプリケーションまたはEJBでプリコンパイルされた文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバー間の通信処理、およびデータベース・サーバー上での通信処理に相当なオーバーヘッドが発生します。処理コストを最小限に抑えるには、アプリケーションで使用されるプリコンパイルされた文およびコール可能文をWebLogic Serverでキャッシュできます。アプリケーションまたはEJBが、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Serverはキャッシュ内に格納されている文を再利用します。プリコンパイル文およびコール可能文を再利用することで、データベース・サーバーのCPU使用率が低下します。その結果、現在の文のパフォーマンスが向上し、CPUサイクルを他のタスクに割り当てられるようになります。
データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されますが、文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。
文キャッシュのタイプ: 文キャッシュにどの文を格納するかを決定するアルゴリズム。「文キャッシュのアルゴリズム」を参照してください。
文キャッシュ・サイズ: 接続ごとにキャッシュに格納する文の数。デフォルト値は10です。「文キャッシュ・サイズ」を参照してください。
管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースの文キャッシュの構成に関する項を参照してください。
文キャッシュのタイプ(またはアルゴリズム)は、データ・ソース内の接続ごとにキャッシュに格納するプリコンパイルされた文またはコール可能文を決定します。次のオプションから選択できます:
LRU(最近最も使用されていない、デフォルト)を文キャッシュのタイプとして選択した場合、WebLogic Serverでは、文キャッシュ・サイズに達するまで、プリコンパイルされた文およびコール可能文がキャッシュされます。アプリケーションがConnection.prepareStatement()をコールすると、WebLogic Serverでは、文が文キャッシュに格納されているかどうかが確認されます。格納されている場合は、キャッシュされた文が返されます(その文がまだ使用されていない場合)。文がキャッシュ内に存在せず、キャッシュがいっぱいの場合は(キャッシュ内の文の数=文キャッシュ・サイズ)、WebLogic Serverはキャッシュ内のどの文が最近最も使用されていないかを判別して、キャッシュ内のその文を新しい文に置換します。
WebLogic ServerにおけるLRU文キャッシュのアルゴリズムでは、近似LRUスキームが使用されます。
FIXEDを文キャッシュのタイプとして選択した場合、WebLogic Serverでは、文キャッシュ・サイズに達するまで、接続時に使用されたプリコンパイルされた文およびコール可能文がキャッシュされます。追加の文を使用した場合、それらの文はキャッシュされません。
この文キャッシュのアルゴリズムを使用すると、ほとんど使用されない文が誤ってキャッシュされることがあります。通常は、LRUアルゴリズムが優先されます。その理由は、めったに使用しない文は最終的にキャッシュ内でよく使用される文に置換されるためです。
「文キャッシュ・サイズ」属性によって、データ・ソースのインスタンス別に、接続ごとにキャッシュするプリコンパイルされた文とコール可能文の合計数が決まります。文をキャッシュすることによって、システム・パフォーマンスの向上を図ることができます。ただし、開いているプリコンパイルされた文とコール可能文をDBMSでどのように処理するかを検討する必要があります。多くの場合、DBMSには、開いている文ごとにカーソルが保持されています。これは、文キャッシュ内にあるプリコンパイルされた文およびコール可能文に当てはまります。キャッシュする文が多すぎると、データベース・サーバーでのオープン・カーソルの限度を超過する場合があります。
たとえば、サーバー2台に10個の接続をデプロイしているデータ・ソースがあり、文キャッシュ・サイズが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つの基本的なテストが用意されています。
自動テスト: データ・ソースに対するオプションを使用して構成し、データベース接続が常に正常であるようにします。
手動テスト: データ・ソースのトラブルシューティングを実行できます。
次の各項では、自動接続テスト・オプションについて説明します。手動の接続テストの詳細は、「データ・ソースおよびデータベース接続のテスト」を参照してください。
データ・ソースに対する自動テスト・オプションを構成するには、管理コンソールから、またはJDBCConnectionPoolParamsBeanを使用するWLSTによって次のオプションを設定します。
テスト頻度 - (JDBCConnectionPoolParamsBean内のTestFrequencySeconds): この属性は、未使用接続のテスト間の秒数の指定に使用します。WebLogic Serverでは未使用の接続がテストされ、障害のある接続はすべて閉じられて置換されます。テスト対象の表名を設定する必要もあります。
予約時に接続をテスト - (JDBCConnectionPoolParamsBean内のTestConnectionsOnReserve): クライアントに接続する前に、各接続をテストする場合にこのオプションを有効にします。これを有効にすると、リクエストへの応答が若干遅れますが、接続が正常であることが保証されます。テスト対象の表名を設定する必要もあります。
テスト対象の表名 - (JDBCConnectionPoolParamsBean内のTestTableName): この属性は、接続テストで使用する表名の指定に使用します。また、SQLと入力してスペースを1つ続け、テストとして実行するSQLコードを入力することによって、標準テストのかわりに実行するSQLコードを指定することもできます。テスト対象の表名は、データベース接続テストの有効化には必須です。
アイドル・プール接続を信頼する秒数 - (JDBCConnectionPoolParamsBean内のSecondsToTrustAnIdlePoolConnection): このオプションは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であると信頼されて接続テストがスキップされることが問題なしと実証された後の秒数の指定に使用します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル・プール接続を信頼する秒数による接続リクエストの遅延の最小化」を参照してください。
これらのオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 接続: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
接続テスト・オプションの設定手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。
データ・ソース内でデータベース接続をテストする際、WebLogic Serverでは、データ・ソースから接続を予約し、その接続に対して小規模な問合せを実行して、接続をデータ・ソース内のプールに戻します。サーバー・インスタンスによってプール状況に関する統計が追跡されます。追跡される内容は、接続テストの完了に要する時間数、接続を待機している接続数、テスト中の接続数などです。最近のテスト接続動作の履歴を使用して、接続テストが失敗したと判断されるまでサーバー・インスタンスが待機する時間が計算されます。
あるスレッドの接続が通常よりも長くかかっているように思われる場合、サーバー・インスタンスは、異常に長時間のテストが完了するまで、その他のスレッドのテストを遅らせることがあります。そのスレッドの接続テストに時間がかかりすぎている場合(デフォルトでは10秒)、プールはDBMS接続の失敗を宣言して無効になり、予約されていなくても、またはアプリケーションが使用中であっても、すべての接続が強制的に切断されます。
これは非常にまれなケースであり、ネットワーク・ケーブルの切断や、ソケットでコールを実行中のJVMスレッドをロックする可能性のあるその他の問題により発生する果てしなく続く中断により、JVMがOS TCPの限度(通常は10分)に到達するまでブレークできないと判断される可能性を軽減することを意図しています。この方法でプールが無効になると、DBMSへの再接続が定期的に試行されます(デフォルトは5秒ごと)。新しい接続が実行されると、プールが再有効化され、後続の接続リクエストが通常として機能します(ロードの必要に応じてプールが再移入されます)。
テストで使用される問合せは、テスト対象の表名の値によって決定されます。値が表名である場合、問合せはselect 1 from table_nameとなります。テスト対象の表名に、SQLで始まり、その後にスペースと問合せが続く完全問合せが含まれている場合は、データベース接続のテスト時にその問合せが使用されます。
接続がテストに失敗すると、その接続が閉じられて再作成され、その後で新しい接続がテストされます。
接続テストのセマンティクスの詳細は、次の各項で説明します。
データ・ソース内に接続が作成されると、WebLogic Serverでは、テスト対象の表名の値によって定義された問合せを使用して各接続がテストされます。接続は、データ・ソースがデプロイされるときに作成されます。作成のタイミングは、サーバーの起動時、データ・ソースの作成時、接続に対する需要を満たすために容量を増やすとき、あるいは、接続テストに失敗した接続を再作成するときです。
このテストの目的は、新しい接続が実行可能であり、アプリケーションから接続が要求されたときに使用可能であることを確認することです。
テスト頻度が0よりも大きい場合は、アプリケーションによって現在予約されていないプールされた接続が定期的にテストされます。このテストは、テスト対象の表名で定義された問合せに基づいています。接続がテストに失敗すると、その接続が閉じられて再作成され、さらに、新しい接続をテストした後でプールに戻されます。
「予約時に接続をテスト」が有効になっている場合、アプリケーションがデータ・ソースからの接続をリクエストしたときに、「テスト対象の表名」で指定された問合せを使用して接続がテストされ、その後でアプリケーションに接続が渡されます。デフォルト値は有効になっていません。
予約済の接続をテストすると、接続リクエストに対する応答に遅れが生じますが、アプリケーションが接続を取得した時点で接続が実行可能であることが保証されます。「アイドル・プール接続を信頼する秒数」を調整することによって、予約済の接続のテストによる影響を最小限に抑えられます。「アイドル・プール接続を信頼する秒数による接続リクエストの遅延の最小化」を参照してください。
DBMSとの接続が、たとえ瞬間的であっても切断すると、データ・ソース内の一部、またはすべてのJDBC接続が通常は使用できなくなります。データ・ソースが要求時に接続をテストするように構成されている場合、アプリケーションがデータベース接続をリクエストしたときに、接続がテストされ、接続が使用不能であることが検出されて、リクエストを満たすために新しい接続への置換が試みられます。通常は、DBMSがオンライン復旧した時点でリフレッシュ・プロセスが成功します。ただし、場合によっては、また一部の失敗モードでは、使用不能の接続をテストすると遅延が長期化することがあります。
この遅延を最小化するため、WebLogicデータ・ソースには、多数の接続テスト失敗の後にデータ・ソース内のすべての接続を使用不能と見なし、データ・ソース内のすべての接続を閉じるロジックが組み込まれています。すべての接続が閉じられた後でアプリケーションが接続をリクエストした場合、データ・ソースは、はじめに使用不能の接続をテストする必要もなく、接続を作成します。この動作によって、データ・ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小限に抑えられます。
WebLogic Serverでは、データ・ソースに対する「テスト頻度」の設定に基づいて、すべての接続を閉じる前の失敗数が決定されます。
「テスト頻度」が0より大きい場合、すべての接続を閉じる前のテスト失敗数は2に設定されます。
「テスト頻度」が0に設定されている場合(定期テストは無効になります)、すべての接続を閉じる前のテスト失敗数は、データ・ソースの最大容量の25%に設定されます。
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、テストを続けて使用不能の接続の置換を試行します。データベースが使用可能になったときにこの動作によってデータ・ソースが即時に反応できるため、この動作は効果的です。ただし、使用不能のデータベース接続のテストにはネットワークのタイムアウトと同じ時間がかかるため、クライアントに対して長時間の遅延が生じることがあります。
この遅延を最小化するため、WebLogicデータ・ソースには、使用不能の接続を置き換えるために2回連続して失敗した後にデータ・ソースを無効化するロジックが含まれています。アプリケーションが無効化されたデータ・ソースからの接続をリクエストした場合は、接続が使用できないことをクライアントに通知するためにPoolDisabledSQLExceptionがすぐにスローされます。
このように無効になったデータ・ソースに対して、リフレッシュ・プロセスが定期的に実行されます。リフレッシュ・プロセスは次の処理を行います。
サーバー・インスタンスは、データベース・サーバーに対して5秒ごとにヘルス・チェックを実行します。この設定は構成可能ではありません。
サーバー・インスタンスは、データベースのリカバリを認識すると、新しいデータベース接続を作成してデータ・ソースを有効にします。
また、管理コンソールを使用してデータ・ソースを手動で有効にすることもできます。
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、テストを続けて使用不能の接続の置換を試行します。データベースが使用可能になったときにこの動作によってデータ・ソースが即時に反応できるため、この動作は効果的です。ただし、使用不能のデータベース接続をテストして置換を無駄に試行すると、OSネットワークのタイムアウト(分)と同じ時間がかかる場合があるため、クライアントにとって予想される失敗メッセージが得られるまで長時間の遅延が生じることがあります。
|
注意: データ・ソースがマルチ・データ・ソースに追加されている場合、そのマルチ・データ・ソースはデータ・ソースの無効化および再有効化の責任を引き受けます。デフォルトでは、マルチ・データ・ソースは2分ごとに(構成可能)チェックを行い、接続を再確立できるデータ・ソースをすべて再有効化します。 |
大量の非常に短いサイクル(reserve-do_one_query-closeなど)でDBMS接続を使用するアプリケーションの場合、データ・ソースが接続をテストすると、使用サイクルごとに相当量のオーバーヘッドが生じることがあります。接続テストの影響を最小限に抑えるには、JDBCデータ・ソース構成で「アイドル・プール接続を信頼する秒数」属性を設定して、最近使用した、または最近テストしたデータベース接続を信頼して接続テストをスキップします。
データ・ソースに対して「予約時に接続をテスト」が有効になっている場合、アプリケーションがデータベース接続をリクエストすると、データベース接続がテストされた後でアプリケーションに接続が渡されます。「アイドル・プール接続を信頼する秒数」に対して指定された時間内にリクエストが行われた場合、接続はテスト済であるか、アプリケーションにより正常に使用されているため、アプリケーションに接続を渡す前の接続テストはスキップされます。
データ・ソースに対する「テスト頻度」が0より大きい値である場合にも、接続が正常に使用されていて、「アイドル・プール接続を信頼する秒数」に指定された時間内にデータ・ソースに接続が戻されていれば、接続テストはスキップされます。
「アイドル・プール接続を信頼する秒数」の設定手順については、Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのテスト・オプションの構成に関する項を参照してください。
「アイドル・プール接続を信頼する秒数」は、特に通信量が大容量の間にデータベース接続テストによって生じた遅延を最小化することによって、アプリケーションのパフォーマンスを向上できるチューニング機能です。ただし、特に設定値が高すぎる場合は、接続テストの効果が低下する可能性があります。適切な値は、使用環境と、接続が使用できなくなる可能性によって異なります。
接続テスト属性が使用環境に最もよく適合するように設定することをお薦めします。たとえば、アプリケーションでデータベース接続失敗が許容されない場合は、「アイドル・プール接続を信頼する秒数」を0に設定して「予約時に接続をテスト」を有効にし、接続がアプリケーションに渡される前にすべての接続がテストされるようにすることをお薦めします。アプリケーションがデータ・ソースから接続を受け取る際の遅延に影響を受けやすく、使用不能の接続を使用したことによるアプリケーション・エラーを許容できる場合には、「アイドル・プール接続を信頼する秒数」の設定値を高くし、「テスト頻度」の設定値を低くして、「予約時に接続をテスト」を有効にすることをお薦めします。
これらの設定を使用すると、アプリケーションが接続をリクエストするときではなく、接続が使用されていないときに、プール内の接続をテストするデータ・ソースへのアプリケーションの依存度が高くなります。
|
注意: 最終的に、WebLogicが最善を尽くしたとしても、WebLogicでの接続テストが正常に行われた直後、かつアプリケーションが接続を使用する直前に接続が失敗する可能性があります。したがって、すべてのアプリケーションは、使用不能の接続により予想外の例外が発生した場合でも適切に応答できるように作成する必要があります。 |
管理コンソールを使用してデータ・ソースを作成すると、管理コンソールでは、選択したDBMSに基づき、データ・ソースの「テスト対象の表名」属性が自動的に設定されます。「テスト対象の表名」属性は、テスト・オプションの構成方法に応じて、オプションとして定期的に実行される接続テストで、または、接続を作成または予約するときに使用されます。データベースのテストが正常に行われるためには、データ・ソース内にデータベース接続を作成するデータベース・ユーザーがデータベース表へのアクセス権を持っている必要があります。アクセス権がない場合は、ユーザーにアクセス権を付与するか(この変更はDBMSで行います)、または、「テスト対象の表名」属性をユーザーがアクセス権を持つ表の名前に変更します(この変更はWebLogic Server管理コンソールで行います)。
「テスト対象の表名」は、オーバーロードのパラメータです。この最も単純なフォームでは、WLSが接続をテストするために問い合せる表の名前を指定します。これをOracleに関して任意の表("DUAL"など)に設定すると、データ・ソースは問合せselect count(*) from DUALを実行します。この方法で使用する場合は、小規模でめったに更新されない表(できれば、DUALなどのpseudo-table)を選択することをお薦めします。
このパラメータを定義する2番目の方法では、接続をテストするために任意のSQL文字列を実行できるようにします。このオプションを使用するには、パラメータを"SQL"に設定し、さらに目的のSQL文字列を指定します。たとえば、SQL select 1はSQLServerに対して機能します。これは定数を選択する問合せに表を必要としません。このオプションは、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 |
|
進行状況 |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Sybase |
SQL SELECT 1 |
WebLogic JDBCデータ・ソースには「接続作成の再試行間隔」オプション(JDBCConnectionPoolParamsBean内のConnectionCreationRetryFrequencySeconds)が組み込まれていて、データベースへの接続設定を試行する間隔を秒数で指定できます。この値を設定して、データ・ソースの作成時にデータベースが使用できない場合、指定した秒数が経過するたびにプール内における接続作成が再試行され、成功するまで続行されます。このオプションは、サーバー起動時にデータ・ソースが作成されたとき、データ・ソースがデプロイされたとき、または初期容量が増加されたときに作成された接続に適用されます。プール拡張用に作成されたり、プール内の使用不能の接続を置換するために作成された接続には適用されません。
デフォルトでは、「接続作成の再試行間隔」は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データ・ソース: 構成: 接続プール」ページで、「非アクティブ接続タイムアウト」の値を指定します。「非アクティブ接続タイムアウト」の値を設定すると、指定した秒数の間に予約された接続に対してアクティビティが発生しなかった場合、接続がデータ・ソースに強制的に戻されます。0(デフォルト値)に設定した場合、この機能は無効になります。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
実際のタイムアウトは、「非アクティブ接続タイムアウト」の設定値を超過することがあります。内部のデータ・ソース・メンテナンス・スレッドは5秒ごとに実行されます。非アクティブ接続タイムアウト(例: 30秒)に達すると、非アクティブな接続がないかチェックされます。現在のチェックの直前、または前のチェックの直後に予約された接続のタイムアウトを回避するために、サーバーは非アクティブの接続に対して「第2のチャンス」を与えます。次回のチェック時でも接続がまだ非アクティブの場合、その接続はタイムアウトして、データ・ソースに強制的に戻されます。概して、設定値よりも50%多い遅延が生じる可能性があります。
アプリケーションが使用可能な接続の存在しないデータ・ソースから接続を取得しようとすると、データ・ソースに使用可能な接続がないという例外がデータ・ソースからスローされます。このエラーを回避するには、接続リクエストのピーク・ロードの受容に必要なサイズまでデータ・ソースが拡大できることを確認します。データ・ソース内で使用可能な最大接続数を増やすには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページで、データ・ソースの「最大容量」の値を高くします。
JDBCデータ・ソースに対して「文タイムアウト」オプションを指定すると、データ・ソースから予約されたデータベース接続での文の処理時間を制限できます。「文タイムアウト」に値を設定すると、WebLogic Serverでは、java.sql.Statement.setQueryTimeout()メソッドを使用して、指定された時間がJDBCドライバに渡されます。コールが実行され、ドライバから例外がスローされた場合は値が無視されます。ドライバは、警告なくコールをサポートしなかったり、限定的サポートをドキュメント化している場合があります。ドライバのドキュメントをチェックして、予想される動作を確認することをお薦めします。
「文タイムアウト」が-1(デフォルト)に設定されると、文はタイムアウトしません。
このオプションの詳細は、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項を参照してください。
アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Threadプロパティを追加し、その値をtrueに設定します。
Pinned-To-Threadを有効にすると、アプリケーションが実行スレッドを使用して初めて接続を予約するときにデータ・ソースからのデータベース接続がその実行スレッドに固定されます。アプリケーションが接続の使用を終了してconnection.close()をコールすると、接続が実行スレッドに固定されたままになり、データ・ソースに戻されません(コールしない場合は、接続がデータ・ソースに戻されます)。その後、アプリケーションが同じ実行スレッドを使用して接続をリクエストすると、WebLogic Serverによってスレッドで予約済みの接続が提供されます。複数のスレッドが同時に接続を予約しようとする場合に発生する、データ・ソースでのロックの競合がなく、限られた数のデータベース接続から同じ接続を予約しようとするスレッドの競合もありません。
|
注意: このリリースでは、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データ型オブジェクトのラップを無効にするには:
まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
「データ・ソースのサマリー」ページで、データ・ソース名をクリックします。
「構成: 接続プール」タブを選択します。
画面下方向にスクロールし、「詳細」をクリックして詳細な接続プール・オプションを表示します。
「データ型のラップ」で、チェック・ボックスを選択解除してラップを無効にします。
「保存」をクリックします。
これらの変更をアクティブにするには、管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックします。
この変更は即時に有効にはなりません。データ・ソースを再デプロイするか、サーバーを再起動する必要があります。
データ型のラップを無効にするWLSTコード・スニペットは、次のとおりです。
. . . jdbcSR = create(dsname,"JDBCSystemResource"); theJDBCResource = jdbcSR.getJDBCResource(); poolParams = theJDBCResource.getJDBCConnectionPoolParams(); poolParams.setWrapTypes(false); . . .
この変更は即時に有効にはなりません。データ・ソースを再デプロイするか、サーバーを再起動する必要があります。
