ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理の構成と管理
11gリリース1 (10.3.6)
B60997-10
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

13 WebLogic JDBCリソースのモニタリング

この章では、稼働中のサーバー、およびコンテナ内にデプロイされたアプリケーションで生成される診断データを作成、収集、分析、アーカイブする方法、およびそのデータにアクセスする方法について説明します。

このデータにより、サーバーおよびアプリケーションの実行時のパフォーマンスに関する指標が提供され、障害発生時に失敗を隔離して診断することができます。WebLogic JDBCは、このサービスを利用して、実行時の統計、ある一定の期間に渡ってのプロファイル情報、ロギングおよびデバッグの機能を拡張し、WebLogicドメインが円滑に実行され続けるよう支援します。

実行時の統計を使用すると、WebLogicドメインのデータ・ソースをモニターして、問題があるかどうか確認できます。問題がある場合、プロファイリングを使用して、問題の原因となっているアプリケーションを特定できます。アプリケーションを絞り込んだ後、JDBCデバッグ機能を使用して、そのアプリケーション内の問題点を突き止めることができます。

次の項で、JDBCオブジェクトのモニタリングについて詳細に説明します。

実行時統計の表示

実行時の統計を表示すると、WebLogicドメイン内のデータ・ソースをモニターできます。

データ・ソースの統計

データ・ソースの実行時の統計は、管理コンソールまたはJBCDataSourceRuntimeMBeanを使用して表示できます。JDBCDataSourceRuntimeMBeanは、データ・ソースの現在の状態を取得するためのメソッド、およびアクティブな接続の平均数、アクティブな接続の現在の数、アクティブな接続の最大数など、データ・ソースに関する統計を取得するためのメソッドを提供しています。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanに関する項を参照してください。

プリコンパイルされた文のキャッシュの統計

プリコンパイルされた文のキャッシュの実行時統計は、管理コンソールまたはJBCDataSourceRuntimeMBeanを使用して表示できます。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanに関する項を参照してください。

プロファイル・ロギング

WebLogic Server 10.3.6以前は、データ・ソース・プロファイル・レコードがWLDFイベントとして記録されました。操作性とパフォーマンスを向上させるため、WebLogic Serverではデータ・ソース・プロファイル・ログを使用してイベントが格納されます。プロファイル・ログには次の利点があります。

データ・ソース・プロファイリングのログの基本特性を次に示します。

WebLogicのロギング・サービスの詳細は、次を参照してください。

プロファイル情報の収集

確認中の統計において、WebLogic Serverドメインになんらかの問題があることが示された場合、データ・ソースを構成して、原因究明の手がかりとなるプロファイル情報を収集できます。収集されたプロファイル情報は、プロファイル・ログのレコードに格納されます。次の項で説明するように、各フィールドには、プロファイル タイプごとに異なる情報が格納されます。

プロファイリングのためにデータ・ソースを構成する場合、プロファイル・データを収集する間隔(収集間隔(秒))を指定する必要があります。間隔を0に設定すると、データ収集は無効化されます。Oracle WebLogic Server管理コンソール・ヘルプJDBCデータ・ソースの診断プロファイルの構成に関する項を参照してください。

プロファイル・タイプ

このドキュメントの次の項で説明するように、データ・ソースおよびプリコンパイルされた文のキャッシュについて、次の情報をプロファイリングすることを選択できます。

接続の使用率(PROFILE_TYPE_CONN_USAGE_STR)

接続使用状況のプロファイリングを有効にすると、データ・ソース内の接続プールからの接続を現在使用しているスレッドについて情報が収集されます。このプロファイル情報の支援により、アプリケーションがデータ・ソースから接続を取得できない理由を特定できます。


注意:

デフォルトでは、独自の接続使用状況のプロファイリングを有効にすると、接続を使用したスレッドのスタック・トレースが提供されません。この情報を取得するには、接続の有効化に加えて接続リークのプロファイリングを有効化する必要があります。接続リークのプロファイリングの詳細は、「接続リーク(PROFILE_TYPE_CONN_LEAK_STR)」を参照してください。


レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: 接続ID

  • User: 接続を使用しているスレッドのスタック・トレース

  • Timestamp: 接続がスレッドにいつ割り当てられたか示すタイム・スタンプ

待機中の接続予約(PROFILE_TYPE_CONN_RESV_WAIT_STR)

待機中の接続予約のプロファイリングを有効にすると、データ・ソースからの接続を予約するのを現在待機しているスレッドついて情報が収集されます。このプロファイル情報の支援により、アプリケーションがデータ・ソースから接続を取得できない理由、または接続を待機できない理由を特定できます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: スレッドID

  • User: 接続を待機しているスレッドのスタック・トレース

  • Timestamp: スレッドが接続をいつ待機し始めたか示すタイム・スタンプ

失敗した接続予約(PROFILE_TYPE_CONN_RESV_FAIL_STR)

失敗した接続予約のプロファイリングを有効にすると、データ・ソースからの接続を予約しようとしたけれども、その接続を取得できなかったスレッドについて情報が収集されます。このプロファイル情報の支援により、アプリケーションが、接続を予約したにもかかわらず、その接続をデータ・ソースから取得できない理由を特定できます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: スレッドID

  • User: 接続を待機しているスレッド、および予約リクエストが失敗したときに受け取る例外のスタック・トレース

  • Timestamp: 予約リクエストがいつ失敗したか示すタイム・スタンプ

接続リーク(PROFILE_TYPE_CONN_LEAK_STR)

接続リークのプロファイリングを有効にすると、データ・ソースからの接続を予約し、その接続がリークした(接続プールに正常に戻されなかった)スレッドついて情報が収集されます。このプロファイル情報の支援により、JDBC接続を正しく閉じていないアプリケーションを特定できます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: 接続ID

  • User: 接続を待機しているスレッドのスタック・トレース

  • Timestamp: 接続リークがいつ検出されたか示すタイム・スタンプ

接続の最終使用(PROFILE_TYPE_CONN_LAST_USAGE_STR)

接続の最終使用状況のプロファイリングを有効にすると、接続を最後に使用した前スレッドについて情報が収集されます。この情報は、保留中のトランザクションが原因で、接続で後続のXA操作が失敗した場合など、接続の問題をデバッグする場合に役立ちます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: スローされたXA例外のスタック・トレース

  • User: 接続を最後に使用したスレッドのスタック・トレース

  • Timestamp: 例外がいつスローされたか示すタイム・スタンプ

マルチスレッド接続使用状況(PROFILE_TYPE_CONN_MT_USAGE_STR)

マルチスレッド接続使用状況のプロファイリングを有効にすると、異なるスレッドにより以前に取得された接続を不正に使用しているスレッドについて情報が収集されます。アプリケーションが問題を報告し、その問題の原因が、複数のスレッドが1つの接続を同時に使用していることと考えられる場合、この情報が役立ちます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: 接続を使用していることが検出された他のスレッドのスタック・トレース

  • User: 接続を予約したスレッドのスタック・トレース

  • Timestamp: 複数のスレッドによる接続の使用がいつ検出されたか示すタイム・スタンプ

文キャッシュ・エントリ(PROFILE_TYPE_STMT_CACHE_ENTRY_STR)

文キャッシュ・エントリのプロファイリングを有効にすると、文キャッシュに追加されたプリコンパイルされた文と呼出し可能文について、およびキャッシュされた文から発生したスレッドについて情報が収集されます。この情報の支援により、キャッシュがどのように使用されているか特定できます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: 文の文字列表現

  • User: 文を使用しているスレッドのスタック・トレース

  • Timestamp: 文がキャッシュにいつ追加されたか示すタイム・スタンプ

文使用状況(PROFILE_TYPE_STMT_USAGE_STR)

文使用状況のプロファイリングを有効にすると、文キャッシュ内のSQL文を現在実行しているスレッドについて情報が収集されます。この情報の支援により、文がどのように使用されているか特定できます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: 文を通じて実行されているSQL文

  • User: 文を使用しているスレッドのスタック・トレース

  • Timestamp: 文の実行期間

接続アンラップ(WEBLOGIC.JDBC.CONN.UNWRAP)

文使用状況のプロファイリングを有効にすると、getVendorObject WebLogic拡張APIまたはJDBC 4.0のunwrapメソッドを使用して基になるJDBC接続にアクセスするアプリケーション・コンポーネントについてプロファイル情報が収集されます。レコードには、次の情報が格納されます。

  • PoolName: この接続が属するデータ・ソースの名前

  • ID: オブジェクトがアンラップされた場所のスタック・トレース

  • User: オブジェクトをアンラップしているスレッドのスタック・トレース

  • Timestamp: オブジェクトがいつアンラップされたか示すタイム・スタンプ

プロファイル情報レコード・ログの例

標準的な出力ログからの文使用状況(PROFILE_TYPE_STMT_USAGE_STR)のプロファイル情報レコードの例を、次に示します。

####<JDBC Data Source-0> <WEBLOGIC.JDBC.STMT.USAGE> <0> <java.lang.Exception
     at
.
.
.
 weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run( ContainerSupportProviderImpl.java:254)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
 > <select 1 from dual> 

プロファイル・ログの各コンポーネントは、カッコ(<および>)で囲まれています。

  • プール名: JDBC Data Source-0

  • プロファイル・タイプ: WEBLOGIC.JDBC.STMT.USAGE

  • タイムスタンプ: 0 (ミリ秒)

  • ユーザー: java.lang.Exception at . . . at weblogic.work.ExecuteThread.run(ExecuteThread.java:254

  • ID: select 1 from dual

診断データへのアクセス

次の方法のいずれかを使用して、診断データにアクセスできます。

  • WebLogic管理コンソール。次の項を参照してください。

  • WebLogic診断フレームワーク(WLDF)のData Accessorコンポーネント。『Oracle WebLogic Server診断フレームワークの構成と使用』のData Accessorによる診断データへのアクセスに関する項。

  • テキスト・エディタを使用して情報を手動で表示。

  • データ・ソースのプロファイリングを実行する場合、デフォルトの収集時間は300秒であるため、データをただちに表示できない場合があります。結果をより適切に視覚化するために、収集時間を小さい値(たとえば、5秒)に設定する必要がある場合があります。

ドライバ・レベルの統計をモニタリングするためのコールバック(非推奨)


注意:

この機能は、WebLogic Server 10.3.6.0では非推奨であり、今後のリリースでは削除される可能性があります。


WebLogic Serverは、JDBCドライバでコールされるメソッドのコールバックを提供しています。これらのコールバックを使用して、実行中のメソッド、スローされた例外、ドライバ・メソッドの実行に使用された時間など、JDBCドライバの使用状況をモニターおよびプロファイリングできます。

コールバック機能を有効にするには、JDBCデータ・ソース記述子(モジュール)内のdriver-interceptor要素のためのコールバック・ハンドラの完全修飾パスを指定します。コールバック・ハンドラには、weblogic.jdbc.extensions.DriverInterceptorインタフェースが実装されている必要があります。JDBCドライバのコールバックを有効にすると、JDBCドライバ内のメソッドが呼び出される前、および呼び出された後に、WebLogic Serverにより、登録されているコールバック・ハンドラのpreInvokeCallback()postInvokeExceptionCallback()およびpostInvokeCallback()メソッドがコールされます。

アプリケーションによりJDBCドライバがコールされると、必ずそのドライバを実装したクラスにコールバックが送信されます。

JDBCデータ・ソースのデバッグ

特定のアプリケーションに問題があることを突き止めた後、WebLogic Serverのデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。

デバッグの有効化

適切なServerDebug構成属性をtrueに設定することで、デバッグを有効化できます。必要に応じて、サーバーのStdoutSeverityDebugに設定することもできます。

次のいずれかの方法で構成属性を変更できます。

コマンド行を使用したデバッグの有効化

コマンド行で適切なプロパティを設定します。次に例を示します。

-Dweblogic.debug.DebugJDBCSQL=true 
-Dweblogic.log.StdoutSeverity="Debug"

この方法は静的であり、サーバーの起動時にのみ使用できます。

WebLogic Server管理コンソールを使用してデバッグを有効化

WebLogic Server管理コンソールを使用して、デバッグ値を設定します。

  1. まだ行っていない場合、管理コンソールのチェンジ・センターで「ロックと編集」をクリックします(『Oracle WebLogic Serverの紹介』の「チェンジ・センターの使用」を参照)。

  2. コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

  3. 「サーバーのサマリー」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。

  4. 「デバッグ」をクリックします。

  5. 「デフォルト」を展開します。

  6. 変更するデバッグ・スコープまたは属性のチェック・ボックスを選択します。

  7. 「有効化」を選択して、選択したデバッグ・スコープまたは属性を有効化します(または「無効化」を選択して無効化します)。

  8. これらの変更を有効にするために、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  9. すべての変更がすぐに有効になるわけではありません。再起動が必要な場合もあります(『Oracle WebLogic Serverの紹介』のチェンジ・センターの使用に関する項を参照)。

    この方法は動的であり、サーバーの実行中にデバッグを有効化するのに使用できます。

WebLogic Scripting Toolを使用してデバッグを有効化

WebLogic Scripting Tool (WLST)を使用して、デバッグ値を設定します。たとえば、次のコマンドでは、debug.pyというデバッグ値を設定するためのプログラムが実行されます。

java weblogic.WLST debug.py

debug.pyプログラムには、次のコードが含まれています。

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCSQL','true')
save()
activate()

JavaからもWLSTを使用できます。次の例では、デバッグ値の設定に使用されるJavaファイルを示します。

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
 public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJDBCSQL','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

WLSTの使用は動的な手法で、サーバーの実行中にデバッグを有効化するために使用できます。

config.xmlファイルへの変更

コンソール、WLSTまたはコマンド行でデバッグ特性を変更すると、その内容がconfig.xmlファイルに反映されます。例13-1を参照してください。

例13-1 JDBCのデバッグ・スタンザの例

.
.
.
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jdbcsql>true</debug-jdbcsql>
</server-debug>
</server> 
.
.
.

この例のconfig.xmlの断片は、トランザクション・デバッグのスコープ(複数のデバッグ属性)および1つのJDBC属性を示しています。

JDBCのデバッグ範囲

JDBCの登録済デバッグ範囲は、次のとおりです。

  • DebugJDBCSQL(スコープweblogic.jdbc.sql): 引数と戻り値、スローされた例外など、呼び出されたすべてのJDBCメソッドに関する情報を出力します。

  • DebugJDBCConn(スコープweblogic.jdbc.connection): データ・ソースのすべての接続予約および解放操作、および接続を取得または閉じるためのすべてのアプリケーション・リクエストを追跡します。

  • DebugJDBCONS(スコープweblogic.jdbc.rac): 低レベルのONSデバッグを追跡します。

  • DebugJDBCRAC(スコープweblogic.jdbc.rac): RACデバッグを追跡します。

  • DebugJDBCUCP(スコープweblogic.jdbc.rac): 低レベルのUCPデバッグを追跡します。

  • DebugJDBCREPLAY(スコープweblogic.jdbc.rac): リプレイ・デバッグを追跡します。

  • DebugJDBCRMI(スコープweblogic.jdbc.rmi): JDBCSQLと同様ですが、RMIレベルです。これとJDBCSQLを有効にすると、クライアントからコールされる操作ごとに、2セットのデバッグ・メッセージが取得されます。

  • DebugJDBCInternal(スコープweblogic.jdbc.internal): データ・ソース、接続環境およびデータ・ソース・マネージャに関連するweblogic/jdbc/common/internalの低レベル・デバッグ。

  • DebugJDBCDriverLogging(スコープweblogic.jdbc.driverlogging): JDBCドライバ・レベルのロギングを有効化します(ServerMBean JDBCLoggingEnabledおよびgetJDBCLogFileNameのかわりに、これを使用します)。Oracleのドライバ・レベル・トレースを取得するには、ojdbc6.jarのかわりにojdbc6_g.jarを使用する必要があります。このデバッグ・スコープでは、ロギングを、サーバー起動時にコマンド行または構成を通じて一度有効化できますが、(DriverManagerインタフェースがあるため)動的に有効化または無効化できません。

  • DebugJTAJDBC(スコープweblogic.jdbc.transaction): トランザクション・デバッグを追跡します。

UCP/ONSのデバッグの設定

WebLogic Serverリリース10.3.6.0以上では、これらのコンポーネントのデバッグに影響するUCPおよびONSのパッケージ名が再パッケージされなくなりました。

UCPのデバッグ

UCPのデバッグは、次を使用して直接設定します。

oracle.ucp.level = FINEST;
oracle.ucp.jdbc.PoolDataSource = WARNING;

ONSのデバッグ

ONSのデバッグを有効にするには、次を使用します。

oracle.ons.debug=true

出力を印刷するには、次のコールを行います。

oracle.ons.ONS public static void setLogStream(PrintStream ps, PrintStream ps2);

リクエストのDye処理

デバッグのもう1つのオプションは、JDBCサブシステムを通じて個々の(通常、dye処理された)アプリケーション・リクエストのフローを追跡することです。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のDyeInjectionモニターによるDye Vectorの構成に関する項を参照してください。