| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.3.0) E90329-05 |
|
 前 |
 次 |
この章には次の項が含まれます:
キャッシュされた文を再利用すると、データベース・サーバー上のCPU使用量が低減され、現在の文のパフォーマンスが向上します。また、CPUサイクルを別のタスクを行うために使用できます。キャッシュの構成オプションには、「文キャッシュのタイプ」および「文キャッシュ・サイズ」が含まれています。
アプリケーションまたはEJBでプリコンパイルされた文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバー間の通信処理、およびデータベース・サーバー上での通信処理に相当なオーバーヘッドが発生します。処理コストを最小限に抑えるには、アプリケーションで使用されるプリコンパイルされた文およびコール可能文をWebLogic Serverでキャッシュできます。アプリケーションまたはEJBが、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Serverはキャッシュ内に格納されている文を再利用します。プリコンパイル文およびコール可能文を再利用することで、データベース・サーバーのCPU使用率が低下します。その結果、現在の文のパフォーマンスが向上し、CPUサイクルを他のタスクに割り当てられるようになります。
データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されますが、文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。
文キャッシュのタイプ—文キャッシュにどの文を格納するかを決定するアルゴリズム。「文キャッシュのアルゴリズム」を参照してください
文キャッシュ・サイズ—接続ごとにキャッシュに格納する文の数。デフォルト値は10です。「文キャッシュ・サイズ」を参照してください
WebLogic Server管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの文キャッシュの構成を参照してください。
文キャッシュのタイプ(またはアルゴリズム)は、データ・ソース内の接続ごとにキャッシュに格納するプリコンパイルされた文またはコール可能文を決定します。次のオプションから選択できます:
「LRU」 (最近最も使用されていない、デフォルト)を「文キャッシュのタイプ」として選択した場合、WebLogic Serverでは、文キャッシュ・サイズに達するまで、プリコンパイルされた文およびコール可能文がキャッシュされます。アプリケーションがConnection.prepareStatement()をコールすると、WebLogic Serverでは、文が文キャッシュに格納されているかどうかが確認されます。格納されている場合は、キャッシュされた文が返されます(その文がまだ使用されていない場合)。文がキャッシュ内に存在せず、キャッシュがいっぱいの場合は(キャッシュ内の文の数=文キャッシュ・サイズ)、WebLogic Serverはキャッシュ内のどの文が最近最も使用されていないかを判別して、キャッシュ内のその文を新しい文に置換します。
WebLogic ServerにおけるLRU文キャッシュのアルゴリズムでは、近似LRUスキームが使用されます。
「文キャッシュ・サイズ」属性によって、データ・ソースのインスタンス別に、接続ごとにキャッシュするプリコンパイルされた文とコール可能文の合計数が決まります。文をキャッシュすることによって、システム・パフォーマンスの向上を図ることができます。ただし、開いているプリコンパイルされた文とコール可能文をDBMSでどのように処理するかを検討する必要があります。
多くの場合、DBMSには、開いている文ごとにリソース・コスト(カーソルなど)が設定されています。これは、文キャッシュ内にあるプリコンパイルされた文およびコール可能文に当てはまります。たとえば、キャッシュする文が多すぎると、データベース・サーバーでのオープン・カーソルの限度を超過する場合があります。サーバー2台に10個の接続をデプロイしているデータ・ソースがあり、文キャッシュ・サイズが10(デフォルト)に設定されている場合、キャッシュされた文に対してデータベース・サーバーで開くことのできるカーソルは200 (10 x 2 x 10)となります。
一部のドライバでは、開いている文ごとに大容量メモリー要件を課している場合があります。サーバーの場合、メモリー使用率(データ・ソース数 * 接続数 * 文数)が基準になります。
一部のDBMSでは、接続ごとの文数/カーソル数に制限を課している場合があります。
文キャッシュ・サイズは、使用するアプリケーションによって異なります。理想的には、DataSourceからの接続ごとに処理されるプリコンパイルされた文またはコール可能文の合計数です。アプリケーションで使用される最大サイズの近似値を求める方法の1つとして、キャッシュ・サイズを非常に大きい数値に設定し、アプリケーションのプール統計を監視して、確認された最大値よりも若干大きい値を採用します。WebLogic DataSourceから見た場合、アプリケーションで必要とされるよりも大きいキャッシュ・サイズを持つことでパフォーマンスが低下することはありません。
ただし、キャッシュ・サイズが小さすぎる場合は、新しい文を受け入れようとする間のキャッシュ・ターンオーバーが高くなり、古い文が再使用されないうちにフラッシュされてしまうため、パフォーマンスに悪影響を及ぼします。すべての文、または大半の文を保持できるだけ十分な大きさの文キャッシュが使用できない場合には、再使用率が低いために文キャッシュのないほうがシステム・パフォーマンスが向上することがあります。
文キャッシュの使用によりパフォーマンスが大幅に向上することがありますが、その使用を決定する前に、制約を考慮する必要があります。文キャッシュを使用する場合は、次の制約に注意してください。
文のキャッシングに関連して、ここには記載していないその他の問題も考えられます。プリコンパイルされた文またはコール可能文に関連してシステムにエラーが生じた場合は、文キャッシュ・サイズを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でプリコンパイルされた文またはコール可能文がキャッシュされると、その文によってデータベースにカーソルが開かれることがあります。キャッシュする文が多すぎると、接続に対するオープン・カーソルの限度を超過する場合があります。接続に対するオープン・カーソルの限度を超過しないようにするには、データベース管理システムで限度を変更するか、データ・ソースの文キャッシュ・サイズを縮小します。
oracle.jdbc.implicitstatementcachesizeがデータ・ソースの接続プロパティに設定されている場合、WebLogic Serverの文キャッシュ・サイズは自動的に0 (ゼロ)に設定されます。
文キャッシュに関して特別な考慮を必要とする場合がいくつかあります。
データ・ソースがDRCPを使用するように構成されている場合、アプリケーションによって接続が閉じられるときには必ずキャッシュがクリアされます。「データベース常駐接続プーリング」を参照してください
データ・ソースがリプレイ・ドライバを通じてアプリケーション・コンティニュイティを使用するように構成されている場合、WebLogic Serverの文キャッシュ・サイズは自動的に0 (ゼロ)に設定されます。
oracle.jdbc.implicitstatementcachesizeが、データベースの接続プロパティに設定されています。
使いやすさを確保し、キャッシングを確実に無効にするために、WebLogic Serverでは文キャッシュ・サイズの値が自動的にゼロ(0)に設定されます。
プリコンパイルされた文のキャッシュが有効になったWebLogicデータ・ソースに対して、JDBC 4.0 setPoolable(false)メソッドがコールされると、ドライバ・オブジェクトでメソッドがコールされるのに加え、文がキャッシュから削除されます。
データ・ソースのデータベース接続が常に正常であるように、接続を定期的にテストすることをお薦めします。WebLogic Serverには、次の2つの基本的なテストが用意されています。
自動テスト: データ・ソースに対するオプションを使用して構成し、データベース接続が常に正常であるようにします。
手動テスト: データ・ソースのトラブルシューティングを実行できます。「データ・ソースおよびデータベース接続のテスト」を参照してください
データ・ソースに対する自動テスト・オプションを構成するには、WebLogic Server管理コンソールから、またはJDBCConnectionPoolParamsBeanを使用するWLSTによって次のオプションを設定します。
テスト頻度 - (JDBCConnectionPoolParamsBean内のTestFrequencySeconds)—この属性は、未使用接続のテスト間の秒数の指定に使用します。WebLogic Serverでは未使用の接続がテストされ、障害のある接続はすべて閉じられて置換されます。テスト対象の表名を設定する必要もあります。
予約時に接続をテスト - (JDBCConnectionPoolParamsBean内のTestConnectionsOnReserve)—クライアントに接続する前に、各接続をテストする場合にこのオプションを有効にします。これを有効にすると、リクエストへの応答が若干遅れますが、接続が正常であることが保証されます。テスト対象の表名を設定する必要もあります。
テスト対象の表名 - (JDBCConnectionPoolParamsBean内のTestTableName)—この属性は、接続テストで使用する表名の指定に使用します。また、SQLと入力してスペースを1つ続け、テストとして実行するSQLコードを入力することによって、標準テストのかわりに実行するSQLコードを指定することもできます。テスト対象の表名は、データベース接続テストの有効化には必須です。「デフォルトのテスト対象の表名を使用したデータベース接続テスト」を参照してください
アイドル・プール接続を信頼する秒数 - (JDBCConnectionPoolParamsBean内のSecondsToTrustAnIdlePoolConnection)—このオプションは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であると信頼されて接続テストがスキップされることが問題なしと実証された後の秒数の指定に使用します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル・プール接続を信頼する秒数による接続リクエストの遅延の最小化」を参照してください
フラッシュされるまでのテストの失敗数 - (JDBCConnectionPoolParamsBean内のCountOfTestFailuresTillFlush)—このオプションは、さらなるデータベース・テストによって発生する遅延を最小限に抑えるためにWebLogic Serverが接続プール内のすべての接続を閉じるまでの間許可される、テストの失敗数の指定に使用します。このパラメータは、マルチ・データ・ソースのメンバーが失敗したときのフェイルオーバーの許容時間を最小限に抑えます。「データベース接続切断後の接続テスト遅延の最小化」を参照してください
無効化されるまでリフレッシュに失敗した接続の数 - (JDBCConnectionPoolParamsBean内のCountOfRefreshFailuresTillDisable)—このオプションは、データベースの失敗によって発生する接続リクエストの処理の遅延を最小限に抑えるためにWebLogic Serverが接続プールを無効にするまでの間許可される、テストの失敗数の指定に使用します。「DBMS接続の切断後の接続リクエスト遅延の最小化」を参照してください
これらのオプションの詳細は、WebLogic Server管理コンソールのJDBCデータ・ソース: 接続: 接続プール・ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
接続テスト・オプションの設定手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのテスト・オプションの構成を参照してください。
次の各項では、自動接続テスト・オプションについて説明します。
データ・ソース内でデータベース接続をテストする際、WebLogic Serverでは、データ・ソースから接続を予約し、その接続に対して小規模な問合せを実行して、接続をデータ・ソース内のプールに戻します。サーバー・インスタンスによってプール状況に関する統計が追跡されます。追跡される内容は、接続テストの完了に要する時間数、接続を待機している接続数、テスト中の接続数などです。最近のテスト接続動作の履歴を使用して、接続テストが失敗したと判断されるまでサーバー・インスタンスが待機する時間が計算されます。
あるスレッドのテストの完了が通常よりも長くかかっているように思われる場合、サーバー・インスタンスは、異常に長時間のテストが完了するまで、その他のスレッドのテストを遅らせることがあります。そのスレッドの接続テストに時間がかかりすぎている場合(デフォルトでは10秒)、プールはDBMS接続の失敗を宣言して無効になり、予約されていなくても、またはアプリケーションが使用中であっても、すべての接続が強制的に切断されます。プールはテスト中または未使用の接続をすべて閉じて、使用中の接続が中断している可能性があるため後でチェックするようにフラグ設定します。テスト間隔の経過後、WebLogic Serverは進行していない使用中の接続をすべて強制的に切断します。
これは非常にまれなケースであり、ネットワーク・ケーブルの切断や、ソケットでコールを実行中のJVMスレッドをロックする可能性のあるその他の問題により発生する果てしなく続く中断により、JVMがOS TCPの限度(通常は10分)に到達するまでブレークできないと判断される可能性を軽減することを意図しています。
テストで使用される問合せは、テスト対象の表名の値によって決定されます。値が表名である場合、問合せはselect count(*) from table_nameとなります。テスト対象の表名に、SQLで始まり、その後にスペースと問合せが続く完全問合せが含まれている場合は、データベース接続の保存時にその問合せが使用されます。
接続がテストに失敗すると、その接続が閉じられて再作成され、その後で新しい接続がテストされます。
接続テストのセマンティクスの詳細は、次の各項で説明します。
データ・ソース内に接続が作成されると、WebLogic Serverでは、テスト対象の表名の値によって定義された問合せを使用して各接続がテストされます。接続は、データ・ソースがデプロイされるときに作成されます。作成のタイミングは、サーバーの起動時、データ・ソースの作成時、接続に対する需要を満たすために容量を増やすとき、あるいは、接続テストに失敗した接続を再作成するときです。
このテストの目的は、新しい接続が実行可能であり、アプリケーションから接続が要求されたときに使用可能であることを確認することです。
テスト頻度が0よりも大きい場合は、アプリケーションによって現在予約されていないプールされた接続が定期的にテストされます。このテストは、テスト対象の表名で定義された問合せに基づいています。接続がテストに失敗すると、その接続が閉じられて再作成され、さらに、新しい接続をテストした後でプールに戻されます。
「予約時に接続をテスト」が有効になっている場合、アプリケーションがデータ・ソースからの接続をリクエストしたときに、「テスト対象の表名」で指定された問合せを使用して接続がテストされ、その後でアプリケーションに接続が渡されます。デフォルト値は有効になっていません。
予約済の接続をテストすると、接続リクエストに対する応答に遅れが生じますが、アプリケーションが接続を取得した時点で接続が実行可能であることが保証されます。「アイドル・プール接続を信頼する秒数」を調整することによって、予約済の接続のテストによる影響を最小限に抑えられます。「アイドル・プール接続を信頼する秒数による接続リクエストの遅延の最小化」を参照してください
DBMSとの接続が、たとえ瞬間的であっても失われると、通常はデータ・ソースの一部またはすべてのJDBC接続が停止します。データ・ソースが予約時に接続をテストするように構成されている場合、アプリケーションがデータベース接続をリクエストしたときに接続がテストされ、接続が停止していることが検出されて、リクエストを満たすために新しい接続への置換が試みられます。通常は、DBMSがオンライン復旧した時点でリフレッシュ・プロセスが成功します。ただし、場合によって、また一部の失敗モードでは、停止している接続をテストすると遅延が長期化することがあります。
この遅延を最小化するために、WebLogicデータ・ソースには、接続テストが何度も連続して失敗した後でデータ・ソースのすべての接続を停止中と見なし、データ・ソース内のすべての接続を閉じるロジックが組み込まれています。すべての接続が閉じられた後でアプリケーションが接続をリクエストした場合、データ・ソースは、はじめに停止中の接続をテストする必要もなく、接続を作成します。この動作によって、データ・ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小限に抑えられます。
WebLogic Serverでは、データ・ソースに対するテスト頻度の設定に基づいて、すべての接続を閉じる条件となる失敗回数が決定されます。
CountOfTestFailuresTillFlushに設定されます。 ノート:
デフォルト値は2です。テスト頻度が0に設定されている場合(定期テストは無効になります)、すべての接続を閉じるまでのテスト失敗回数は、データ・ソースの最大容量の25%に設定されます。
ノート:
この値は、privilegedSecuredContentPort値によってオーバーライドされます。実際には、すべての接続をクローズする前のテスト失敗の数は、フラッシュするまでのテスト失敗の数、つまりCountOfTestFailuresTillFlush(WebLogic Server管理コンソールのConnection Poolパラメータにあります)に従います。 使用不能のデータベース接続のテスト中における遅延を最小化するには、接続プールに対してCountOfTestFailuresTillFlush属性を設定します。この機能を有効にするには、TestConnectionsOnReserveをtrueに設定する必要もあります。
接続テストの連続失敗回数が、構成済またはデフォルトの上限回数に達した場合、プールで現在使用されていない接続はすべて停止し、後続の接続リクエストは新しい接続を取得します。アクティブな接続は中断しませんが、アクティビティに関してモニターされます。アクティビティが60秒以内に検知されなかった場合、その接続は破棄されます。
通常は、デフォルト値で十分です。次のような環境では、この値を増やす必要がある場合もあります。
JDBCアクティビティを数分間示さないことのある実行速度の遅いアプリケーションを使用している
ネットワーク/ファイアウォールの問題が発生して、常に1つまたは2つの接続が停止する
DBMSが使用できなくなると、データ・ソースは、接続リクエストに応えようとしながら、テストを続けて使用不能の接続の置換を試行します。データベースが使用可能になったときにこの動作によってデータ・ソースが即時に反応できるため、この動作は効果的です。ただし、DBMSが完全にダウンした場合には、DBMSがリストアするまで数分、数時間、または何日もかかる場合があります。使用不能のデータベース接続のテストにはネットワークのタイムアウトと同じ時間がかかるため、クライアントに対して長時間の遅延が生じることがあります。このような遅延は、すべての接続が置換されるまで、接続プール内の使用不能の接続ごとに発生するため、クライアントにとって予想される失敗メッセージが得られるまで長時間の遅延が生じることがあります。
データベースが使用できない間にクライアント・アプリケーションに対して発生する遅延を最小化するには、接続プールに対してCountOfRefreshFailuresTillDisable属性を設定します。デフォルト値は2です。この機能を有効にするには、TestConnectionsOnReserveをtrueに設定し、InitialCapacityを0より大きい値に設定する必要もあります。
使用不能の接続の置換に関して構成済、またはデフォルトの連続失敗数が確認されると、接続プールが中断されます。アプリケーションが中断された接続プールからの接続をリクエストした場合は、接続が使用できないことをクライアントに通知するためにPoolDisabledSQLExceptionがスローされます。
このように無効になったデータ・ソースに対して、リフレッシュ・プロセスが定期的に実行されます。リフレッシュ・プロセスは次の処理を行います。
サーバー・インスタンスは、データベース・サーバーに対して5秒ごとにヘルス・チェックを実行します。この設定は構成可能ではありません。
サーバー・インスタンスは、データベースのリカバリを認識すると、新しいデータベース接続を作成してデータ・ソースを有効にします。
また、WebLogic Server管理コンソールまたはWLSTを使用してデータ・ソースを手動で有効にすることもできます。
ノート:
データ・ソースがマルチ・データ・ソースに追加されている場合、そのマルチ・データ・ソースはデータ・ソースの無効化および再有効化の責任を引き受けます。デフォルトでは、マルチ・データ・ソースは2分ごとに(構成可能)チェックを行い、接続を再確立できるデータ・ソースをすべて再有効化します。マルチ・データ・ソースのレベルでテスト間隔を使用して構成します。この設定のセマンティクスは、データ・ソース・レベルとは異なる点に注意してください。
大量の非常に短いサイクル(reserve-do_one_query-closeなど)でDBMS接続を使用するアプリケーションの場合、データ・ソースが接続をテストすると、使用サイクルごとに相当量のオーバーヘッドが生じることがあります。接続テストの影響を最小限に抑えるには、JDBCデータ・ソース構成で「アイドル・プール接続を信頼する秒数」属性を設定して、最近使用した、または最近テストしたデータベース接続を信頼して接続テストをスキップします。
データ・ソースに対して「予約時に接続をテスト」が有効になっている場合、アプリケーションがデータベース接続をリクエストすると、データベース接続がテストされた後でアプリケーションに接続が渡されます。「アイドル・プール接続を信頼する秒数」に対して指定された時間内にリクエストが行われた場合、接続はテスト済であるか、アプリケーションにより正常に使用されているため、アプリケーションに接続を渡す前の接続テストはスキップされます。
データ・ソースに対する「テスト頻度」が0より大きい値である場合にも、接続が正常に使用されていて、「アイドル・プール接続を信頼する秒数」に指定された時間内にデータ・ソースに接続が戻されていれば、接続テストはスキップされます。
「アイドル・プール接続を信頼する秒数」の設定手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのテスト・オプションの構成を参照してください。
「アイドル・プール接続を信頼する秒数」は、特に通信量が大容量の間にデータベース接続テストによって生じた遅延を最小化することによって、アプリケーションのパフォーマンスを向上できるチューニング機能です。ただし、特に設定値が高すぎる場合は、接続テストの効果が低下する可能性があります。適切な値は、使用環境と、接続が使用できなくなる可能性によって異なります。
接続テスト属性が使用環境に最もよく適合するように設定することをお薦めします。たとえば、アプリケーションでデータベース接続失敗が許容されない場合は、「アイドル・プール接続を信頼する秒数」を0に設定して「予約時に接続をテスト」を有効にし、接続がアプリケーションに渡される前にすべての接続がテストされるようにすることをお薦めします。アプリケーションがデータ・ソースから接続を受け取る際の遅延に影響を受けやすく、使用不能の接続を使用したことによるアプリケーション・エラーを許容できる場合には、「アイドル・プール接続を信頼する秒数」の設定値を高くし、「テスト頻度」の設定値を低くして、「予約時に接続をテスト」を有効にすることをお薦めします。
これらの設定を使用すると、アプリケーションが接続をリクエストするときではなく、接続が使用されていないときに、プール内の接続をテストするデータ・ソースへのアプリケーションの依存度が高くなります。
ノート:
最終的に、WebLogicが最善を尽くしたとしても、WebLogicでの接続テストが正常に行われた直後、かつアプリケーションが接続を使用する直前に接続が失敗する可能性があります。したがって、すべてのアプリケーションは、使用不能の接続により予想外の例外が発生した場合でも適切に応答できるように作成する必要があります。
AGLおよびFANを有効にして実行する場合:
ONSはデータベース・インスタンスが停止したときに停止イベントを送信するため、「予約時に接続をテスト」を使用して実行する必要はありません。これによって、データベースでのテストのオーバーヘッドを除去する(または低減する)ことにより、パフォーマンスが大幅に向上する場合があります。ただし、「予約時に接続をテスト」では、ネットワークの接続性やデータベースへのアプリケーションのアクセスなど、その他の障害に関してテストします。オラクル社は、「予約時に接続をテスト」を指定して実行し、SecondsToTrustAnIdlePoolConnectionおよびTestFrequencySeconds(またはその一方)を使用してオーバーヘッドを低減させることをお薦めします。
CountOfTestFailuresTillFlushおよびCountOfRefreshFailuresTillDisableは無視されます。RACインスタンス全体の無効化は、インスタンスが停止していることを示すFANイベントが受信された時点で発生します。
WebLogic Server管理コンソールを使用してデータ・ソースを作成すると、選択されたDBMSに基づいて、WebLogic Server管理コンソールがデータ・ソースの「テスト対象の表名」属性を自動的に設定します。「テスト対象の表名」属性は、テスト・オプションの構成方法に応じて、オプションとして定期的に実行される接続テストで、または接続を作成したり予約するときに使用されます。データベースのテストが正常に行われるためには、データ・ソース内にデータベース接続を作成するデータベース・ユーザーがデータベース表へのアクセス権を持っている必要があります。アクセス権がない場合は、ユーザーにアクセス権を付与するか(この変更はDBMSで行います)、「テスト対象の表名」属性をユーザーがアクセス権を持つ表の名前に変更します(この変更はWebLogic Server管理コンソールで行います)。
「テスト対象の表名」は、オーバーロードのパラメータです。最も簡単な形式は、WebLogic Serverが接続テストを問い合せる表の名前を付けることです。これを任意の表(Oracleの場合は"DUAL"など)に設定すると、データ・ソースは問合せselect count(*) from DUALを実行します。この方法で使用する場合は、小規模でめったに更新されない表(できれば、DUALなどのpseudo-table)を選択することをお薦めします。
このパラメータを定義する2番目の方法では、接続をテストするために任意のSQL文字列を実行できるようにします。このオプションを使用するには、パラメータを"SQL"に設定し、さらに目的のSQL文字列を指定します。たとえば、SQL select 1はSQLServerに対して機能します。これは定数を選択する問合せに表を必要としません。このオプションは、WebLogic Serverプール接続テストのDBMS側の制御を追加して、テストの高速化を図る場合に役立ちます。
表22-1 DBMSによるデフォルトのテスト対象の表名
| DBMS | デフォルトのテスト対象の表名(問合せ) |
|---|---|
DB2 |
SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES |
Microsoft SQL Server |
SQL SELECT 1 |
MySQL |
SQL SELECT 1 |
Oracle |
SQL ISVALID |
Sybase |
SQL SELECT 1 |
デフォルトでは、「接続作成の再試行間隔」は0秒です。この値が0に設定されている場合、接続作成の再試行は無効になり、データベースが使用できない場合はデータ・ソースの作成が失敗します。
WebLogic Server管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ、または『Oracle WebLogic Server MBeanリファレンス』のJDBCConnectionPoolParamsBeanに関する項を参照してください。
ConnectionReserveTimeoutSeconds)および「接続の最大待機数」(HighestNumWaiters)があり、接続リクエストを有効化してデータ・ソースからの接続を待機するように設定できます。 この2つの属性を同時に指定すると、大量のスレッドをブロックしてシステムを無効にすることなく、接続リクエストを有効化して接続を待機するように設定できます。
これらのオプションの詳細は、WebLogic Server管理コンソールのJDBCデータ・ソース: 接続: 接続プール・ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化も参照してください。
アプリケーションがデータ・ソースからの接続をリクエストしたときに、データ・ソース内の接続がすべて使用中であり、データ・ソースが最大容量まで拡大している場合、接続使用不可のSQL例外がアプリケーションに送られます。これを回避するには、「接続予約のタイムアウト」の値(秒)を、接続リクエストが接続が使用可能になるまで待機するように設定します。「接続予約のタイムアウト」が期限切れになった後で使用可能になる接続がない場合、リクエストは失敗し、PoolLimitSQLException例外がアプリケーションに送られます。
「接続予約のタイムアウト」を-1に設定すると、使用可能な接続が存在しない場合は、接続リクエストが即時にタイムアウトになります。「接続予約のタイムアウト」を0に設定すると、接続リクエストは無期限に待機します。デフォルト値は10秒。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続リクエストにおける接続待機の有効化を参照してください。
接続を待機する接続リクエストによって、スレッドがブロックされます。接続を同時に待機している接続リクエストが多すぎて、スレッドがブロックされると、システム・パフォーマンスが低下することがあります。これを回避するには、「接続の最大待機数」(HighestNumWaiters)属性を設定して、接続を同時に待機できる接続リクエスト数を制限します。
「接続の最大待機数」(HighestNumWaiters)をMAX-INT(デフォルト)に設定すると、接続を待機できる接続リクエスト数の限界が効果的に除去されます。「接続の最大待機数」を0に設定すると、接続リクエストは接続を待機できません。最大リクエスト数に達すると、アプリケーションが接続をリクエストしたときにSQLExceptionがスローされます。
WebLogic Server管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページで、「非アクティブ接続タイムアウト」の値を指定すると、リークした接続を自動的にリカバリできます。
リークした接続とは、データ・ソース内の接続プールに適切に戻されなかった接続です。「非アクティブ接続タイムアウト」の値を設定すると、指定した秒数の間に予約された接続に対してアクティビティが発生しなかった場合、接続がデータ・ソースに強制的に戻されます。0(デフォルト値)に設定した場合、この機能は無効になります。
このオプションの詳細は、WebLogic Server管理コンソールのJDBCデータ・ソース: 接続: 接続プール・ページを参照するか、Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanを参照してください。
実際のタイムアウトは、「非アクティブ接続タイムアウト」の設定値を超過することがあります。内部のデータ・ソース・メンテナンス・スレッドは5秒ごとに実行されます。非アクティブ接続タイムアウト(たとえば30秒)に達すると、非アクティブな接続がないかチェックされます。現在のチェックの直前、または前のチェックの直後に予約された接続のタイムアウトを回避するために、サーバーは非アクティブの接続に対して「第2のチャンス」を与えます。次回のチェック時でも接続がまだ非アクティブの場合、その接続はタイムアウトして、データ・ソースに強制的に戻されます。概して、設定値よりも50%多い遅延が生じる可能性があります。
データ・ソース内で使用可能な最大接続数を増やすには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」ページで、データ・ソースの「最大容量」の値を高くします。
JDBCデータ・ソースに対して「文タイムアウト」オプションを指定すると、データ・ソースから予約されたデータベース接続での文の処理時間を制限できます。
「文タイムアウト」に値を設定すると、WebLogic Serverでは、java.sql.Statement.setQueryTimeout()メソッドを使用して、指定された時間がJDBCドライバに渡されます。コールが実行され、ドライバから例外がスローされた場合は値が無視されます。ドライバは、警告なくコールをサポートしなかったり、限定的サポートをドキュメント化している場合があります。ドライバのドキュメントをチェックして、予想される動作を確認することをお薦めします。
「文タイムアウト」が-1(デフォルト)に設定されると、文はタイムアウトしません。
このオプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 接続: 接続プール」ページを参照してください。
データ・ソースからのデータベース接続の予約にかかるアプリケーションの時間を最小化し、データベース接続に対するスレッド間の競合を除去するには、JDBCデータ・ソースで「スレッドに固定」オプションをtrueに設定します。
『Oracle WebLogic Server管理コンソール・オンライン・ヘルプ』の「JDBC データ ソース : コンフィグレーション : 接続プール」ページを参照してください。
「スレッドに固定」を有効にすると、アプリケーションが実行スレッドを使用して初めて接続を予約するときにデータ・ソースからのデータベース接続がその実行スレッドに固定されます。アプリケーションが接続の使用を終了してconnection.close()をコールすると、接続が実行スレッドに固定されたままになり、データ・ソースに戻されません(コールしない場合は、接続がデータ・ソースに戻されます)。その後、アプリケーションが同じ実行スレッドを使用して接続をリクエストすると、WebLogic Serverによってスレッドで予約済みの接続が提供されます。複数のスレッドが同時に接続を予約しようとする場合に発生する、データ・ソースでのロックの競合がなく、限られた数のデータベース接続から同じ接続を予約しようとするスレッドの競合もありません。
ノート:
「スレッドに固定」機能は、IdentityPoolを指定した場合は使用できません。WebLogic Serverリリース12.1.2以降、この組合せを使用する構成では、データ・ソースのデプロイが失敗します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 接続: 接続プールを参照してください。
PinnedToThreadが有効になると接続プール動作の性質が変更されるため、次のように、一部の接続プールの属性または機能の動作が変わったり、動作の変更に適合できなくなる場合があります。
最大容量が無視されます。接続プール内の接続数は、初期容量または、接続プールから予約された接続数のいずれか大きい方に等しくなります。
縮小は、接続が接続プールに戻されなくなるため、PinnedToThreadを有効にした場合は接続プールに適用されません。事実上、接続は常に予約されています。
接続プールをリセットすると、接続プールからリセットされた接続は「テストが必要」とマークされます。接続が次回に予約されると、接続がテストされ、必要に応じて再作成されます。接続プールをリセットした場合、接続は同期にテストされません。この機能では、「予約時に接続をテスト」を有効にして、テスト対象の表名または問合せを指定する必要があります。
PinnedToThread機能を使用する場合は、次の点を考慮してください。
Dベースの接続プールを有効化をtrueに設定して使用すると、エラーがスローされて、データ・ソースはデプロイされません。
「データベース資格証明の使用」をtrueに設定して使用すると、すべての接続はJDBCディスクリプタで定義されたデフォルト・ユーザーにより所有されますが、OracleプロキシはgetConnection(user, password)で指定されたユーザーとパスワードに設定されます。同様に、Oracleプロキシをtrueに設定すると、ユーザーとパスワードはデータベース資格証明にマップされ、Oracleプロキシが設定されます。これは、PinnedToThreadを使用しない場合と同じ動作です。
PinnedToThreadの使用時に接続ラべリングはサポートされないため、labelプロパティを使用して接続を取得しようとすると、例外がスローされます。
マルチ・データ・ソースを使用する場合は、マルチ・データ・ソースにより選択されるメンバー・データ・ソース別に接続が維持されます。たとえば、アルゴリズム・タイプとしてFailoverが指定された場合、接続は、最初はMDSのプライマリ・メンバーに対してのみ維持されます。フェイルオーバーが発生した場合、接続はMDSの次のメンバーに対して維持されます。アルゴリズム・タイプとしてLoad-Balancingを指定した場合、接続はMDSの各メンバーに対して維持されます。
Active GridLinkを使用する場合、AffinityおよびRuntime Load Balancingは、インスタンスの選択に関連して、引き続き以前と同じように機能します。スレッドごとに1つのインスタンスにつき最大1つの接続が保存されます(OnePinnedConnectionOnly=trueの設定と同じですが、インスタンスごとのベースです)。グラビテイションはサポートされていません(あまり使用されないノードへの接続の移行は行われません)。
PinnedToThreadが有効になっている場合、接続プールの最大容量(接続プールに作成されたデータベース接続の最大数)は、接続のリクエストに使用された実行スレッド数に、各スレッドが予約する同時実行接続数を乗じた値になります。この値は、接続プール用に指定された 最大容量を超過することもあります。システム設計の際にこのように超過する接続数を考慮して、オープン・カーソルなどの追加の関連リソースがデータベースで許容できることを確認する必要があります。
また、接続は接続プールに戻されません。つまり、接続数と使用中の関連リソース数を低減するために接続プールを縮小することはできません。このコストを最小化するには、追加のドライバ・パラメータ、onePinnedConnectionOnlyを設定します。onePinnedConnectionOnlyがtrueに設定されている場合は、最初にリクエストされた接続のみがスレッドに固定されます。スレッドが要求した追加の接続はすべて取り除かれ、必要に応じて接続プールに戻されます。次のようにProperties属性を使用して、onePinnedConnectionOnlyを設定します。
Properties="onePinnedConnectionOnly=true;user=examples"
システムで追加のリソース要件を処理できる場合は、PinnedToThreadオプションを使用してパフォーマンスを高めることをお薦めします。
システムで追加のリソース要件を処理できない場合、またはPinnedToThreadを有効にした後でデータベース・リソース・エラーが表示される場合は、PinnedToThreadを使用しないことをお薦めします。
ラッピングを無効にすると、ネイティブのドライバ・オブジェクトを直接使用して、アプリケーションのパフォーマンスを大幅に改善できます。
WebLogic Serverから返されるドライバのJDBCオブジェクトの中には、デフォルトによりラップされているものがあります。データ・ソース・オブジェクトをラップすることにより、WebLogic Serverでは次の機能が使用できます。
すべてのメソッド・コールからデバッグ出力を生成します。
接続の使用率を追跡して、接続が適切にタイムアウトできるようにします。
透過的なトランザクションの自動リスト化と、セキュリティ認証を提供します。
WebLogic Serverには、オブジェクトのラップを無効にする機能があり、次のような利点をもたらします。
WebLogic Serverでは、ラッパーを通して表示されるインタフェースを実装するベンダー・メソッドに対して動的プロキシが生成されますが、データ型の中にはインタフェースを実装しないものがあります。たとえば、Oracleデータ型のArray、Blob、Clob、NClob、Ref、SQLXML、およびStructは、インタフェースを実装しないクラスです。ラップを無効にすると、アプリケーションはネイティブのドライバ・オブジェクトを直接使用できます。
ノート:
これらの具体的なクラスを使用しないで、かわりに標準のSQL型または対応するOracleインタフェースを使用することをお薦めします。Oracle WebLogic Server JDBCアプリケーションの開発のOracle JDBCタイプのAPI拡張機能の使用方法を参照してください。
ラップのオーバーヘッドを除去すると、パフォーマンスが大幅に向上する場合があります。
ラップを無効にすると(wrap-types要素はfalse)、次のデータ型はラップされません。
Array
Blob
Clob
NClob
Ref
SQLXML
Struct
ParameterMetaData
接続テストは実行されません。
ResultSetMetaData
接続テストは実行されません。
結果セット・テストは実行されません。
JDBC MTプロファイリングは実行されません。
WebLogic Server管理コンソールとWLSTを使用して、データ型のラップを無効にできます。
データ型のラップを無効にするWLSTコード・スニペットは、次のとおりです。
. . . jdbcSR = create(dsname,"JDBCSystemResource"); theJDBCResource = jdbcSR.getJDBCResource(); poolParams = theJDBCResource.getJDBCConnectionPoolParams(); poolParams.setWrapTypes(false); . . .
この変更は即時に有効にはなりません。データ・ソースを再デプロイするか、サーバーを再起動する必要があります。
JDBCで使用されるチューニング可能なタイマー・プロパティのweblogic.jdbc.gravitationShrinkFrequencySeconds、weblogic.jdbc.harvestingFrequencySecondsおよびweblogic.jdbc.securityCacheTimeoutSecondsについて学習します。
weblogic.jdbc.gravitationShrinkFrequencySeconds - 接続は、GridLinkデータ・ソース上で定期的に停止する場合があります。様々なRACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザのランタイム・ロード・バランシングと一致しない場合は、過重インスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトでは30秒ごとに発生します。この動作を調整するには、接続のリバランスが行われるまでシステムが待機する時間(秒)を指定するシステム・プロパティweblogic.jdbc.gravitationShrinkFrequencySecondsを使用します。0以下の値を設定すると、リバランス・プロセスが無効になります。
weblogic.jdbc.harvestingFrequencySeconds - 接続収集により、データ・ソースが使用可能な接続数の指定値になったときにアプリケーションにより収集可能とマークされた予約済の接続がリリースされます。デフォルトでは、このチェックは30秒ごとに実行されます。このシステム・プロパティを使用して、データ・ソースによる収集頻度の時間(秒)を変更できます。0以下の値を設定すると、接続収集が無効になります。収集された接続のリカバリを参照してください
weblogic.jdbc.securityCacheTimeoutSeconds - WebLogic Serverユーザーの資格証明が予約接続のリクエストごとにチェックされるため、接続プールから接続を予約する際にパフォーマンスが影響を受けます。これを解決するには、このシステム・プロパティを使用してチェックを制御します。0以下の値を設定すると、キャッシュが無効になり、ユーザー認証がそのつど実施されます。0よりも大きい値を設定した場合は、指定された時間(秒)内でユーザーごとに1回だけ、ユーザー認証が実施されます。その後、値がキャッシュされます。プール・アクセス制限が動的に変更された場合は、キャッシュがクリアされた後で、一度に1回ずつユーザーがプールによって再認証されます。デフォルト値は10分です。
