Learning Visually with Examples [Electronic resources] نسخه متنی

17.4. DB2 First-Failure Data Capture

First-failure data capture (FFDC) is a general term applied to the set of diagnostic information that DB2 captures automatically when errors occur. This information reduces the need to reproduce errors to get diagnostic information. The information captured by FFDC is stored in the following files. (The DIAGPATH Database Manager Configuration parameter specifies the location of these files.)

• Administration notification log :
  When significant events occur, DB2 writes information to the administration notification log. The information is intended for use by database and system administrators. Many notification messages provide additional information to supplement the SQLCODE that is provided. The type of event and the level of detail of the information gathered are determined by the NOTIFYLEVEL configuration parameter. (The NOTIFYLEVEL parameter is discussed in the next section.)

  On Windows systems, the DB2 administration notification log is not created as a separate file; instead, its entries are incorporated into the Windows event log and can be reviewed through the Windows Event Viewer.

  On Linux and UNIX, the administration notification log for the instance is called

  instance_name .nfy.

• db2diag.log :
  Diagnostic information about errors is recorded in the db2diag.log text file. This information is more detailed than the administration notification log and is intended for DB2 technical support, but it can be useful for experienced database administrators. The level of detail of the information is determined by the DIAGLEVEL configuration parameter. (The DIAGLEVEL parameter is discussed in the next section.)

• Dump files :
  For some error conditions, extra information is logged in external binary files named after the failing process ID. These files have the file extension

  xxx , where

  xxx is the partition number. For single-partitioned environments, this extension is always

  000 . Dump files are intended for use by DB2 technical support.

• Trap files :
  The database manager generates a trap file if it cannot continue processing because of a trap, segmentation violation, or exception. Trap file names begin with the letter

  t and have the file extension

  TRP on Windows systems and

  xxx on Linux/UNIX systems, where

  xxx is the partition number. These files are intended for use by DB2 technical support.

• Core files

  (Linux/UNIX only) :
  When DB2 terminates abnormally, the operating system generates a core file. The core file is a binary file that contains information similar to the DB2 trap files. Core files may also contain the entire memory image of the terminated process. These files are intended for use by DB2 technical support.

17.4.1. The Database Manager Configuration Parameters Related to FFDC

The following Database Manager Configuration parameters are related to FFDC:

• DIAGPATH

• DIAGLEVEL

• NOTIFYLEVEL

17.4.1.1 The DIAGPATH Parameter

The DIAGPATH parameter specifies the fully qualified path in which DB2 puts the FFDC information. The default value for DIAGPATH is a null string. We recommend that you keep this default value. If you choose to change the value, we recommend that you use a centralized location, especially if there are multiple database instances.

When the value of DIAGPATH is a null string, the FFDC information is placed in the following locations.

• For Windows systems:

  - If the DB2INSTPROF environment variable is

  not set, the information is placed in DB2PATH\

  instance_name . DB2PATH is the environment variable that indicates where DB2 is installed on a Windows system.

  - If the DB2INSTPROF environment variable

  is set, the information is placed in DB2INSTPROF\

  instance_name ,DB2INSTPROF is the environment variable that indicates the location of the instance directory. The DB2INSTPROF variable is normally not set, therefore instances on Windows are created under the directory specified in DB2PATH.

• For Linux/UNIX operating systems:

  - The information is placed in

  $HOME /sqllib/db2dump, where

  $HOME is the home directory of the instance owner.

We recommend that you clean out the DIAGPATH directory periodically to keep it from becoming too large.

17.4.1.2 The DIAGLEVEL Parameter

The DIAGLEVEL parameter specifies the type of diagnostic errors that will be recorded in the db2diag.log file. Table 17.2 lists the valid values for this parameter. The default level is 3. Increase the level to 4 if you want more information. However, be aware that the db2diag.log grows very fast at the 4 level due to the large amount of information logged.

17.4.1.3 The NOTIFYLEVEL Parameter

The NOTIFYLEVEL parameter specifies the type of administration notification messages that are written to the administration notification log. On Linux/UNIX platforms, the administration notification log is a text file called

instance.nfy . On Windows, all administration notification messages are written to the Event Log. The errors can be written by DB2, the Health Monitor, the Capture and Apply programs, and user applications. Table 17.3 lists the valid values for this parameter. You might wish to increase the value of this parameter to gather additional problem determination data to help resolve a problem.

17.4.2. db2diag.log Example

The following is an example of a db2diag.log entry at a diagnostic level of 3:

2004-06-01-18.30.19.884359-240 I1179921C311       LEVEL: Event
PID     : 163880               TID  : 1           PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, config/install, sqlfLogUpdateCfgParam, probe:30
CHANGE  : CFG DBM: "Instance_Memory" <automatic> From: "3394" To: "2405"

Here is a breakdown of the entries in this db2diag.log:

• The message was generated at

  2004-06-01-18.30.19.884359 .

• The process ID (PID) is

  163880 .

• The thread ID (TID) is

  1 .

• The process name is

  db2star2 .

• The instance name is

  db2inst1 .

• The partition (node) number is

  0 as indicated by the field

  NODE : 000.

• The DB2 internal component identifier is

  config/install .

• The DB2 internal function identifier is

  sqlfLogUpdateCfgParam .

• The unique error identifier (probe ID) within the reported function is

  30 . This indicates where in the DB2 source code the error or warning is logged. This information is used only by DB2 Technical Support.

The last part of the message entry is a message that often includes error codes, page dumps, or other detailed information. Sometimes this information will be complex, but usually it will give you an idea of the type of operation that is causing the failure, along with some supporting information to help the investigation.

17.4.3. Administration Notification Log Examples

The following is a sample administration notification log entry in the notification log on a UNIX system:

2004-06-01-18.30.22.941721   Instance:sylviaq   Node:000
PID:163880(db2star2)   TID:1   Appid:none
base sys utilities  DB2StartMain Probe:911
ADM7513W Database manager has started.

You interpret these entries the same way as you do the entries in the db2diag.log. This message is logged when the Database Manager Configuration parameter NOTIFYLEVEL is set at 3 and indicates that the instance has started.

On Windows, you need to open the Windows Event Viewer to view the DB2 administration notification log entries. From the Windows

Start menu, choose

Administrative Tools >

Event Viewer . Figure 17.5 shows the Windows Event Viewer. The DB2 messages are displayed along with messages from other applications. The DB2 messages in the figure are displayed as

DB2-0 (where

DB2 is the instance name and

0 represents the partition number) in the Source column.

The entry highlighted is a DB2 message at warning level. Double-click on it to display the entire message, as shown in Figure 17.6.