JDBC Debugging Scopes Request Dyeing

13-8 Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server

13.3.2 JDBC Debugging Scopes

The following are registered debugging scopes for JDBC: ■ DebugJDBCSQL scope weblogic.jdbc.sql - prints information about all JDBC methods invoked, including their arguments and return values, and thrown exceptions. ■ DebugJDBCConn scope weblogic.jdbc.connection - trace all connection reserve and release operations in data sources as well as all application requests to get or close connections. ■ DebugJDBCRMI scope weblogic.jdbc.rmi - similar to JDBCSQL but at the RMI level; turning on this one and JDBCSQL will get two sets of debug messages for each operation called from a client. ■ DebugJDBCInternal scope weblogic.jdbc.internal - low level debugging in weblogicjdbccommoninternal related to the data source, the connection environment, and the data source manager. ■ DebugJDBCDriverLogging scope weblogic.jdbc.driverlogging - enables JDBC driver level logging this replaces ServerMBean JDBCLoggingEnabled and getJDBCLogFileName. Note that to get driver level tracing for Oracle, you need to use ojdbc14_g.jar instead of ojdbc14.jar. Note that for this debug scope, it can be turned on once via the command line or configuration when the server is booted but cannot be turned on or off dynamically due to the DriverManager interface.

13.3.3 Request Dyeing

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 Diagnostics Framework for Oracle WebLogic Server. Note: Oracle WebLogic JDBC Spy logs detailed information about JDBC calls issued by an application and then passes the calls to the wrapped Oracle 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 Type 4 JDBC Drivers for Oracle WebLogic Server. 14 Managing WebLogic JDBC Resources 14-1 14 Managing WebLogic JDBC Resources Using the Administration Console, command line, JMX programs, or WebLogic Scripting Tool WLST scripts, you can manage the JDBC data sources in your domain. This section includes the following information: ■ Section 14.1, Testing Data Sources and Database Connections ■ Section 14.2, Managing the Statement Cache for a Data Source ■ Section 14.3, Shrinking a Connection Pool ■ Section 14.4, Resetting a Connection Pool ■ Section 14.5, Suspending a Connection Pool ■ Section 14.6, Resuming a Connection Pool ■ Section 14.7, Shutting Down a Data Source ■ Section 14.8, Starting a Data Source ■ Section 14.9, Managing DBMS Network Failures

14.1 Testing Data Sources and Database Connections

JDBCDataSourceRuntimeMBean.testPool To make sure that the database connections in a data source remain healthy, you should periodically test the connections. WebLogic Server includes two basic types of testing: automatic testing that you configure with attributes on the data source and manual testing that you can do to trouble-shoot a data source. Allowing WebLogic Server to automatically maintain the integrity of pool connections should prevent most DBMS connection problems. For more information about configuring automatic connection testing, see Section 10.2, Connection Testing Options for a Data Source. To manually test a connection from a data source, you can use the Test Data Source feature on the JDBC Data Source: Monitoring: Testing page in the Administration Console see Test JDBC data sources or the testPool method in the JDBCDataSourceRuntimMBean . To test a database connection from a data source, Test Reserved Connections must be enabled and Test Table Name must be defined in the data source configuration. Both are defined by default if you create the data source using the Administration Console. When you test a data source, WebLogic Server reserves a connection, tests it using the query defined in Test Table Name, and then releases the connection.