DBA Presentation

Introduction to DB2 Access Path

1
Copyright1996-2006 NCS Pte Ltd. All Rights Reserved.

What is Access Path?

1. An access path is an algorithm used by DB2 to satisfy the requirements of SQL statements..

2. The chosen access path determines the performance of the SQL query.

How is an SQL query being read in DB2?

1. SQL specifies what data to retrieve or manipulate, but does not specify how the database accomplishes these tasks.

2. DB2 database management systems have their own sequencing and optimization, (1) they find the data sources, (2) read the rows or indexes to rows, and (3) then narrow the columns returned those qualified in a select list.

How does DB2 optimize the access on a table? 1. The DB2 optimizer is the heart and soul of DB2. It analyzes SQL statements and determines the most efficient access path available for satisfying each statement. 2. Optimizer chooses an access plan for a SQL statement by modeling the execution cost of several alternative access plans and choosing the one with the minimal estimated cost.

Continues.

3. An access plan can use one of two ways to access data in a table (a) by directly reading the table - table scan (b) by reading an index and then retrieving the row in the table - index scan
4. "Cost" is defined as the estimated CPU time it takes (TIMERONS) to run the request. 5. Optimization is based on timerons, not on resource utilization or real time. 6. Usually the fastest plan is also the most resource efficient plan, but this is not necessarily true. 7. The goal of the optimizer is to eliminate I/O as early as possible by identifying the best path to data. 8. The optimizer will "rewrite" the query.

How do we see the optimized access plan that DB2 selected?

1. EXPLAIN is a monitoring tool that produces access path information about plan, package, or SQL statement when it is bound. The output appears in a table called PLAN_TABLE. 2. The plan table can be populated by two ways. (a) by executing the SQL statement EXPLAIN. (b) when you bind or rebind a plan or package using option EXPLAIN(YES). 3. The information in PLAN_TABLE can help you to: (a) Design tables, indexes, and application programs (b) Determine when to rebind an application (c) Determine the access path chosen for a query Continues..
6

4. For example: The following query to a plan table returns the rows for all the SQL statements in a plan in their logical order:
SELECT QUERYNO, PLANNO, METHOD, CHAR(TNAME,18) TNAME, ACCESSTYPE FROM CPFU.PLAN_TABLE WHERE PROGNAME = 'SEM0715' ORDER BY TIMESTAMP, QUERYNO, QBLOCKNO,PLANNO; ---------+---------+---------+---------+---------+---------+--------QUERYNO PLANNO METHOD TNAME ACCESSTYPE ---------+---------+---------+---------+---------+---------+--------87 1 0 B_PERSINFO I 87 2 1 B_SEMPL I

5. There are many information available in the Plan Table. For example. - tells you whether an index access or table space scan is used. - tells you how many indexes and index columns are used and what I/O methods are used to read the pages. - tells you which join method and type are used, the order in which DB2 joins the tables, and when and why it sorts any rows.

Plan Table Important columns

The Plan Table containing many columns, related to a particular SQL statement.

PLANNO : The number of the steps in the query. It shows order of those steps. METHOD: Indicates the join method used for the table. 0 - First table accessed 1 - Nested loop join 2 - Merge scan join 3 - Sorts needed by the query 4 - Hybrid join MATCHCOLS : Number of matching index columns. INDEXONLY : Whether Table Space is referred or not.

ACCESSNAME : Name of the index used.

ACCESSTYPE : Discussed in the next slide. Continues..
8

Different Access Types available in DB2

1. Is access through an index? Yes, if ACCESSTYPE is I, I1, N or MX 2. Is access through more than one index? Yes, if ACCESSTYPE=M

3. How many columns of the index are used in matching? You may read it from MATCHCOLS

How do we EXPLAIN an SQL statement?

1. The EXPLAIN statement obtains information about access path selection for an explainable statement.

2. A statement is explainable if it is a SELECT or INSERT within SELECT statement, or the searched form of an UPDATE or DELETE statement.
3. Output from EXPLAIN is one or more rows of data inserted into the plan table. 4. We can EXPLAIN a SQL in two ways. (a) Using SPUFI execution. (b) Using Admin Tool. 5. Following Examples would demonstrate both methods.

10

How do we list PLAN_TABLE & DSN_STATEMNT_TABLE entries that use Production statistics?
Invoke EXPLAIN from DB2 Admin Tool, use the following COLL IDs:

CCPFE00 Collection ID for Prod Copy of Packages CPPFE01 Collection ID for UAT version of programs

11

How do we analyze access paths for alternate SQL?

A SQL from a program LIS0119 was taken for this analysis. Following steps were carried out to illustrate the access path analysis: 1. 2. 3. 4. The original SQL was analyzed and identified its access path. Deliberately the SQL was changed to see the difference in access path The changed SQL was analyzed and identified its access path. Both the access path was compared and identified the best access path.

12

Good Practices when coding SQLs:

1. Try to avoid using SQL without WHERE predicate. 2. Use WITH UR when committed data is not required, e.g. during investigation to avoid contention. 3. Try to avoid using UNION ALL, instead use UNION. 4. Try avoid using DISTINCT, GROUP BY, and ORDER BY clauses, because sorting is needed, especially when the result set is big. 5. Avoid using SELECT *, instead retrieve only the required columns. 6. If you dont need entire set of result, then use FETCH FIRST n ROWS ONLY clause.

13

Guidelines for coding WHERE predicate: 1. Ensure at least one matching indexed column is used in the WHERE predicate.

2. Ensure the most restrictive predicate is indexed. SELECT LST_UPD_TS FROM T_PERSDTL WHERE SEX=M AND CTZ=Y AND EEACN_C=1234 D Most restrictive column, indexed 3. When using the range of data in the WHERE predicate use BETWEEN clause, instead of > and < operators. a LBS_TRN_DTE BETWEEN 01-01-2009 AND 31-01-2009 O LBS_TRN_DTE >= 01-01-2009 AND LBS_TRN_DTE <= 31-01-2009
4. Do not code redundant predicates. e.g. GENDER_TITLE = Mr AND SEX = M

Continues.

14

Guidelines for coding WHERE predicate: 5. Predicate can be coded in ON clause, WHERE clause, or HAVING clause.
From pgm:BKOA011 SELECT A.LIFE_POL_NUM FROM T_LBOMSTR A LEFT JOIN T_LBOTRN B ON A.LIFE_POL_NUM = B.LIFE_POL_NUM WHERE EEACN_C = :WS-EEACN-C AND LBO_ALLT_STS_CDE = 'A' From pgm:LISM075 SELECT SUM(ANC_PRM_AMT),SUM(LIFE_AVAIL_FUND_AMT) - SUM(LBO_ALLT_AMT) INTO :WS-TOTAL-LIFE-ANTY-PRM,:WS-RRA-BALANCE FROM T_POLICY WHERE EEACN_C = :WS-CPF-ACCT AND LIFE_POL_STS_CDE = 'A' AND LIFE_FUND_SRC_CDE = '1' HAVING COUNT(ANC_PRM_AMT) > 0

6. The descending order of efficient predicates OPERATORS are: (i) = (ii) COLUMN op* Value (iii) IN (iv) BETWEEN (v) sub-query (vi) NOT *op can be replaced with <, >
Refer to DB2 V9 Performance Monitoring & Tuning Guide for Indexable and Stage 1 predicates. 15

Avoid using the following predicates which will not use index COL <> value COL NOT BETWEEN val1 and val2 COL NOT IN (val1, val2) COL NOT LIKE val% COL EXISTS (sub query) You may use IN instead. COL NOT EXISTS (sub query) Using functions on a column will deter index being used a LST_UPD_TS BETWEEN 2009-01-01-00.00.00.000000 AND 2009-01-31-00.00.00.000000 O DATE(LST_UPD_TS) BETWEEN 01-01-2009 AND 31-01-2009

a POL_LTTR_TP_CDE LIKE PLCLB% O SUBSTR(POL_LTTR_TP_CDE,1,4) = PLCLB

16

Access Path Exception Report

Purpose: For all programs moved to UAT*, this report will display queries which may have potential performance implications. Access path details are generated using production statistics loaded in development (CPFE schema). Only queries which have the following access types will be reported: Table Scan (Type = R) Multiple Index Scan (Access Type = M/MI/MX/MU) Index Scan with 0 MATCHCOL (Access Type = I, MATCHCOLS = 0) Frequency : Report is generated daily at 4PM. Programs checked out to UAT after 4PM will be included in next days report. Report Inputs : CPFE.PLAN_TABLE, CPFE.DSN_STATEMNT_TABLE, SYSIBM.SYSTABLES Report File : TST8.PMC.D001A.EXPLNRPT.GD *NOTE: UAT Checkout after 4 pm and if moved to production on same day or before 4 pm the next day will not be captured by this report
17

Sample Access Path Exception Report and Description of Details

PROG NAME - The name of the program or package containing the statement being explained QUERYNO - A number intended to identify the statement being explained. For a row produced by an EXPLAIN statement, specify the number in the QUERYNO clause. For a row produced by non-EXPLAIN statements, specify the number using the QUERYNO clause, which is an optional part of the SELECT, INSERT, UPDATE and DELETE statement syntax. Otherwise, DB2 assigns a number based on the line number of the SQL statement in the source program. When the values of QUERYNO are based on the statement number in the source program, values greater than 32767 are reported as 0. However, in a very long program, the value is not guaranteed to be unique. If QUERYNO is not unique, the value of TIMESTAMP is unique.

18

QBLOCKNO - A number that identifies each query block within a query. The value of the numbers are not in any particular order, nor are they necessarily consecutive. PLAN NO. - The number of the step in which the query indicated in QBLOCKNO was processed. This column indicates the order in which the steps were executed. TABLE NAME - The name of a table, materialized query table, created or declared temporary table, materialized view, or materialized table expression. The value is blank if METHOD is 3. The column can also contain the name of a table in the form DSNWFQB(qblockno). DSNWFQB(qblockno) is used to represent the intermediate result of a UNION ALL or an outer join that is materialized. If a view is merged, the name of the view does not appear.

19

ACCESS TYPE - Latest access type for QUERYNO. This is method of accessing the table, and may have the following values: I - By an index (and MATCHCOL = 0; which means index scan with no matching index key) M - By a multiple index scan (followed by MX, MI, or MU) MI - By an intersection of multiple indexes MU - By a union of multiple indexes MX - By an index scan on the index named in ACCESSNAME R - By a table space scan
PROCMS estimated processor cost in milliseconds for the revised query MATCHOLS For access type I or MX, this refers to the number of index keys used in an index scan. Otherwise, 0.

TABLE ROW COUNT Row count for the table referenced in the query.
REMARKS Describes the access type
20

What information is needed when we escalate to DBA team (in relation to Access Path) ? 1. The owner of the issue should have completed their preliminary analysis. 2. The following information need to be furnished when escalating to DBA (a) Job Name, Job Type, and environment. (b) Priority of this issue or any expected time limitation. (c) Affected SQL code. (d) The access path information and any finding of improvements or suggestions.

(d) Any special condition of the situation or resource e.g. was the job was rescheduled or was the SQL changed recently, etc.

21

Together We can Make the Difference

Thank You Mayur & Norman

22
Copyright1996-2006 NCS Pte Ltd. All Rights Reserved.