Integrating Db2 Data and RMF 70 & 72 (CPU & WLM) Metrics

Insights into Db2 operation are provided by RMF 70 data in areas such as CPU utilization and consumption at the processor and system levels. Several relevant areas are provided by RMF 72 data, including CPU consumption at the workload / service class / report class levels, WLM data relative to how service goals are being achieved and delays inhibiting that, and transaction metrics for DDF workloads which are often visible to WLM.

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

RMF 70 and 72 CPU and Workload Manager metrics help provide the integrated perspective needed by Db2, along with all subsystems operating on z/OS. Type 70 data shows CPU utilization by processor, and it shows CPU consumption at the processor and system levels.

Tooling can convert into your units of choice,  here we’re viewing it by MSUs. Then type 72’s take it from there to break down that CPU consumption into groupings you typically care about including WLM workload. Now since Db2 time directly on behalf of its callers is accounted for by the callers, for example, CICS or batch jobs, typically a relatively small amount of CPU is classified directly under Db2. Often that’s only CPU consumed by DDF or by Db2 system support address spaces like master DBM1 and IRLM. They typically show up under Db2 workloads or service classes, and which are captured in Type 30 address space data that’s being referenced here.

RMF 72 data also provides WLM performance indices or PIs reflecting the degree to which a service class is meeting its goal. Most Db2 work is accounted for and managed by the service class of its caller, for example, CICS. So we’ll see similar service classes here as we saw under CPU. The PIs for this service class, which is home to the Db2 system address spaces typically operate well under one, indicating that the service class goal is being exceeded.

Here we see the WLM velocity in red, which quantifies the percentage of time the address spaces received access to needed resources when requested, and the PIs in blue, which for velocity goals will have a direct inverse relationship. WLM’s data that captures the using and delay samples by resource can also be examined if needed, as seen here.

Due to the way DDF is architected within z/OS WLM has visibility into key transaction metrics for Db2 DDF service classes. So the DDF service class here begins with these character strengths, and we’ll go ahead and set that global filter so that all of our reports reflect that until we change it. So narrowing our view to this DDF service class, the available metrics include the transaction rate, the transaction response time, and CPU per transaction. And this data can be explored at the system level if needed.

So these key transaction metrics are also available for installation defined report classes, and that can serve as a low-cost substitute for the voluminous transaction data produced by subsystems like CICS and Db2 if these high-level metrics are all that is needed.

Learn More About Analyzing Db2 Statistics and Accounting Data