USing the EXPLAIN Feature to Improve DB2~ Query Performance Frank Solcntan, Blue Cross Blue Shield of CT North Haven, CT 06(73 .lBSTR.lCT - Providing pointer controlled access to data - Avoiding scanning of all table data This paper discusses the use of the SOL EXPLAIN - Avoiding sorts feature of DB2 to"assist in the understanding of - Avoiding access to the table data entirely bow DB2 btuldles an SOL query request and how to look for tuning opportunities for better query perforaenee. This paper will explain how DB2 How does DB2 prOC!!5S an SOl query? processes an SOL request. how to use the SOL EXPLAIN statement with the SAS8 SOL PASS-~ The SOL statement that is presented to DB2. Facility. obtain the EXP~N results. and whether dynamically (SAS. QMF) or through the BIND interpret what those results maan. In addition. process (application programs). must move through this paper will present some helpful ideas for many internal DB2 components to locate and optimizing queries to save both time and system retrieve physical table data. The following gives overbead. a flow and description of the DB2 components used to satisfy an·SOL query request: 1I1TROOOCTIOlf SOL Parser - Checks for proper SOL syntax To acquire the skills to enhance SOL query performance it is important to understand the Optimizer underlying component structures that make up the - Confirms the users authority 1m2 DBMS. 1m2 is a Database Management system. - Decomposes query into query blocks comprising of two dimensional tables" and indexes a query block represents a section of an that fora a basic relational structure. SOL SOL statement e.g .• base SELECl". a provides tbe means for data access and retrieval subquery. a UNICN froa ~ tables. Internally. ~ contains tables - Merges query with any DB2 table views that fora a catalog that store information about being accessed in the query all DB2 objects. An intelligent component of DB2. - Obtains catalog statistics for DB2 objects the optiaizer. deteraines the probable access path accessed of 4 eingle SOL ototoment to tho data doto~inod - ChOOa811!11 an accolI!IIlI!II po th: by lntoraatlon contain in the DB2 catalog. Tbe - Sequences query blocks optimizer is an inference engine that makes all - Computes row filter factors ~ data access decisions. The optimizer's - COmputes access path costs decision ean only be indirectly influenced through - Determines whether to use an index coding strategies in the SOL code. The SOL EXPLAIN - Determines which indexes to use is used to request that ~ explain the - Chooses least costly path optimizer's access path decision. Access path - Creates the access plan per foraonce ae.y be .a. f foctod by: Code generator - Number of rows to be accessed - Converts access plan to object machine - Distribution of data code - Access strategy - Stores access plan as an Application Plan - Sequencing of data for statically bound applications - COndition of the databases - Requested approach to the data Executor - Executes stored Applic~tion Plans to Table INDEXES enhance access path performance by: access data 196 - Execute dynaaic (Ad-Hoc) queries one time SORnLUNIQ 0IAR(1) NOr NULL. only SCIR1N....TOIN 0IAR(l) NOr NULL. SORl>LQRDBIUIV 0IAR(1) NOr NULL. Data Retrieval SORnLGllOOPIIY 0IAR(1) NOr NULL. Deta Manager-1M SClRl'C..UNIQ 0IAR(l) NOr WLL. - Stage 1 row fIlter. called sargable SORTC_30IN 0IAR(l) NOr NULL. - Evaluates predicates (from WHERE SClRTC...0RDERB'i OfAR(l) NOr NULL. clause) as the data is retrieved from SClRl'C..GROUPIIY OfAR(l) NOr NULL. tbe physical storage (resource TSLOClOClDE 0IAR(3) NOr NULL. efficieut) :TIlIESTAHP 0IAR(16) NOr NULL. - Usee the Buffer Manager to access the RI!HARKS VAROIAR( 25.) NOr NULL. tables PREPETOi CHAR(l) NOr NULL WIn! DEPAULT. - Used by the Relational Data Syatem-RIlS ~ALOfAR(l) NOr NULL wrm DEPAULT. - Relational Deta systea-RDS MIXlJPSEQ SMALLINr NOT NULL wrm DEPAULT. - Stage 2 row filter. called non-sargable VERSION VAROIAR(6.) NOr NULL WIn! DEPAULT. - Interface for queries (creates results CXlLLID 0IAR(18) NOr NULL wrm DEPAULT) table) - Makes calls to the Deta Manager IN DBNAHE. TSNAME - Evaluates predicates (from WHERE c18use) after the data has been retrieved in the buffer (resource The follOWing is a simple coding semple to intensive) illustrate issuing an SOL EXPLAtN for a query - Buffer Manager SELECT using the SOL PASS-THROUGH Facility: - Works like a scratch pad area for 082 - Inter feces between the VSAM Media OPTIONS LINESIZE=250 PAGESIZE=60; Manager and the Deta M8nager PKlC SOL; VSAM Media Manager <XlNNECT TO DB2 (SSID=yourdb2.,.,.t_); - Manages the physical data storage EXl!Cl1l1! (EXPLAIN ALL SET IlUERYID = 1 l'OR SELECT A .CXlLl .A.ax.. Bow t.o EXPUIH .B.OJLJ .B.CXlL4 Before any query can be explained. a pla~tablB PROM TABLEA A pref1xed by the User ID doing the explaining must .TABLEB B be defined in the DB2 subsystem where the tables WHERE A.ax.l IN (1) that are being accessed reside. 082 will insert AND A. OJL2 BETWEEN ? Alm ? rows representing the results of issuing an SOL AND B.CXlL3 = 1 EXPLAIN in the userid.PLAN-TABLE. The format of AND A.COLI = B.COLI the PLAlLTABLE is as followa: AND A.COL2 - B.CCL2 BY DB2; CREATE TABLE USXRID. PLAl'LTABLE \\IPIlT &SQLXMSG; ( QllI!RYN:l INTEGER NOr NULL. QBLOCI(NO SMALLINr NOr NULL. TITLE "002 Query Explain Resul tan: APPI.NAME 0i.\R( 8) NOr NULL. CREATE TABLE 'l'EXPLAIN It:> SELECT • noGlIANE 0i.\R(8) NOr NULL. PROM <DINI!CTION TO DB2 (SELECT • PLANro SM.\I.I. INr NOr NULL. PROM userld.PUl'LTABLE MEnt:lD SMALLINT NOr NULL. WHERE OUERYID = 1); QlEATOR 0i.\R(8) NOr NULL. "INANE 0i.\R(18) NOr NULL. TABNO SMALLINr NOr NULL. Acx:ESSIY?E 0i.\R(2) NOr NULL. DISCIJtINI!Cr PROM DB2; MATOIalLS SMALLINr NOr NULL. RUN; Acx:ESSCREATOR 0i.\R(8) NOr NULL. ACCESSNo\)(I! 0i.\R( 18) NOr NULL. PIlOC PRINr DATA=TEXPLAIN; INIlEXDNLY 0i.\R(1) NOr NULL. RUN; 197 To explain a query. the ooly eleaent that is TABID - N~ that identifies the ,sequence required is that the stata.ent EIPLAEH ALL SET of references to the seae table in OUBRYRJ .. 1 Pal IIlUSt prec:ed.e the SELEct clause. the PROM clause To issue an EXPLAIN. the EXECUTE state.ant TSI.OQ(MOI)E - The TABLI!SPACE lock _e (enables DBMS specific SOL) must be used or an IS -Intent &bare error will occur. The EXECUTE EXPLAIN statement IX -Intent exclusive can be eo.mented out when ready to actually SIX -Share with intent exclusive execute the query. When executing these S -Share statements. DB2 will insert rows representing the U -Update EXPLAIN data in the PLAlLTABLE. The query explain x -Exclusive .owa will. be identified by the number that is used TIMESTAMP - Date and till8 the EXPI.AIN was .in the SET QUERYlIl = D... so that this particular processed query can be easily 10ca~ when querying the REMARKS - Pield in which comaents can be PLAN...TABtE. Notice that -1- (parameter markers) inserted are used in place of actual data. Using actual data may cause a different access patb than using The PLAtLTA8LE colwms that relate to INDEX usage -1- due to differing filter factors. Use M1- when inforaation about the explained SOL are as the data is unknown or will vary to obtain the DB2 follows: default factor. Use actual data if it is known or static to obtain the actual filter factor results;' ACCESSTYPE - Type of table INDEX usage: It. filter factor of a Where predicate is a R -Pull table scan (uses no percentage that estimates how aeny rows are index) rejected by and how many rows are not rejected by I -Use an index ~he WHERE predicate. Filter factors greatly aftect 11 -one-fetch scan (MIN or MAX ~he estimated costs of the ~ access paths to be functiOns) chosen by the optiaizer by estimating the N -Index scan (predicate uses percentage.of the rows returned after evaluating an IN) ~be NtERE predicate. Use the &sg'''XI,s;t: aacro M -Multi-index scan followed variable which contains the return code and error by: descriptions produced by DB2 to check for MX -Matching index scan on successful execution of tbe SQL statements. row pointers only Appendix It. shows an exaaple of sc.e explained MI -consolidate (intersect) output frca a PLAN-TABLE. of row pointers from multiple indexes MU -Collbination (union) of Vhat do the EXPLAIlJ columas aean? row pointers from aultiple indexes 'The PLAN.....TABLE columns that relate to GENERAL MATCHCXlLS - NWlber 0 f index keys used in an inforaation about the explained sgL are as index scan follows: AOCESSCREATOR - creator of the index being used QlII!R'iNO - OUery nWlber assigned by the ACC:BSSNAMB - Name of the index being used explaining user INCEXCNLY - Y if all data comes from the QB[.OCIQl:l - Number that identifios the SOL query index sections for a query with a SELECT. N if data aust come from the subquery. \JNICIf table APPLNAM! - Plan naae for prograas with eabedded - Sequence of steps in a multi- SOL (C.COBOL.etc) index scan PRJGNAME - Prograa naae for programs with embedded SOL The PLANLTABLE columns that relate to SORT usage PLANNO - identifies the order of operations information about the explained SOL are as within a ~ follows: aEATOR - Creator of a new table (materialized view} accessed - Indicates the table 30IN method - N..... 01 naw table (1IIIIter1al1zed o -First table accessed. first View) accessed outer table 198 1 -Nested loop join required to return large sets of data. Very Z -Merge scan join effective when the table data is in clustered 3 -Sort required for CJRDBR BY.