By Anthony Ciabattoni, Jim Pickel, Andreas Henicke, and Paul McWilliams

The Db2 for z/OS Sysplex Workload Balancing feature is an industry standard in providing the highest level of application availability against a Db2 sysplex group. It features transaction load balancing and seamless transaction reroute, providing 24 x 7 application availability. This feature is built upon the z/OS Sysplex Distributor and z/OS Workload Manager Sysplex routing services. Sysplex Workload Balancing improves the application efficiency against a Db2 Sysplex Group through improved availability, overall capacity, and increased work throughput.

z/OS Workload Manager provides automatic and dynamic balancing of Db2 transaction by using the Db2 Sysplex Workload Balancing feature. WLM balancing transactions are affected by the following factors:

• Free and available LPAR capacity.
• Performance Index (how are the transactions meeting their goals).
• Queue time ratio (how long do transactions wait until started).
• Health indicator (depends on number of connections and Db2 storage use). 

To ensure effective workload balancing when using the Db2 Sysplex Workload Balancing feature, use the following best practices.

Understand the LPAR configuration and performance

Use the z/OS CPU activity report and workload activity report to understand your LPAR configuration, load, and performance index.

Monitor the Db2 “health value”

Regularly check the health of your Db2 environment by monitoring factors like the number of open connections and Db2 storage use. Adjust routing decisions based on these health indicators. You can obtain the Db2 health value by issuing the following DISPLAY THREAD command:

DISPLAY THREAD (*) TYPE(SYSTEM)

You can identify the number of open connections to by issuing the Db2 -DISPLAY DDF command:

• If number of connections is greater the 80% of the connection limit, divide the health value by 2.
• If number of connections is greater the 90% connection limit, the divide the health value by 4. 

Monitor the Db2 queue time

Keep an eye on the Db2 queue time to ensure efficient transaction processing. The Db2 queue time is determined by how long a transaction weights for thread to run the transaction. When the Db2 thread limit is reached will elongate weight times and influences the routing decisions.

Adapt to Performance Index Fluctuations

The Db2 Performance Index reflects the Performance Index of the service class period used by DDF. Understand how the Db2 Performance Index changes over time. The Performance Index can fluctuate heavily which influences routing. Use the z/OS IEAOPT RTPIFACTOR parmlib option to mitigate the impact of the Performance Index on routing:

• When RTPIFACTOR is 0, the server weight is independent from the server PI.
• When RTPIFACTOR is 100 and the server PI is bigger than 1, the server weight is divided by the server PI.
• When RTPIFACTOR is between 1 and 99, it results in a corresponding intermediate influence of the server PI on the server weight returned by WLM.
• This results in a proportional influence on the Db2 members routing.

Define Clear Goals

Set clear goals for Db2 transactions to ensure they are met within expected timeframes. If critical workload consistently misses its goal, consider prioritizing the service class periods by setting a new importance level. A goal should always reflect the business requirements that a typical transaction should complete. If a goal is permanently not achieved and it is important work, you might also consider tightening the goal to convince WLM to prefer this service class period, but it might impact other important work.

DDF goal setting can be based on the following factors:

• Individual Db2 members.
• Groups of transactions running under DDF enclave.
• Individual transactions running under DDF enclave.
• Transactions associated with individual user IDs.
• Transactions associated with individual locations. 

You can also control routing decisions by managing percentile goals. Use 80% to 95% for percentile goals when goals are not being met. This recommendation applies always to percentile response time goals, not only in association with WLM routing. When tightening the goal, typically you can make the time smaller and keeping the percentage or increase the percentage. The goal should reflect your expectation and should not be kind of a WLM thumbscrew. It is recommended to use meaningful percentages in the range of 80% to 95%. 

High performance DBATS the effective response time of the enclave is until the DBAT is terminate which may include multiple transactions. The recommendation is to change the WLM service classes use velocity goals when they are used to manage the processing of client connections with high performance DBATs. Existing WLM service classes that use response time or percentile-response-time goals, where the enclave is used for a single transaction generally not cannot meet their performance objectives.

Consider Capacity Expansion

If optimization efforts do not yield the desired result, consider expanding the system capacity. This can improve overall throughput and performance, enhancing the effectiveness of workload balancing.

Conclusion

By following these guidelines and continuously monitoring and adjusting your workload balancing strategy, you can ensure efficient operation and maximize the availability of your Db2 sysplex environment.

#Db2forz/OS#Db2Znews