DB2 Version 9.7 for Linux, UNIX, and Windows

Interpretation of diagnostic log file entries

Use the db2diag log files analysis tool (db2diag) to filter and format the db2diag log files. With the addition of administration notification log messages being logged to the db2diag log files using a standardized message format, viewing the db2diag log files first is a recommended choice to understand what has been happening to the database.

As an alternative to using db2diag, you can use a text editor to view the diagnostic log file on the machine where you suspect a problem to have occurred. The most recent events recorded are the furthest down the file.

Note: The administration notification (instance_name.nfy) and diagnostic (db2diag.log) logs grow continuously as single log files. When the diagsize database manager configuration parameter is set to a nonzero value, both the administration notification and the db2diag log files become a series of rotating log files (instance_name.N.nfy and db2diag.N.log) having a limited total size which is determined by the value of the diagsize configuration parameter.

The following example shows the header information for a sample log entry, with all the parts of the log identified.

Note: Not every log entry will contain all of these parts. Only the first several fields (timestamp to TID) and FUNCTION will be present in all the db2diag log file records.
2007-05-18-14.20.46.973000-240 1  I27204F655 2  LEVEL: Info 3 
PID : 3228 4  TID : 8796 5  PROC : db2syscs.exe 6 
INSTANCE: DB2MPP 7  NODE : 002 8  DB : WIN3DB1 9 
APPHDL : 0-51 10  APPID: 9.26.54.62.45837.070518182042 11 
AUTHID : UDBADM 12  
EDUID : 8796 13  EDUNAME: db2agntp 14  (WIN3DB1) 2
FUNCTION: 15  DB2 UDB, data management, sqldInitDBCB, probe:4820
DATA #1 : 16  String, 26 bytes
Setting ADC Threshold to: 
DATA #2 : unsigned integer, 8 bytes 
1048576

Legend:

1.
A timestamp and timezone for the message.
Note: Timestamps in the db2diag log files contain a time zone. For example: 2006-02-13-14.34.35.965000-300, where "-300" is the difference between UTC (Coordinated Universal Time, formerly known as GMT) and local time at the application server in minutes. Thus -300 represents UTC - 5 hours, for example, EST (Eastern Standard Time).
2.
The record ID field. The recordID of the db2diag log files specifies the file offset at which the current message is being logged (for example, "27204") and the message length (for example, "655") for the platform where the DB2® diagnostic log was created.
3.
The diagnostic level of the message. The levels are Info, Warning, Error, Severe, Critical, and Event.
4.
The process ID
5.
The thread ID
6.
The process name
7.
The name of the instance generating the message.
8.
For multi-partition systems, the database partition generating the message. In a non-partitioned database, the value is "000".
9.
The database name
10.
The application handle. This value aligns with that used in db2pd output and lock dump files. It consists of the coordinator partition number followed by the coordinator index number, separated by a dash.
11.
Identification of the application for which the process is working. In this example, the process generating the message is working on behalf of an application with the ID 9.26.54.62.45837.070518182042.

A TCP/IP-generated application ID is composed of three sections

  1. IP address: It is represented as a 32-bit number displayed as a maximum of 8 hexadecimal characters.
  2. Port number: It is represented as 4 hexadecimal characters.
  3. A unique identifier for the instance of this application.
Note: When the hexadecimal versions of the IP address or port number begin with 0 through to 9, they are changed to G through to P. For example, "0" is mapped to "G", "1" is mapped to "H", and so on. The IP address, AC10150C.NA04.006D07064947 is interpreted as follows: The IP address remains AC10150C, which translates to 172.16.21.12. The port number is NA04. The first character is "N", which maps to "7". Therefore, the hexadecimal form of the port number is 7A04, which translates to 31236 in decimal form.

This value is the same as the appl_id monitor element data. For detailed information about how to interpret this value, see the documentation for the appl_id monitor element.

To identify more about a particular application ID, either:

  • Use the LIST APPLICATIONS command on a DB2 server or LIST DCS APPLICATIONS on a DB2 Connect™ gateway to view a list of application IDs. From this list, you can determine information about the client experiencing the error, such as its database partition name and its TCP/IP address.
  • Use the GET SNAPSHOT FOR APPLICATION command to view a list of application IDs.
  • Use the db2pd -applications -db <dbname> command.
12
The authorization identifier.
13
The engine dispatchable unit identifier.
14
The name of the engine dispatchable unit.
15.
The product name ("DB2"), component name ("data management"), and function name ("sqlInitDBCB") that is writing the message (as well as the probe point ("4820") within the function).
16.
The information returned by a called function. There may be multiple data fields returned.

Now that you have seen a sample db2diag log file entry, here is a list of all of the possible fields:

<timestamp><timezone>       <recordID>         LEVEL: <level> (<source>)
PID     : <pid>             TID  : <tid>       PROC : <procName>  
INSTANCE: <instance>        NODE : <node>      DB   : <database>
APPHDL  : <appHandle>       APPID: <appID>	
AUTHID  : <authID>
EDUID   : <eduID>           EDUNAME: <engine dispatchable unit name>
FUNCTION: <prodName>, <compName>, <funcName>, probe:<probeNum>
MESSAGE : <messageID>  <msgText>
CALLED  : <prodName>, <compName>, <funcName>   OSERR: <errorName> (<errno>)
RETCODE : <type>=<retCode> <errorDesc>
ARG #N  : <typeTitle>, <typeName>, <size> bytes
... argument ...
DATA #N : <typeTitle>, <typeName>, <size> bytes
... data ...

The fields which were not already explained in the example, are: