75 ways to demystify DB2 #72: Techtip : As a DBA, how should I manage DB2 diagnostic files?

Body

With the increasing use of autonomic technologies, DB2 servers can produce large message logging files, administrative notification log files, and event log files. This is especially true in large warehouse environments with many logical and physical partitions. When a fault occurs, the database manager can produce vast amounts of diagnostic data for first failure data capture (FODC) purposes. This increase in logging activity can lead to increased file system space consumption and manageability issues. Allowing the db2diag.logfile to grow until it consumes all space in the file system can lead to significant problems. Simply deleting the diagnostic log files is not a viable option because DB2 support often requests historical diagnostic data.

It is recommended that you download and use the db2back.kshscript from the developerWorks web site. This script includes many useful options. For example, remove diagnostic and administration notification log entries that have been produced a certain number of days ago or archive the diagnostic and administration notification log files to a new location in compressed format. Terms and conditions included in the download apply and all scripts should be tested in a non‐production environment before deployment in production. Download the script from the following site.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0904db2messagelogs/index.html?ca=dth-grn&=dgp-my
This script is currently the recommended method for managing diagnostic files. One consideration of using this script is that you must manually download it and configure it on your servers, and then use crontabto schedule it to process regularly.

For development and QA clusters, set the DIAGSIZE database manager parameter to a non‐zero value and restart the instance; a series of rotating diagnostic log files and a series of rotating administration notification log files are used. When non‐zero, the DIAGSIZE parameter specifies the size in MB of theses log files These files are called the db2diag.n.logand <instance>.n.nfy files, where n is an integer; <instance>.n.nfy files apply only to Linux and UNIX operating systems. The number of db2diag.n.log files and <instance>.n.nfy files cannot exceed 10 each. When the tenth file is full, the oldest file is deleted, and a new file is created. One advantage of this method is that a single command is used to set it up. A significant disadvantage of this method, however, is that the database manager can remove important diagnostic information that was recently produced if the set size is too small. As a result, if using this method set the DIAGSIZE database manager parameter sufficiently high to store a minimum of a week’s worth of diagnostic files. Specifying a size that can hold the diagnostic files for longer than a week is recommended.