Integrating Db2 Data with RMF 74.4 Coupling Facility Metrics

High volume Db2 data sharing groups are very dependent on responsive coupling facility performance, giving Db2 teams keen interest in coupling facility metrics such as service times and request and reclaim rates captured in the RMF 74.4 records.

More Db2 Statistics Videos

1. Exploring Assessments of Key Metrics
2. Db2 Buffer Pool Tuning: Exploring Key Metrics (Part 1)
3. Db2 Buffer Pool Tuning: Exploring Key Metrics (Part 2)
4. Db2 I/O Cache Insights from IFCID 199 and SMF 42 Data
5. Buffer Efficiency from IFCID 199 and SMF 42
6. Measuring Benefits of Db2 Buffer Pool Tuning
7. Exploring Other Db2 Statistics Metrics
8. Walkthrough of Db2 Statistics Dashboard for Buffer Pool Tuning
9. Integrating with RMF Metrics (70, 71, 72, 74)
10. Integrating with RMF 70 and 72 CPU and WLM Metrics
11. Integrating with RMF 71 Memory and Large Frame Metrics
12. Integrating with RMF 74.4 Coupling Facility Metrics

Video Transcript

One more data source critical to Db2 performance in data sharing environments is coupling facility metrics found in RMF 74.4 records. High volume Db2 data sharing groups are very dependent on highly responsive coupling facility performance. So there’s several coupling facility metrics of interest to Db2 personnel, so let’s briefly look at synchronous and asynchronous request rates and service times, false lock contention, and directory reclaims. So this view assesses several metrics of interest for high activity coupling facility structures. Let’s go ahead and look at the group buffer pool structure for buffer pool 20, a buffer pool that was a prime focus in our buffer tuning analysis. Along the top row, we see at a glance several metrics of interest, the level of synchronous and asynchronous activity, the service times for the synchronous and asynchronous requests, and so on. So you typically want a coupling facility request to be completed in a synchronous manner, since the CPU spinning during the execution of a coupling facility requests, z/OS has built-in mechanisms to convert requests to be asynchronous when needed to avoid consuming excessive amounts of CPU. One consideration that can cause that is distance between the processor and the coupling facility, as in some high availability configuration. So for this coupling facility structure, we see that most requests are completed synchronously at a service time around eight microseconds. If a structure has significant async activity, then you’re going to want to be aware of that service time as well.

We do notice somewhat of an increase in the evening hours in this service time. So let’s go ahead and compare the service time metric against the request rate for the synchronous requests, put that on the secondary axis, and when we do that we do see that at the times when service time has increased, there also tends to be much higher request rate.

Now another metric of interest for tuning coupling facility cache structures is directory reclaims. When due to a shortage of directory entries, data buffers are being invalidated, even though the data itself was not changed. Let’s scroll down here and we see that Db2 group buffer pool four is being assessed as having a significant amount of reclaims. So if we go ahead and look at that in some detail. So here’s the profile for this particular day. Let’s go ahead and compare it to the previous day. And when we do that, we see a pretty common profile there. So it’s a common activity, may warrant some additional investigation.

One more metric of interest for lock structures is false lock contention where two different locks on different resources, hash to the same lock entry. And so in that event, extra overhead is consumed and the second lock requester is suspended until it’s determined that there was no real actual lock contention for the resource. So, in this environment, in the Db2 structures in the production environment, there’s no significant level of false lock contention. If we look at the primary Db2 lock structure, we see that the percentage of false lock contention only exceeds the 1% threshold for a few intervals.

Learn More About Analyzing Db2 Statistics and Accounting Data