DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 1

Using Explain Tables for Tuning Queries

Susan LawsonYL&A

Yevich, Lawson & Assoc. Inc.2743 S. Veterans Pkwy PMB 226

Springfield, IL 62704

www.ylassoc.comwww db2expert com

© YL&A 1997-2009

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.

www.db2expert.com

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 2

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.

n 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.

n The use of this information or the implementation of any of these techniques is a client responsibility and depends on the client’s ability to evaluate and integrate them into the client’s operational environment.

n 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.

© YL&A 1997-2009

n Clients attempting to adapt these techniques to their own environments do so at their own risks.

n Foils, handouts, and additional materials distributed as part of this presentation or seminar should be reviewed in their entirety.

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

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 3

EXPLAIN and EXPLAIN Tools and Queries

n EXPLAIN has been enhanced greatly for DB2 V8 and DB2 9n Several EXPLAIN tools are available

– Visual Explain– Optimization Service Centerp

l Replaces Visual Explainl Works with V8 NFM

– Data Studiol Visual Explain Plug-Ins

n However, DB2 EXPLAIN facility is built-in to DB2– No additional tools are needed to perform an EXPLAIN

© YL&A 1997-2009

– EXPLAIN tables contain access path information– Anyone can read the access path information from the EXPLAIN

tables

Visual Explain Tool (DB2 V8)

n A GUI interface to the information in the EXPLAIN tablesn Provides information about statements in the systemn Can dynamically EXPLAIN statementsn Can get Statistics for accessed objectsn Ability to browse subsystem parametersn Compatible with V7 subsystemsn With V8 subsystems

– More information than the PLAN_TABLE provides– Cardinality and Filter Factor information– Additional of predicate information

© YL&A 1997-2009

Additional of predicate information– Some rewritten predicates exposed

n Method of transmission of information to IBM– XML File– Service SQL Feature

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 4

Visual Explain – Index Scan

© YL&A 1997-2009

VISUAL EXPLAIN - Fetch

© YL&A 1997-2009

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 5

Visual Explain – Statistics Advisor

© YL&A 1997-2009

Visual Explain – Join Predicates and Filter Factor

© YL&A 1997-2009

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 6

Optimization Service Center (DB2 9)n A workstation-based tool

– Easy interaction with DB2 EXPLAIN and the explain tables– Allows you to analyze

l SQL statementsl Objectsl Objectsl Statisticsl The statement cachel Workloads

n Replaces Visual Explainn Has Many of the features of Visual Explainn Compatible with V8 Subsystems in New Function Mode

H dditi l f t th t b h d

© YL&A 1997-2009

n Has additional features that can be purchased

Why Not Use These Products for EXPLAIN?

n PC workstation maybe does not have enough power– These tools use a lot of the machine

n DB2 Connect Enterprise Edition is requiredn Remote connections to mainframe are required

Thi i it– This raises security concernsl Especially for production

n SPUFI or QMF is often preferred– This is a fast and easy method

© YL&A 1997-2009

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 7

Additional Explain Tables

n Most available in V8n Now very accessible in V9 via Optimization Service

Center or SQLn Documented in IBM DSN VIEWREF TABLEDB2 9 Performance

Guide

DSN_VIEWREF_TABLEDSN_QUERY_TABLE

DSN_PGRANGE_TABLEDSN_SORTKEY_TABLE

DSN_SORT_TABLEDSN_DETCOST_TABLE

DSN FILTER TABLEPLAN_TABLE

© YL&A 1997-2009

DSN_FILTER_TABLEDSN_PTASK_TABLE

DSN_PGROUP_TABLEDSN_STRUCT_TABLE

DSN_PREDICAT_TABLE

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

© YL&A 1997-2009

EXPLAIN– Helps those especially without distributed access to the

mainframe

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 8

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 PathMore details are available but the first look simplifies the view and� More details are 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

© YL&A 1997-2009

PLAN_TABLEDSN_FILTER_TABLE

DSN_PREDICAT_TABLEDSN_DETCOST_TABLE

PLAN_TABLE

� This is the base access path information

METHODMERGE_JOIN_COLSCREATOR

Columns for initial analysis First table accessed, join method, or sort

Number of merge scan joined columns

Name of table TNAMECORRELATION_NAMEACCESSTYPEACCESSNAMEINDEXONLYMIXOPSEQMATCHCOLSSORT#### ColsPREFETCH

accessed Table correlation name in queryIndex access or table

space scanIndex name if used

‘Y’ if index-only accessMulti-index step number (if used)Quantity of index

matching columns used Sort reasonsPrefetch type if used ‘Y’ if table space scan and

© YL&A 1997-2009

PREFETCHPAGE_RANGEJOIN_TYPEPARENT_QBLOCKNOTABLE TYPEBIND_TIME

Prefetch type if used ‘Y’ if table space scan and partition elimination

Join type if used Parent query block number (subqueries, etc.)

Table, work file, MQT, subquery, etc.

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 9

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

COLLIDPROGNAMEQUERYNOEXPLAIN_TIME

PREDNOSTAGE

These columns used for join to PLAN_TABLE

The relative predicate number used to join to

DSN_PREDICAT_TABLE

Th di t t ( h

Columns for initial analysis

© YL&A 1997-2009

The predicate stage (where processed within DB2).

Matching, Screening, Stage 1, or Stage 2

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 10

DSN_PREDICAT_TABLE

� Contains information about the predicates in a query– One row per simple and compound predicate

COLLID These columns used for join to PLAN TABLE

Columns for initial analysis

PROGNAMEQUERYNOEXPLAIN_TIMEPREDNO

FILTER_FACTORBOOLEAN_TERMTEXT

The relative predicate number used to join to DSN_FILTER_TABLE

join to PLAN_TABLE

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

predicate alone)

© YL&A 1997-2009

predicate alone)

Whether or not the predicate is Boolean Term(when it evaluates to false does it make the

entire WHERE clause false)

The actual predicate text including rewritten or generated predicates

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

COLLIDPROGNAMEQUERYNOEXPLAIN_TIMEQBLOCKNOPLANNO

These columns used for join to PLAN_TABLE

The number of rows the optimizer thinks will qualify

after only local predicates are

Columns for initial analysis

© YL&A 1997-2009

ONECOMPROWS applied (take the lowest value)

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 11

Basic PLAN_TABLE Query SELECT SUBSTR(DIGITS(QUERYNO),5) CONCAT 'SELECT SUBSTR(DIGITS(QUERYNO),5) CONCAT '--' CONCAT ' CONCAT SUBSTR(DIGITS(QBLOCKNO),4) CONCAT 'SUBSTR(DIGITS(QBLOCKNO),4) CONCAT '--' CONCAT SUBSTR(DIGITS(PLANNO),4) AS ' CONCAT SUBSTR(DIGITS(PLANNO),4) AS Q_QB_PL ,PROGNAME AS PNAME ,SUBSTR(CHAR(METHOD),1,1) AS MT 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 ,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 ,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 ,SORTN_JOIN CONCAT SORTC_UNIQ CONCAT SORTC_JOIN CONCAT SORTC_ORDERBY CONCAT SORTC GROUPBY AS NJ CUJOG PREFETCH AS PF COLUMN FN EVAL ASCONCAT SORTC GROUPBY AS NJ CUJOG PREFETCH AS PF COLUMN FN EVAL ASCONCAT SORTC_GROUPBY AS NJ_CUJOG ,PREFETCH AS PF ,COLUMN_FN_EVAL AS CONCAT SORTC_GROUPBY AS NJ_CUJOG ,PREFETCH AS PF ,COLUMN_FN_EVAL AS CFE ,CHAR(MIXOPSEQ) AS MIX ,ACCESS_DEGREE AS A_DEG ,JOIN_DEGREE AS J_DEG 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 ,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 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 ,QBLOCK_TYPE AS QB_TYP ,BIND_TIME AS B_TM ,HINT_USED AS HINT ,PRIMARY_ACCESSTYPE AS PR_ACC ,PRIMARY_ACCESSTYPE AS PR_ACC

FROM PLAN_TABLE A FROM PLAN_TABLE A

----WHERE PROGNAME = 'YLAPROG1' <WHERE PROGNAME = 'YLAPROG1' <---- TARGET A SPECIFIC PROGRAM HERE TARGET A SPECIFIC PROGRAM HERE

WHERE BIND TIME = (SELECT MAX(BIND TIME) FROM PLAN TABLE B WHEREWHERE BIND TIME = (SELECT MAX(BIND TIME) FROM PLAN TABLE B WHERE

© YL&A 1997-2009

WHERE BIND_TIME = (SELECT MAX(BIND_TIME) FROM PLAN_TABLE B WHERE WHERE BIND_TIME = (SELECT MAX(BIND_TIME) FROM PLAN_TABLE B WHERE A.PROGNAME = B.PROGNAME AND A.COLLID = B.COLLID) A.PROGNAME = B.PROGNAME AND A.COLLID = B.COLLID)

ORDER BY PROGNAME, BIND_TIME, Q_QB_PL, MIX; ORDER BY PROGNAME, BIND_TIME, Q_QB_PL, MIX;

Advanced EXPLAIN QueryWITH MAXTIME (COLLID, PROGNAME, QUERYNO, BIND_TIME) AS (SELECT COLLID, PROGNAME, QUERYNO, 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 MAX(BIND_TIME) FROM PLAN_TABLE WHERE COLLID = 'DSNESPCS' AND PROGNAME = 'DSNESM68' GROUP BY COLLID, PROGNAME, QUERYNO) COLLID, PROGNAME, QUERYNO) SELECT SUBSTR(P.PROGNAME, 1, 8) AS PROGNAME,SUBSTR(DIGITS(P.QUERYNO), 6) CONCAT 'SELECT SUBSTR(P.PROGNAME, 1, 8) AS PROGNAME,SUBSTR(DIGITS(P.QUERYNO), 6) CONCAT '--' CONCAT ' CONCAT SUBSTR(DIGITS(P.QBLOCKNO), 4) CONCAT 'SUBSTR(DIGITS(P.QBLOCKNO), 4) CONCAT '--' CONCAT SUBSTR(DIGITS(P.PLANNO), 4) AS ' CONCAT SUBSTR(DIGITS(P.PLANNO), 4) AS QQP,SUBSTR(CHAR(P.METHOD), 1, 3) AS MTH ,SUBSTR(CHAR(F.PREDNO), 1, 3) 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 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 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 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 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 ,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 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 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 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,P.QBLOCK_TYPE AS QB_TYP,P.PARENT_QBLOCKNO AS P_QB,P.TABLE_TYPE AS TB_TYP,P.BIND_TIME AS B_TMFROM PLAN_TABLE P INNER JOIN MAXTIME M ON M.COLLID = P.COLLID AND M.PROGNAME=P.PROGNAME FROM PLAN_TABLE P INNER JOIN MAXTIME M ON M.COLLID = P.COLLID AND M.PROGNAME=P.PROGNAME AND M.QUERYNO=P.QUERYNO AND M.BIND_TIME=P.BIND_TIME AND M.QUERYNO=P.QUERYNO AND M.BIND_TIME=P.BIND_TIME LEFT JOIN DSN_FILTER_TABLE F LEFT JOIN DSN_FILTER_TABLE F ON M.COLLID = F.COLLID AND M.PROGNAME=F.PROGNAME AND M.QUERYNO=F.QUERYNO AND ON M.COLLID = F.COLLID AND M.PROGNAME=F.PROGNAME AND M.QUERYNO=F.QUERYNO AND P.QBLOCKNO=F.QBLOCKNO P.QBLOCKNO=F.QBLOCKNO AND P.PLANNO = F.PLANNO AND M.BIND_TIME=F.EXPLAIN_TIME AND P.ACCESSTYPE Not IN ('MX', 'MI', 'MU') AND P.PLANNO = F.PLANNO AND M.BIND_TIME=F.EXPLAIN_TIME AND P.ACCESSTYPE Not IN ('MX', 'MI', 'MU')

© YL&A 1997-2009

LEFT JOIN DSN_PREDICAT_TABLE E LEFT JOIN DSN_PREDICAT_TABLE E ON F.PROGNAME = E.PROGNAME AND F.QUERYNO=E.QUERYNO AND F.QBLOCKNO=E.QBLOCKNO ON F.PROGNAME = E.PROGNAME AND F.QUERYNO=E.QUERYNO AND F.QBLOCKNO=E.QBLOCKNO AND F.PREDNO = E.PREDNO AND M.BIND_TIME=E.EXPLAIN_TIME AND F.PREDNO = E.PREDNO AND M.BIND_TIME=E.EXPLAIN_TIME LEFT JOIN TABLE (SELECT MIN(X.ONECOMPROWS) AS ONECOMPROWS FROM DSN_DETCOST_TABLE X 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 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 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; ON 1=1 ORDER BY PROGNAME, B_TM, QQP, MIX, F.PREDNO;

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 12

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 FOREXPLAIN PLAN SET QUERYNO = 3 FORSELECT A.FIRSTNME, A.LASTNAME, B.DEPTNAMEFROM DSN8710.EMP AINNER JOIN

DSN8710.DEPT BON A.WORKDEPT = B.DEPTNOWHERE A EMPNO = '000010';

© YL&A 1997-2009

WHERE A.EMPNO 000010 ;

EXPLAIN Results

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

NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP B_TM -------- -- --- ----- -- ------ ---- ------ --------------------------

PLAN_TABLE Query

NNNNN SELECT 0 T 2007-08-13 15:47:24.150000NNNNN SELECT 0 T 2007-08-13 15:47:24.150000

Advanced EXPLAIN QueryPROGNAME QQP MTH P_NO MJC TBCREATOR TBNAME CORR_NM ROWS_POST_FILTER ATYP A_NM IXO -------- ----------- --- ---- --- --------- ------------------ -------- ---------------- ---- --------------- ---DSNESM68 00003-01-01 0 2 ---- DSN8710 EMP A 1.0 I XEMP1 NDSNESM68 00003-01-02 1 3 ---- DSN8710 DEPT B 14.0 I XDEPT1 N

The number of rows the optimizer thinks will

qualify after only local predicates are applied (take the lowest value)The query’s predicate

number

Whether or not the predicate is Boolean Term

© YL&A 1997-2009

MIX MCOL STAGE FF BT PRED_TEXT30 NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP ------ ------ --------- ------------ -- ------------------------------ -------- -- --- ----- -- ------ ---- ------0 1 MATCHING 0.0238095223 Y A.EMPNO='000010' NNNNN SELECT 0 T0 1 MATCHING 0.0714285969 Y A.WORKDEPT=B.DEPTNO 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

Whether or not the predicate is Boolean Term

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 13

Simple Query Improvement EXPLAINed!

� The following query has no Boolean Term predicatesEXPLAIN PLAN SET QUERYNO=1 FORSELECT *FROM DSN8710.EMPWHERE EMPNO = ?OR (EMPNO = ? AND

� This improved query has a redundant predicated added

(LASTNAME >= ?)

OR EMPNO > ?ORDER BY EMPNO, LASTNAME;

EXPLAIN PLAN SET QUERYNO=2 FORSELECT *FROM DSN8710.EMP

© YL&A 1997-2009

WHERE (EMPNO = ?OR (EMPNO = ? AND

LASTNAME >= ?)OR EMPNO > ?)AND EMPNO >= ?ORDER BY EMPNO, LASTNAME;

This redundant predicate was added to the query to get

index access on the EMPNO indexed column

Advanced Explain Query Results

Advanced EXPLAIN for Query 1PROGNAME QQP MTH P_NO MJC TBCREATOR TBNAME CORR_NM ROWS_POST_FILTER ATYP A_NM IXO -------- ----------- --- ---- --- --------- ------- -------- -------- -------- ----- ------- ---DSNESM68 00001-01-01 0 2 --- DSN8710 EMP -------- 15.3 I XEMP1 N DSNESM68 00001-01-01 0 4 --- DSN8710 EMP -------- 15.3 I XEMP1 N DSNESM68 00001-01-01 0 5 --- DSN8710 EMP -------- 15.3 I XEMP1 N DSNESM68 00001-01-01 0 6 --- DSN8710 EMP -------- 15.3 I XEMP1 N

MIX MCOL STAGE FF BT PRED_TEXT30 NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP ------ ------ --------- ------------ -- ------------------------------ -------- -- --- ----- -- ------ ---- ------0 0 STAGE1 .0238095223 N DSN8710.EMP.EMPNO=(EXPR) NNNNN SELECT 0 T0 0 STAGE1 .0238095223 N DSN8710.EMP.EMPNO=(EXPR) NNNNN SELECT 0 T0 0 STAGE1 .3333333134 N DSN8710.EMP.LASTNAME>=(EXPR) NNNNN SELECT 0 T0 0 STAGE1 .3333333134 N DSN8710.EMP.EMPNO>(EXPR) NNNNN SELECT 0 T

Advanced EXPLAIN for Query 2PROGNAME QQP MTH P_NO MJC TBCREATOR TBNAME CORR_NM ROWS_POST_FILTER ATYP A_NM IXO -------- ----------- --- ---- --- --------- ------- -------- -------- -------- ----- ------- ---DSNESM68 00002-01-01 0 3 --- DSN8710 EMP -------- 5.1 I XEMP1 N DSNESM68 00002-01-01 0 5 --- DSN8710 EMP -------- 5.1 I XEMP1 N DSNESM68 00002-01-01 0 6 --- DSN8710 EMP -------- 5.1 I XEMP1 N

© YL&A 1997-2009

DSNESM68 00002-01-01 0 7 --- DSN8710 EMP -------- 5.1 I XEMP1 N DSNESM68 00002-01-01 0 8 --- DSN8710 EMP -------- 5.1 I XEMP1 N

MIX MCOL STAGE FF BT PRED_TEXT30 NJ_CUJOG PF CFE PGRNG JT QB_TYP P_QB TB_TYP ------ ------ --------- ------------ -- ------------------------------ -------- -- --- ----- -- ------ ---- ------0 1 STAGE1 .0238095223 N DSN8710.EMP.EMPNO=(EXPR) NNNNN SELECT 0 T0 1 STAGE1 .0238095223 N DSN8710.EMP.EMPNO=(EXPR) NNNNN SELECT 0 T0 1 STAGE1 .3333333134 N DSN8710.EMP.LASTNAME>=(EXPR) NNNNN SELECT 0 T0 1 STAGE1 .3333333134 N DSN8710.EMP.EMPNO>(EXPR) NNNNN SELECT 0 T0 1 MATCHING .3333333134 Y DSN8710.EMP.EMPNO>=(EXPR) NNNNN SELECT 0 T

The improvement is detailed in the advanced EXPLAIN

output via the access method, matchcols, boolean

term, and text columns

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 14

Complicated Output

� The examples shown here are not perfect� Output can be influenced by

–Compound predicates–Multi Index access–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 read the PLAN_TABLE first to get the ‘Big y _ g 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 or even the Explain Products

© YL&A 1997-2009

explain join query, or even the Explain Products

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 15

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 '-' The predicate number and,SUBSTR(DIGITS(F.QUERYNO), 6) CONCAT CONCAT SUBSTR(DIGITS(F.QBLOCKNO), 4)CONCAT '-' CONCATSUBSTR(DIGITS(F.PLANNO), 4) AS QQP,PREDNO, STAGE, EXPLAIN_TIME AS B_TM

FROM DSN_FILTER_TABLE FORDER BY PROGNAME, B_TM, QQP, PREDNO;

SELECT SUBSTR(P.PROGNAME, 1, 8) AS PROGNAME,SUBSTR(DIGITS(P.QUERYNO), 6) CONCAT '-'

The predicate number and stage is pulled from the

DSN_FILTER_TABLE

The predicate number, filter factor and boolean term flag

is pulled from the DSN_PREDICATE_TABLE

© YL&A 1997-2009

CONCAT SUBSTR(DIGITS(P.QBLOCKNO), 4) AS QQ,PREDNO, FILTER_FACTOR, BOOLEAN_TERM AS BT,JOIN, AFTER_JOIN AS AJ, ADDED_PRED AS AP,REDUNDANT_PRED AS RP,KEYFIELD, substr(TEXT,1,40), EXPLAIN_TIME AS B_TM

FROM DSN_PREDICAT_TABLE PORDER BY PROGNAME, B_TM, QQ, PREDNO;

Addition predicate information is pulled: join

predicate, after join predicate, added (generated)

predicate, and redundant predicate flags

Reading Tables Separately Example

SELECT A.FIRSTNME, A.LASTNAME, B.DEPTNAMEFROM DSN8810.EMP aINNER JOIN

DSN8810.DEPT BON A.WORKDEPT = B.DEPTNOWHERE A.EMPNO = '000010'; Our join predicate is

identified as using a key field

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

PROGNAME QQ PREDNO FILTER FACTOR BT JOIN AJ AP RP KEYFIELD

DSN_FILTER_TABLE Query Output

DSN_PREDICAT_TABLE Query Output

© YL&A 1997-2009

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 Y

TEXT B_TM---------+---------+---------+---------+---------+---------+--------(A.EMPNO='000010' AND A.WORKDEPT=B.DEPTN 2008-08-06-13.25.46.040000A.EMPNO='000010' 2008-08-06-13.25.46.040000A.WORKDEPT=B.DEPTNO 2008-08-06-13.25.46.040000

The compound predicate is displayed

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 16

Reading Tables Separately Example

EXPLAIN PLAN SET QUERYNO=1 FORSELECT A.FIRSTNME, A.LASTNAME, B.DEPTNAMEFROM DSN8810.EMP aINNER JOIN

DSN8810.DEPT BON A.WORKDEPT = B.DEPTNOWHERE A WORKDEPT = 'B01'; Our join predicate is

id ifi d 2WHERE A.WORKDEPT = B01 ;

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

PROGNAME QQ PREDNO FILTER_FACTOR BT JOIN AJ AP RP KEYFIELD---------+---------+---------+---------+---------+---------+---------+---------+--------

DSN_FILTER_TABLE Query Output

DSN_PREDICAT_TABLE Query Output

identified as stage 2

© YL&A 1997-2009

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.170000A.WORKDEPT='B01' 2008-08-06-13.08.53.170000A.WORKDEPT=B.DEPTNO 2008-08-06-13.08.53.170000B.DEPTNO='B01' 2008-08-06-13.08.53.170000

This fourth predicate was generated by DB2 via

predicate transitive closure

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

informationinformation

DSN_VIEWREF_TABLEDSN_QUERY_TABLE

DSN_PGRANGE_TABLEDSN_SORTKEY_TABLE

Views and MQTs used in a query

Query text before and after query transformation

Qualified partitions for a page range scan

The keys for all sorts

© YL&A 1997-2009

DSN_SORT_TABLEDSN_PTASK_TABLE

DSN_PGROUP_TABLEDSN_STRUCT_TABLE

yin a query

Sort operations required

Information about query parallelism

Information about each query block in a query

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 17

� 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

Global Prepare Cache – V8

� 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

© YL&A 1997-2009

� SQLESETI function for remote applicationsEXPLAIN STMTCACHE

STMTID = int

EXPLAIN STMTCACHESTMTTOKEN = string

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 statement cache y� 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– Consists of one row per SQL statement in the dynamic statement cache

© YL&A 1997-2009

Co s sts o o e o pe SQ state e t t e dy a c state e t cac efor which the current authorization ID is authorized to execute.

EXPLAIN STMTCACHE ALL

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 18

DSN_STATEMENT_CACHE_TABLE – V8STMT_ID Statement ID, EDM unique tokenSTMT_TOKEN Statement token. User-provided identification stringCOLLID Collection id value is DSNDYNAMICSQLCACHEPROGRAM_NAME Program name, Name of package or DBRM that performed the

initial PREPAREINV DROPALT Invalidated by DROP/ALTERINV_DROPALT Invalidated by DROP/ALTERINV_REVOKE Invalidated by REVOKEINV_LRU Removed from cache by LRUINV_RUNSTATS Invalidated by RUNSTATSCACHED_TS TS Timestamp when statement was cachedUSERS Number of current users of statement. These are the users that

have prepared or executed the statement during their current unit of work.

© YL&A 1997-2009

COPIES Number of copies of the statement owned by all threads in the system

LINES Precompiler line number from the initial PREPAREPRIMAUTH User ID - Primary authorization ID of the user that did the initial

PREPARECURSQLID CURRENT SQLID of the user that did the initial prepare

BIND_QUALIFIER Bind Qualifier, object qualifier for unqualified table names

BIND_ISO ISOLATION BIND option: , 'UR' - Uncommitted Read , 'CS' - Cursor Stability , 'RS' - Read Stability , 'RR' - Repeatable Read

BIND_C DATA CURRENTDATA BIND option: - 'Y' - CURRENTDATA(YES) - 'N' - CURRENTDATA(NO)

BIND_DYNRL DYNAMICRULES BIND option: - 'B' - DYNAMICRULES(BIND), 'R' - DYNAMICRULES(RUN)

BIND DEGRE CURRENT DEGREE value: - 'A' - CURRENT DEGREE = ANY , '1' - CURRENT DEGREE = 1

DSN_STATEMENT_CACHE_TABLE (cont..) – V8

BIND_DEGRE CURRENT DEGREE value: A CURRENT DEGREE ANY , 1 CURRENT DEGREE 1

BIND_SQLRL CURRENT RULES value: ‘D' - CURRENT RULES = DB2, 'S' - CURRENT RULES = SQL

BIND_CHOLD 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

STAT_TS Timestamp of stats when IFCID 318 is started

STAT_EXEC Number of executions of statement. For a cursor statement, this is the number of OPENs

STAT_GPAG Number of getpage operations performed for statement

STAT_SYNR Number of synchronous buffer reads performed for statement

STAT WRIT N b f b ff it ti f d f t t t

© YL&A 1997-2009

STAT_WRIT Number of buffer write operations performed for statement

STAT_EROW Number of rows examined for statement

STAT_PROW Number of rows processed for statement

STAT_SORT Number of sorts performed for statement

STAT_INDX Number of index scans performed for statement

STAT_RSCN Number of table space scans performed for statement

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 19

STAT_PGRP Number of parallel groups created for statementSTAT_ELAP Accumulated elapsed time used for statementSTAT_CPU Accumulated CPU time used for statementSTAT_SUS_SYNIO Accumulated wait time for synchronous I/OSTAT_SUS_LOCK Accumulated wait time for lock and latch request

DSN_STATEMENT_CACHE_TABLE (cont..) – V8

STAT_SUS_SWIT Accumulated wait time for synchronous execution unit switchSTAT_SUS_GLCK Accumulated wait time for global locksSTAT_SUS_OTHR Accumulated wait time for read activity done by another thread STAT_SUS_OTHW Accumulated wait time for write activity done by another threadSTAT_RIDLIMT Number of times a RID list was not used because the number of RIDs would

have exceeded one or more DB2 limitsSTAT_RIDSTOR Number of times a RID list was not used because not enough storage was

available to hold the list of RIDs

© YL&A 1997-2009

EXPLAIN_TS When statement cache table is populatedSCHEMA CURRENT SCHEMA valueSTMT_TEXT Statement textSTMT_ROWID Statement ROWID

� New Columns in V9

BIND RA TOT

DSN_STATEMENT_CACHE_TABLE – V9

BIND_RA_TOTTotal number of rebinds that have been issued for the dynamic

statement due to REOPT(AUTO)BIND_TO_TYPE

N – REOPT(NONE) or its equivalent1 – REOPT(ONCE) or its equivalentA – REOPT(AUTO)

© YL&A 1997-2009

( )O – Current plan is deemed as optimal and no need for further

REOPT(AUTO)

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 20

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_TABLEwhere 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 i i th d i SQL h i l di th fi t

© YL&A 1997-2009

for queries in the dynamic SQL cache, including the first 100 characters of the SQL text.

Could also get STMTID and then obtain the access path information from the cache.

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 243727 252134 5508 16 1741 26 SELECT2008-08-26 01:55:24.243727 252134 5508.16 1741.26 SELECT

2008-08-26 01:55:30.130466 193977 2943.68 930.89 SELECT

An example statement extracting elapsed and CPU time

© YL&A 1997-2009

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).

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 21

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

© YL&A 1997-2009

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

DB2 9 for z/OS DBA Certification Guide

“DB2 9 for z/OS DBA Certification Guide” McPressOctober 2007 Authored By Susan Lawson and Dan Luksetich

© YL&A 1997-2009

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 22

DB2 Information on the Web� IBM

� Ibm.com� IBM Software

� Ibm.com/software� DB2 Family

� Ibm.com/software/db2DB2 S l ti Di t A li ti� DB2 Solutions Directory Applications

� 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 f / f / /

© YL&A 1997-2009

� ftp://ftp.software.ibm.com/software/data/db2zos� DB2 Magazine

� http:// www. db2mag. Com� DB2 Certification

� http://www.ibm.com/certify� DB2 Experts

� www.db2expert.com

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

� DB2 V9 for z/OS Transition� DB2 V8 for z/OS Transition

– Application or DBA or both� SQL (z/OS and LUW)

– Basic SQL

We customize allclasses based upon

customer requirements

– Advanced and Complex SQL– SQL Performance Tuning and Optimization

� Application Development– Stored Procedure Development and Implementation– UDFs and Triggers Development

� Database Design– Physical Design, Logical Design

ONLY YL&A offers you theDB2 V9 DBA Certification

Crammer Course to

© YL&A 1997-2009

� Data Sharing– Implementation, Performance, Recovery

� High Performance Design and Tuning– Application, Database, Systems

� DB2 V9 for z/OS Certification Crammer Course

help you become certified!!

DB2 9 for z/OS 6/14/2009

© YL&A 1999 - 2009 23

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

© YL&A 1997-2009

become reality until production– Results: problems identified, solutions proposed (many implemented

immediately), continual knowledge transfer during the process

Cost Avoidance Through Performance Tuning!!!!