ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理
11g リリース 1 (10.3.1)
B55546-01
  目次
目次

戻る
戻る
 
次へ
次へ
 

6 WebLogic JDBC リソースのモニタ

WebLogic Server のこのリリースには WebLogic 診断フレームワークが含まれています。これは、WebLogic Server プロセス内で実行され、標準のサーバ ライフ サイクルに参加する、モニタと診断のサービスです。このサービスを使用すると、実行中のサーバおよびそのコンテナ内にデプロイされているアプリケーションによって生成された診断データを作成、収集、分析、アーカイブし、それらの診断データにアクセスできます。このデータを基に、サーバおよびアプリケーションの実行時パフォーマンスを把握できます。また、障害発生時に、このデータを使用して、障害を隔離および診断できます。WebLogic JDBC は、このサービスを利用して、実行時の統計、ある一定の期間に渡ってのプロファイル情報、ロギング、およびデバッグの機能を拡張し、WebLogic ドメインが円滑に実行され続けるよう支援します。

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

以下の節では、JDBC オブジェクトのモニタについて詳細に説明します。

WebLogic 診断フレームワークの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』を参照してください。

実行時の統計の表示

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

データ ソースの統計

データ ソースの実行時の統計は、Administration Console または JBCDataSourceRuntimeMBean を使って表示できます。JDBCDataSourceRuntimeMBean は、データ ソースの現在の状態を取得したり、アクティブな接続の平均数、現在のアクティブな接続数、アクティブな接続の最大数などデータ ソースに関する統計を取得したりするためのメソッドを提供します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCDataSourceRuntimeMBean」を参照してください。

プリペアド ステートメント キャッシュの統計

プリペアド ステートメント キャッシュの実行時の統計は、Administration Console または JBCDataSourceRuntimeMBean を使って表示できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCDataSourceRuntimeMBean」を参照してください。

プロファイル情報の収集

表示されている統計から WebLogic Server ドメインに問題があると分かった場合は、任意のデータ ソースをコンフィグレーションして、問題の原因を特定するのに役立つ、プロファイル情報を収集できます。収集されたプロファイル情報は、WLDF アーカイブの中のレコードに格納されます。後述するように、各フィールドには、プロファイル タイプごとに別の情報が格納されます。

プロファイリングのためにデータ ソースをコンフィグレーションする際には、プロファイル データ収集の間隔 ([収集間隔 (秒) のプロファイル]) を指定する必要があります。間隔を 0 に設定すると、データ収集は無効化されます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「メトリック収集用のハーベスタのコンフィグレーション」を参照してください。

プロファイル タイプ

このドキュメントで後述するように、データ ソースおよびプリペアド ステートメント キャッシュについて、以下の情報のプロファイリングを選択することができます。

接続使用状況 (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)

別のスレッドによって以前に取得された接続を誤って使用するスレッドに関する情報を収集するには、マルチスレッド接続使用状況のプロファイルを有効にします。この情報は、接続が複数のスレッドによって同時に使用されていることが原因ではないかと思われる問題をアプリケーションが報告した場合に有用です。レコードには、以下の情報が格納されています。

  • 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 - 文の実行されている期間

診断データへのアクセス

プロファイル データを収集したら、以下のサンプルで示されるコードに類似したコードを使用して、そのデータにアクセスできます。サンプル内に太字で示したプロファイル タイプを、適切なものに置き換えます。コードの最初の部分では、収集されたプロファイル データ (jdbcProfData) が格納されるベクトル変数 (dataV) を定義します。コードの 2 番目の部分では、格納されたデータをベクトル変数から取得し、出力します。

}
jdbcProfData = getData("EventsDataArchive", "TYPE LIKE '%" +
JDBCLegalHelper.PROFILE_TYPE_CONN_USAGE_STR + "%'");
Vector dataV = new Vector();
for (int i = 0; i < jdbcProfData.length; i++) {
if (jdbcProfData[i].getPoolName().equalsIgnoreCase
(Data_Source_1))
dataV.add(jdbcProfData[i]);
}

System.out.println("records found for PROFILE_TYPE_CONN_USAGE_STR : " + 
dataV.size());
for (int a = 0; a < dataV.size(); a++) {
System.out.println("ID : " + ((ProfileDataRecord) 
dataV.get(a)).getId());
System.out.println("PoolName : " + ((ProfileDataRecord)
dataV.get(a)).getPoolName());
System.out.println("Time : " + ((ProfileDataRecord)
dataV.get(a)).getTimestamp());
System.out.println("User : " + ((ProfileDataRecord)
dataV.get(a)).getUser());
}

診断データにアクセスするもう 1 つの方法は、WebLogic 診断フレームワーク (WLDF) のデータ アクセサ コンポーネントを使用することです。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「データ アクセサを使用した診断データへのアクセス」を参照してください。

ドライバ レベルの統計をモニタするためのコールバック

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

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

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

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

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

デバッグの有効化

デバッグは、適切な ServerDebug コンフィグレーション属性を「true」に設定することで有効化できます。必要に応じて、サーバの StdoutSeverity を「Debug」に設定することもできます。

コンフィグレーション属性は、以下のいずれかの方法で変更できます。

コマンドラインを使用してデバッグを有効化する

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

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

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

WebLogic Server Administration Console を使用してデバッグを有効化する

WebLogic Server Administration Console を使用して、デバッグ値を設定します。

  1. まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします (『Oracle Fusion Middleware Oracle WebLogic Server の紹介』の「チェンジ センタの使用」を参照)。

  2. Administration Console の左ペインで、[環境] を展開して [サーバ] を選択します。

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

  4. [デバッグ] をクリックします。

  5. [デフォルト] を展開します。

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

  7. [有効化] (または [無効化]) を選択して、チェックを入れたデバッグ スコープまたは属性を有効化 (または無効化) します。

  8. Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。

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

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

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

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

java weblogic.WLST debug.py

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

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 ファイルに反映されます。コード リスト 6-1 を参照してください。

コード リスト 6-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 のデバッグ スコープ

java weblogic.diagnostics.debug.DebugScopeViewer を使うと DebugScope 定義をツリー表示できます。

以下に示す JDBC 用の登録済みデバッグ スコープを有効化できます。

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

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

  • 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 についてドライバ レベルでの追跡を得るには、ojdbc14.jar ではなく ojdbc14_g.jar の使用が必要です。このデバッグ スコープの場合、サーバ起動時にコマンドラインまたはコンフィグレーションを介して一度、有効化できますが、(DriverManager インタフェースがあるため) 動的に有効または無効にすることはできません。


    注意 :

    Oracle WebLogic JDBC Spy は、アプリケーションによって発行された JDBC 呼び出しに関する詳細情報をログに記録して、その呼び出しをラップされた WebLogic Type 4 JDBC ドライバに渡します。このログの情報は、アプリケーションの問題を解決するために使用できます。WebLogic JDBC Spy の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Type 4 JDBC ドライバ ガイド』の「WebLogic JDBC Spy による JDBC 呼び出しのトラッキング」を参照してください。

要求の仕分け

これ以外のデバッグ方法としては、JDBC サブシステムを介して個々の (通常は「仕分けされた」) アプリケーション リクエストのフローを追跡することです。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」を参照してください。