There’s no shortage of articles, white papers, manuals, redbooks and other materials on DB2 UDB for z/OS V8 systems performance. Performance is also a popular presentation topic for DB2 Regional Users Groups (RUGs).
Systems Tuning Enigma
Despite the abundant information, advice and guidelines on DB2 performance and tuning, many organizations often attend conferences to learn more because:
- They’re facing a particular immediate problem and hope they find a presentation to guide them through the mess they’re in.
- Many tuning alternatives carry a disclaimer such as, “may not apply in all situations,” or “presented only as an idea, use at your own risk.”
- There’s a common need to identify the tuning strategies, tips, tricks, and traps that can be implemented immediately with minimal risks and maximum benefits.
- Knowing how to change parameters, monitor thresholds, and analyze access paths isn’t sufficient; success requires understanding why a problem occurs and a particular strategy is superior to the alternatives.
Few organizations get the chance to develop proactive strategies that address the “why” of systems tuning. The effect of many tuning adventures is to make something faster, cheaper or better, but is tuning really a good idea? If you concentrate on the little things, will overall system performance be better?
- The three most important issues are:
- What is your overall systems performance- tuning strategy?
- Why are you implementing particular tactics?
- How do you decide what tuning tactics to implement?
This article will concentrate on the first issue; the other issues will be addressed in future articles.
Setting a Strategy
You should start with developing and documenting a performance measurement and tuning strategy, including the reasons why each element of the strategy exists. This is the only way you can justify the best practices derived from your strategies.
Performance is defined based on how you measure it. The many measurement possibilities include:
• Resource usage encompasses average CPU used over time, average and peak network traffic, disk I/O activity, and so forth. It’s usually measured with tools such as Resource Measurement Facility (RMF) and DB2 Performance Monitor (DB2PM).
• Application Service Level Agreements (SLAs) address average and peak online transaction elapsed times, completion of batch jobs within a production window, incidence of job abends, data availability, etc. These are usually measured by scheduling systems and application-built monitoring components.