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
- Exploring Assessments of Key Metrics
- Db2 Buffer Pool Tuning: Exploring Key Metrics (Part 1)
- Db2 Buffer Pool Tuning: Exploring Key Metrics (Part 2)
- Db2 I/O Cache Insights from IFCID 199 and SMF 42 Data
- Buffer Efficiency from IFCID 199 and SMF 42
- Measuring Benefits of Db2 Buffer Pool Tuning
- Exploring Other Db2 Statistics Metrics
- Walkthrough of Db2 Statistics Dashboard for Buffer Pool Tuning
- Integrating with RMF Metrics (70, 71, 72, 74)
- Integrating with RMF 70 and 72 CPU and WLM Metrics
- Integrating with RMF 71 Memory and Large Frame Metrics
- Integrating with RMF 74.4 Coupling Facility Metrics
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.
Speak to a Technical Expert Today
Whether you are conducting product research, need support on a project, are experiencing downtime, or want to learn more about how IntelliMagic can support your business, our experts are here to help.
You May Also Be Interested In:
Profiling zHyperLink Performance and Usage
In this blog, we demonstrate how to profile zHyperLink performance and usage by reviewing one mainframe site’s recent production implementation of zHyperLink for reads, for Db2.
How A Db2 Newbie Quickly Spotlights the Root Cause of a Db2 Slowdown
This blog explores how a non-Db2 expert quickly identified latch contention arising from a Data Sharing Index Split as the root cause of a Db2 delay/slowdown.
Integrating Dataset Performance (SMF 42.6) and Db2 Buffer Pools & Databases (SMF 102/IFCID 199) Data
Dataset performance data from SMF 42.6 records provides disk cache and response time data at the Db2 buffer pool and Db2 database levels when integrated with Db2 Statistics IFCID 199 data.