Oracle Weblogic JDBC General Issue Topics

Troubleshooting JDBC problems by debugging or tracing JDBC

JDBC debugging and tracing sometimes is key in order to find out what is going on and analyze the SQL statements that actually are sent to the database. However JDBC is a multi-layered subsystem, of which only parts are inside WebLogic Server. Debugging and tracing of the JDBC driver layer is highly driver-dependent. Information regarding debug and trace flags for the drivers are available from the driver vendors.
Once you have narrowed the problem down to a specific area, you can activate WebLogic Server’s debugging features to track down the specific problem within the application. Debugging can be activated by setting the appropriate ServerDebug configuration attribute to true. See Debugging JDBC Data Sources

• DebugJDBCConn (scope weblogic.jdbc.connection) will enable tracing of all connection reserve and release operations in data sources as well as all application requests to get or close connections.
• DebugJDBCSQL (scope weblogic.jdbc.sql) will print information about all JDBC methods invoked, including their arguments and return values, and thrown exceptions.
• DebugJDBCDriverLogging (scope weblogic.jdbc.driverlogging) will enable JDBC driver level logging. 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).

These debug flags and tracing can be very verbose, so consider very carefully where you turn on those flags. They will create a lot of output and also possibly have a slight performance impact on your system. They should not be turned on in production systems.

How to tune JDBC connection pools for production environments?

Configuration of JDBC connection pools for production systems is a critical and important task to ensure stability and performance. Some general recommendations may help as a starting point for administrators:

• Set InitialCapacity = MaxCapacity: This will ensure that all connections are opened during WebLogic Server startup. As creation of a physical database connection is very expensive, all needed connections should be opened immediately and kept open.  Before doing so, first insure that the physical memory of the database can handle all connections as they could easily add up in memory and lead to swaps.
• Disable shrinking by setting ShrinkingEnabledto false: As mentioned above, creation of physical database connections is expensive, so connections should be established once and kept during the complete lifetime of the WebLogic Server instance.
• Turn off refresh functionality if it is not needed: 
• Set TestConnectionsOnReserveto true. This will ensure that connections are tested before they go to the application and are reopened if needed.
• Set the number of connections in the JDBC pool equal to the number of execute threads that use the connections. This helps to avoid ResourceExceptions.