- David Sciaraffa, Software Development Manager – IBM Db2 Availability
In common lore spread throughout software engineering classes, the term ‘bug’ (referring to a software defect) was coined after a moth embedded itself within an electromechanical computer relay sometime during the infancy of computing. True or not, the almost infinite permutations of timing and procedural conditions in modern software stacks mean that software defects (bugs) are inevitable.
All software, including enterprise relational databases, are susceptible to software defects. The IBM Db2 support and development teams provide excellent assistance for a wide range of support issues, usage questions, best practices, and of course software bugs.
The complexity of software bugs will vary, and the more complex issues will often require specific diagnostic data leading up to the problem occurrence. This means that, quiet often, there is insufficient diagnostic data during the first occurrence of a problem to determine the root cause, and the reproduction of a problem is required with diagnostic data collection in place for the time frame leading up to the problem.
The Db2 Persistent Data Collection Scripts help to reduce problem determination times, and often reduce the need for problem reproductions.
The scripts are available for download here: http://www.ibm.com/support/docview.wss?uid=swg22005477
In the spirit of agility, the scripts are simple ksh scripts, operational on both Linux and AIX platforms. They collect various diagnostics from both the Operating System, and from Db2. The Db2 diagnostics come from negligible-impact MON_GET* functions, and the db2pd tool (which is functional even when database connectivity is not possible).
The scripts are used by several extremely high transaction volume production database banking systems, with no performance impact.
There are three scripts in total:
Db2_dataCollect_minutely.sh – You should use a crontab or scheduler to execute this script about every minute or two.
The diagnostic data collected by this script is stored into a staging folder and is automatically tarred and compressed (gzip) upon completion (with exceptional compression ratios, so data volumes are manageable).
Db2_dataCollect_hourly.sh – You should use a crontab or scheduler to execute this script about every hour.
The diagnostic data collected by this script is stored into a staging folder and automatically tarred and compressed (gzip) upon completion (with exceptional compression ratios, so data volumes are manageable).
Db2_dataCollect_archive_purge.sh – You should use a crontab or scheduler to execute this about script every 24hours.
This script will move the diagnostic data from the staging folders (where the collection scripts above store their diagnostic data) into an archive folder. It will then delete any files older then a retention period (default 30 days) from the archive folder.
In future blog posts, I hope to provide details on how database administrators can utilize the diagnostic data collected by these scripts. Seasoned DBAs will be familiar with much of the information collected here and find it useful for self analysis. Db2 support analysts will find it extremely useful in the triage of a multitude of problems.
Your feedback is always welcome. If you have any suggestions, corrections or recommendations, or would like to monitor for updates to these scripts, please subscribe to the public community for Db2 Persistent Data Collection Scirpts:
https://www.ibm.com/developerworks/community/groups/service/html/communitystart?communityUuid=a294bddb-9ded-4757-8d5e-ca5ba173e2cd
