Integrating Db2 SMF Data with RMF Metrics (70, 71, 72, 74)

Since Db2 interacts heavily with z/OS and other subsystems, “outside” perspectives provided by RMF metrics are essential to effectively manage Db2 operational health and performance.

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 critical aspect of effectively managing a Db2 environment is having an integrated perspective across the z/OS ecosystem within which Db2 operates. Achieving this needed visibility depends primarily on metrics provided from RMF. I’m sure Db2 teams wish they could operate as an island, but the fact is that Db2 interacts heavily with z/OS and other subsystems. Thus managing Db2’s operational health and performance requires outside perspectives in areas such as sufficient access to CPU – utilization, capping, achievement of WLM goals. Db2 is, as we said earlier, the subsystem with the greatest capability to leverage the large amounts of memory available on today’s processors to enhance performance and efficiency; minimizing paging, while leveraging large frames, one megabyte, two gigabytes are big parts of that story.

Db2 data sharing environments are also among the top exploiters of the coupling facility and rely heavily on high-performing requests to lock and group buffer pool structures.

As it deals with massive quantities of data, Db2 relies heavily on fast performance from disk subsystems. Fast response times for database I/Os, which in turn rely on good cache hit ratios, as we discussed earlier. Db2 often generates very high logging volumes and thus can be sensitive to the log file performance and zHyperwrite, if used. Also, healthy interactions with other subsystems, such as MQ and the network are of critical importance. So, as much as we might wish otherwise, Db2 does not exist on an island. Having the needed insights into its operational health and performance is much broader than that provided by Db2 100 and 101 records thus requiring good visibility across the z/OS infrastructure.

RMF metrics that provide the needed insights into many of these areas in which we will briefly explore today include type 70 data providing CPU utilization and consumption at the system level. Also RMF 72 data provides several metrics of potential interest to Db2 teams, including CPU consumption at the workload service class report class levels, workload manager data relative to how service class goals are being achieved, and delays that might be inhibiting that, and transaction metrics for DDF workloads, which are often visible through WLM. Type 71 data gives insights into memory paging and large frames all at the system level. Since Db2 is typically the largest exploiter of memory in general, as well as of 1MB and 2 GB large frames, visibility here is of particular interest to Db2 teams. And finally, due to their dependence on highly responsive coupling facility performance, data sharing groups have keen interest in key metrics such as service times and request and reclaim rates in the 74.4 records. And as mentioned earlier, common, intuitive tooling benefits all teams in all directions, not only other teams wanting to understand what’s going on within Db2 but also Db2 teams who need easy visibility into how they might be impacted by what is happening in a z/OS environment or how Db2 might be impacting other workloads.

Learn More About Analyzing Db2 Statistics and Accounting Data