![]() ![]() ![]() ![]() ![]() ![]() |
This release of WebLogic Server includes the WebLogic Diagnostic Framework, which is a monitoring and diagnostic service that runs within the WebLogic Server process and participates in the standard server life cycle. This service enables you to create, collect, analyze, archive, and access diagnostic data generated by a running server and the applications deployed within its containers. This data provides insight into the runtime performance of servers and applications and enables you to isolate and diagnose faults when they occur. WebLogic JDBC takes advantage of this service to provide enhanced runtime statistics, profile information over a period of time, logging, and debugging to help you keep your WebLogic domain running smoothly.
You can use the runtime statistics to monitor the data sources in your WebLogic domain to see if there is a problem. If there is a problem, you can use profiling to determine which application is the source of the problem. Once you’ve narrowed it down to the application, you can then use JDBC debugging features to find the problem within the application.
The following sections include details about monitoring JDBC objects:
For more information about the WebLogic Diagnostic Framework, see Configuring and Using the WebLogic Diagnostic Framework.
Viewing runtime statistics allows you to monitor the data sources in your WebLogic domain.
You can view runtime statistics for a data source via the
Administration Console or through the JBCDataSourceRuntimeMBean
. The JDBCDataSourceRuntimeMBean
provides methods for getting the current state of the data source and for getting statistics about the data source, such as the average number of active connections, the current number of active connections, the highest number of active connections, and so forth. For more information, see
JDBCDataSourceRuntimeMBean in the WebLogic Server MBean Reference.
You can view runtime statistics for a prepared statement cache via the
Administration Console or through the JBCDataSourceRuntimeMBean
. For more information, see
JDBCDataSourceRuntimeMBean in the WebLogic Server MBean Reference.
If the statistics that you are seeing indicate that there is a problem in your WebLogic Server domain, you can configure any data source to collect profile information to help you pinpoint the source of the problem. The collected profile information is stored in records in the WLDF Archive. The fields contain different information for different profile types, as described in the sections that follow.
When configuring your data source for profiling, you must specify the interval at which profile data is harvested (Harvest Frequency Seconds
); if the interval is set to 0, harvesting of data is disabled. For more information, see
Configuring the Harvester for Metric Collection.
You can choose to profile the following information about data sources and the prepared statement cache, as described in the next sections of this document:
Enable connection usage profiling to collect information about threads currently using connections from the pool of connections in the data source. This profile information can help determine why applications are unable to get connections from the data source.
Note: | By default, enabling connection usage profiling on its own will not provide a stack trace of the threads using the connections. To obtain this information you must enable profiling of connection leaks in addition to enabling connection. For more information about profiling connection leaks see Connection Leak (PROFILE_TYPE_CONN_LEAK_STR). |
The record contains the following information:
Enable connection reservation wait profiling to collect information about threads currently waiting to reserve a connection from the data source. This profile information can help determine why applications are unable to get connections from the data source or to wait for connections. The record contains the following information:
Enable connection reservation failure profiling to collect information about threads that attempt to reserve a connection from the data source but fail to get that connection. This profile information can help determine why applications are unable to get connections from the data source even after reserving them. The record contains the following information:
Enable connection leak profiling to collect information about threads that have reserved a connection from the data source and the connection leaked (was not properly returned to the pool of connections). This profile information can help determine which applications are not properly closing JDBC connections. The record contains the following information:
Enable connection last usage profiling to collect information about the previous thread that last used the connection. This information is useful when you are debugging problems with connections infected in pending transactions that cause subsequent XA operations on the connections to fail. The record contains the following information:
Enable connection multithreaded usage profiling to collect information about threads that erroneously use a connection that was previously obtained by a different thread. This information is useful when an application reports a problem that you suspect may have been caused by the simultaneous use of a connection by more than one thread. The record contains the following information:
Enable statement cache entry profiling to collect information for prepared and callable statements added to the statement cache, and for the threads that originated the cached statements. This information can help you determine how the cache is being used. The record contains the following information:
Enable statements usage profiling to collect information about threads currently executing SQL statements from the statement cache. This information can help you determine how statements are being used. The record contains the following information:
Once profile data has been collected, you can access it using code similar to that shown in the sample below, substituting the appropriate profile type for the one shown in boldface type. The first part of the code defines a vector variable (dataV
) in which the collected profile data (jdbcProfData
) is stored. The second part of the code gets the stored data from the vector variable and prints it.
}
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());
}
Another method for accessing diagnostic data is to use the Data Accessor component of the WebLogic Diagnostic Framework (WLDF); for more information see “Accessing Diagnostic Data With the Data Accessor” in Configuring and Using the WebLogic Diagnostic Framework.
WebLogic Server provides callbacks for methods called on a JDBC driver. You can use these callbacks to monitor and profile JDBC driver usage, including methods being executed, any exceptions thrown, and the time spent executing driver methods.
To enable the callback feature, you specify the fully qualified path of the callback handler for the driver-interceptor element in the JDBC data source descriptor (module). Your callback handler must implement the weblogic.jdbc.extensions.DriverInterceptor interface. When you enable JDBC driver callbacks, WebLogic Server calls the preInvokeCallback()
, postInvokeExceptionCallback()
, and postInvokeCallback()
methods of the registered callback handler before and after invoking any method inside the JDBC driver.
Any time an application calls the JDBC driver, a callback is sent to the class that implemented the driver.
Once you have narrowed the problem down to a specific application, you can activate WebLogic Server’s debugging features to track down the specific problem within the application.
You can enable debugging by setting the appropriate ServerDebug
configuration attribute to "true
." Optionally, you can also set the server StdoutSeverity
to "Debug
".
You can modify the configuration attribute in any of the following ways.
Set the appropriate properties on the command line. For example,
-Dweblogic.debug.DebugJDBCSQL=true
-Dweblogic.log.StdoutSeverity="Debug"
This method is static and can only be used at server startup.
Use the WebLogic Server Administration Console to set the debugging values:
This method is dynamic and can be used to enable debugging while the server is running.
Use the WebLogic Scripting Tool (WLST) to set the debugging values. For example, the following command runs a program for setting debugging values called debug.py
:
java weblogic.WLST debug.py
The debug.py program contains the following code:
user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCSQL','true')
save()
activate()
Note that you can also use WLST from Java. The following example shows a Java file used to set debugging values:
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);
}
}
}
Using the WLST is a dynamic method and can be used to enable debugging while the server is running.
Changes in debugging characteristics, through console, or WLST, or command line are persisted in the config.xml
file. See
Figure 6-1, Example Debugging Stanza for JDBC, on page 6-10:
.
.
.
<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>
.
.
.
This sample config.xml
fragment shows a transaction debug scope (set of debug attributes) and a single JDBC attribute.
It is possible to see the tree view of the DebugScope definitions using java weblogic.diagnostics.debug.DebugScopeViewer.
You can enable the following registered debugging scopes for JDBC:
Note: | Oracle WebLogic JDBC Spy logs detailed information about JDBC calls issued by an application and then passes the calls to the wrapped WebLogic Type 4 JDBC driver. You can use the information in the logs to help troubleshoot problems in your application. For more information about WebLogic JDBC Spy, see “Tracking JDBC Calls with WebLogic JDBC Spy” in WebLogic Type 4 JDBC Drivers. |
Another option for debugging is to trace the flow of an individual (typically “dyed”) application request through the JDBC subsystem. For more information, see “Configuring the Dye Vector via the DyeInjection Monitor” in Configuring and Using the WebLogic Diagnostic Framework.
![]() ![]() ![]() |