DB2 DDF Transaction Rates Without Tears
MartinPacker 11000094DH Visits (6745)
Some of my blog posts revolve around a single SMF field, or maybe a couple. This post is one of those.
If I look at my customers’ mainframe estates , especially the DB2 portion of them, they’re getting more complex by the year.
In particular, quite a few customers are in the “tens of DB2 subsystems” category. One of the things driving the number up are SAP implementations, leading to multiple DB2 subsystems for a plethora of applications.
This post is mostly about “DDF heavy” DB2 subsystems - from the z/OS Performance point of view.
The Featured SMF Field
This field is Independent Enclave Transaction Count. With interval records you would, of course, turn this into a rate.
(Other fields you might like to consider are SMF30ETA (Independent Enclave Transaction Active Time) and a bunch of Independent Enclave CPU fields (SMF30ENC and some breakout ones for specialty engines). With these I think you can do some interesting calculations.)
But What Is An Independent Enclave And Why Do I Care?
The most notable case of this is with DDF:
The following diagram outlines what happens when work comes into DDF.
In this example there are three threads - Txn A, Txn B, and Txn C.
One of the key things to note is that for DDF work there is no SMF 30 record for the enclave, just the DIST address space.
DB2 Subsystem Transactions Without DB2 Instrumentation
The reasons for this are straightforward and reasonable, I think:
So I like to use SMF 30 first, which guides me to the specific CICS regions, DB2 (or MQ) subsystems, etc.
So, SMF30ETC for a DIST address space directly gives me the DDF transaction count for that subsystem, no DB2 instrumentation needed.
So Get To The Point
So, suppose I had multiple DB2 subsystems in an LPAR.
The general recommendation is to stick their IRLM address spaces in SYSSTC and the rest - DBM1, DIST, and MSTR - in a notional “STCHI” service class. This service class should have Importance 1 and a goal of something like 70% or more.
There’s probably not much to separate the various DB2 subsystems so often they all end up in the same (“STCHI”) service class.
But suppose you wanted to understand the transaction rate to each subsystem, without using DB2 instrumentation. Then this field (SMF30ETC) gives you that.
What About RMF?
There is another approach with RMF, but it solves a slightly different problem.
If clumps of DDF transactions are assigned different report classes their transaction rates will be recorded there. (The same is true for service classes.)
Generally I don’t see DDF work to different DB2 subsystems on the same LPAR assigned to the same report (or service) classes so this is a nice way to work out which clumps of transactions form the bulk of the DDF traffic to each service class.
I’d also add this is a good way to figure out whether any DB2 subsystem has little DDF work.
As I learn more about this deceptively simple piece of instrumentation I’ll let you know.
And there are many more things I could say about DDF. Most of those will have to await my “More Fun With DDF” presentation. It’s the very next conference presentation I’ll be building - with a real “drop dead” date. Stay tuned!