This document summarizes a presentation about analyzing DDF workloads using performance data. The presentation describes how to classify "alien" DB2 work coming through DDF and determine what is issuing the requests. It provides examples analyzing the behavior of different DDF clients, including identifying a CPU spike from one client and determining if another client is exhibiting "sloshing" behavior. The key lessons are that DDF management requires using WLM and application examination/tuning, and SMF 101 accounting trace records are important for instrumentation.

1. Technical University/Symposia materials may not be reproduced in whole or in part without the prior written permission of IBM.
9.0
© Copyright IBM Corporation 2015
More Fun With DDF
Session z011599
Martin Packer
IBM

2. Abstract
The idea of "alien" DB2 work coming into your system through DDF strikes
fear into even the most seasoned Performance Specialist...
How will I classify it?
What will stop it from taking over my machine?
This presentaDon describes how to use performance data to address both
of those quesDons, based on the author's recent experiences with
numerous customers.
It also enables you to understand what applicaDons and machines are
issuing the DDF requests, improving your knowledge of the applicaDon
landscape.

3. Agenda
• What Is DDF?
• Why Do I Care About DDF?
• Tutorial
• Client N
• Client S
• Client P
• Conclusion

4. What Is DDF?
• One of the major gateways into z/OS
• Specific to DB2 as the server
• Around since DB2 Version 2
• Refined many Dmes since
• Broadly clients are:
• JDBC – 'JCC'
• z/OS – 'DSN'
• OS/400 – 'QSQ'
• Other – 'SQL'
• Higher risk of "feral SQL"

5. Why Do I Care About DDF?
• Many modern applicaDons use DDF to get to DB2
• You'd like them to perform well
• You'd like them not to take over your machine
• You'd like to know what they even are
• Don't you just hate it when work shows up and nobody
tells you?
• You'd like to ensure zIIP exploitaDon is opDmal

6. Tutorial

7. We're Interested In

8. StarDng Right At
The Top

9. Drilling
Down Into A
Service Class

10. Roughly 60%

11. But What Is A DDF Transac<on?
• ConversaDons between requestors and DB2 are of
variable complexity
• Some do few commits
• Some do many
• Each commit / abort ends a transacDon
• Infrequent commits can lead to long transacDons
• Frequent commits to short ones
• So a transacDon is generally not a whole
conversaDon
• A DDF transacDon is a WLM transacDon
• And we've already seen those

12. Mul<period Transac<ons
• As with many transacDon types WLM can work
with "period aging"
• If a transacDon accumulates enough service it'll fall into
second and subsequent periods
• Generally we're talking about CPU

14. CPU And The DBM1 And DIST Address Spaces
Mostly Independent Enclave Roughly 60% of
Independent Enclave

15. SMF 30 Contains Transac<on Rate
• SMF30ETC is Independent Enclave TransacDon Rate Count
• Process for DIST address space
• Counts transacDons for all DDF service classes served by the
subsystem
• Likewise doesn't disDnguish between period endings
• Many customers have mulDple DB2 subsystems per LPAR
• Unnecessary to have separate service classes for each
• SMF30ETC lets you see how busy, transacDonwise, each subsystem
is
• Could usefully divide Enclave CPU by transacDon rate

16. DDF And The DB2 Accoun<ng Trace (SMF 101) Record
• Everything you'd expect from a 101 record
• e.g. Timings
• e.g. SQL Counts
• Plus more:
• DDF IdenDfiers (QMDA secDon)
• DDF Counters (QLAC secDon)
• WLM Service Class (QWACWLME)
• Records for requester and for server
• DB2 on z/OS to DB2 on z/OS appears twice
• One in each subsystem
• Records can be rolled up
• ACCUMACC=10 is default
• 10th Commit / Rollback
• Or some other obscure cases
• ACCUMACC=NO
• 1 per Commit / Rollback
• Can calculate ACCUMACC value from SMF 101

17. QMDA and QLAC Sec<ons
• QMDA – idenDfiers
• Different for z/OS and other plahorms
• Useful for designing DDF WLM classificaDon rules
• AccounDng InformaDon
• IP Address / Net Name
• End User ID
• z/OS DB2 CorrelaDon / Plan informaDon
• …
• QLAC – counters
• Common across all plahorms
• Sent & Received
• SQL Statements
• Bytes
• Rows
• Blocks
• Commits / Aborts
• …

18. QWHS and QWACWLME
• QWHS Common to SMF 101 records from different types of
connecDons.
• Standard Header in Product SecDon
• QWHSLWID – 24-byte Logical Unit Of Work ID
• QWHSNID – 8-byte Network Name
• QWHSLUNM – 8-byte LU Name
• QWHSLUUV – 6-byte Uniqueness Value
• QWHSLUCC – 2-byte Commit Count
• QWHSLWID (minus QWHSLUCC) allows you to De a
conversaDon together.
• QWACWLME unique to DDF
• WLM Service Class
• Binary zeroes for other amachments

19. Batch And DDF – Strange Bedfellows?
• SAP Batch is not JES Batch
• A bunch of "transacDons" ie SMF 101 records
• Unique correlator in QWHS secDon
• Plonng commit (or record) rate by minute Dmes the job
• Gives bemer granularity than JES Batch
• Eg Varying effect of CPU queuing – Not Accounted For Dme
• Conversely, some JES Batch uses DDF
• Job J amaches to Subsystem A
• Subsystem A talks DDF to Subsystem B
• Field QTXAOTSE for A documents Dme spent in B and
communicaDng
• Collect SMF 101 from both subsystems
• Correlators in QWHS secDons match

20. Client 1
-
Some Basic Sta<s<cs

25. Client 2
-
A CPU Spike

34. Client 3
-
Sloshing Or Not?

35. Sloshing Or Not? You Decide

36. A Nice Response Time Distribu<on

37. So What Have We
Learnt?

38. Maybe you learnt something like this
• DDF Is Important To Manage
• DDF Management needs to happen with WLM and
by applicaDon examinaDon / tuning
• AccounDng Trace SMF 101 is key instrumentaDon
• MarDn has some super DFSORT code to summarise it
• Down to arbitrarily short Dme intervals
• You can have more fun with DDF (than you
might've supposed)