DB2 Version 10.1 for Linux, UNIX, and Windows
DB2 Version 10.1 for Linux, UNIX, and Windows
The following topics can help you to acquire the conceptual information that you need to effectively troubleshoot problems with the DB2® product:
Troubleshooting is a systematic approach to solving a problem. The goal is to determine why something does not work as expected and how to resolve the problem.
Depending on your platform, DB2 diagnostic information contained in a dump file, trap file, diagnostic log file, administration notification log file, alert log file, and first occurrence data collection (FODC) package can be found in the diagnostic data directory specified by the diagpath database manager configuration parameter.
The DB2 database manager writes the following kinds of information to the administration notification log: the status of DB2 utilities such as REORG and BACKUP; client application errors; service class changes, licensing activity; log file paths and storage problems; monitoring and indexing activities; and table space problems. A database administrator can use this information to diagnose problems, tune the database, or monitor the database.
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 is an excellent first task in understanding what has been happening to the database.
There are many other files and utilities available outside of DB2 to help analyze problems. Often they are just as important to determining root cause as the information made available in the DB2 files.
Learning more about messages can help you to identify an error or problem and resolve the problem by using the appropriate recovery action. This information can also be used to understand where messages are generated and logged.
There are two types of internal return codes: ZRC values and ECF values. They are displayed in DB2 trace output and in the db2diag log files. ZRC and ECF values are typically negative numbers and are used to represent error conditions.
Dump files are created when an error occurs for which there is additional information that would be useful in diagnosing a problem (such as internal control blocks). Every data item written to the dump files has a timestamp associated with it to help with problem determination. Dump files are in binary format and are intended for DB2 customer support representatives.
DB2 generates a trap file if it cannot continue processing because of a trap, segmentation violation, or exception. All signals or exceptions received by DB2 are recorded in the trap file. The trap file also contains the function sequence that was running when the error occurred. This sequence is sometimes referred to as the "function call stack" or "stack trace." The trap file also contains additional information about the state of the process when the signal or exception was caught.
First occurrence data capture (FODC) is the process used to capture scenario-based data about a DB2 instance. FODC can be invoked manually by a DB2 user based on a particular symptom or invoked automatically when a predetermined scenario or symptom is detected. This information reduces the need to reproduce errors to get diagnostic information.
A db2cos script is invoked by default when the database manager cannot continue processing due to a panic, trap, segmentation violation or exception.
Diagnosing some problems related to memory, swap files, CPU, disk storage, and other resources requires a thorough understanding of how a given operating system manages these resources. At a minimum, defining resource-related problems requires knowing how much of that resource exists, and what resource limits might exist per user.