WebLogic JDBC のコンフィグレーションと管理
![]() |
![]() |
![]() |
![]() |
WebLogic Server のこのリリースには、WebLogic 診断サービスが含まれています。これは、WebLogic Server プロセス内で実行され、標準のサーバ ライフサイクルに参加する、モニタおよび診断サービスです。このサービスを使用すると、実行中のサーバおよびそのコンテナ内にデプロイされているアプリケーションによって生成された診断データを作成、収集、分析、アーカイブし、それらの診断データにアクセスできます。このデータを基に、サーバおよびアプリケーションの実行時パフォーマンスを把握できます。また、障害発生時に、このデータを使用して、障害を隔離および診断できます。WebLogic JDBC は、このサービスを利用して、実行時の統計、ある一定の期間に渡ってのプロファイル情報、ロギング、およびデバッグの機能を拡張し、WebLogic ドメインが円滑に実行され続けるよう支援します。
実行時の統計を使用すると、WebLogic ドメインのデータ ソースをモニタして、問題があるかどうかを確認することができます。問題があれば、プロファイリングによって、問題の原因となっているアプリケーションを判断できます。アプリケーションを絞り込んだら、JDBC デバッグ機能を使用して、そのアプリケーション内の問題点を突き止めます。
以下の節では、JDBC オブジェクトのモニタについて詳細に説明します。
WebLogic 診断サービスの詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』を参照してください。
実行時の統計を表示すると、WebLogic ドメインのデータ ソースをモニタできます。
データ ソースの実行時の統計は、Administration Console または JBCDataSourceRuntimeMBean
を使って表示できます。JDBCDataSourceRuntimeMBean
は、データ ソースの現在の状態を取得したり、アクティブな接続の平均数、現在のアクティブな接続数、アクティブな接続の最大数などデータ ソースに関する統計を取得したりするためのメソッドを提供します。詳細については、『WebLogic Server MBean リファレンス』の「JDBCDataSourceRuntimeMBean」を参照してください。
プリペアド ステートメント キャッシュの実行時の統計は、Administration Console または JBCDataSourceRuntimeMBean
を使って表示できます。詳細については、『WebLogic Server MBean リファレンス』の「JDBCDataSourceRuntimeMBean」を参照してください。
表示されている統計から WebLogic Server ドメインに問題があると分かった場合は、任意のデータ ソースをコンフィグレーションして、問題の原因を特定するのに役立つ、プロファイル情報を収集できます。収集されたプロファイル情報は、WLDF アーカイブの中のレコードに格納されます。後述するように、各フィールドには、プロファイル タイプごとに別の情報が格納されます。
プロファイリングのためにデータ ソースをコンフィグレーションする際には、プロファイル データ収集の間隔 (Harvest Frequency Seconds
) を指定する必要があります。間隔を 0 に設定すると、データ収集は無効化されます。詳細については、「メトリック収集用のハーベスタのコンフィグレーション」を参照してください。
このマニュアルで後述するように、データ ソースおよびプリペアド ステートメント キャッシュについて、以下の情報のプロファイリングを選択することができます。
データ ソース内の接続のプールからの接続を現在使用しているスレッドに関する情報を収集するには、接続使用状況のプロファイルを有効化します。このプロファイル情報は、アプリケーションがデータ ソースからの接続を取得できない理由を判断するのに役立ちます。
注意 : デフォルトでは、接続使用状況のプロファイルを独自に有効化しても、接続を使用しているスレッドのスタック トレースは得られません。この情報を得るには、接続の有効化に加えて、接続リークのプロファイルを有効化する必要があります。接続リークのプロファイルの詳細については、「接続リーク (PROFILE_TYPE_CONN_LEAK_STR)」を参照してください。
データ ソースからの接続の予約を現在待機しているスレッドに関する情報を収集するには、待機中の接続予約のプロファイルを有効化します。このプロファイル情報は、アプリケーションがデータ ソースからの接続を取得できない、または接続を待機できない理由を判断するのに役立ちます。レコードには、以下の情報が格納されています。
データ ソースからの接続を予約しようとしても、取得に失敗するスレッドに関する情報を収集するには、失敗した接続予約のプロファイルを有効化します。このプロファイル情報は、アプリケーションがデータ ソースからの接続を、予約後も取得できない理由を判断するのに役立ちます。レコードには、以下の情報が格納されています。
リークされた (接続のプールに正常に戻されなかった) 接続、およびデータ ソースからの接続を予約したスレッドのプロファイルを収集するには、接続リークのプロファイルを有効化します。このプロファイル情報は、JDBC 接続を正しく閉じていないアプリケーションを判断するのに役立ちます。レコードには、以下の情報が格納されています。
最後に接続を使用した以前のスレッドに関する情報を収集するには、接続の最終使用状況のプロファイルを有効化します。この情報は、接続に対する後続の XA 操作の失敗を招く保留中のトランザクションで発生した接続に関する問題をデバッグする際に役立ちます。レコードには、以下の情報が格納されています。
別のスレッドによって以前に取得された接続を誤って使用するスレッドに関する情報を収集するには、マルチスレッド接続使用状況のプロファイルを有効にします。この情報は、接続が複数のスレッドによって同時に使用されていることが原因ではないかと思われる問題をアプリケーションが報告した場合に有用です。レコードには、以下の情報が格納されています。
ステートメント キャッシュに追加されたプリペアド ステートメントと呼び出し可能ステートメント、およびキャッシュされた文から発生したスレッドに関する情報を収集するには、ステートメント キャッシュ エントリのプロファイルを有効にします。この情報は、キャッシュがどのように使われているかを判断するのに役立ちます。レコードには、以下の情報が格納されています。
ステートメント キャッシュからの SQL 文を現在実行しているスレッドに関する情報を収集するには、ステートメント使用状況のプロファイルを有効にします。この情報は、文がどのように使われているかを判断するのに役立ちます。レコードには、以下の情報が格納されています。
プロファイル データを収集したら、以下のサンプルで示されるコードに類似したコードを使用して、そのデータにアクセスできます。サンプル内に太字で示したプロファイル タイプを、適切なものに置き換えます。コードの最初の部分では、収集されたプロファイル データ (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) のデータ アクセサ コンポーネントを使用することです。詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』の「データ アクセサを使用した診断データへのアクセス」を参照してください。
WebLogic Server では、JDBC ドライバに対して呼び出されるメソッドのコールバックを提供しています。これらのコールバックは、実行されているメソッド、任意の送出された例外、ドライバ メソッドの実行に費やされた時間など、JDBC ドライバの使用状況をモニタおよびプロファイリングするために使用できます。
コールバック機能を有効化するには、JDBC データ ソース記述子 (モジュール) 内の driver-interceptor 要素に対するコールバック ハンドラの絶対パスを指定する必要があります。コールバック ハンドラには、weblogic.jdbc.extensions.DriverInterceptor インタフェースが実装されている必要があります。JDBC ドライバのコールバックが有効化されていると、WebLogic Server は JDBC ドライバ内の任意のメソッドの呼び出し前と呼び出し後に、登録されたコールバック ハンドラの preInvokeCallback()
、postInvokeExceptionCallback()
、または postInvokeCallback()
メソッドを呼び出します。
アプリケーションが JDBC ドライバを呼び出すと、必ずそのドライバを実装したクラスにコールバックが送信されます。
特定のアプリケーションに問題があると突き止めたら、WebLogic Server のデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。
デバッグは、適切な ServerDebug
コンフィグレーション属性を「true
」に設定することで有効化できます。必要に応じて、サーバの StdoutSeverity
を「Debug
」に設定することもできます。
コンフィグレーション属性は、以下のいずれかの方法で修正できます。
コマンドラインで適切なプロパティを設定します。次に例を示します。
-Dweblogic.debug.DebugJDBCSQL=true
-Dweblogic.log.StdoutSeverity="Debug"
この方法は静的なものであり、サーバの起動時にのみ使用できます。
WebLogic Server Administration Console を使用して、デバッグ値を設定します。
WebLogic Server 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 の使用は動的な方法であり、サーバの実行中にデバッグを有効化するのに使用できます。
Administration Console、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 属性を示します。
java weblogic.diagnostics.debug.DebugScopeViewer
を使うと DebugScope 定義をツリー表示できます。
以下に示す JDBC 用の登録済みデバッグ スコープを有効化できます。
注意 : BEA WebLogic JDBC Spy は、アプリケーションによって発行された JDBC 呼び出しに関する詳細情報をログに記録して、その呼び出しをラップされた WebLogic Type 4 JDBC ドライバに渡します。このログの情報は、アプリケーションの問題を解決するために使用できます。WebLogic JDBC Spy の詳細については、『WebLogic Type 4 JDBC ドライバ ガイド』の「WebLogic JDBC Spy による JDBC 呼び出しのトラッキング」を参照してください。
これ以外のデバッグ方法としては、JDBC サブシステムを介して個々の (通常は「仕分けされた」) アプリケーション リクエストのフローを追跡することです。詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』の「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」を参照してください。
![]() ![]() |
![]() |
![]() |