Diagnostic data directory path
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 capture (FODC) package can be found in the diagnostic data directory specified by the diagpath or alt_diagpath database manager configuration parameters.
- Primary diagnostic data directory path
- All diagnostic data for members, cluster caching facilities, database partition
servers, and database partitions is logged to a private db2diag log file. This split diagnostic data
directory path is the default condition unless you specify the diagpath value
with a valid path name and the
- Alternate diagnostic data directory path
- The alt_diagpath database manager configuration parameter is an alternate diagnostic data directory path that provides a secondary path for storing diagnostic information. The path specified by the alt_diagpath parameter is used only when the database manager fails to write to the path specified in diagpath and ensures that important diagnostic information is not lost. For the alternate diagnostic data directory path to be available, you must set the alt_diagpath configuration parameter. For greater resiliency, it is recommended that you set this parameter to a path that is on a different file system than diagpath.
The benefit of specifying a single diagnostic data directory path is that diagnostic information, from several database partitions and hosts, can be consolidated in a central location for easy access by setting a single diagnostic data directory path. The benefit of using the default split diagnostic data directory path is that diagnostic logging performance can be improved because of less contentions on the db2diag log file.
- Increased resiliency to the loss of important diagnostic information.
- Compatibility with some tools used for diagpath such as splitting.
Merging files and sorting records
Merging and sorting records of multiple diagnostic files of the same type, based on timestamps,
can be done with the db2diag -merge command in the case of a split diagnostic
data directory path. For more information, see:
db2diag - db2diag logs analysis
Space requirements for diagnostic data
Diagnostic data collection in the path specified by the diagpath parameter can generate large volumes of diagnostic information, especially if core file dumps and first occurrence data capture (FODC) data is not redirected to a separate directory path or if you use a single db2diag.log file that grows in size indefinitely. Enough space must be available to store the diagnostic data, and you must perform regular house keeping in the diagnostic path to ensure sufficient space remains available.
You can use the following recommendations when configuring diagnostic data logging on your data server to make sure space requirements for diagnostic data are met:
- Meet minimum space requirements for diagnostic
- The minimum amount of free space available in the diagnostic directory path should be two times the amount of physical memory installed on the machine (minimum free space = 2x physical memory). For example, if a machine has 64 GB of physical memory installed, a minimum of 128 GB of space for diagnostic data should be available in the file system.
- Redirect core file dumps and FODC data to a different directory path
- Both core file dumps and FODC data can consume significant disk space quickly and both send data to the directory path specified by the diagpath database manager configuration parameter by default. To keep more space available in the diagnostic directory path, core file dumps and FODC data can be redirected to a different directory path or file system. You can control where core files are generated through the DB2FODC registry variable by setting the DUMPDIR variable to point to a directory path that is different from diagpath. Similarly, you can control where FODC package directories are created by setting FODCPATH variable to point to a different directory path.
- Move or remove files that are no longer needed
- If you run the db2support command without specifying an output path that is different than diagpath, the resulting compressed archive is stored in the diagnostic directory path. Once you have uploaded the file to IBM, remember to move the compressed archive out of the diagnostic directory path or it will continue to consume available disk space.
- Configure for rotating diagnostic logs and archive log files
- By default, if you use a single db2diag.log file, the Db2 diagnostic log file will grow in size indefinitely. If you configure for rotating diagnostic logs by setting the diagsize database manager configuration parameter, then a series of rotating diagnostic log files and a series of rotating administration notification log files are used that fit into the size defined by diagsize. As log files fill up, the oldest files are deleted and new log files are created. In addition, when the oldest db2diag.log file is deleted, FODC directories and other diagnostic files older than the new db2diag.log time span will be deleted. To avoid losing information too quickly because of file rotation (the deletion of the oldest log file), set diagsize to a value that is greater than 50 MB but not more than 80% of the free space in the directory paths that you specify with the diagpath and alt_diagpath parameters. You can also preserve rotating diagnostic log files by archiving them from diagpath with the db2diag -archive command.
- Configure an alternate diagnostic path
- As a fail-safe to prevent the loss of important diagnostic information, the alt_diagpath database manager configuration parameter provides an alternate diagnostic data directory path for storing diagnostic information. If the database manager fails to write to the path specified by diagpath, the path specified by alt_diagpath is used to store diagnostic information until diagpath becomes available again. For greater resiliency, point the alt_diagpath parameter to a different file system than the diagpath parameter.