We are pleased to announce the release of a new DB2 best practices paper: Troubleshooting DB2 servers
Even in a perfectly engineered world, things can break. Hardware that is not redundant can fail, or software can encounter a condition that requires intervention. You can automate some of this intervention. For example, you can enable your DB2 server to automatically collect diagnostic data when it encounters a significant problem. Eventually, however, a human being must look at the data to diagnose and resolve the issue. When the need arises, you can use several DB2 troubleshooting tools that provide highly granular access to diagnostic data.
The information and scenarios in this paper show how you can use the DB2 troubleshooting tools to diagnose problems on your server.
In large database environments, the collection of diagnostic data can introduce an unwanted impact to the system. This paper shows how you can minimize this impact by tailoring the values of a few basic troubleshooting configuration parameters such as diagpath, DUMPDIR, and FODCPATH and by collecting data more selectively.
The result? When things do break, you are well prepared to make troubleshooting as quick and painless as possible.
The following DB2 troubleshooting scenarios are covered in this paper:
Troubleshooting high processor usage spikes
Troubleshooting sort overflows
Troubleshooting locking issues
For each scenario, this paper shows you how to identify the problem symptoms, how to collect the diagnostic data with minimal impact to your database environment, and how to diagnose the cause of the problem.
The target audience for this paper is database and system administrators who have some familiarity with operating system and DB2 commands.
This paper applies to DB2 V10.1 FP2 and later, but many of the features that are described here are available in earlier DB2 versions as well.