Answer: Reduce the amount of work Oracle needs to do to return the desired result.

Transcription

1 SQL Tuning 101 excerpt: Explain Plan A Logical Approach By mruckdaschel@affiniongroup.com Michael Ruckdaschel Affinion Group International

2 My Qualifications Software Developer for Affinion Group International for 12 years an expert in SQL Performance Tuning for Oracle Databases. Over 8 years tuning experience Over 20 years Applications Design and Development experience. Current tuning experience includes Oracle 9iR2 RAC, and earlier versions of Oracle to Version 7, with databases up to 7 Terabytes in size

3 Question: What is the Single Most-Effective way to tune a SQL statement? Answer: Reduce the amount of work Oracle needs to do to return the desired result.

4 Myth or Fact???????? MYTH: FACT: It SQL doesn t Tuning matter cannot how overcome I write poor my SQL process or Process, design. we can always tune it later.????? MYTH: FACT: My 90% SQL of all is performing performance poorly, problems there involve must inefficiency be other users of your / processes SQL and process, slowing me NOT down. problems with the database If (i.e. only indexing, there was other an users, index on file column system, x, data my SQL model, would etc) perform MYTH:????? FACT: I Given need correct to add hints information to every (i.e. query Statistics), to make and Oracle properly perform. written SQL, Oracle Oracle is going will to make choose the right the wrong decision access in its method execution most of of a Given the time. Query most of the time. MYTH:????? FACT: Full There Table are Scans many are times bad! where Index a Full Access Table is Scan always is going better! to be more efficient than Index Access, and vice-versa.????? MYTH: FACT: Only Solely executing from looking a query at the will Explained determine Plan its performance one can tell characteristics. how a query will perform. However, comparing two plans, one may estimate which will likely incur less work.

5 Our Agenda What is Oracle going to do? How does Oracle derive this plan? How do we find out Oracle plan? How do we read an Explain Plan? Access Methods Join Methods and Order Stepping through the plan Plan Evaluation

6 Given a SQL Statement, What is Oracle going to do? Explain Plan: The steps Oracle is going to go through in executing our query, to get us the information we ve requested. FACT: Oracle only knows how to deal with 1-2 row sources (e.g. Tables) at a time. Possible Exception is BITMAP table access --More on that later.

7 EXPLAIN PLAN (Cont d) It will Tell Us: what Table Access Method Oracle is going to use to access each table in our query (Direct Row Access or Table/Index Scan) what Join Method Oracle is going use to join each row set with another row set. what order Oracle is going to access and join the tables in our query. how much data (rows and bytes) Oracle is estimating the query is going to access at each step., if the underlying table is partitioned, how many, and which, partitions will be scanned / accessed.

8 What do you think of this SQL? SELECT FROM temp_open_ar_transactions ar,fin_trans ft,ftc_inv fi,member_contract mc,recognition_fin_link rfl,member_contract_attrib mca,refund_method rm,member_recognition mr,partner p,partner_corporation pc WHERE ar.fin_trans_sysid = ft.fin_trans_sysid AND ft.ftc_inv_sysid = fi.ftc_inv_sysid AND ft.member_contract_sysid = mc.member_contract_sysid AND ft.cur_recognition_fin_link_sysid = rfl.recognition_fin_link_sysid AND rfl.mem_contract_attrib_sysid = mca.member_contract_attrib_sysid AND mca.refund_method_id = rm.refund_method_id AND mca.partner_id = p.partner_sysid AND p.partner_corporation_sysid = pc.partner_corporation_sysid AND rfl.recognition_fin_link_sysid = mr.recognition_fin_link_sysid AND mr.recognition_date <= cycle_date.mth_cycle_date_eod AND mr.closed_date IS NULL GROUP BY HAVING mr_revenue_amt!= 0 AND mr_comm_amt!= 0

9 Id Operation Name Rows Bytes TempSpc Cost Pstart Pstop SELECT STATEMENT K 2029K * 1 FILTER 2 SORT GROUP BY K 981M 2029K * 3 HASH JOIN 3948K 926M 1992K 4 TABLE ACCESS FULL REFUND_METHOD * 5 HASH JOIN 3948K 899M 1992K 6 TABLE ACCESS FULL PARTNER_CORPORATION * 7 HASH JOIN 3948K 824M 1992K 8 TABLE ACCESS FULL PARTNER * 9 HASH JOIN 3948K 790M 400M 1991K 10 TABLE ACCESS FULL MEMBER_CONTRACT_ATTRIB 8230K 306M 3809 * 11 HASH JOIN 3948K 643M 15M 1973K 12 TABLE ACCESS FULL FTC_INV 618K 9062K 80 * 13 HASH JOIN 3948K 587M 576M 1965K * 14 HASH JOIN 3948K 530M 1998M 1867K * 15 HASH JOIN 17M 1797M 1746M 1072K * 16 HASH JOIN 17M 1545M 1226M 613K 17 TABLE ACCESS FULL TEMP_OPEN_AR_TRANSACTIONS 17M 1024M TABLE ACCESS FULL FIN_TRANS 552M 15G 229K 19 PARTITION RANGE ALL TABLE ACCESS FULL RECOGNITION_FIN_LINK 608M 8708M 120K PARTITION RANGE ITERATOR 1 KEY * 22 TABLE ACCESS FULL MEMBER_RECOGNITION 136M 4425M 637K 1 KEY 23 TABLE ACCESS FULL MEMBER_CONTRACT 144M 2073M Predicate Information (identified by operation id): filter(round(sum("mr"."revenue_amt"*"ar"."unapp_percent"),2)<>0 AND ROUND(SUM("MR"."COMM_AMT"*"AR"."UNAPP_PERCENT"),2)<>0) 3 - access("mca"."refund_method_id"="rm"."refund_method_id") 5 - access("p"."partner_corporation_sysid"="pc"."partner_corporation_sysid") 7 - access("mca"."partner_id"="p"."partner_sysid") 9 - access("rfl"."mem_contract_attrib_sysid"="mca"."member_contract_attrib_sysid") 11 - access("ft"."ftc_inv_sysid"="fi"."ftc_inv_sysid") 13 - access("ft"."member_contract_sysid"="mc"."member_contract_sysid") 14 - access("rfl"."recognition_fin_link_sysid"="mr"."recognition_fin_link_sysid") 15 - access("ft"."cur_recognition_fin_link_sysid"="rfl"."recognition_fin_link_sysid") 16 - access("ar"."fin_trans_sysid"="ft"."fin_trans_sysid") 22 - filter("mr"."closed_date" IS NULL AND "MR"."RECOGNITION_DATE"<="INFOCTL"."CYCLE_DATE"."MTH_CYCLE_DATE_EOD"())

10 How does Oracle derive this plan? The Cost-Based Optimizer The optimizer determines the most efficient way to execute a SQL statement after considering many factors related to the objects referenced and the conditions specified in the query. This determination is an important step in the processing of any SQL statement and can greatly affect execution time 1 It is a program that uses various database statistics, and other knowledge of the data, to derive estimated costs for all of the various ways a given join condition or data selection may be performed. It selects the lowest cost method of achieving the desired result. Most of the time this works very well.

11 The Cost-Based Optimizer (Cont d) But sometimes, Oracle does not know the data as well as we do. Oracle will occasionally start with the wrong table Or, Oracle will occasionally choose the wrong Join or Access method, etc. for one or more tables In these instances, we tune the SQL (e.g. Manually alter the SQL for execution path). What are some ways we can do this? Hints Change Join Order Change Join Method (Hash Join, Sort Join, Nested Loops, etc ) Force Index Usage Rewrite the SQL Prevent Index Access (Apply function to indexed column) Use correlated sub-query vs. table join Create an in-line view in the FROM clause

12 The Cost-Based Optimizer (Cont d) Some functions of the CBO: Evaluation of expressions and conditions Statement Transformation Choose Optimization Approach (Best Throughput, or Response Time) Choose Access Paths Choose Join Orders Choose Join Method Statistics are CRUCIAL to this processing!!!

13 Figure 1-2 Cost-Based Optimizer Components

14 Statistics generated include the following: Table statistics Number of rows Number of blocks Average row length Column statistics Number of distinct values (NDV) in column Number of nulls in column Data distribution (histogram) Index statistics Number of leaf blocks Levels Clustering factor System statistics I/O performance and utilization CPU performance and utilization

15 Without statistics Oracle makes bad decisions! w/o Stats Oracle Assumes (for tables): Table Statistic Number of rows Average row length Number of blocks Remote Number of rows Remote Average row length Default num_of_blocks * (block_size - cache_layer) / avg_row_len 100 Bytes 100 blocks 2000 rows 100 bytes

16 Without statistics Oracle makes bad decisions! w/o Stats Oracle Assumes (for indexes): Index Statistic Default Levels 1 Leaf blocks 25 Leaf blocks per key 1 Data blocks per key 1 Distinct keys 100 Clustering Factor 800 (8 * number of blocks)

17 Bad Stats Example FIN_TRANS Table OWNER TABLE NAME INDEX_NAME DISTINCT_KEYS FDS FIN_TRANS FIN_TRANS_MEMCONSYSID TABLE_NAME NUM_ROWS BLOCKS FIN_TRANS TABLE_NAME NUM_ROWS BLOCKS TMP_NFT_NEW ,840 Member Contract Sysids in FIN_TRANS? 577M / 195,840 = 2949 Rows per key (MC_SYSID)

18 Bad Stats Example SELECT * FROM fin_trans ft,tmp_nft_new tnn WHERE tnn.member_contract_sysid = ft.member_contract_sysid Execution Plan SELECT STATEMENT Optimizer=CHOOSE (Cost= Cardinality=13349 Bytes= ) 1 0 HASH JOIN (Cost= Card=13349 Bytes= ) 2 1 TABLE ACCESS (FULL) OF 'TMP_NFT_NEW (Cost=2 Cardinality=719 Bytes=97065) 3 1 TABLE ACCESS (FULL) OF 'FIN_TRANS (Cost= Cardinality= Bytes= )

19 How do we find out Oracle Plan? Using SQL*Plus Autotrace Facility SET AUTOTRACE TRACEONLY EXPLAIN 1 select count(1) 2 from member_contract mc 3,member_contract_attrib mca 4* where mca.member_contract_attrib_sysid = cur_mem_contract_attrib_sysid / Execution Plan SELECT STATEMENT Optimizer=CHOOSE (Cost=23585 Card=1 Bytes=12) 1 0 SORT (AGGREGATE) 2 1 NESTED LOOPS (Cost=23585 Card= Bytes= ) 3 2 INDEX (FAST FULL SCAN) OF 'MC_MCAS_IDX' (NON-UNIQUE) (Cost=13745 Card= Bytes= ) 4 2 INDEX (UNIQUE SCAN) OF 'PK_MEMBER_CONTRACT_ATTRIB' (UNIQUE) (Cost=1 Card=1 Bytes=6)

20 Or: Using the Explain Plan Stmt. Explain Plan Set Statement Id = <some id value> For <SQL Statement> Such As: 1 EXPLAIN PLAN 2 SET statement_id = 'MRUCKDASCHEL' FOR 3 SELECT count(1) 4 FROM member_contract mc 5,member_recognition mr 6 WHERE mr.member_contract_sysid = mc.member_contract_sysid 7 AND mr.recognition_date > '01-jan-2006' #> / Explained.

21 This will store rows in a table called: PLAN_TABLE keyed by STATEMENT_ID These are retrieve using SQL like: SELECT decode(id, 0,'1.1', FROM lpad(' ', 2 * (level - 1)) level '.' position) ' ' initcap(decode(object_type, null, null, object_type ' ')) initcap(operation) ' ' decode(object_name, null, initcap(options),'(' initcap(options) ') of ' object_name) ' ' decode(id, 0, decode(position, null, 'Rule', 'Cost = ' position)) Query_Plan plan_table CONNECT BY PRIOR id = parent_id AND statement_id = USER START WITH id = 0 AND / statement_id = USER

22 This will produce a plan like: QUERY_PLAN Select Statement Cost = Sort Aggregate 3.1 Hash Join 4.1 Unique Index (Fast Full Scan) of PK_MEMBER_CONTRACT_MEMCONSYSID 4.2 Partition Range Iterator 5.1 Table Access (Full) of MEMBER_RECOGNITION

23 Another way to retrieve your Plan: SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY()) Will Produce This: Id Operation Name Rows Bytes TempSpc Cost Pstart Pstop SELECT STATEMENT K 1 SORT AGGREGATE 1 22 * 2 HASH JOIN 1450M 29G 3092M 1374K 3 INDEX FAST FULL SCAN PK_MEMBER_CONTRACT_MEMCONSYSID 170M 1139M PARTITION RANGE ITERATOR * 5 TABLE ACCESS FULL MEMBER_RECOGNITION 1450M 20G 178K Predicate Information (identified by operation id): access("mr"."member_contract_sysid"="mc"."member_contract_sysid") 5 - filter("mr"."recognition_date">to_date(' :00:00', 'yyyy-mm-dd hh24:mi:ss'))

24 To Run Explain Plan: You need access to a PLAN_TABLE Create One In Your Schema Or: Gain Access to an existing one by someone granting you access and create a synonym CREATE SYNONYM PLAN_TABLE FOR COMMON_AREA.PLAN_TABLE;

25 How to read Explain Plan Output: First, Understand the following: Table Access Methods Table Join Methods Table Join Order

26 Table Access Methods Full Table Scans Rowid Scans Index Scans Bitmap Access Cluster Scans Hash Scans Index Unique Scans Index Range Scans Index Range Scans Descending Index Skip Scans Full Scans Fast Full Index Scans Index Joins Bitmap Joins Bitmap AND / OR

27 Full Table Scan This type of scan reads all rows from a table and filters out all rows which do not meet the WHERE clause criteria. This involves one logical read per row. When does this Occur? Lack of Index Large Amount of Data Small Table Parallelism FULL Hint Given

28 Rowid Scans A second step. Oracle first obtains the rowids of selected rows either from the table WHERE clause, or through an index scan of table indexes. Definition: A Rowid specifies a datafile and the data block containing a particular Row and the location of the row in that block. Locating a row by specifying its rowid is the fastest way to retrieve a single row. Access by rowid might be required to retrieve any columns which are not present in an index. Not Always Necessary on index access.

29 Index Scans B-Tree Index Organization A row is retrieved by traversing the index, using the indexed column values specified by the statement. An index scan retrieves data from an index based on the value of one or more columns in the index. Index access involves at least two logical reads per row. Consider the following Diagram of the B-Tree Index Structure: There are several types of Index Scans:

30 Index Unique Scan This scan returns, at most, a single rowid. This scan may be done when there is a UNIQUE or PRIMARY KEY constraint on the table containing the search key. When Used: This type of scan is used when all columns of a unique B-Tree index are specified using an equality condition. May be forced with the INDEX hint.

31 Index Range Scan This scan is used for accessing selective data. The range may be bounded or unbounded. When Used: This type of scan is used when one or more leadingcolumns of an index is specified in conditions such as: Col1 = :b1 Col1 < :b1 Col1 > :b1 Col1 LIKE ABC% AND combination of the preceding conditions for leading columns in the index May be forced with the INDEX hint.

32 Index Range Scan Descending Identical to Index Range Scan, except that data is returned in descending order. When Used: This type of scan is used when ordering data in descending order and that order may be satisfied by an index or when seeking a value less than a specified value. By Default, indexed data is returned ascending order. May be forced with the INDEX_DESC hint.

33 Index Skip Scan This scan is used for composite indexes where the leading-column of the index is not specified in the predicate. The index is split into logically smaller sub-indexes. When Used: This type of scan is used when the leading-column of an index is not specified in the conditions. Skip Scanning is advantageous if there are few distinct values in the leading column of the composite index, and many distinct values in the non-leading key.

34 Index Full Scan This is like a Full table scan, but Oracle only reads Index blocks, one at a time. Typically scanning index blocks is faster than scanning table blocks. When Used: This scan is used if a predicate references one of the columns in the index, not necessarily the leading column. Or: If there is no predicate reference and: All columns in the table referenced are in the index At least one of the indexed columns is NOT NULL. A Full Scan may be used to eliminate a sort operation.

35 Index Fast Full Scan This is an alternative to a FULL table scan, when the index contains all columns that are needed by the query, and at least one index column is NOT NULL This scan accesses data in the index itself, without accessing the table. The entire index is read using multi-block reads and can be parallelized. Data is NOT returned in the index order. Restrictions: At least one indexed column must have the NOT NULL constraint There must be a parallel clause on the Index if FFS in parallel is desired. The index must have been analyzed. May be forced using the INDEX_FFS hint

36 Index Joins This is a hash join of several indexes that collectively contain all of the table columns that are referenced in the query. No table access is thereby needed. May be forced with the INDEX_JOIN hint Bitmap Joins A bitmap join uses a bitmap for key values and a mapping function that converts each bit position to a rowid. Bitmaps can efficiently merge indexes that correspond to several conditions in a WHERE clause, using Boolean operations to resolve AND and OR conditions.

37 Bitmap Table Access This is a special Method of accessing a table whereby Oracle will combine the use of multiple B-Tree indexes according to criteria in the WHERE Clause. Oracle will only consider if there is at least 1 bitmap index on the table. Can involve combinations of B-Tree and Bitmap, but needn t involve any Bitmap Idx Rowids contained in B-Tree Indexes must be converted to bitmaps. After conversion, Boolean AND/OR operations for Bitmaps may be used. May be forced using the INDEX_COMBINE hint

38 This could produce a plan like: SELECT STATEMENT SORT AGGREGATE BITMAP CONVERSION COUNT BITMAP OR BITMAP AND BITMAP INDEX c1_ind SINGLE VALUE BITMAP CONVERSION FROM ROWIDS INDEX c2_ind RANGE SCAN BITMAP CONVERSION FROM ROWIDS SORT ORDER BY INDEX c3_ind RANGE SCAN

39 How does the CBO choose the Access Path? The optimizer first determines which access paths are available by examining the conditions in the statement's WHERE clause and its FROM clause 2. The optimizer then generates a set of possible execution plans using available access paths and estimates the cost of each plan, using the statistics for the index, columns, and tables accessible to the statement 2. The lowest estimated cost wins.

40 Join Methods Nested Loop Joins Hash Joins Sort Merge Joins Cartesian Joins Outer Joins

41 Nested Loop Join One table is designated as an outer (Driving) table, and the other the inner table. All matching rows in the inner table are accessed for each row in the outer table. Consider the following Nested Loop: For X in 1 to 10 Loop (Outer) For Y in 1 to 10 Loop (Inner) i = i + 1 print i: X, Y End Loop End Loop

42 Nested Loop Join (cont d) Ideally, the inner table access is some type of index access, or the table s/b very small. Otherwise, a Hash Join may be more efficient. The order of tables in this type of Join is Very Important. Nested Loops may be Nested inside other Nested Loops.

43 Hash Join This Hash Join Table: Method is Definition used to join large data sets. The join key is hashed to an index entry in a hash The table. optimizer uses the smaller of two data sources to build a hash table, in Memory, if possible, on the Join Key. The hash table is an array and the row that goes with the hash key is stored in that entry. The optimizer scans the larger table, probing the hash table to find the joined rows.

44 Hash Join (cont d) When Used: The Optimizer will use a hash join to join two tables if they are joined using an equi-join (i.e. a.col1 = b.col1) And if either of the following conditions are met: A large amount of data needs to be joined. A large fraction of the table needs to be joined. Hash Joins can be effective when the lack of a useful index renders Nested Loop joins ineffective. 3

45 Sort Merge Join Can be used to join rows from two independent sources. Generally, perform worse than Hash Joins, except if the following are true: The Row Sources are sorted already A Sort Operation does not have to be done. Benefit may be lost if slower table access method is chosen (e.g. Full Table Scan) Useful when an inequality condition (i.e. <, <=, >, or >=) is selected

46 Sort Merge Join (cont d) Sort / Merge Joins perform better than Nested Loops Joins for large data sets. Two Steps: (No Driving Table as in NL Join) 1. Sort: Both inputs are Sorted on Join Key 2. Merge: Two sorted lists are merged

47 Sort Merge Join (cont d) When Used: When Join Condition is not an equi-join Parameter OPTIMIZER_MODE is set to RULE Parameter HASH_JOIN_ENABLE is set to FALSE Because data must already be sorted by other operations, optimizer thinks SJ is cheaper than HJ Estimated Cost: Optimizer thinks SJ cost less than HJ cost based on HASH_AREA_SIZE and SORT_AREA_SIZE The USE_MERGE hint has been specified.

48 Cartesian Join A join where every row from one data source is joined with every row from another data source. This creates a Cartesian Product. Happens when a table is listed in the FROM clause, but not joined to any other table in the WHERE clause. Generally, BAD NEWS!, resulting from poorly written SQL Sometimes, rarely, the optimizer thinks this type of join is less costly and induces.

49 Outer Join Extends the results of a simple join. Returns all rows that satisfy the Join Condition plus some or all rows from one table where the join condition is not satisfied. Similar But Different Types: Nested Loop Outer Join Hash Join Outer Join Sort Merge Outer Join Full Outer Join

50 Join Order Now we need to know how to analyze an Explained Plan and understand what is done when. Remember our Nested Loop example: For X in 1 to 10 Loop (Outer) For Y in 1 to 10 Loop (Inner) i = i + 1 print i: X, Y End Loop End Loop

51 Join Order (Cont d) For X in 1 to 10 Loop (Outer) For Y in 1 to 10 Loop (Inner) i = i + 1 print i: X, Y End Loop End Loop Q: What is the first real instruction executed? A: i = i + 1 The first innermost item from the top is the first instruction executed.

52 Join Order (Cont d) Similarly: 1.1 SELECT STATEMENT Optimizer=CHOOSE(Cost=23585 Card=1 Bytes=12) 2.1 SORT (AGGREGATE) 3.1 NESTED LOOPS (Cost=23585 Card= Bytes= ) 4.1 INDEX (FAST FULL SCAN) OF 'MC_MCAS_IDX' (NON-UNIQUE) (Cost=13745 Card= Bytes= ) 4.2 INDEX (UNIQUE SCAN) OF 'PK_MEMBER_CONTRACT_ATTRIB' (UNIQUE) (Cost=1 Card=1 Bytes=6) First Step? 4.1 Index Access (Fast Full Scan) Then what? For the first value returned by 4.1, and every other, 4.2 is performed. 3.1 Indicates that for every row 4.1 returns 4.2 is repeated to EOT (Index) Sort (Aggregate) = COUNT(1)

53 ID Query Plan Select Statement Choose Cost=743,837 Rows=27,748 COST/ROW = 27 Let s examine a few: 2 Sort Group By Cost=743,837 Rows=27,748 3* Hash Join Cost=743,528 Rows=27,748 4 View Cost=287,095 Rows=5,772 5 Sort Group By Cost=287,095 Rows=5,772 6* Hash Join Cost=286,920 Rows=106,262 7* Hash Join Cost=286,616 Rows=106,262 8 Table Access (Full) of REJ_CRED_MBRS_BAL Analyzed Cost=2 Rows=5,772 9 Table Access (Full) of FIN_TRANS Analyzed Cost=272,992 Rows=655,903, Table Access (Full) of FTC_INV Analyzed Cost=91 Rows=697, View Cost=456,424 Rows=27, Sort Group By Cost=456,424 Rows=27,748 13* Hash Join Cost=456,189 Rows=27,748 14* Hash Join Cost=445,299 Rows=776, Merge Join Cartesian Cost=23,090 Rows=161, Nested Loops Cost=11,546 Rows=5, Table Access (Full) of REJ_CRED_MBRS_BAL Analyzed Cost=2 Rows=5, Table Access (By Index Rowid) of MEMBER_CONTRACT Analyzed Cost=2 Rows=1 19* Unique Index (Unique Scan) of PK_MEMBER_CONTRACT_MEMCONSYSID Analyzed Cost=1 Rows=1 20 Buffer Sort Cost=23,088 Rows=28 21 Table Access (Full) of REFUND_METHOD Analyzed Cost=2 Rows=28 22 Table Access (Full) of AR_DISTRIB_DETAILS Analyzed Cost=124,239 Rows=784,295, Table Access (Full) of MEMBER_CONTRACT_ATTRIB Analyzed Cost=4,744 Rows=10,223,240 Predicate Information (identified by operation id): Access - ("A"."MEMBER_CONTRACT_SYSID"="B"."MEMBER_CONTRACT_SYSID") 6 - Access - ("FI"."FTC_INV_SYSID"="FT"."FTC_INV_SYSID") 7 - Access - ("A"."MEMBER_CONTRACT_SYSID"="FT"."MEMBER_CONTRACT_SYSID") 13 - Access - ("MC"."CUR_MEM_CONTRACT_ATTRIB_SYSID"="MCA"."MEMBER_CONTRACT_ATTRIB_SYSID AND "MCA"."REFUND_METHOD_ID"="RM"."REFUND_METHOD_ID") 14 - Access - ("MC"."MEMBER_CONTRACT_SYSID"="ARDD"."MEMBER_CONTRACT_SYSID") 19 - Access - ("A"."MEMBER_CONTRACT_SYSID"="MC"."MEMBER_CONTRACT_SYSID") ~/src/tuning_requests/2006_requests/ _bsperling/plan_orig_query log

54 ID Query Plan Insert Statement Choose Cost=1,779,896 Rows=1,128,413 COST/ROW = 2 2 Sort Group By Cost=1,779,896 Rows=1,128,413 3* Hash Join Cost=1,769,786 Rows=1,128,413 4 Table Access (Full) of PARTNER_CORPORATION Analyzed Cost=2 Rows=1,379 5* Hash Join Cost=1,769,747 Rows=1,128,413 6 Table Access (Full) of PARTNER Analyzed Cost=3 Rows=4,056 7* Hash Join Cost=1,769,677 Rows=1,128,413 8* Table Access (Full) of MEMBER_CONTRACT_ATTRIB Analyzed Cost=4,744 Rows=851,937 9* Hash Join Cost=1,763,458 Rows=1,128, Table Access (Full) of CA_MONTHLY_MEMBERS Analyzed Cost=3 Rows=21,400 11* Hash Join Cost=1,757,904 Rows=27,603,992 12* Table Access (Full) of MEMBER_CONTRACT Analyzed Cost=51,344 Rows=529, Partition Range Iterator Partitions: KEY * Table Access (Full) of MEMBER_RECOGNITION Analyzed Cost=764,775 Rows=2,022,571,722 Partitions: KEY - 65 Predicate Information (identified by operation id): Access - ("P"."PARTNER_CORPORATION_SYSID"="PC"."PARTNER_CORPORATION_SYSID") 5 - Access - ("MCA"."PARTNER_ID"="P"."PARTNER_SYSID") 7 - Access - ("MC"."CUR_MEM_CONTRACT_ATTRIB_SYSID"="MCA"."MEMBER_CONTRACT_ATTRIB_SYSID") 8 - Filter - ("MCA"."BILLING_METHOD_ID"=3) 9 - Access - ("A"."MEMBERSHIP_NUMBER"="MC"."MEM_CONTRACT_ID") 11 - Access - ("MR"."MEMBER_CONTRACT_SYSID"="MC"."MEMBER_CONTRACT_SYSID") 12 - Filter - ("MC"."SERVICE"='SHP' AND "MC"."TERM_COUNTER"<=11) 14 - Filter - ("MR"."CLOSED_DATE" IS NULL AND "MR"."RECOGNITION_DATE">'31-MAR-05') ~/src/tuning_requests/2006_requests/ _bsperling/plan_orig_query.7409.log

55 ID Query Plan Select Statement Choose Cost=10,429,451 Rows=401,107,070 COST/ROW = 0 2 Sort Group By Cost=10,429,451 Rows=401,107,070 3 Merge Join Cartesian Cost=93,689 Rows=401,107,070 4* Table Access (By Index Rowid) of FIN_TRANS Analyzed Cost=75 Rows=1 5 Nested Loops Cost=43,388 Rows=621 6 Nested Loops Cost=9,188 Rows=456 7* Hash Join Cost=4,232 Rows=118 8 Nested Loops Cost=4,228 Rows=118 9* Hash Join Cost=4,228 Rows= Nested Loops Cost=3 Rows=28 11 Table Access (By Index Rowid) of BILLING_METHOD Analyzed Cost=1 Rows=1 12* Unique Index (Unique Scan) of XPKBILLING_METHOD Analyzed Rows=1 13 Table Access (Full) of REFUND_METHOD Analyzed Cost=2 Rows=28 14* Table Access (By Index Rowid) of MEMBER_CONTRACT_ATTRIB Analyzed Cost=4,224 Rows=1,421 15* Non-Unique Index (Range Scan) of MEMCA_MEMEXPDT_IDX Analyzed Cost=88 Rows=40,928 16* Unique Index (Unique Scan) of XPKTERM_TYPE Analyzed Rows=1 17 Table Access (Full) of BILLING_GROUP Analyzed Cost=3 Rows=3,042 18* Table Access (By Index Rowid) of MEMBER_CONTRACT Analyzed Cost=42 Rows=4 19* Non-Unique Index (Range Scan) of MC_MCAS_IDX Analyzed Cost=2 Rows=75 20* Non-Unique Index (Range Scan) of FIN_TRANS_MEMCONSYSID Analyzed Cost=2 Rows=19 21 Sort Aggregate Rows=1 22 Partition Range Iterator Partitions: KEY - KEY 23* Table Access (By Local Index Rowid) of AR_AP_FIN_LINK Analyzed Cost=16,658 Rows=260,943 Partitions: KEY - KEY 24* Non-Unique Index (Range Scan) of AR_AP_FIN_LINK_PROCDATE Analyzed Cost=3,488 Rows=2,818,189 Partitions: KEY - KEY 25 Buffer Sort Cost=10,429,376 Rows=646, Unique Index (Fast Full Scan) of FTC_INV_TYPNUMSEQ Analyzed Cost=81 Rows=646,320 Predicate Information (identified by operation id): Filter - ("FT"."FIN_TRANS_TYPE"<>'J' AND "FT"."FIN_TRANS_TYPE"<>'T' AND "FT"."FIN_TRANS_SYSID">= (SELECT /*+ */ MIN("AR_AP_FIN_LINK"."FIN_TRANS_SYSID") FROM "FDS"."AR_AP_FIN_LINK" "AR_AP_FIN_LINK" WHERE "AR_AP_FIN_LINK"."PROCESSED_DATE"<"INFOCTL"."CYCLE_DATE"."CYCLE_DATE"()+1 AND "AR_AP_FIN_LINK"."PROCESSED_DATE">"INFOCTL"."CYCLE_DATE"."CYCLE_DATE_BOM"() AND "AR_AP_FIN_LINK"."PROCESS_CODE"='F')) 7 - Access - ("MCA"."BILLING_GROUP_SEQ_NUM"="BG"."BILLING_GROUP_SYSID") 9 - Access - ("MCA"."BILLING_METHOD_ID"="BM"."BILLING_METHOD_ID" AND "MCA"."REFUND_METHOD_ID"="RM"."REFUND_METHOD_ID") 12 - Access - ("BM"."BILLING_METHOD_ID"=3) 14 - Filter - ("MCA"."BILLING_METHOD_ID"=3 AND "MCA"."COMPANY_CODE"<>'NON') 15 - Access - ("MCA"."MEM_EXP_DATE">ADD_MONTHS("INFOCTL"."CYCLE_DATE"."CYCLE_DATE_EOM"(),-3) AND "MCA"."MEM_EXP_DATE"<"INFOCTL"."CYCLE_DATE"."CYCLE_DATE_EOM"()) 16 - Access - ("MCA"."TERM_TYPE_ID"="TT"."TERM_TYPE_ID") 18 - Filter - ("MC"."RECORD_ADD_DATE">"INFOCTL"."CYCLE_DATE"."CYCLE_DATE_BOM"()) 19 - Access - ("MC"."CUR_MEM_CONTRACT_ATTRIB_SYSID"="MCA"."MEMBER_CONTRACT_ATTRIB_SYSID") 20 - Access - ("MC"."MEMBER_CONTRACT_SYSID"="FT"."MEMBER_CONTRACT_SYSID") 23 - Filter - ("AR_AP_FIN_LINK"."PROCESS_CODE"='F') 24 - Access - ("AR_AP_FIN_LINK"."PROCESSED_DATE">"INFOCTL"."CYCLE_DATE"."CYCLE_DATE_BOM"() AND "AR_AP_FIN_LINK"."PROCESSED_DATE"<"INFOCTL"."CYCLE_DATE"."CYCLE_DATE"()+1) ~/src/tuning_requests/2006_requests/ _bsperling/plan_orig_query log

56 Ok. So we know how to read a Plan Now What? Where to go from here? How do we Tune the SQL?

57 Where to go from here? Remember: In most Cases, Oracle will make the right decision. If it ain t broke, don t fix it! The single most-effective way to tune any SQL statement: reduce the amount of work that Oracle needs to do, to return the desired result Your Tuning Goals: What is acceptable performance? Achieve it and move on!!!!

58 Where to go from here? (Cont d) Use these to evaluate the plan. 1. Look at Oracle chosen join order. With your understanding of the underlying data, does the initial join produce the smallest result set first? Does the table Oracle decides to start with make sense (i.e. Will produce the smallest data set, or could be easily joined to an indexed column?) Is there any Join Criteria that you could add to give Oracle an opportunity make more selective joins (e.g. Smaller Result Set initially)

59 Where to go from here? (Cont d) 2. Look at Oracle chosen join type for each set. With your understanding of the underlying data, and the query, does Oracle select the right join type for each set of data? Are large data sets being joined (i.e. Hash Join is better)? Is the driving data set sufficiently small, and an index available, to support Nested Loops? Did you expect Index access, and got Full Table scan, or vice-versa? Is Oracle smarter than you? (e.g. Did it make the right decision?)

60 Where to go from here? (Cont d) 3. Look at Oracle chosen method of table access. With your understanding of the underlying data, and the query, does Oracle select the right method to access each table? Did you expect Index access, and got Full Table scan, or vice-versa? Is Oracle smarter than you? (e.g. Did it make the right decision?)

61 Where to go from here? (Cont d) 3. Oracle chosen method of table access. (cont d) What Filters are in the Where clause to limit data? Is Oracle starting with the Filtered Data? Could you add selection criteria to the WHERE clause to cause the amount of data selected (and joined) to be reduced? Could you avoid large amounts of data being needlessly scanned by adding a partition key to your selection criteria?

62 Where to go from here? (Cont d) 4. Check Oracle Assumptions With your understanding of the underlying data, and the query, does Oracle make the correct assumptions (estimates) regarding the amount of data that will be returned at each step? Consider the following example:

63 SELECT sub.row_id AS subscription_id,pkg.row_id AS pkg_row_id,inv.row_id inv_row_id,pay.con_id,pay.actl_pay_dt,pay.x_mlov_pay_type_cd,pay.x_mlov_status_cd,pay.pay_amt,pkg.x_billing_cycle,pl.x_pay_freq,pli.x_membership_fee_trial,sub.x_promo_cd,sub.created FROM siebel.s_src_payment pay,siebel.s_invoice inv,siebel.s_pri_lst_item pli,siebel.s_pri_lst pl,siebel.s_agree_item sub,siebel.s_prod_int pkg WHERE pkg.prod_cd = 'Package' AND pkg.x_pkg_type IS NOT NULL AND pkg.row_id = sub.prod_int_id AND pl.row_id = sub.pri_lst_id AND pkg.row_id = pli.prod_id AND pli.pri_lst_id = sub.pri_lst_id AND sub.row_id = inv.agree_item_id AND inv.row_id = pay.pr_invoice_id AND pay.pay_amt > 0 AND pay.pay_amt <> pli.x_membership_fee_trial AND pay.x_pay_flow_type_cd = 'Debit' AND pay.x_transact_reason = 'Fees' AND pay.x_mlov_status_cd <> 'Cancelled' ORDER BY sub.row_id,pay.actl_pay_dt,inv.row_id Consider this SQL

64 ID Query Plan Select Statement Choose Cost=16,091 Rows=741 COST/ROW = 22 2 Sort Order By Cost=16,091 Rows=741 3 Nested Loops Cost=16,056 Rows=741 4 Nested Loops Cost=16,049 Rows=741 With this Plan 5* Hash Join Cost=15,376 Rows=22,429 6 Nested Loops Cost=6,514 Rows=155,073 7 Nested Loops Cost=5 Rows=353 8* Table Access (By Index Rowid) of S_PROD_INT Analyzed Cost=1 Rows=78 9* Non-Unique Index (Skip Scan) of S_PROD_INT_F11 Analyzed Cost=13 Rows=1, Table Access (By Index Rowid) of S_PRI_LST_ITEM Analyzed Cost=1 Rows=5 11* Unique Index (Range Scan) of S_PRI_LST_ITEM_U1 Analyzed Cost=2 Rows=5 12* Table Access (By Index Rowid) of S_AGREE_ITEM Analyzed Cost=6,514 Rows= And-Equal 14* Non-Unique Index (Range Scan) of S_AGREE_ITEM_F5 Analyzed 15* Non-Unique Index (Range Scan) of S_AGREE_ITEM_F1 Analyzed Cost=714 Rows=134,525 16* View () of index$_join$_002 Cost=6,187 Rows=5,019,953 17* Hash Join Cost=15,376 Rows=22,429 18* Non-Unique Index (Fast Full Scan) of S_INVOICE_F20 Analyzed Cost=263 Rows=5,019, Unique Index (Fast Full Scan) of S_INVOICE_P1 Analyzed Cost=263 Rows=5,019,953 20* Table Access (By Index Rowid) of S_SRC_PAYMENT Analyzed Cost=1 Rows=1 21* Non-Unique Index (Range Scan) of S_SRC_PAYMENT_V1 Analyzed Cost=2 Rows=1 22 Table Access (By Index Rowid) of S_PRI_LST Analyzed Cost=1 Rows=1 23* Unique Index (Unique Scan) of S_PRI_LST_P1 Analyzed Rows=1 Predicate Information (identified by operation id): Access - ("SUB"."ROW_ID"="INV"."AGREE_ITEM_ID") 8 - Filter - ("PKG"."X_PKG_TYPE" IS NOT NULL) 9 - Access - ("PKG"."PROD_CD"='Package') Filter - ("PKG"."PROD_CD"='Package') 11 - Access - ("PKG"."ROW_ID"="PLI"."PROD_ID") 12 - Filter - ("PKG"."ROW_ID"="SUB"."PROD_INT_ID" AND "PLI"."PRI_LST_ID"="SUB"."PRI_LST_ID") 14 - Access - ("PLI"."PRI_LST_ID"="SUB"."PRI_LST_ID") 15 - Access - ("PKG"."ROW_ID"="SUB"."PROD_INT_ID") 16 - Filter - ("INV"."AGREE_ITEM_ID" IS NOT NULL) 17 - Access - ("indexjoin$_alias$_008".rowid="indexjoin$_alias$_007".rowid) 18 - Filter - ("indexjoin$_alias$_007"."agree_item_id" IS NOT NULL) 20 - Filter - ("PAY"."PAY_AMT">0 AND "PAY"."PAY_AMT"<>"PLI"."X_MEMBERSHIP_FEE_TRIAL" AND "PAY"."X_PAY_FLOW_TYPE_CD"='Debit AND "PAY"."X_TRANSACT_REASON "='Fees' AND "PAY"."X_MLOV_STATUS_CD"<>'Cancelled') 21 - Access - ("INV"."ROW_ID"="PAY"."PR_INVOICE_ID") 23 - Access - ("PL"."ROW_ID"="SUB"."PRI_LST_ID") ~/src/tuning_requests/2008_requests/2008_04_04_siebel_lrq

65 SELECT COUNT(1) FROM siebel.s_prod_int pkg,siebel.s_pri_lst_item pli WHERE pkg.prod_cd = 'Package' AND pkg.x_pkg_type IS NOT NULL AND pkg.row_id = pli.prod_id /... COUNT(1) row selected. Elapsed: 00:00:01.22 No errors. run_sql.sh : End : Mon Aug 11 17:34:42 EDT 2008

66 ID Query Plan Select Statement Choose Cost=16,091 Rows=741 COST/ROW = 22 2 Sort Order By Cost=16,091 Rows=741 3 Nested Loops Cost=16,056 Rows=741 4 Nested Loops Cost=16,049 Rows=741 5* Hash Join Cost=15,376 Rows=22,429 6 Nested Loops Cost=6,514 Rows=155,073 7 Nested Loops Cost=5 Rows=353 8* Table Access (By Index Rowid) of S_PROD_INT Analyzed Cost=1 Rows=78 9* Non-Unique Index (Skip Scan) of S_PROD_INT_F11 Analyzed Cost=13 Rows=1, Table Access (By Index Rowid) of S_PRI_LST_ITEM Analyzed Cost=1 Rows=5 11* Unique Index (Range Scan) of S_PRI_LST_ITEM_U1 Analyzed Cost=2 Rows=5 12* Table Access (By Index Rowid) of S_AGREE_ITEM Analyzed Cost=6,514 Rows= And-Equal 14* Non-Unique Index (Range Scan) of S_AGREE_ITEM_F5 Analyzed 15* Non-Unique Index (Range Scan) of S_AGREE_ITEM_F1 Analyzed Cost=714 Rows=134,525 16* View () of index$_join$_002 Cost=6,187 Rows=5,019,953 17* Hash Join Cost=15,376 Rows=22,429 18* Non-Unique Index (Fast Full Scan) of S_INVOICE_F20 Analyzed Cost=263 Rows=5,019, Unique Index (Fast Full Scan) of S_INVOICE_P1 Analyzed Cost=263 Rows=5,019,953 20* Table Access (By Index Rowid) of S_SRC_PAYMENT Analyzed Cost=1 Rows=1 21* Non-Unique Index (Range Scan) of S_SRC_PAYMENT_V1 Analyzed Cost=2 Rows=1 22 Table Access (By Index Rowid) of S_PRI_LST Analyzed Cost=1 Rows=1 23* Unique Index (Unique Scan) of S_PRI_LST_P1 Analyzed Rows=1 Predicate Information (identified by operation id): Access - ("SUB"."ROW_ID"="INV"."AGREE_ITEM_ID") 8 - Filter - ("PKG"."X_PKG_TYPE" IS NOT NULL) 9 - Access - ("PKG"."PROD_CD"='Package') Filter - ("PKG"."PROD_CD"='Package') 11 - Access - ("PKG"."ROW_ID"="PLI"."PROD_ID") 12 - Filter - ("PKG"."ROW_ID"="SUB"."PROD_INT_ID" AND "PLI"."PRI_LST_ID"="SUB"."PRI_LST_ID") 14 - Access - ("PLI"."PRI_LST_ID"="SUB"."PRI_LST_ID") 15 - Access - ("PKG"."ROW_ID"="SUB"."PROD_INT_ID") 16 - Filter - ("INV"."AGREE_ITEM_ID" IS NOT NULL) 17 - Access - ("indexjoin$_alias$_008".rowid="indexjoin$_alias$_007".rowid) 18 - Filter - ("indexjoin$_alias$_007"."agree_item_id" IS NOT NULL) 20 - Filter - ("PAY"."PAY_AMT">0 AND "PAY"."PAY_AMT"<>"PLI"."X_MEMBERSHIP_FEE_TRIAL" AND "PAY"."X_PAY_FLOW_TYPE_CD"='Debit AND "PAY"."X_TRANSACT_REASON "='Fees' AND "PAY"."X_MLOV_STATUS_CD"<>'Cancelled') 21 - Access - ("INV"."ROW_ID"="PAY"."PR_INVOICE_ID") 23 - Access - ("PL"."ROW_ID"="SUB"."PRI_LST_ID") ~/src/tuning_requests/2008_requests/2008_04_04_siebel_lrq

67 SELECT COUNT(1) FROM WHERE AND AND AND /... 6 Nested Loops Cost=6,514 Rows=155,073 7 siebel.s_prod_int Nested Loops pkg Cost=5 Rows=353 8*,siebel.s_pri_lst_item Table Access pli (By Index Rowid) of S_PROD_INT Analyzed Cost=1 Rows=78 9* Non-Unique Index (Skip Scan) of S_PROD_INT_F11 Analyzed Cost=13 Rows=1,019 10,siebel.s_agree_item Table Access sub (By Index Rowid) of S_PRI_LST_ITEM Analyzed Cost=1 Rows=5 11* Unique Index (Range Scan) of S_PRI_LST_ITEM_U1 Analyzed Cost=2 Rows=5 12* pkg.prod_cd Table = 'Package' Access (By Index Rowid) of S_AGREE_ITEM Analyzed Cost=6,514 Rows= pkg.x_pkg_type And-Equal IS NOT NULL 14* Non-Unique Index (Range Scan) of S_AGREE_ITEM_F5 Analyzed 15* pkg.row_id = pli.prod_id Non-Unique Index (Range Scan) of S_AGREE_ITEM_F1 Analyzed Cost=714 Rows=134,525 COUNT(1) row selected. ~19M / 155K = 122 Times More rows than expected. sub.pri_lst_id = pli.pri_lst_id 1 SELECT table_name 2,owner 3,num_rows 4,partitioned 5 FROM dba_tables 6* WHERE table_name = UPPER('S_AGREE_ITEM') ~19M / 36M = 52% of Rows in Table That is a significant difference!!!! MRUCKDASCHEL@elizabeth_crmuk2 SQL> / TABLE_NAME OWNER NUM_ROWS PAR S_AGREE_ITEM SIEBEL NO Elapsed: 00:03:39.73 No errors. run_sql.sh : Begin : Mon Aug 11 18:06:24 EDT 2008

68 What are some ways we can alter this plan? Rewrite and/or modify the SQL: Force Index Usage Elimination (WHERE) Modify selection criteria to WHERE (i.e. Partition Key) Use Correlated Sub-Query (EXISTS) rather than Join Alter the Database and/or Session (Not too common, other than Indexes) Add Hints (s/b last resort)

69 Plan Modification: 1.Enable Index Usage / Partition Pruning If a Function is applied to an indexed column in the WHERE clause, the Index cannot be used. What is Partition Pruning??? On a partitioned table or index, if the partition key Same goes for Partition Pruning. If a is referenced in the WHERE clause, Oracle will only access function those is Partitions applied that to the have partition that/thosekey partition column, key partition value(s) pruning CANNOT occur. Conversly, the application of a Function may be used eliminate the usage of an index.

70 Plan Modification: (Cont d) 2. Modify Selection Criteria to WHERE clause: If Oracle is not using a Join Method, Join Order, or Table Access that you think should be used, you can try adding/deleting Join conditions which you know to be true (or are also true). For example, if a Join is being done to a table that is redundant (e.g. A join on the Primary Key AND another set of columns from the same two tables, unnecessary Table Access may occur.

71 Plan Modification: (Cont d) 3. Use correlated sub-query rather than join. Instead of coding this: SELECT MC.MEM_CONTRACT_ID FROM MEMBER_CONTRACT MC,MC_TEMP_TABLE MCT WHERE MCT.MC_SYSID = MC.MEMBER_CONTRACT_SYSID /

72 Plan Modification: (Cont d) 3. Use correlated sub-query rather than join. Consider Doing This: (Assuming idx on MCT.MC_SYSID) SELECT MC.MEM_CONTRACT_ID FROM MEMBER_CONTRACT MC WHERE EXISTS ( SELECT 1 FROM MC_TEMP_TABLE MCT WHERE MCT.MC_SYSID = MC.MEMBER_CONTRACT_SYSID) /

73 Plan Modification: (Cont d) 4. Hinting Hints are not really Hints They are Directives!!!!! Should be used as a last Resort. Use CAUTION when storing hard-coded in application code. Consider employing Parallelism

74 I m probably over my time limit! We talked about how to understand what an Explain Plan is telling us Table Access Methods, Join Methods, and Join Orders We discussed how we can evaluate this plan, and alter it intelligently to achieve our objectives.