Personal tools
You are here: Home DB2 How To's How to read db2diag.log file
Navigation
Log in


Forgot your password?
 
Document Actions

How to read db2diag.log file

When an error occurs, the db2diag.log file is updated with information about the error.

The following example shows the header information for a sample db2diag.log file entry.


1997-03-16-11.53.18.001160 (1)   Instance:payroll (2)  Node:000 (3)
PID:44829(db2agent (SAMPLE)) (4) Appid:*LOCAL.payroll.970317140834 (5)
lock_manager (6) sqlplrq (7) Probe:111 (8) Database:SAMPLE (9)
DIA9999E (10) An internal return code occurred. Report the following:
"0xFFFFE10E". (11)

Legend:

(1)
A timestamp for the message.
(2)
The name of the instance generating the message.
(3)
For DB2 Enterprise - Extended Edition systems with a db2nodes.cfg file, the node generating the message. (If the db2nodes.cfg file is not used, the value is "000".)
(4)
Identification of the process generating the message. In this example, the message came from the process identified as 44829. The name of this process is db2agent and it is connected to the database named SAMPLE.

Note: If the application is operating in a DUOW environment, the ID shown is the DUOW correlation token.

(5)
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 *LOCAL.payroll.970317140834.

To identify more about a particular application ID, either:

  • Use the db2 list applications command to view a list of application IDs. From this list, you can determine information about the client experiencing the error, such as its node name and its TCP/IP address.
  • Use the db2 get snapshot for application command to view a list of application IDs.
(6)
The DB2 component that is writing the message. For messages written by user applications using the db2AdminMsgWrite API, the component will read "User Application".
(7)
The name of the function that is providing the message. This function operates within the DB2 subcomponent that is writing the message. For messages written by user applications using the db2AdminMsgWrite API, the function will read "User Function".

To find out more about the type of activity performed by a function, look at the fourth letter of its name. In this example, the letter "p" in the function "sqlplrq" indicates a data protection problem. (Logs could be damaged, for example.)

The following list shows some of the letters used in the fourth position of the function name, and the type of activity they identify:

b
Buffer pools
c
Communication between clients and servers
d
Data management
e
Engine processes
o
Operating system calls (such as opening and closing files)
p
Data protection (such as locking and logging)
r
Relational database services
s
Sorting
x
Indexing
(8)
Identification of the internal error that was reported.
(9)
The database on which the error occurred.
(10)
Diagnostic message indicating that an internal error occurred.
(11)
Hexadecimal representation of an internal return code. 


Notes:

  • Check the end of the file for the most recent data, because new information is always appended to the bottom of the file.
  • Entries always have a timestamp. If you know when an error occurred, look for the first entry in the file marked with this time.
  • The db2diag.log file grows continuously. When it gets too large, back it up and then erase the file. A new db2diag.log file is generated automatically the next time it is required by the system.

Security Awareness
Would you like your company to implement gamification into your security awareness program?





Polls