Have you ever been bothered by the db2diag.log growing out of control? I have. While on Linux and Unix you have nice tools like logrotate and its analogs written in a number of script languages, no such luck if you run DB2 on Windows. There is no Windows port of logrotate, and your MSCE colleagues don’t always look favourably at you trying to install ActivePerl or Cygwin on a production server.
Having suffered enough from Notepad not being able to open a 300 megabyte db2diag.log, I have written a Windows command script to rotate the DB2 diagnostic log file. It uses only built-in Windows commands and therefore can run on any out of the box Windows 2000, Windows XP, or Windows 2003 system. By the way, it should work for any log files (with some limitations), not necessarily those generated by DB2.
The scipt, logrotatew.cmd, works like this: it reads a configuration file, where you specify the logs to be rotated and how many generations you want to keep. It then renames each specified log, for example, db2diag.log to db2diag.log.1, db2diag.log.1 to db2diag.log.2 etc. The oldest generation of the log is then deleted. Optionally, it can compress the rotated logs with any file compression utility with a command line interface, e.g. gzip, which has a Windows port. Check the sample configuration file for details.
Make sure you invoke the script with the following command line, otherwise it will not work properly:
cmd /v:on /c logrotatew.cmd [-f <configfile>]
<configfile> argument is optional; if it is not specified the script will look for logrotatew.conf in the current directory.
There are some limitations, of course. Unlike the original logrotate, logrotatew does not:
- save its state, therefore doing the entire rotation cycle every time it is invoked;
- check the file size; if your log is empty it will still be rotated;
- have an option of mailing the rotated log;
Also, as mentioned, it does rename the active log file. DB2 will happily recreate its log file if it doesn’t find it where it was before. However, some programs may not be that robust. If you choose to use my script, test in your environment before attempting to implement it on a production system.
You can download the script and a sample configuration file here (right-click and Save As…). As usual, caveat emptor, no warranties express or implied, use at your own risk, etc. etc.