What is to be gained from Bufferpool Tuning?
Inappropriate bufferpool settings can cause ugly problems from temporary system hold to loss of an entire DB2 data sharing group. Does it really have to come to that? Ample evidence of problems appears way before, a lot of CPU was already burned before things crash. Reckless CPU burning involves a great deal of expense. The primary issue with buffer pool tuning is to avoid unnecessary I/O and the cost involved. The best thing we can do against bottlenecks at peak times is to avoid impediments. An ongoing search method for avoidable I/O and their prevention keeps systems healthy, saves on machine resources, and prevents unpleasant surprises.
What can be expected from Bufferpool Tuning?
A precise answer to a simple question: Do we have tuning potential? In other words: Do the systems already work efficiently or can we achieve measurable improvements? Don’t use a tool that attempts to improve things that are OK or already optimal, what a complete waste of your valuable time. A helpful bufferpool tool is pro-active and warns when things are about to turn bad and leaves me alone as long as everything is in good shape.
The key feature is “ongoing surveillance” according to quality criteria that I can set. For example, send me a warning if more than 10% avoidable IO appears with these bufferpools.
Clear Briefing – Recommendation of Tuning Measures
Let’s assume tuning potential is detected, performance is suboptimal, what next? In order to save me the pain of lengthy analysis, the best buffer pool tool should provide recommendations and predict their outcome. Preferably, it will already deliver the required ALTER statements, especially when many objects are involved. It is uncommon that only the size or the thresholds of a single pool has to be changed, more often the assignment of objects to pools must be reworked. A tool that helps me do this, that helps me to deliver system performance, is what I need.