Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Munich 2016 - Z011599 Martin Packer - More Fun With DDF

How to have more fun looking at DDF

  • Login to see the comments

  • Be the first to like this

Munich 2016 - Z011599 Martin Packer - More Fun With DDF

  1. 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. 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. 3. Agenda •  What Is DDF? •  Why Do I Care About DDF? •  Tutorial •  Client N •  Client S •  Client P •  Conclusion
  4. 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. 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. 6. Tutorial
  7. 7. We're Interested In
  8. 8. StarDng Right At The Top
  9. 9. Drilling Down Into A Service Class
  10. 10. Roughly 60%
  11. 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. 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
  13. 13. CPU And The DBM1 And DIST Address Spaces Mostly Independent Enclave Roughly 60% of Independent Enclave
  14. 14. 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
  15. 15. 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
  16. 16. 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 •  …
  17. 17. 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
  18. 18. 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
  19. 19. Client 1 - Some Basic Sta<s<cs
  20. 20. Client 2 - A CPU Spike
  21. 21. Client 3 - Sloshing Or Not?
  22. 22. Sloshing Or Not? You Decide
  23. 23. A Nice Response Time Distribu<on
  24. 24. So What Have We Learnt?
  25. 25. 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)