If your application displays JDBC-related exception messages,
activate the JDBC trace service. The resulting log text can help you
identify the problem.
Turn on tracing for most database JDBC
implementations through the administrative console; see the article Enabling trace at server startup for instructions.
Turn on tracing for most database JDBC implementations
through the administrative console; see the articleTracing and logging configuration for instructions.
This method activates JDBC tracing for all applications that will
run in the server you specify. Identify your database type by selecting
the trace group WAS.database and typing one of the following trace
strings in the console:
- com.ibm.ws.database.logwriter Trace string for databases
that use the GenericDataStoreHelper. You can also use this trace
string for unsupported databases.
- com.ibm.ws.db2.logwriter Trace string for DB2 databases.
- com.ibm.ws.oracle.logwriter Trace string for Oracle databases.
- com.ibm.ws.derby.logwriter Trace string for Derby databases.
- com.ibm.ws.informix.logwriter Trace string for Informix
databases.
- com.ibm.ws.sqlserver.logwriter Trace string for Microsoft
SQL Server databases.
- com.ibm.ws.sybase.logwriter Trace string for Sybase databases.
A few JDBC drivers require that you set trace differently, at the
data source level. These drivers include:
Configuring trace for these drivers through the WAS.database
group results in corrupt trace information. WebSphere Application
Server sets trace for the group at the server level, causing the trace
service to begin only after your application establishes an initial
connection. Because that first connection does not carry trace information,
reusing that first connection is never tracked. Consequently the application
cannot accurately match trace information to connection use.
Provider-specific configuration
Some JDBC
providers have custom properties and configuration settings that you
can use to tweak their trace settings.
- DB2 data sources
The custom properties for a data source
with DB2 Data Server Driver for JDBC and SQLJ are:
- traceLevel
The possible values for traceLevel are:
- TRACE_NONE = 0
- TRACE_CONNECTION_CALLS = 1
- TRACE_STATEMENT_CALLS = 2
- TRACE_RESULT_SET_CALLS = 4
- TRACE_DRIVER_CONFIGURATION = 16
- TRACE_CONNECTS = 32
- TRACE_DRDA_FLOWS = 64
- TRACE_RESULT_SET_META_DATA = 128
- TRACE_PARAMETER_META_DATA = 256
- TRACE_DIAGNOSTICS = 512
- TRACE_SQLJ = 1024
- TRACE_XA_CALLS = 2048
- TRACE_META_CALLS = 8192
- TRACE_DATASOURCE_CALLS = 16384
- TRACE_LARGE_OBJECT_CALLS = 32768
- TRACE_SYSTEM_MONITOR = 131072
- TRACE_TRACEPOINTS = 262144
- TRACE_ALL = -1
Avoid trouble: Trace of Statement calls will expose
the user data in sets to the PreparedStatement objects, and Trace
of ResultSet calls will expose data returned in gets from the ResultSet
objects.
gotcha
- traceFile
- Specifies to integrate the DB2 Data Server Driver for JDBC and
SQLJ trace with the application server's trace function:
- If you do not set the value, traces are integrated.
If you
use integrated trace, you can dynamically enable or disable trace
by setting the following property in the application server's trace
specification at run time:
WAS.database=all
- If you set the traceFile property to a valid path name for a file,
then the Data Server Driver trace is written to the specified file
regardless of the application server's trace specification.
- traceFileAppend
- Specifies to append to or overwrite the file that is specified
by the traceFile property:
- To append to the current file, set the property to true.
- To overwrite the current file, set the property to false.
Avoid trouble: If you change the values
for traceLevel, traceFile, or traceFileAppend, then the you must restart
the application server to instantiate new data source objects with
the changed settings.
gotcha