#モニタリングしたいJDBCリソースの処理の一例

oJDBCDataSourceRuntime = getMBean(„JDBCServiceRuntime/<サーバ名>/JDBCDataSourceRuntimeMBeans/

<

>')

oState = oJDBCDataSourceRuntime.getState()

oCurrCapacity = oJDBCDataSourceRuntime.getCurrCapacity()

oActiveConnectionsCurrentCount = oJDBCDataSourceRuntime.getActiveConnectionsCurrentCount() oWaitingForConnectionCurrentCount = oJDBCDataSourceRuntime.getWaitingForConnectionCurrentCount() print "State : " + str(oState)

print "CurrCapacity : " + str(oCurrCapacity)

print "ActiveConnectionsCurrentCount : " + str(oActiveConnectionsCurrentCount)

print "WaitingForConnectionCurrentCount : " + str(oWaitingForConnectionCurrentCount)

<Insert Picture Here>

WLS11g のデータ・ソースに

おける実践ノウハウ

接続プールの容量について①

• 接続プールの「初期容量」や「最大容量」の値は同じにし ておくことを奨励します。

• サーバ起動時に必要な数の接続プールを全て作ってしま

うことで、運用中に接続プールが増減するコストを軽減し

ます。

接続プールの容量について②

• WebLogic で同時実行される最大スレッド数 <= 接続プー ルの「最大容量」にする。

• WebLogic 上のアプリケーションは実行スレッドにて処理 されるが、同時実行スレッド数が多くなると、それに対応 できる接続プール中の接続が無ければ接続予約時でス レッドの待機が発生してしまい、性能に悪影響となる。

• WebLogic で同時実行される最大スレッド数はワークマネ

ジャー機能でサーバまたはアプリケーション別に指定でき

る。

接続プールのテストについて①

• プロダクション環境では正常な接続プールが振り出される ことを保証するためにも、「予約時に接続をテスト」オプシ ョンを有効にすることをお勧めします。

• アプリケーションが接続を予約する際に必ずテストが実施 されますので、接続プールの信頼性が保たれます。接続 予約の際のボトルネックもほとんど無視できますが、チュ ーニングするには「アイドルプール接続を信頼する秒数」

を設定します。

接続プールのテストについて②

• WebLogic とデータベースの間に Firewall 等が設置されて いる場合、 Firewall が接続プール中の接続と DB 間のアイ ドルな通信を一定間隔で自動切断する場合がある。

• FireWall の設定変更による対応が必要だが、場合によっ

てはテスト頻度を利用することで、回避をすることも可能

である。

V$SESSION にクライアント情報を埋め込む（1/2）

WebLogicの複数のデータソースに設定された、接続用のユーザー名が同一の 場合、DB側からデータソースを識別することが出来ません。

データソース①

WebLogic

アプリ①

データソース③ アプリ②

データソース③ アプリ③

データソース①～③から DB へ接続を行うユーザー名が 同一の場合、 DB 側からは、

接続（セッション）がどのデー

タソースから確立されている

ものかを特定することが出

来ません。

V$SESSION にクライアント情報を埋め込む（2/2）

デフォルトでは v$session.program には” JDBC Thin Client” が設定さ

れますが、プロパティに program をセットすることでどのデータソース

から接続したセッションか判定できるようになります。