Managing diagnostic directories for Db2 or Db2 Warehouse
As a database administrator, you can clean up files created during various processes completed by Db2 or Db2 Warehouse.
Locate the diagnostic data directory by checking Db2 or Db2 Warehouse configuration settings or environment variable settings. If the files in the diagnostic directory path cause the file system to become full, take one of the following actions:
- Increase the size of the persistent volume claim.
- Move the files to another file system. See Table 1.
- Use the server to archive the files, and then delete them by using the following steps:
- Run the db2support utility to collect the Db2 or Db2 Warehouse system diagnostic information. For more information, see Using the db2support tool.
- Archive the db2support.zip file and diagnostic files that are listed in Table 1 to your server with the client.
- Delete the files that are listed in Table 1.
Important:
- Do not delete the db2diag.log file and files within the stmmlog directory. They contain history that can be useful for diagnosing server problems that are related to the database.
- Do not delete active logs that are within /mnt/logs/active or /mnt/bludata0/db2/databases/db2inst1/ log directory. To prune active log files, see PRUNE HISTORY/LOGFILE command.
Filename | Description |
---|---|
instance_name.nfy instance_name.n.nfy (such as db2inst.1.nfy) |
Administration notification logs |
db2eventlog.xxx (such as db2eventlog.123) | Db2® event log |
nnnnnnn.nnnnn.nnn.dump.bin (such as 1234567.12345.123.dump.bin) | Binary dump files of key in-memory structures |
nnnnnnn.n.nnn.trap.txt (such as 1234567.1.123.trap.txt) | Trap files |
nnnnnnn.nnnnn.nnn.apm.bin (such as 1234567.12345.123.amp.bin) | Access the plan-manager binary dump files |
nnnnnnn.nnnnn.nnn.stack.txt (1234567.12345.123.stack.txt | Stack traces |
FODC_xxxx/core<pid> | Core files These FODC_xxx directories contain the time stamp in the directory name. Keep the most recent directories and their files. The history can be useful for diagnosing possible future problems that are related to the database. A guideline is to keep at least 1 weeks worth. |
events/db2optstats.n.log (such as events/db2optstats.1.log) | Statistics log file |