Solving problems
This section analyzes several problem symptoms that you might encounter when using a trace.
Each symptom is listed in the following table, followed by an analysis of the problem and a suggested solution.
For more information about tracing running threads, see Recommendations-for-detail-traces-of-long-running-threads.
Symptom | Analysis | Solution |
|---|---|---|
| The target DB2 is no longer active: All current trace requests (and monitors) have a status of QIS. | You can check if the target DB2 is inactive by looking at the DB2 messages in the Journal Log (Option L, or PF5), or by requesting one of the online displays such as STDB2D. If the RST (restart) option for the trace is HOT, the trace is reactivated automatically when DB2 restarts. |
TRACE LIMIT EXCEEDED A detail trace was requested, but the maximum of four traces for that DB2 are already active. | One of the four detail traces must be stopped (not necessarily purged) before another can be started. | |
DB2 TRACE FAILURE A detail trace was requested, but the start trace request to DB2 failed. | Check the Journal Log for additional DB2 messages to determine and correct the error. | |
TRACE LOGGING QUIESCED Logging was requested, but logging is not active because the Trace Directory is not available. | Check the Journal Log at the time the BBI-SS PAS was started. Analyze the additional messages about the failure to allocate the Trace Directory. Correct the problem, and restart the BBI-SS PAS to activate logging. | |
GETMAIN RETURN AREA FAILURE A GETMAIN for buffer storage failed because the BBI-SS PAS region size was exceeded. | Reduce the size of STORAGE, TRSIZE, or TRBUFF to reduce the total amount of storage requested, or stop or purge other Current Traces to free up their storage allocations. A very large buffer GETMAIN (for example, STORAGE=8000K) might fail because of space fragmentation. | |
A trace request fails with the following message: BUFFERS EXCEED LIMIT | The specifications for buffer sizes exceeded the allowed limit (TRLIM) for a single trace. | Reduce the size of STORAGE, TRSIZE or TRBUFF to reduce the total amount of storage requested. The value for TRLIM is specified in BBPARM member DMRBEXxx. |
Extended CSA usage is too high, and several buffers contain DB2 trace data (identifier RMID=26). | When MainView for DB2 issues a DB2 Start Trace request, DB2 GETMAINs storage in ECSA based on the ZPARM MONSIZE value. The storage is freed only when DB2 terminates. The storage is reused when that OPx destination is reused for another trace request. | Ensure that you have not specified too high a value for MONSIZE. The default value is 256K. A maximum of eight buffers of MONSIZE size may be held by DB2. |
DB2 issues the following message: DSNW133I DSNWVSRV TRACE DATA LOST, OPx NOT ACCESSIBLE, RC=8 Later DB2 issues the following message: DSNW123I DSNWVSRV TRACE RECORDING HAS BEEN RESUMED ON OPx When you are viewing the trace displays (STRAC, DTRAC) some of the detail events are missing, and the following message might be displayed near the top of the screen: DZ3114W SOME DETAIL DATA LOST - BUFFER INCOMPLETE | MainView for DB2 cannot transfer the trace data that is passed from the DB2 IFI quickly enough. This situation might be caused by dispatching priority or the volume of events. |
|
No data is shown in an active trace for a long-running thread. | The data is being collected but is usually only shown in LTRAC/STRAC when the thread is completed and the DB2 accounting record is available. While the thread is active, you can view the events with the UTRAC display, which is like DTRAC, but it is accessible from DUSER for that thread. | You must set up trace logging to trace long-running threads effectively. This setting allows access to the DTRAC data while the thread is running. By accessing the trace data from the TLDS, you can see each buffer of detail trace events as it is filled and written to the trace log. For more information, see Recommendations-for-detail-traces-of-long-running-threads. |
No data is shown in an active trace for a long-running thread. | Trace records are being discarded, identified by either of the following messages: IM7910Wdddd MAX TRACE LOG RECORDS QUEUED, DISCARDING DZ0100Wdddd MAX TRACE RECORDS QUEUED, DISCARDING | For complete analysis and solution information, see Discarded-trace-records. |
When viewing a detail trace (STRAC or DTRAC displays), one of the following messages is displayed:
| When collecting detail trace data, an insufficient number or size of buffers was available to collect all event data that is being passed from DB2. NO BUFFER No buffer was available to collect the trace events for one or more threads. Only the accounting record is available for viewing for the thread. | Increase the number of buffers to three times the expected number of concurrent threads. Or: Restrict the number of concurrent threads that could be traced with the trace selection criteria DB2AUTH, DB2PLAN, or DB2LOC. |
When viewing a detail trace (STRAC or DTRAC displays), one of the following messages is displayed:
| BUFFER OVERFLOW At least once while a thread was being traced, the current buffer filled up and no additional buffer was available to continue. Tracing continues when a buffer becomes available but detail events in the middle or end of that thread are missing. | Increase TRBUFF or TRSIZE, or reduce the number of events to be traced. This problem is often caused by tracing LOCKS or DDFVTAM events, which can be overwhelming in number. To trace these events without logging, restrict the number of concurrent threads to one with selection criteria, specify TRBUFF=3, and increase TRSIZE. If you specify logging, ensure that you have three to five buffers per concurrent thread and keep the size as usual. Three buffers might not be enough to trace a single thread when running on a fast CPU and logging many events. In this case, the I/O to write a buffer and free it for reuse might not be fast enough. If you are tracing multiple threads (for example, 5 possible threads * 3 = 15 buffers), buffer usage and I/Os occur at different times for each thread. This situation increases the chances of finding a free buffer, and three probably will be sufficient. |
When viewing a detail trace (STRAC or DTRAC displays), one of the following messages is displayed:
| BUFFER INCOMPLETE Although sufficient buffer storage was available, at least some detail events are missing for one or more threads. The trace was started or stopped in the middle of thread processing--the first or last events are missing. If the trace was stopped before thread completion, only a dummy accounting record without statistics is available. | Start/stop the trace when no threads are processing, or ignore the incomplete threads. |
BUFFER INCOMPLETE The data from DB2 was arriving faster than it could be processed. | Check the Journal Log for message DSNW133I to verify the problem (dispatching priority or size of IFIBUFF) and refer to that symptom description. | |
BUFFER INCOMPLETE When you are viewing a long-running application from Current Traces (the online STORAGE buffer), the first events for some threads are missing because only the last two buffers per thread can be saved online. | View this trace from History Traces (the trace log data sets), where all buffers can be saved and combined to show the complete thread data. | |
BUFFER INCOMPLETE When you are viewing a thread that spans multiple trace log data sets, only the last log data set contains DB2 accounting statistics. Detail trace data (DTRAC, UTRAC, and detail trace summaries in STRAC and TSTAT) is incomplete in each log data set. However, accounting data in the final log is complete and represents the entire thread. The detail trace data in each log can be added together for total results. | When tracing applications that can span multiple buffers, allocating one large trace log data set is preferable to several small ones. |
Related topic