DB2 9 for z/OS

6/14/2009

Using Explain Tables for Tuning Queries

Susan Lawson YL&A

Yevich, Lawson & Assoc. Inc. 2743 S. Veterans Pkwy PMB 226 Springfield, IL 62704 www.ylassoc.com www.db2expert.com www db2expert com

IBM is a registered trademark of International Business Machines Corporation. DB2 is a trademark of IBM Corp. Copyright 1998-2009, YL&A, All rights reserved.
YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

Disclaimer PLEASE READ THE FOLLOWING NOTICE

n

The information contained in this presentation is based on techniques, algorithms, and documentation published by the several authors and companies, and in addition is the result of research. It is therefore subject to change at any time without notice or warning. The information contained in this presentation has not been submitted to any formal tests or review and is distributed on an As is basis without any warranty, either expressed or implied. The use of this information or the implementation of any of these techniques is a client responsibility and depends on the clients ability to evaluate and integrate them into the clients operational environment. While each item may have been reviewed for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Clients attempting to adapt these techniques to their own environments do so at their own risks. Foils, handouts, and additional materials distributed as part of this presentation or seminar should be reviewed in their entirety.

YL&A 1997-2009

Abstract

DB2 z/OS V8 and 9 have introduced us to many new EXPLAIN tables. This presentation will introduce users some of the new EXPLAIN tables used by these tools for advanced query analysis, and demonstrate how SQL queries can be used to gather and analyze the advanced information.

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

EXPLAIN and EXPLAIN Tools and Queries

n n

EXPLAIN has been enhanced greatly for DB2 V8 and DB2 9 Several EXPLAIN tools are available Visual Explain Optimization p Service Center l Replaces Visual Explain l Works with V8 NFM Data Studio l Visual Explain Plug-Ins However, DB2 EXPLAIN facility is built-in to DB2 No additional tools are needed to perform an EXPLAIN EXPLAIN tables contain access path information Anyone can read the access path information from the EXPLAIN tables

YL&A 1997-2009

Visual Explain Tool (DB2 V8)

n n n n n n n

A GUI interface to the information in the EXPLAIN tables Provides information about statements in the system Can dynamically EXPLAIN statements Can get Statistics for accessed objects Ability to browse subsystem parameters Compatible with V7 subsystems With V8 subsystems

More information than the PLAN_TABLE provides Cardinality and Filter Factor information Additional of predicate information Some rewritten predicates exposed
n

Method of transmission of information to IBM

XML File Service SQL Feature

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

Visual Explain Index Scan

YL&A 1997-2009

VISUAL EXPLAIN - Fetch

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

Visual Explain Statistics Advisor

YL&A 1997-2009

Visual Explain Join Predicates and Filter Factor

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

Optimization Service Center (DB2 9)

n

A workstation-based tool Easy interaction with DB2 EXPLAIN and the explain tables Allows you to analyze
l l l l l

SQL statements Objects Statistics The statement cache Workloads

n n n n

Replaces Visual Explain Has Many of the features of Visual Explain Compatible with V8 Subsystems in New Function Mode H additional Has dditi l features f t that th t can be b purchased h d

YL&A 1997-2009

Why Not Use These Products for EXPLAIN?

n

n n

PC workstation maybe does not have enough power These tools use a lot of the machine DB2 Connect Enterprise Edition is required Remote connections to mainframe are required This Thi raises i security it concerns l Especially for production SPUFI or QMF is often preferred This is a fast and easy method

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

Additional Explain Tables

n n

Most available in V8 Now very accessible in V9 via Optimization Service Center or SQL Documented in IBM DSN VIEWREF TABLE DSN_VIEWREF_TABLE DB2 9 Performance DSN_QUERY_TABLE Guide DSN_PGRANGE_TABLE DSN_SORTKEY_TABLE DSN_SORT_TABLE DSN_DETCOST_TABLE PLAN_TABLE DSN FILTER TABLE DSN_FILTER_TABLE DSN_PTASK_TABLE DSN_PGROUP_TABLE DSN_STRUCT_TABLE DSN_PREDICAT_TABLE
YL&A 1997-2009

EXPLAIN Tables Explained The DB2 EXPLAIN facility populates the EXPLAIN tables

If any of the EXPLAIN Tables exist for the Userid, then they will
be populated automatically when you EXPLAIN The EXPLAIN Tables can be queried just like any other table

Visual Explain and Optimization Service Center define the EXPLAIN tables

However, once created you can use them independent of these

products You can also migrate or create them yourself

It is possible to have a Green Screen advanced EXPLAIN

Helps those especially without distributed access to the

mainframe

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

EXPLAIN Tables and Columns of Primary Interest When EXPLAINing there are just a few primary tables and columns that should be initially focused on

There is much more, but this is just for initial analysis

Your first look at the Access Path More details are available, available but the first look simplifies the view and can answer many questions

WARNING!

Most EXPLAIN table analysis should be left in the hands of IBM

of professional EXPLAIN products!

Any Tweaking of EXPLAIN is done without IBM support

PLAN_TABLE DSN_FILTER_TABLE DSN_PREDICAT_TABLE DSN_DETCOST_TABLE

YL&A 1997-2009

PLAN_TABLE This is the base access path information

Columns for initial analysis
METHOD MERGE_JOIN_COLS CREATOR TNAME CORRELATION_NAME ACCESSTYPE ACCESSNAME INDEXONLY MIXOPSEQ MATCHCOLS SORT#### Cols PREFETCH PAGE_RANGE JOIN_TYPE PARENT_QBLOCKNO TABLE TYPE BIND_TIME
First table accessed, join method, or sort Number of merge scan joined columns Name of table accessed Index access or table space scan Y if index-only access Quantity of index matching columns used Prefetch type if used Join type if used Table, work file, MQT, subquery, etc. Table correlation name in query Index name if used Multi-index step number (if used) Sort reasons Y if table space scan and partition elimination Parent query block number (subqueries, etc.)

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

Warnings About Using the Other EXPLAIN Tables Can quite easily query these tables via SQL Should limit what is viewed in the tables These tables exist in support of the IBM query analysis products IBM can change/eliminate them at any time IBM does NOT support your use of these tables beyond the authorized tools Will not respond to issues about these tables You are using them on your own and at your own risk

YL&A 1997-2009

DSN_FILTER_TABLE Contains information about how predicates are used during query processing

One row per simple and compound predicate

Columns for initial analysis
COLLID PROGNAME QUERYNO EXPLAIN_TIME PREDNO STAGE
These columns used for join to PLAN_TABLE The relative predicate number used to join to DSN_PREDICAT_TABLE The predicate Th di t stage t (where ( h processed within DB2). Matching, Screening, Stage 1, or Stage 2

YL&A 1997-2009

YL&A 1999 - 2009

DB2 9 for z/OS

6/14/2009

DSN_PREDICAT_TABLE Contains information about the predicates in a query

One row per simple and compound predicate

Columns for initial analysis
COLLID PROGNAME QUERYNO EXPLAIN_TIME PREDNO FILTER_FACTOR BOOLEAN_TERM TEXT
The actual predicate text including rewritten or generated predicates These columns used for join to PLAN_TABLE PLAN TABLE The relative predicate number used to join to DSN_FILTER_TABLE The predicate filter factor (percent of rows to be returned based on this predicate alone) Whether or not the predicate is Boolean Term (when it evaluates to false does it make the entire WHERE clause false)

YL&A 1997-2009

DSN_DETCOST_TABLE Provides detailed cost information about the mini-plans in a query

There can be multiple rows per query block and plan step
Take the one with the smallest value

Columns for initial analysis

COLLID PROGNAME QUERYNO EXPLAIN_TIME QBLOCKNO PLANNO ONECOMPROWS
These columns used for join to PLAN_TABLE The number of rows the optimizer thinks will qualify after only local predicates are applied (take the lowest value)

YL&A 1997-2009

YL&A 1999 - 2009

10

DB2 9 for z/OS

6/14/2009

Basic PLAN_TABLE Query

SELECT SUBSTR(DIGITS(QUERYNO),5) CONCAT ''-' CONCAT SUBSTR(DIGITS(QBLOCKNO),4) CONCAT ''-' CONCAT SUBSTR(DIGITS(PLANNO),4) AS Q_QB_PL ,PROGNAME AS PNAME ,SUBSTR(CHAR(METHOD),1,1) AS MT ,SUBSTR(TNAME,1,18) AS TNAME ,CHAR(TABNO) AS T_NO ,ACCESSTYPE AS AT ,CHAR(MATCHCOLS) AS MC ,SUBSTR(ACCESSNAME,1,8) AS ACC_NM ,INDEXONLY AS IX ,SORTN_JOIN CONCAT SORTC_UNIQ CONCAT SORTC_JOIN CONCAT SORTC_ORDERBY CONCAT SORTC SORTC_GROUPBY GROUPBY AS NJ_CUJOG NJ CUJOG ,PREFETCH PREFETCH AS PF ,COLUMN_FN_EVAL COLUMN FN EVAL AS CFE ,CHAR(MIXOPSEQ) AS MIX ,ACCESS_DEGREE AS A_DEG ,JOIN_DEGREE AS J_DEG ,PARALLELISM_MODE AS P_MODE ,MERGE_JOIN_COLS AS MJC ,CORRELATION_NAME AS COR_NM ,PAGE_RANGE AS PG_RG ,JOIN_TYPE AS JT ,WHEN_OPTIMIZE AS WH_OP ,QBLOCK_TYPE AS QB_TYP ,BIND_TIME AS B_TM ,HINT_USED AS HINT ,PRIMARY_ACCESSTYPE AS PR_ACC FROM PLAN_TABLE A --WHERE -WHERE PROGNAME = 'YLAPROG1' <-<-- TARGET A SPECIFIC PROGRAM HERE WHERE BIND BIND_TIME TIME = (SELECT MAX(BIND_TIME) MAX(BIND TIME) FROM PLAN_TABLE PLAN TABLE B WHERE A.PROGNAME = B.PROGNAME AND A.COLLID = B.COLLID) ORDER BY PROGNAME, BIND_TIME, Q_QB_PL, MIX;

YL&A 1997-2009

Advanced EXPLAIN Query

WITH MAXTIME (COLLID, PROGNAME, QUERYNO, BIND_TIME) AS (SELECT COLLID, PROGNAME, QUERYNO, MAX(BIND_TIME) FROM PLAN_TABLE WHERE COLLID = 'DSNESPCS' AND PROGNAME = 'DSNESM68' GROUP BY COLLID, PROGNAME, QUERYNO) SELECT SUBSTR(P.PROGNAME, 1, 8) AS PROGNAME,SUBSTR(DIGITS(P.QUERYNO), 6) CONCAT ''-' CONCAT SUBSTR(DIGITS(P.QBLOCKNO), 4) CONCAT ''-' CONCAT SUBSTR(DIGITS(P.PLANNO), 4) AS QQP,SUBSTR(CHAR(P.METHOD), 1, 3) AS MTH ,SUBSTR(CHAR(F.PREDNO), 1, 3) AS P_NO,SUBSTR(CHAR(P.MERGE_JOIN_COLS), 1, 3) AS MJC,SUBSTR(P.CREATOR, 1, 8) AS TBCREATOR,SUBSTR(P.TNAME, 1, 18) AS TBNAME,SUBSTR(P.CORRELATION_NAME, 1, 8) AS CORR_NM,DEC(D.ONECOMPROWS, 10, 1) AS ROWS_POST_FILTER,P.ACCESSTYPE AS ATYP,SUBSTR(P.ACCESSNAME, 1, 15) AS A_NM,P.INDEXONLY AS IXO,CHAR(P.MIXOPSEQ) AS MIX ,CHAR(P.MATCHCOLS) MCOL ,F.STAGE AS STAGE,DEC(E.FILTER_FACTOR, 11, 10) AS FF,E.BOOLEAN_TERM AS BT ,SUBSTR(E.TEXT, 1, 30) AS PRED_TEXT30,P.SORTN_JOIN CONCAT P.SORTC_UNIQ CONCAT P.SORTC_JOIN CONCAT P.SORTC_ORDERBY CONCAT P.SORTC_GROUPBY AS NJ_CUJOG,P.PREFETCH AS PF,P.COLUMN_FN_EVAL AS CFE,P.PAGE_RANGE AS PGRNG,P.JOIN_TYPE AS JT ,P.QBLOCK_TYPE AS QB_TYP,P.PARENT_QBLOCKNO AS P_QB,P.TABLE_TYPE AS TB_TYP,P.BIND_TIME AS B_TM FROM PLAN_TABLE P INNER JOIN MAXTIME M ON M.COLLID AND M.QUERYNO=P.QUERYNO AND M.BIND_TIME=P.BIND_TIME LEFT JOIN DSN_FILTER_TABLE F ON M.COLLID = F.COLLID AND M.PROGNAME=F.PROGNAME AND M.QUERYNO=F.QUERYNO AND P.QBLOCKNO=F.QBLOCKNO AND ON AND P.PLANNO = F.PLANNO AND M.BIND_TIME=F.EXPLAIN_TIME AND P.ACCESSTYPE Not IN ('MX', 'MI', 'MU') LEFT JOIN DSN_PREDICAT_TABLE E F.PROGNAME = E.PROGNAME AND F.QUERYNO=E.QUERYNO AND F.QBLOCKNO=E.QBLOCKNO F.PREDNO = E.PREDNO AND M.BIND_TIME=E.EXPLAIN_TIME = P.COLLID AND M.PROGNAME=P.PROGNAME

LEFT JOIN TABLE (SELECT MIN(X.ONECOMPROWS) AS ONECOMPROWS FROM DSN_DETCOST_TABLE X WHERE M.PROGNAME = X.PROGNAME AND M.QUERYNO = X.QUERYNO AND P.QBLOCKNO = X.QBLOCKNO AND P.PLANNO = X.PLANNO AND M.BIND_TIME = X.EXPLAIN_TIME) AS D ON 1=1 ORDER BY PROGNAME, B_TM, QQP, MIX, F.PREDNO;
YL&A 1997-2009

YL&A 1999 - 2009

11

DB2 9 for z/OS

6/14/2009

Sample EXPLAIN Statement

Running this statement will populate the EXPLAIN tables

Then we can run the two EXPLAIN reporting queries

EXPLAIN PLAN SET QUERYNO = 3 FOR SELECT A.FIRSTNME, A.LASTNAME, B.DEPTNAME FROM DSN8710.EMP A INNER JOIN DSN8710.DEPT B ON A.WORKDEPT = B.DEPTNO WHERE A.EMPNO A EMPNO = '000010'; 000010 ;

YL&A 1997-2009

EXPLAIN Results PLAN_TABLE Query

PROGNAME -------DSNESM68 DSNESM68 QQP ----------00003-01-01 00003-01-02 MTH --0 1 MJC --------TBCREATOR --------DSN8710 DSN8710 TBNAME -----------------EMP DEPT CORR_NM -------A B ATYP ---I I A_NM --------------XEMP1 XDEPT1 IXO --N N MIX -----0 0 MCOL -----1 1

NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP B_TM -------- -- --- ----- -- ------ ---- ------ -------------------------NNNNN SELECT 0 T 2007-08-13 15:47:24.150000 NNNNN SELECT 0 T 2007-08-13 15:47:24.150000

The querys predicate number

PROGNAME -------DSNESM68 DSNESM68 QQP ----------00003-01-01 00003-01-02 MTH --0 1 P_NO ---2 3

Advanced EXPLAIN Query

MJC --------TBCREATOR --------DSN8710 DSN8710 TBNAME -----------------EMP DEPT

The number of rows the optimizer thinks will qualify after only local predicates are applied (take the lowest value)

CORR_NM ROWS_POST_FILTER ATYP A_NM -------- ---------------- ---- --------------A 1.0 I XEMP1 B 14.0 I XDEPT1

IXO --N N

Whether or not the predicate is Boolean Term

MIX -----0 0 MCOL -----1 1 STAGE --------MATCHING MATCHING FF -----------0.0238095223 0.0714285969 BT -Y Y PRED_TEXT30 -----------------------------A.EMPNO='000010' A.WORKDEPT=B.DEPTNO NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP -------- -- --- ----- -- ------ ---- -----NNNNN SELECT 0 T NNNNN SELECT 0 T

The predicate stage (where processed within DB2). Matching, Screening, Stage 1, or Stage 2

The predicate filter factor (percent of rows to be returned based on this predicate alone)

The actual predicate text including rewritten or generated predicates

YL&A 1997-2009

YL&A 1999 - 2009

12

DB2 9 for z/OS

6/14/2009

Simple Query Improvement EXPLAINed! The following query has no Boolean Term predicates
EXPLAIN PLAN SET QUERYNO=1 FOR SELECT * FROM DSN8710.EMP WHERE EMPNO = ? OR ( (EMPNO = ? AND LASTNAME >= ?) OR EMPNO > ? ORDER BY EMPNO, LASTNAME;

This improved query has a redundant predicated added

EXPLAIN PLAN SET QUERYNO=2 FOR SELECT * FROM DSN8710.EMP WHERE (EMPNO = ? OR (EMPNO = ? AND LASTNAME >= ?) OR EMPNO > ?) This redundant predicate was AND EMPNO >= ? added to the query to get index access on the EMPNO ORDER BY EMPNO, LASTNAME;
indexed column
YL&A 1997-2009

Advanced Explain Query Results Advanced EXPLAIN for Query 1

PROGNAME -------DSNESM68 DSNESM68 DSNESM68 DSNESM68 MIX -----0 0 0 0 MCOL -----0 0 0 0 QQP MTH P_NO MJC ----------- --- ---- --00001-01-01 0 2 --00001-01-01 0 4 --00001-01-01 0 5 --00001-01-01 0 6 --FF -----------.0238095223 .0238095223 .3333333134 .3333333134 BT -N N N N TBCREATOR --------DSN8710 DSN8710 DSN8710 DSN8710 TBNAME ------EMP EMP EMP EMP CORR_NM ROWS_POST_FILTER -------- -------- --------------15.3 -------15.3 -------15.3 -------15.3 ATYP ----I I I I A_NM IXO ------- --XEMP1 N XEMP1 N XEMP1 N XEMP1 N

STAGE --------STAGE1 STAGE1 STAGE1 STAGE1

PRED_TEXT30 NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP ------------------------------ -------- -- --- ----- -- ------ ---- -----DSN8710.EMP.EMPNO=(EXPR) NNNNN SELECT 0 T DSN8710.EMP.EMPNO=(EXPR) NNNNN SELECT 0 T DSN8710.EMP.LASTNAME>=(EXPR) NNNNN SELECT 0 T DSN8710.EMP.EMPNO>(EXPR) NNNNN SELECT 0 T

Advanced EXPLAIN for Query 2

PROGNAME -------DSNESM68 DSNESM68 DSNESM68 DSNESM68 DSNESM68 MIX -----0 0 0 0 0 MCOL -----1 1 1 1 1 QQP MTH P_NO MJC ----------- --- ---- --00002-01-01 0 3 --00002-01-01 0 5 --00002-01-01 0 6 --00002-01-01 0 7 --00002-01-01 0 8 --BT -N N N N Y TBCREATOR --------DSN8710 DSN8710 DSN8710 DSN8710 DSN8710 TBNAME ------EMP EMP EMP EMP EMP CORR_NM ROWS_POST_FILTER ATYP A_NM IXO -------- -------- -------- ----- ------- ---------5.1 I XEMP1 N -------5.1 I XEMP1 N -------5.1 I XEMP1 N -------5.1 I XEMP1 N -------5.1 I XEMP1 N NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP -------- -- --- ----- -- ------ ---- -----The improvement is detailed0 T NNNNN SELECT in the advanced EXPLAIN 0 T NNNNN SELECT NNNNN SELECT 0 T output via the access NNNNN SELECT 0 T boolean0 T NNNNN method, matchcols, SELECT

STAGE FF --------- -----------STAGE1 .0238095223 STAGE1 .0238095223 STAGE1 .3333333134 STAGE1 .3333333134 MATCHING .3333333134

PRED_TEXT30 -----------------------------DSN8710.EMP.EMPNO=(EXPR) DSN8710.EMP.EMPNO=(EXPR) DSN8710.EMP.LASTNAME>=(EXPR) DSN8710.EMP.EMPNO>(EXPR) DSN8710.EMP.EMPNO>=(EXPR)

term, and text columns

YL&A 1997-2009

YL&A 1999 - 2009

13

DB2 9 for z/OS

6/14/2009

Complicated Output The examples shown here are not perfect Output can be influenced by Compound predicates Multi-Index Multi Index access More rows of data than are needed can appear Be careful and adjust queries as needed Joining to additional EXPLAIN tables can further complicate the output

YL&A 1997-2009

Reading the Tables Separately If the output from the Advanced Query is too complicated Can reading each table separately Always y read the PLAN_TABLE _ first to g get the Big g Picture on the access path Reading each table separately Easier to do Have to put the data together yourself Can provide more information than the advanced explain join query query, or even the Explain Products

YL&A 1997-2009

YL&A 1999 - 2009

14

DB2 9 for z/OS

6/14/2009

Reading Tables Separately Example Here are queries to read the Filter and Predicate Tables

Do this when EXPLAINing a single statement and be sure to

Delete all rows from the Explain Tables first
SELECT SUBSTR(F.PROGNAME, 1, 8) AS PROGNAME ,SUBSTR(DIGITS(F.QUERYNO), 6) CONCAT '-' CONCAT SUBSTR(DIGITS(F.QBLOCKNO), 4) CONCAT '-' CONCAT SUBSTR(DIGITS(F.PLANNO), 4) AS QQP, PREDNO, STAGE, EXPLAIN_TIME AS B_TM FROM DSN_FILTER_TABLE F ORDER BY PROGNAME, B_TM, QQP, PREDNO;
The predicate number and stage is pulled from the DSN_FILTER_TABLE

SELECT SUBSTR(P.PROGNAME, 1, 8) AS PROGNAME ,SUBSTR(DIGITS(P.QUERYNO), 6) CONCAT '-' CONCAT SUBSTR(DIGITS(P.QBLOCKNO), 4) AS QQ, Addition predicate PREDNO, FILTER_FACTOR, BOOLEAN_TERM AS BT, information is pulled: join JOIN, AFTER_JOIN AS AJ, ADDED_PRED AS AP, predicate, after join REDUNDANT_PRED AS RP, KEYFIELD, substr(TEXT,1,40), EXPLAIN_TIME AS B_TMpredicate, added (generated) predicate, and redundant FROM DSN_PREDICAT_TABLE P predicate flags ORDER BY PROGNAME, B_TM, QQ, PREDNO;
YL&A 1997-2009

The predicate number, filter factor and boolean term flag is pulled from the DSN_PREDICATE_TABLE

Reading Tables Separately Example

SELECT A.FIRSTNME, A.LASTNAME, B.DEPTNAME FROM DSN8810.EMP a INNER JOIN DSN8810.DEPT B ON A.WORKDEPT = B.DEPTNO WHERE A.EMPNO = '000010';

Our join predicate is identified as using a key field

DSN_FILTER_TABLE Query Output

PROGNAME QQP PREDNO STAGE B_TM ---------+---------+---------+---------+---------+---------+---------+--DSNESM68 00001-01-01 2 MATCHING 2008-08-06-13.25.46.040000 DSNESM68 00001-01-02 3 MATCHING 2008-08-06-13.25.46.040000

DSN_PREDICAT_TABLE Query Output

PROGNAME QQ PREDNO FILTER FILTER_FACTOR FACTOR BT JOIN AJ AP RP KEYFIELD ---------+---------+---------+---------+---------+---------+---------+---------+-------DSNESM68 00001-01 1 +0.1000000000000000E+01 Y N N N N DSNESM68 00001-01 2 +0.2380952239036560E-01 Y N N N Y DSNESM68 00001-01 3 +0.7142859697341919E-01 Y Y N N Y TEXT B_TM ---------+---------+---------+---------+---------+---------+-------(A.EMPNO='000010' AND A.WORKDEPT=B.DEPTN 2008-08-06-13.25.46.040000 A.EMPNO='000010' 2008-08-06-13.25.46.040000 A.WORKDEPT=B.DEPTNO 2008-08-06-13.25.46.040000

The compound predicate is displayed

YL&A 1997-2009

YL&A 1999 - 2009

15

DB2 9 for z/OS

6/14/2009

Reading Tables Separately Example

EXPLAIN PLAN SET QUERYNO=1 FOR SELECT A.FIRSTNME, A.LASTNAME, B.DEPTNAME FROM DSN8810.EMP a INNER JOIN DSN8810.DEPT B ON A.WORKDEPT = B.DEPTNO WHERE A.WORKDEPT A WORKDEPT = 'B01'; B01 ;

Our join predicate is id ifi d as stage 2 identified

DSN_FILTER_TABLE Query Output

PROGNAME QQP PREDNO STAGE B_TM ---------+---------+---------+---------+---------+---------+---------+--DSNESM68 00001-01-01 4 MATCHING 2008-08-06-13.08.53.170000 DSNESM68 00001-01-02 2 MATCHING 2008-08-06-13.08.53.170000 DSNESM68 00001-01-02 3 STAGE2 2008-08-06-13.08.53.170000

DSN_PREDICAT_TABLE Query Output

PROGNAME QQ PREDNO FILTER_FACTOR BT JOIN AJ AP RP KEYFIELD ---------+---------+---------+---------+---------+---------+---------+---------+-------DSNESM68 00001-01 1 +0.1000000000000000E+01 Y N N N N DSNESM68 00001-01 2 +0.2380952239036560E-01 Y N N N Y DSNESM68 00001-01 3 +0.7142859697341919E-01 Y Y N N N DSNESM68 00001-01 4 +0.7142859697341919E-01 Y N Y N Y TEXT B_TM ---------+---------+---------+---------+---------+---------+-------(B.DEPTNO='B01' AND (A.WORKDEPT='B01' AN 2008-08-06-13.08.53.170000 A.WORKDEPT='B01' 2008-08-06-13.08.53.170000 A.WORKDEPT=B.DEPTNO 2008-08-06-13.08.53.170000 B.DEPTNO='B01' 2008-08-06-13.08.53.170000

This fourth predicate was generated by DB2 via predicate transitive closure

YL&A 1997-2009

Addition Information Not Covered

This is only an introduction to the use of these tables May require more information Compliments the PLAN_TABLE information Filter, Detailed Cost, and Predicate tables provide enhanced information
Views and MQTs used in a query

DSN_VIEWREF_TABLE DSN_QUERY_TABLE DSN_PGRANGE_TABLE DSN_SORTKEY_TABLE DSN_SORT_TABLE DSN_PTASK_TABLE DSN_PGROUP_TABLE DSN_STRUCT_TABLE

Query text before and after query transformation Qualified partitions for a page range scan The keys y for all sorts in a query Sort operations required Information about query parallelism Information about each query block in a query
YL&A 1997-2009

YL&A 1999 - 2009

16

DB2 9 for z/OS

6/14/2009

Global Prepare Cache V8 Explain has been enhanced

Allowing for EXPLAINs to be done for statements in the global

prepare cache
The access path used by the statement is written to the PLAN_TABLE COLLID - DSNDYNAMICSQLCACHE The statement does NOT go through access path selection (as opposed to normal explain processing of dynamic SQL)

Statement Id (STMTID) available from trace records with IFCID 316,

124 Statement Token (STMTTOKEN) assigned by application that prepares statement
RRSAF SET_ID function SQLESETI function for remote applications EXPLAIN STMTCACHE STMTID = int EXPLAIN STMTCACHE STMTTOKEN = string
YL&A 1997-2009

DSN_STATEMENT_CACHE_TABLE V8
To populate use keyword ALL is on EXPLAIN STMTCACHE DSN_STATEMENT_CACHE_TABLE is created to hold the output of IFCID 316 and IFCID 318 Two different sets of information that can be collected from the SQL statements in the dynamic y statement cache STMTCACHE with the STMTID or STMTTOKEN

Traditional access path information to be written to the PLAN_TABLE

for the associated SQL statement

Single row written to DSN_STATEMENT_CACHE_TABLE if it exists

STMTCACHE with the ALL keyword

Information is written only DSN_STATEMENT_CACHE_TABLE Co Consists s sts o of o one e row o pe per SQ SQL state statement e t in t the e dy dynamic a c state statement e t cac cache e
for which the current authorization ID is authorized to execute.

EXPLAIN STMTCACHE ALL

YL&A 1997-2009

YL&A 1999 - 2009

17

DB2 9 for z/OS

6/14/2009

DSN_STATEMENT_CACHE_TABLE V8
STMT_ID STMT_TOKEN COLLID PROGRAM_NAME INV DROPALT INV_DROPALT INV_REVOKE INV_LRU INV_RUNSTATS CACHED_TS USERS Statement ID, EDM unique token Statement token. User-provided identification string Collection id value is DSNDYNAMICSQLCACHE Program name, Name of package or DBRM that performed the initial PREPARE Invalidated by DROP/ALTER Invalidated by REVOKE Removed from cache by LRU Invalidated by RUNSTATS TS Timestamp when statement was cached Number of current users of statement. These are the users that have prepared or executed the statement during their current unit of work. Number of copies of the statement owned by all threads in the system Precompiler line number from the initial PREPARE User ID - Primary authorization ID of the user that did the initial PREPARE CURRENT SQLID of the user that did the initial prepare
YL&A 1997-2009

COPIES LINES PRIMAUTH CURSQLID

DSN_STATEMENT_CACHE_TABLE (cont..) V8
BIND_QUALIFIER BIND_ISO BIND_C BIND_DYNRL BIND DEGRE BIND_DEGRE BIND_SQLRL BIND_CHOLD STAT_TS STAT_EXEC STAT_GPAG STAT_SYNR STAT WRIT STAT_WRIT STAT_EROW STAT_PROW STAT_SORT STAT_INDX STAT_RSCN Bind Qualifier, object qualifier for unqualified table names ISOLATION BIND option: , 'UR' - Uncommitted Read , 'CS' - Cursor Stability , 'RS' - Read Stability , 'RR' - Repeatable Read DATA CURRENTDATA BIND option: - 'Y' - CURRENTDATA(YES) - 'N' - CURRENTDATA(NO) DYNAMICRULES BIND option: - 'B' - DYNAMICRULES(BIND), 'R' - DYNAMICRULES(RUN) CURRENT DEGREE value: - 'A' A - CURRENT DEGREE = ANY , '1' 1 - CURRENT DEGREE = 1 CURRENT RULES value: D' - CURRENT RULES = DB2, 'S' - CURRENT RULES = SQL Cursor WITH HOLD bind option 'Y' - Initial PREPARE was done for a cursor WITH HOLD, 'N' - Initial PREPARE was not done for a cursor WITH HOLD Timestamp of stats when IFCID 318 is started Number of executions of statement. For a cursor statement, this is the number of OPENs Number of getpage operations performed for statement Number of synchronous buffer reads performed for statement N b of Number f buffer b ff write it operations ti performed f d for f statement t t t Number of rows examined for statement Number of rows processed for statement Number of sorts performed for statement Number of index scans performed for statement Number of table space scans performed for statement

YL&A 1997-2009

YL&A 1999 - 2009

18

DB2 9 for z/OS

6/14/2009

DSN_STATEMENT_CACHE_TABLE (cont..) V8
STAT_PGRP STAT_ELAP STAT_CPU STAT_SUS_SYNIO STAT_SUS_LOCK STAT_SUS_SWIT STAT_SUS_GLCK STAT_SUS_OTHR STAT_SUS_OTHW STAT_RIDLIMT STAT_RIDSTOR EXPLAIN_TS SCHEMA STMT_TEXT STMT_ROWID Number of parallel groups created for statement Accumulated elapsed time used for statement Accumulated CPU time used for statement Accumulated wait time for synchronous I/O Accumulated wait time for lock and latch request Accumulated wait time for synchronous execution unit switch Accumulated wait time for global locks Accumulated wait time for read activity done by another thread Accumulated wait time for write activity done by another thread Number of times a RID list was not used because the number of RIDs would have exceeded one or more DB2 limits Number of times a RID list was not used because not enough storage was available to hold the list of RIDs When statement cache table is populated CURRENT SCHEMA value Statement text Statement ROWID

YL&A 1997-2009

DSN_STATEMENT_CACHE_TABLE V9

New Columns in V9
BIND RA TOT BIND_RA_TOT
Total number of rebinds that have been issued for the dynamic statement due to REOPT(AUTO)

BIND_TO_TYPE
N REOPT(NONE) or its equivalent 1 REOPT(ONCE) or its equivalent A REOPT(AUTO) ( ) O Current plan is deemed as optimal and no need for further REOPT(AUTO)

YL&A 1997-2009

YL&A 1999 - 2009

19

DB2 9 for z/OS

6/14/2009

DSN_STATMENT_CACHE_TABLE Usage
SELECT cached_ts, STAT_EXEC, dec(stat_elap,12,2) as stat_elap, dec(STAT_CPU,12,2) as stat_cpu, left(STMT_TEXT,100) as short_text from UID1.DSN_STATEMENT_CACHE_TABLE where primauth = ABC' and explain_ts > '2008-08-27-00.00.00.000000' order by stat_cpu desc

An example statement extracting elapsed and CPU time f queries for i in i th the d dynamic i SQL cache, h i including l di th the fi first t 100 characters of the SQL text. Could also get STMTID and then obtain the access path information from the cache.
YL&A 1997-2009

Example Output
CACHED_TS STAT_EXEC STAT_ELAP STAT_CPU SHORT_TEXT -------------------------------------------------------------------------------------------------------------------------2008-08-26 01:55:29.340787 341295 7050.42 1924.97 SELECT 2008-08-26 01:55:24 01:55:24.243727 243727 2008-08-26 01:55:30.130466 252134 193977 5508.16 5508 16 2943.68 1741.26 1741 26 930.89 SELECT SELECT

An example statement extracting elapsed and CPU time for queries in the dynamic SQL cache, including the SQL text (just the first few characters in this example).

YL&A 1997-2009

YL&A 1999 - 2009

20

DB2 9 for z/OS

6/14/2009

Conclusions IBM's advanced SQL analysis tools

Nice if you have them available

The EXPLAIN tables explained

Many new tables with additional information

Defining the EXPLAIN tables you need

Can be defined and populated outside the tools

Running EXPLAINs under SPUFI

Or anywhere an EXPLAIN can be executed

Queries for the EXPLAIN tables

Basic and advanced

Selecting only at the fields needed for query tuning

Many very useful fields for additional information

EXPLAIN facilities for dynamic SQL tuning

Ability to look at statement cache

YL&A 1997-2009

DB2 9 for z/OS DBA Certification Guide

DB2 9 for z/OS DBA Certification Guide McPress October 2007 Authored By Susan Lawson and Dan Luksetich

YL&A 1997-2009

YL&A 1999 - 2009

21

DB2 9 for z/OS

6/14/2009

DB2 Information on the Web

IBM Ibm.com IBM Software Ibm.com/software DB2 Family Ibm.com/software/db2 DB2 S Solutions l ti Directory Di t A Applications li ti Ibm.com/developerworks/db2 "Red Books" ibm. com/ redbooks DB2 for z/OS Ibm. Com/software/db2zos DB2 Support Ibm.com/software/db2zos/support.html DB2 for z/OS Papers f //f ftp://ftp.software.ibm.com/software/data/db2zos f / f / / DB2 Magazine http:// www. db2mag. Com DB2 Certification http://www.ibm.com/certify DB2 Experts www.db2expert.com
YL&A 1997-2009

Courses by YL&A - Taught by skilled instructors world-wide!

DB2 V9 for z/OS Transition DB2 V8 for z/OS Transition We customize all Application or DBA or both classes based upon SQL (z/OS and LUW) customer requirements Basic SQL Advanced and Complex SQL SQL Performance Tuning and Optimization Application Development Stored Procedure Development and Implementation UDFs and Triggers Development ONLY YL&A offers you the Database Design DB2 V9 DBA Certification Physical Design, Logical Design Crammer Course to Data Sharing help you become certified!! Implementation, Performance, Recovery High Performance Design and Tuning Application, Database, Systems DB2 V9 for z/OS Certification Crammer Course
YL&A 1997-2009

YL&A 1999 - 2009

22

DB2 9 for z/OS

6/14/2009

CPU Reduction Through Performance Audits

DB2 Performance Audits Existing or new database designs and applications Certification of design and implementation acceptance Evaluation of all the performance points in a DB2 environment Physical Design Subsystem Application Code and SQL Help with bringing legacy application to an e-business environment the rules have changed! What was acceptable performance in the past is NOT acceptable in an e-business environment Experienced in fighting fires many performance problems do not become reality until production Results: problems identified, solutions proposed (many implemented immediately), continual knowledge transfer during the process

Cost Avoidance Through Performance Tuning!!!!

YL&A 1997-2009

YL&A 1999 - 2009

23