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) 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, 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:

  • <source> Indicates the origin of the logged error. (You can find it at the end of the first line in the sample.) The possible values are:

    • origin - message is logged by the function where error originated (inception point)
    • OS - error has been produced by the operating system
    • received - error has been received from another process (client/server)
    • sent - error has been sent to another process (client/server)

  • MESSAGE Contains the message being logged. It consists of:

    • <messageID> - message number, for example, ECF=0x9000004A or DIA8604C
    • <msgText> - error description

    When the CALLED field is also present, <msgText> is an impact of the error returned by the CALLED function on the function logging a message (as specified in the FUNCTION field)

  • CALLED This is the function that returned an error. It consists of:

    • <prodName> - The product name: "OS", "Db2", "Db2 Tools" or "Db2 Common"
    • <compName> - The component name ('-' in case of a system call)
    • <funcName> - The called function name
  • OSERR This is the operating system error returned by the CALLED system call. (You can find it at the end of the same line as CALLED.) It consists of:
    • <errorName> - the system specific error name
    • <errno> - the operating system error number
  • ARG This section lists the arguments of a function call that returned an error. It consists of:
    • <N> - The position of an argument in a call to the "called" function
    • <typeTitle> - The label associated with the Nth argument typename
    • <typeName> - The name of the type of argument being logged
    • <size> - The size of argument to be logged
  • DATA This contains any extra data dumped by the logging function. It consists of:
    • <N> - The sequential number of data object being dumped
    • <typeTitle> - The label of data being dumped
    • <typeName> - The name of the type of data field being logged, for example, PD_TYPE_UINT32, PD_TYPE_STRING
    • <size> - The size of a data object