DB2 performance is elusive and difficult to achieve in any type of application system these days. With so many options, servers, databases, application coding techniques and configuration parameters, it is sometimes amazing that things get done at all. The number of items to check and the number of items that affect performance continues to increase as more options, flexibility and features are added into an application system.
Several of the biggest principles that guide my DB2 performance tuning approach are pretty basic and serve the purpose of clarifying things to do.
1. Select an area for DB2 performance tuning.
- Note that it says an area, a single area. This area should not be too big or contain too many topics. Develop a focus and definition of what performance really is. Get agreement on DB2 performance from management, users and developers. If there is no agreement between these stakeholders, quit now because no DB2 performance improvement will ever be achieved.
2. Remove non-essential items from the DB2 performance effort.
- DB2 performance is more than technology. This is the step to separate the politics from the technology. Performance is the user experience of the server, database design and application code. Figure out how to make it faster and better. It is the user experience that matters, nothing else. Remove the items that don’t affect DB2 performance.
3. What is the technology involved from end to end?
- Discover and create a trace or detail report of who, what, when and where. Get a real report that can be reproduced at least three times. If the trace or report cannot be reproduced, disregard its value and findings. Deal with reality and real DB2 performance issues that are happening repeatedly.
4. Prioritize the topics and issues.
- From the report, list the topics and issues. This is where you divide and conquer the DB2 performance problems. Prioritize all the topics and issues, even the ones that you cannot touch. Reality is unpopular sometimes and your baby may be ugly.
5. Purge non-critical topics and issues.
- Decide what can be touched, changed or improved. If it cannot be changed, purge it or give it to the person that says it can be improved.
6. Sort into cost, time and DB2 performance impact categories.
- Analyze the topics and divide into small, medium and large issues and their associated small, medium and large performance impact. Money, return on investment, will be an issue and is a descriptor of the categories. Now get everyone to agree on the categorized items.
7. Improve, replace and redesign
- Get everyone involved and work the list items at a fever pace. Performance is not built in a day and it will take time to fix the DB2 performance items. At least now, everyone knows what the DB2 performance problems are and what needs to be done to fix them.
___________________________________________________________
Dave Beulke is an internationally recognized DB2 consultant, DB2 training and DB2 education instructor. Dave helps his clients improve their strategic direction, dramatically improve DB2 performance and reduce their CPU demand, saving millions in their systems, databases and application areas within their mainframe, UNIX and Windows environments.
Leave a Reply