AOL/J End

とりあえず、今理解している範囲でのEBSのJDEBC接続プールの動きである。基本の動きは11i、12とも変わっていない。このプールの仕組の上にApplication Moduleの仕組が搭載されている。その辺の動きついては、また今度かな。

AOL/J Part6.

やっと最後。FND_JDBC_USABLE_CHECKは変更した方が良いと思うが、後は無視してもよいと俺は思う。どういうときに設定を見直す必要があるのか、教えてください。

FND_JDBC_USABLE_CHECK
FND_JDBC_USABLE_CHECKは接続をクライアントに貸し出す前にPL/SQLでの検索を行うかどうかを決定する。プールは接続を渡す前に使用可能かどうかのチェックを行う。これは常に接続がNullではなく、またクローズされていないことのチェックある。FND_JDBC_USABLE_CHECKがtrueに設定されていると、更にその接続が、簡単なPL/SQLの検索を行うことができるどうかの確認も行なわれる。

これはデフォルトがfalseになっているので注意。Safetyチェックなので、できればTrueにした方が良いと思うが、何故PL/SQLのみなのか、説明はない。JavaからPL/SQLをコールする場合の方法としてチェックが必要という意味なのだろうか？
 
FND_JDBC_CONTEXT_CHECK
FND_JDBC_CONTEXT_CHECKは、接続がプールに戻されるときにAOLのセキュリティ情報とNLSの状態がデータベースから取得されるかどうかを決定する。FND_JDBC_CONTEXT_CHECKがtrueの場合、接続がプールに戻されるときにこれらが取得される。(これはDBConnObj.isReusable() に実装されている)。このチェックは選択アルゴリズムが利用可能リストにある接続のセッション情報にアクセスできるよう、接続が返されるときに行われる。

FND_JDBC_PLSQL_RESET 
PL/SQLリセットのフラグは、プールがクライアントに接続を渡す前にその接続で持っているPL/SQLの状態が解放されるかどうかを左右する。このフラグのデフォルトはfalseです。trueにセットされると、プールが接続を渡す前にPL/SQLの状態がクリアされる。  
 
プールは利用可能なリストの中からクライアントのための接続を選択した後、その接続の初期化を
行う。その初期化のうちの一つが、後にapps initializationのルーチンが実行される必要があ
るかどうかを決定するためにSessionManagerによって利用されるフラグをセットすることである。
FND_JDBC_PLSQL_RESETがtrueにセットされていると、このフラグは常にtrueとなります。プールは接続を初期化した後、その接続が使用可能かどうかのチェックも行う。この場合、チェックはPL/SQLの状を解放するDBMS_SESSION.RESET_PACKAGEの実行も行う。これがtrueに設定されていると、プールのパフォーマンスは悪くなる。

AOL/J Part5

FND_JDBC_MAX_WAIT_TIME(変更不可)
 
最大待ち時間は、クライアントが接続を取得しようとするのにどの位の時間を費やすかを決定する。
す。接続をプールから借りるアルゴリズムには、経過時間を最大待ち時間と比較してチェックする
機能が組み込まれている。最大値を超えた場合、nullがクライアントに返されます。事前定義の
設定は10秒。
  
FND_JDBC_SELECTION_POLICY(変更不可)
 
選択ポリシーは、あるクライアントに関しての接続が、利用可能な接続のリストからどのように選択されるかを決定する。コストベースの選択アルゴリズムを採用するよう事前定義されています。このアルゴリズムでは、そのクライアントの状態に一致するように行われる初期化処理が最小になる。
Pool.COSTと呼ばれるコストベースが設定されている。

AOL/J Part4

FND_JDBC_BUFFER_DECAY_INTERVAL
 
バッファ減衰間隔はどの位の頻度で接続プールのメンテナンスが行われるかを指定する。
スレッドはバッファサイズを最大でもFND_JDBC_BUFFER_DECAY_INTERVAL秒毎にチェックする。
各サイクル間の実際の時間はJVMの負荷によって幾らか異なる。実際は大分ずれていると思う。

このパラメータは、FND_JDBC_BUFFER_DECAY_SIZEと共にバッファの減衰量の調整に利用される。例えば、バッファ減衰サイズが3で減衰間隔が1分の場合、1分当たりのバッファの減衰量は3を超えることはない。デフォルトは300秒だったりする。60秒までインターバルを短くすることは可能。

負荷が高い時は、FND_JDBC_BUFFER_DECAY_INTERVALとFND_JDBC_BUFFER_DECAY_SIZEの2つの値の調整に尽きると思う。想定される負荷(例えば、1分あたり増加量以上の数値を設定すればよい）


FND_JDBC_BUFFER_DECAY_SIZE
 
バッファ減衰サイズは利用可能な接続がバッファサイズ以上になっているときに1回のスレッドのサ
イクルで除去されるべき接続の最大数を指定する。このパラメータは、FND_JDBC_BUFFER_DECAY_
INTERVALと共に減衰量の調整のために使用される。


設定値によるケースパターンは後で記述。

AOL/J Part3

FND_JDBC_BUFFER_MIN
 
最小バッファは、プールが利用可能リストに保持しようとする最小の接続数。
バッファサイズがFND_JDBC_BUFFER_MIN以下になると、プール管理のスレッドは
新しい接続を作るように通知される。通知されると、スレッドは即座にその差分を
埋めるだけの接続を作成しようと試みます。プールが既に最大値に達している場合には
新しい接続は作成されない。
このパラメータを0に設定すると、最小バッファのメンテナンスは無効化されます。
しかし、最大バッファのメンテナンスは行われたままです。一方でパラメータを
FND_MAX_JDBC_CONNECTIONSより大きな値に設定すると、全てのバッファのメンテナンス
は無効化される。


FND_JDBC_BUFFER_MAX

最大バッファはプールが利用可能リストに保持しようとす接続の最大数です。
負荷の高い間、バッファは最大数を超えることがあります。しかし、負荷が低くなると、
メンテナンスのスレッドは最大バッファの数までバッファを減少させます。

値が整数(例:30)の場合、最大バッファは固定。
一方でパーセント(例:20%)の場合、最大バッファは一定ではなく、代わりにトータルの
プールサイズのパーセントとして動的に算出される。最小バッファも最大バッファを
動的に決定する際に考慮される。( 整数値にパーセント記号(%)を変えることで変更可能であり
%の場合は10%以上が指針)

 maximum(t) =  minimum + ( (FND_JDBC_BUFFER_MAX/100)  * FND_MAX_JDBC_CONNECTIONS)

ここで、maximum(t)及びsize(t)はある時刻における最大バッファとプールサイズです。
スレッドは定期的にバファサイズをチェックします。バッファサイズが最大バッファより
大きい場合、スレッドはFND_JDBC_BUFFER_DECAY_SIZEに指定された数もしくは
最小バッファを超えた接続数の内、より小さい方の数だけ利用可能な接続を減少させます。
接続が利用可能リストから除去されるとき、最も長い時間利用されていないものが
最初に除去される。

このパラメータを100%に、あるいはFND_MAXIMUM_JDBC_CONNECTIONSと同じ値
及びFND_JDBC_BUFFER_MIN以下の値に設定することでメンテナンスのスレッドが
接続を除去されないようになる。

このパラメータを0に設定すると、最大バッファのメンテナンスは無効化される。

FND_JDBC_BUFFER_MINとFND_JDBC_BUFFER_MAXの双方を0に設定するとメンテナンス
がされなくなる。通常はMINとMAXの間で維持しようとする。

AOL/J Part2

AOL/Jにおいて、各種パラメータの定義、設定のポイントを記述する。

FND_MAX_JDBC_CONNECTIONS 

利用可能な(Available)接続とロック(lock)された(他のクライアントによって使用中で

利用不可の)接続の総計の許容される最大数。プールが最大サイズに達して、

全ての接続がロックされると、現在のクライアントが返却しない限り

新しいクライアントはプールから接続を借りることができません。

デフォルトの設定は500.(12.1.3)

設定した時は、Oracle DBの 初期化パラメータであるProcessesにも気をつけること。

FND_MAX_JDBC_CONNECTIONS ＞ PROCESSESだと、PROCESSESの数値を超えて、

新規コネクションを作成する段階でORA-00020が発生する。

FND_MAX_JDBC_CONNECTIONS達して、再利用可能なコネクションが存在しない場合、

Oracle AS側からエラーが戻される。 その他として、エンハンス機能である

AOL/J Connection Harvesterというものがあるが、現時点は稼動確認を取っていないので、

説明は無。

AOL/J Part1

年明けから結構経ってしまった。反省。

EBSの JDBCのConnection Poolingの仕組である。アプリケーションモジュールのプーリングの仕組とは異なるので注意が必要。

AutoConfigで調整が可能である為、大量負荷がかかるOAFのアプリケーションをデリバリする場合は、負荷テストで、各値の数値の増減を確認した方がよい。
(オラクル社より診断ツールが提供されている。プロファイルは「FND:　診断」を「Y」に変えると、取得することが可能になり、「AOL/Jデータベース接続 プール・ステータス」というメニューから表示可能である。ログイン後、以下のURLを叩いても可能。

http://<hostname>:<port>/OA_HTML/jsp/fnd/AoljDbcPoolStatus.jsp


「available connection」、「locked connections」、「connection destroyed ( by  thread)」を中心にモニタリングした方がよい。「leaked connections」は存在しないと認識するが、仮に発生していたら調査をした方がよい。