DB2 DDF Transaction Rates Without Tears

(Originally posted 2016-05-02.)

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 [1], 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

Don’t reach for your SMF manual just yet but there is a very nice field I finally realised the significance of recently – SMF30ETC. It’s in the SMF 30 Performance Section, most useful in the Interval records (Subtypes 2 and 3).

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?

An independent enclave is a unit of work that runs in an address space but in a different service class to the one the address space itself runs in.

The most notable case of this is with DDF:[2]

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.

• When a user from outside the LPAR comes into DB2 they come in through the DIST address space using the Distributed Data Facility (DDF).
• The initial work to set up for the transaction[3] does not run on an independent enclave SRB. It does run under the DIST address space’s service class.[4]
• After WLM classification, authorisation and a few other things the transaction runs under an independent enclave. Generally this enclave would be classified to a separate WLM service class.[5] In this case Txn A and Txn C are both classified to DDFHI, while Txn B is classified to DDFLO.

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

As you’ve probably gathered by now I like to glean middleware-specific information without using its data.

The reasons for this are straightforward and reasonable, I think:

• If you have a plethora of, for example, CICS regions you can’t turn on CICS-specific instrumentation for them all.
• Middleware-specific SMF is generally voluminous and maybe expensive to collect. Still further process.

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.

That’s it.

 

So Get To The Point

I thought I just had. 🙂

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?

You might think that a report class with the DIST address space in gives you the transaction rate. I don’t believe it does. So SMF30ETC is the best source of information.

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.

 

Conclusion

If confronted by a plethora [6] of DB2 subsystems that are likely to have DDF work in the same service class on the same system I’d use SMF30ETC to figure out which have high transaction rates, and which have more expensive transactions.

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!