Section 17.4. DB2 First-Failure Data Capture


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.

Table 17.2. Values for the DIAGLEVEL Parameter

Value

What It Captures

0

No diagnostic data.

1

Only severe errors.

2

All errors.

3

All errors and warnings (this is the default).

4

All errors, warnings, and informational messages.


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.

Table 17.3. Values for the NOTIFYLEVEL Parameter

Value

What It Captures

0

No administration notification messages (this setting is not recommended).

1

Only fatal and unrecoverable errors.

2

Everything captured at NOTIFYLEVEL 1, plus conditions that require immediate attention from the system administrator or the database administrator. If the condition is not resolved, it could lead to a fatal error. Notification of very significant, non-error activities (for example, recovery) might also be logged at this level. This level captures Health Monitor alarms.

3

Everything captured at NOTIFYLEVEL 2, plus conditions that are nonthreatening and do not require immediate action but might indicate the system is not optimal. This level captures Health Monitor alarms, Health Monitor warnings, and Health Monitor attentions. This is the default.

4

Everything captured at NOTIFYLEVEL 3, plus informational messages.


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.

Figure 17.5. The Windows Event Viewer


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.

Figure 17.6. DB2 administration notification log entry on Windows




Understanding DB2(R. Learning Visually with Examples)
Understanding DB2: Learning Visually with Examples (2nd Edition)
ISBN: 0131580183
EAN: 2147483647
Year: 2004
Pages: 313

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net