Troubleshooting Guide

Taking Other Traces

There are other traces you can perform to diagnose problems. This section discusses:

• "Administration Tools Trace"

• "Taking a Graphical Interface Trace"

• "Taking a CLI/ODBC/JDBC Trace"

• "Taking a DB2 Connect Trace (ddcstrc)"

• "Taking a DRDA Trace (db2drdat)"

• "Taking an SNA Trace"

Administration Tools Trace

Occasionally, DB2 Customer Service may request that you take an administration tools trace. This trace is intended for DB2's graphical administrative tools (such as the Control Center, the Alert Center, and the Command Center), and provides additional information when these tools encounter a problem accessing or using a database. (If you suspect the user interface itself to be the problem, take an ICLUI trace instead; see "Taking a Graphical Interface Trace".)

This trace is only recommended for problems that can be re-created. It provides detailed information on requests, connections, attachments to instances, CLI calls, DAS requests, API calls, and other activities that were happening when the problem occurs.

The format of the trace file is similar to the log file (see "Using the Administrative Tools Log"), except that more information is recorded.

Depending on how much information is written to it, the trace file can grow to the maximum file size imposed by the operating system. The file is overwritten the next time you perform an administration tools trace.

Invoking an Administration Tools Trace

To invoke the administration tools trace facility:

1. Ensure that the tool is closed.

2. Set tracing on with the following command:

   set DBTTRACE=Y
   

3. You can specify where the trace file will be stored with the following command:

   set DBTTRACE_FILE=location
   

   • If location is a file name with a fully qualified path, the file will be created at that location.

     For example, the following command will send trace output to the file d:\aetrace:

     set DBTTRACE_FILE=d:\aetrace  
     

   • If location contains a file name only, the trace file will have that name, and be located in the directory specified by the DB2INSTPROF registry value. If this directory is read-only or does not exist, the file is created in the directory specified by the registry value DB2PATH.

   • If you do not use the set DBTTRACE_FILE command, or do not specify a value for location, the file's name is dbttrace.trc, and it is stored in the directory specified by the DB2INSTPROF or DB2PATH registry values (as described in the previous bullet).

4. Invoke the tool with its command. For example, use the db2cc.exe command to activate the trace for the Control Center.

5. Perform the procedure that caused the problem.

6. Close the tool.

7. Browse the trace file for diagnostic information. The file remains in the system until it is erased or overwritten by another trace.

Taking a Graphical Interface Trace

If you have problems with graphical interfaces on the Windows 95, Windows NT, or OS/2 operating systems, you can enable an ICLUI trace. This trace helps you diagnose problems with the user interface (for example, with windows or dialog boxes not appearing or not refreshing).

To invoke an ICLUI trace for the Control Center:

1. Ensure the Control Center is closed.

2. Set ICUI tracing on to collect standard error output:

   set ICLUI_TRACE=ON
   set ICLUI_TRACETO=STDERR
   

3. Invoke the Control Center with the following command:

   db2cc 2 > db2cc.out
   

   In this example, the ICLUI trace will be stored in a file called db2cc.out. (The "2" is a filepointer to standard log (STDLOG), which is being redirected to db2cc.out.)

4. Perform the procedure that caused the problem with the user interface.

5. Capture the db2cc.out file.

Taking a CLI/ODBC/JDBC Trace

The CLI trace can be used for any CLI, ODBC, or JDBC application that connects to DB2 using the CLI Driver.

To turn on this trace facility, set the db2cli.ini keyword option TRACE on (1). CLI trace records are appended to the file specified by the TRACEFILENAME keyword, or placed in the directory specified by the TRACEPATHNAME keyword.

For example, to set up a CLI trace file that is written to disk after each trace entry, include the following lines in the common section of the initialization file (DB2CLI.INI).

[COMMON]
TRACE=1
TRACEFILENAME=E:\TRACES\CLI\MONDAY.CLI
TRACEFLUSH=1

In the above example:

• The trace is activated by setting the value of TRACE to 1, and deactivated by setting it to 0.

• The trace output will be placed in the file E:\TRACES\CLI\MONDAY.CLI

  Alternatively, you can use the keyword TRACEPATHNAME to store files in a particular subdirectory. For information, see the Installing and Configuring DB2 Clients online book.

• With the value of TRACEFLUSH set to 1, the trace will write files to disk every time they are updated. This value is recommended to avoid loss of data in the event of a crash.

• These settings will apply to all connections to DB2:

You can configure the DB2 CLI/ODBC driver further by using the DB2 Client Configuration Assistant tool:

1. Select the DB2 database alias you are configuring.
2. Select the Settings push button. The Settings window appears.
3. Select the Settings push button. The ODBC Data Source Configuration window appears.
4. Select the Advanced push button. A notebook appears where you can set the configuration keywords.

For more information on taking CLI traces, see the online help for ODBC data sources in the Client Configuration tool. For information on determining when to take the traces, see the CLI Guide and Reference.

Taking a DB2 Connect Trace (ddcstrc)

The DB2 Connect trace (ddcstrc) is useful for diagnosing problems with the DB2 Connect product. For information, see the DB2 Connect User's Guide.

Taking a DRDA Trace (db2drdat)

Use the DRDA trace (db2drdat command) to capture the DRDA data stream exchanged between a DRDA Application Requestor (AR) and the DRDA Application Server (AS). This tool is most often used for problem determination, but you can also use it for performance tuning in a client/server environment by determining how many sends and receives are required to execute an application. You need one of SYSADM, SYSCTRL, or SYSMAINT authority to use it.

The syntax for the db2drdat command is shown in the following diagram. Explanations of the parameters follow.

                      +-------+
               +-on-+ V       |
>>-db2drdat--+-+----+---+--r-++--+-----------+-+---------------><
             |          +--s-+   +--l=length-+ |
             |          +--c-+                 |
             +-off--+--------------+-+--------++
                    +--t=tracefile-+ +--p=pid-+
 

Parameters

on

Turns on AS trace events (all if none are specified).

off

Turns off AS trace events.

-r

Traces DRDA requests received from the DRDA AR. Logged information includes:

• The type of DRDA request
• The receive buffer

-s

Traces DRDA replies sent to the DRDA AR. Logged information includes:

• The type of DRDA reply/object
• The send buffer

-c

Traces the SQLCA received from the DRDA requestor. This is a formatted, easy-to-read version of not null SQLCAs.

Logged CPI-C error information includes:

• Severity
• Protocol used
• API used
• Local LU name
• Failed CPI-C function
• CPI-C return code

-l

Specifies the size of the buffer used to store the trace information.

-p

Traces events only for the process with the specified process identifier (pid). If -p is not specified, all agents with incoming DRDA connections on the server are traced.

Note: Find out which process identifiers to trace from the agent field returned by the LIST APPLICATIONS command. For details, see the Command Reference.

-t

Specifies the destination file for the trace. If a file name is specified without a complete path, the path is determined from the current path.

Note: If tracefile is not specified, messages are directed to the db2drdat.dmp file in the current directory.

Notes:

• Do not issue the db2trc command while db2drdat is active. (For information on db2trc, see "Using the DB2 Trace Facility (db2trc)").

• The db2drdat command returns an exit code. A zero value indicates that the command completed successfully, and a nonzero value indicates that the command was not successful.

• If db2drdat sends the output to a file that already exists, the old file is erased unless the permissions on the file do not allow it to be erased. In this situation, the operating system returns an error.

Taking an SNA Trace

DB2 generates alerts to notify database administrators or network administrators of a serious database error or database server error. It uses two standards of alerts: SNMP (see "SNMP Alerts"), and SNA (for communication with MVS/ESA, VM, VSE, or AS/400 systems).

When an SNA alert is generated, it includes different kinds of information about the problem that occurred. You can use this information to help correct whatever is causing a problem with SNA and APPC communications.

For information on taking an SNA trace, use the keywords "SNA trace" at the DB2 Product and Service Technical Library at: http://www.software.ibm.com/data/db2/library/

[ DB2 List of Books | Search the DB2 Books ]