DB2 Version 9.7 for Linux, UNIX, and Windows

System core files (Linux and UNIX)

If a program terminates abnormally, a core file is created by the system to store a memory image of the terminated process. Errors such as memory address violations, illegal instructions, bus errors, and user-generated quit signals cause core files to be dumped.

The core file contains core in the file name and is placed in the directory specified by the diagpath database manager configuration parameter, by default, unless otherwise configured using the values in the DB2FODC registry variable. Note that system core files are distinct from DB2® trap files.

Core file control settings

Core files can result in the generation of large volumes of diagnostic data that require space to store and can impose a significant overhead on the system. To help you control how core files are handled, several DB2FODC registry variable settings are available. You can make DB2FODC registry variable settings persistently with the db2set command or change them dynamically (in-memory only) through the db2pdcfg command. Persistent settings made with the db2set command do not become effective until the instance is recycled; dynamic settings made with the db2pdcfg command are effective immediately and until the instance is recycled.

You can control the following core file behaviors through the DB2FODC registry variable:

Whether core files are generated or not (with the DUMPCORE setting)
How big core files can become (with the CORELIMIT setting)
Where the generated core files are stored (with the DUMPDIR setting)

As a rule, a core file can become as large as the amount of physical memory installed on the machine where the core file is generated. For example, if your data server has 64 GB of physical memory, there must be at least 64 GB of space available in the directory path where the core file will be stored. It is possible to limit the size of the core file, but it is recommended that you configure core file behaviour to point to a file system with enough space available instead. If you must limit the amount of space a core file can use, ensure that the amount of space available is at least as great as the amount of physical memory on the machine or you risk truncating the core file and losing diagnostic information. For example, to limit the amount of space available for core file generation to 64 GB and to redirect core files to /tmp persistently, issue the following command. The settings will become effective only after the instance is recycled.

db2set DB2FODC="CORELIMIT=64000000000 DUMPDIR=/tmp"

When a core file is generated, it can impose a significant overhead on the system, which in turn can affect system availability. If the performance impact to system availability during core file generation is unacceptable, you can disable core file generation, but it is recommended that you do not disable it permanently. Core files contain diagnostic information that can be required in order to troubleshoot a problem successfully. If diagnostic information is not available because core file generation was turned off permanently, troubleshooting a problem with your data server might become impossible. For example, to turn core file generation off dynamically, effective immediately and until the instance is recycled, issue the following command:

db2pdcfg DB2FODC="DUMPCORE=OFF"