If you experience a recurring and reproducible
problem with DB2®, tracing sometimes
allows you to capture additional information about it. Under normal
circumstances, you should only use a trace if asked to by IBM Software Support.
The process of taking a trace entails setting up the trace facility,
reproducing the error and collecting the data.
The amount of information gathered by a trace grows rapidly. When
you take the trace, capture only the error situation and avoid any
other activities whenever possible. When taking a trace, use the smallest
scenario possible to reproduce a problem.
Collecting a trace often has a detrimental effect on the performance
of a DB2 instance. The degree
of performance degradation is dependent on the type of problem and
on how many resources are being used to gather the trace information.
IBM Software
Support should provide the following information when traces are requested:
- Simple, step by step procedures
- An explanation of where each trace is to be taken
- An explanation of what should be traced
- An explanation of why the trace is requested
- Backout procedures (for example, how to disable all traces)
Though you should be counseled by IBM Software Support as to which traces to obtain,
here are some general guidelines as to when you'd be asked to obtain
particular traces:
- If the problem occurs during installation, and the default installation
logs are not sufficient to determine the cause of the problem, installation
traces are appropriate.
- If the problem occurs in one of the GUI (Graphical User Interface)
tools, and the same actions succeed when performed via explicit commands
in the DB2 command window, then
a Control Center trace is appropriate. Note that this will only capture
problems with tools that can be launched from the Control Center.
- If the problem manifests in a CLI application, and the problem
cannot be recreated outside of the application, then a CLI trace is
appropriate.
- If the problem manifests in a JDBC application, and the problem
cannot be recreated outside of the application, then a JDBC trace
is appropriate.
- If the problem is directly related to information that is being
communicated at the DRDA® layer,
a DRDA trace is appropriate.
- For all other situations where a trace is feasible, a DB2 trace is most likely to be appropriate.
Trace information is not always helpful in diagnosing an error.
For example, it might not capture the error condition in the following
situations:
- The trace buffer size you specified was not large enough to hold
a complete set of trace events, and useful information was lost when
the trace stopped writing to the file or wrapped.
- The traced scenario did not recreate the error situation.
- The error situation was recreated, but the assumption as to where
the problem occurred was incorrect. For example, the trace was collected
at a client workstation while the actual error occurred on a server.