Troubleshooting Guide

Using the System Error Log (syslog)

DB2 logs severe error and warning conditions to the system error log (syslog). These entries are usually a subset of what appears in the db2diag.log. The exception is when a severe error occurs where the DB2 database manager was not able to write to the db2diag.log. When such errors occur, it is recommended that you look at the syslog file.

Entries are added to the syslog based on priority and on what facility caused the error or warning condition. For example, system security, the kernel, and system daemons can all cause entries to be logged.

Priority refers to the urgency of the message. Message priorities are as follows, listed from highest to lowest:

Emergency
Alert
Critical
Error
Warning
Notice
Information
Debug

DB2 adds alert messages to the system error log only for very severe situations (for example, if agents are killed or the architecture of a database is compromised). Alerts are also referenced in the db2diag.log and in the alert log (db2alert.log). For more information, see First Failure Data Capture.

Setting Up the System Error Log

To route alerts to the system error log, perform the following the steps:

Each machine can be configured to log various combinations of facilities and priorities. To begin logging DB2 error and warning conditions in the syslog, you must generate a log file by adding the following line to the /etc/syslog.conf file. This action requires that you have system authority.
```
       user.warn     fully_qualified_file_name
```
where:
- user is the facility to log. This includes DB2 and any other applications logging messages with the same facility name.
- warn is the priority over which messages are logged. The syslog file logs error and warning conditions that are of equal and higher priority than this priority level. Available choices are:
  
  alert
  Only alert messages are logged
  err
  Error and alert messages are logged
  warn
  Warning, error, and alert messages are logged
  info
  Information, warning, error, and alert messages are logged
- fully_qualified_file_name is the file (along with its fully qualified path) where the messages will be logged and the SQLCA will be dumped. This file will not be created by the system; you must create it in the specified path.
The syslog daemon must be sent a signal to restart so that it will know about the new configuration in the syslog.conf file. Use:
- For AIX only:
```
refresh -s syslogd
```
- For AIX and other UNIX-based systems:
```
kill -1 pid_of_syslogd
```
  where pid_of_syslogd is the process ID of the syslogd process. You can obtain this process ID by issuing the ps -fu syslogd command. You must have system authority in order to use the kill -1 command.
Check to see if information is being logged into the syslog file by issuing:
```
ps -fu db2sysc
kill -36 db2sysc.process.id
```
Check the file at fully_qualified_file_name (as defined in the /etc/syslog.conf file). If there is information in the file, then the system error log has been enabled to capture the information.
The log file may grow quickly, and you will have to reduce its size periodically. You must use kill -1 pid_of_syslog after you issue the following commands:
```
mv logfile logfile.old
touch logfile
```
Instead of using a kill command, for AIX you can include the following line in the crontab that you run as part of your regular system maintenance:
```
refresh -s syslogd
```

Understanding the System Error Log

Messages generated by the database manager appear in the /etc/syslog.conf file.

An example of an entry in the system log is shown below. In this example, the entries are truncated to fit on the page.

Jun 18 15:02:53 bluj DB2[46827]: DB2(db2inst1.000(1))oper_system_services sqlobeep(2) reports:(3) Jun 18 15:02:53 (4) bluj (5) DB2[46827(6)]: extra symptom string provided:(7) RIDS/sqlesysc_ Jun 18 15:02:53 bluj DB2[46827]: data: (8) 54686973 20697320 616e2065 78616d70 Jun 18 15:02:53 bluj DB2[46827]: data: 6c65206f 66206c6f 67676564 20646174 Jun 18 15:02:53 bluj DB2[46827]: data: 61 Jun 18 15:02:53 bluj DB2[46827]: 2 piece(s) of dump data provided... to file(9) /u/db2inst1/ Jun 18 15:02:53 bluj DB2[46827]: 1. 'DUMP EXAMPLE #1' has been dumped (10) Jun 18 15:02:53 bluj DB2[46827]: 2. 'DUMP EXAMPLE #2' has been dumped

Legend:

(1)

The instance name and, for DB2 Universal Database Enterprise - Extended Edition for the Solaris Operating Environment and DB2 Universal Database Enterprise - Extended Edition for Windows NT; systems with a db2nodes.cfg file, the node number.

(2)

The reporting component and function.

(3)

The first line continues with the probe ID and error and alert numbers.

(4)

A timestamp for when the event occurred.

(5)

The host name.

(6)

The process ID of the reporting process

Use the ps command to view information about the process id of the reporting process. For example, execute the following command to get information about the reporting process:

ps -fu 46827

(7)

A symptom string that contains additional information about where and why the problem occurred.

(8)

A hexadecimal dump of data that includes return codes and other information that can be interpreted by DB2 Customer Support.

(9)

Information about additional dump files. Larger structures and other binary data may be dumped to additional files. Typically these files are located in /u/$DB2INSTANCE/sqllib/db2dump. The name of the file is identified in the syslog file.

(10)

An entry to identify a piece of dump data.

[ Top of Page | Previous Page | Next Page ]