To see whether your specific problem has been addressed, review the Cannot access a data source topic. If you cannot find
your problem described there, investigate the problem further by using the
following instructions to enable
tracing for relevant WebSphere Application Server components.
This topic includes
the following sections:
Trace strings for JDBC data sources
Turn
on JDBC tracing by using the following trace strings:
- 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.cloudscape.logwriter Trace string for Cloudscape 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.
The trace group that includes the trace strings is WAS.database.
JDBC trace properties
Use a back-end
database that supports JDBC tracing. Setting trace strings does not result
in a trace if the database does not support JDBC tracing. The following databases
offer JDBC tracing at this time:
Set the level of trace desired for DB2 Universal database and
Oracle as custom properties on the datasource.
- DB2 Universal JDBC driver provider Custom properties for DB2 are:
- traceLevel Possible traceLevel values are:
- traceFile Use this property to integrate the DB2 trace with the
WebSphere Application Server trace. If you do not set the value, traces are
integrated. Otherwise, DB2 traces are directed to the desired file. You can
dynamically enable or disable trace. You can run an application and turn on
the DB2 trace if there is a problem. Use the run time trace enablement provided
with the Application Server by specifying a trace string of com.ibm.ws.db2.logwriter=all=enabled.
- Oracle JDBC provider Custom properties for Oracle are:
- oraclelogCategoryMask Controls the output category. The default
is 47, which is (OracleLog.USER_OPER 1 | OracleLog.PROG_ERROR 2 | OracleLog.ERROR
4 | OracleLog.WARNING 8 | OracleLog.DEBUG1 32).
Possible values are:
- OracleLog.USER_OPER 1
- OracleLog.PROG_ERROR 2
- OracleLog.ERROR 4
- OracleLog.WARNING 8
- OracleLog.FUNCTION 16
- OracleLog.DEBUG1 32
- OracleLog.SQL_STR 128
- oraclelogModuleMask Controls which modules write debug output.
The default is 1, which is OracleLog.MODULE_DRIVER 1.
Possible values are:
- OracleLog.MODULE_DRIVER 1,
- OracleLog.MODULE_DBACCESS 2
- oraclelogPrintMask Controls which information to print with each
trace message. The default is 62, which is ([OracleLog.FIELD_OBJECT for 9i
/ OracleLog.FIELD_CONN for 8i] 32 | OracleLog.FIELD_CATEGORY 16 | OracleLog.FIELD_SUBMOD
8 | OracleLog.FIELD_MODULE 4 | OracleLog.FIELD_TIME 2).
Possible values
are:
- OracleLog.FIELD_TIME 2
- OracleLog.FIELD_MODULE 4
- OracleLog.FIELD_SUBMOD 8
- OracleLog.FIELD_CATEGORY 16
- OracleLog.FIELD_OBJECT 32
- OracleLog.FIELD_THREAD 64
Notes for Oracle JDBC tracing:
- Oracle 9i requires the use of classes12_g.zip to display traces.
With Oracle8i, the classes12_g.zip is optional.
- You can dynamically enable or disable trace. You can run an application
and turn on the Oracle trace if there is a problem. Use the run-time trace
enablement provided with the WebSphere Application Server products, by specifying
a trace string of com.ibm.ws.oracle.logwriter=all=enabled.
If JDBC tracing
does not provide enough information to isolate and fix your problem, check
to see if the problem has been identified and documented by looking at the available online support (hints and
tips, technotes, and fixes). If you do not find your problem listed
there, contact IBM Support.
For current information available from IBM Support on known problems and
their resolution, see the IBM Support page.
IBM Support has documents that can save you time gathering information
needed to resolve this problem. Before opening a PMR, see the IBM Support page.