Query tuning by eliminating throwaway

Transcription

1 Query tuning by eliminating throwaway This paper deals with optimizing non optimal performing queries. Abstract Martin Berg Server Technology System Management & Performance Oracle Denmark APS July 2000 During time there has been many descriptions on how to tune queries, but most descriptions ends up being a list of recommendations ( best practices ) or examples on experienced problems ( worst practices ). The result of this is that tuning to a large degree is left over to guesswork and the experience of the SQL tuner. Several experienced SQL tuners today are using information about the row sources used in a query for tuning purposes, but the method(s) has sofar not been formalized nor described and has been up to the ingenuity of the SQL tuner. This paper attempts to deliver a structured method for query tuning using tools already available with the Oracle RDBMS. The method described here was first introduced in a very limited way in the Oracle 8 Statement Tuning courseware from Intended audience is all developers and DBA s with the need to tune queries. The required level is above novice level as many concepts from basic SQL execution are assumed as known. Why is a query not performing optimal? There can be more reasons why a query is not performing optimal. For the purpose of this paper these reasons will be categorized in 4 main areas Doing too many IO operations Using expensive operations on rows (like sorting) Not utilizing the available resources (for example parallelization) Processing too many rows Experience has shown that a large part of non optimal performing queries can credit the lack of performance to the fourth reason - processing too many rows. The number of rows processed within a query is dependent on output generated, the operations used and how many rows are retrieved, but then thrown away, because they were not used in the output of the query. Most badly performing queries usually exhibits a high amount of rows processed and then thrown away because they were not needed in the output. This paper focuses on how to identify these processed, but thrown away rows and how to use this identification to tune queries. This idea of rows thrown away will hereafter be called throwaway. July 2000 Page 1

2 Structure of paper The rest of the paper will use following outline: 1. Basic Method for Query Tuning 2. Initial Examples 3. Defining Throwaway 4. Oracle Version Dependencies 5. Detailed Description of Throwaway in Row Sources 6. Secondary Throwaway 7. Tuning SQL by Eliminating Throwaway, the Method 8. Examples on Applying the Method 9. Using SQL Trace and tkprof 10. Tracing Issues 11. Miscellanous Issues If you already are familiar with using the quantification of row sources found in the tkprof output you can skip directly to section 3 and then continue with sections 6, 7 and 8 and use sections 4, 5, 9, 10 and 11 as reference. July 2000 Page 2

3 1. A Basic Method for Performing Query Tuning Before describing the concept of throwaway it would be appropriate to describe a generic method for performing query tuning. Basically tuning of queries can be done by following high level method: 1. Set goals 2. Identify queries to be tuned 3. For every query identified: 4. Analyze query 5. Suggest changes to improve performance 6. Implement changes 7. Test improvement 8. Repeat until goal reached (or time spend) Traditionally the hardest part of this is to get from step 4 ( analyze ) to step 5 ( suggest changes ) and has - as described in the introduction - been up to the guesswork and/or experience of the statement tuner. The concept of tuning by eliminating throwaway is meant to directly address this part of the tuning method by quantifying the work done in each of the execution steps a query is build upon. July 2000 Page 3

4 2. Initial Examples Let s demonstrate the concept of throwaway by looking at two simple examples: Query 1: Select CLASS_ID From CLASSES Where TYPE = 'S/EC' Output from tkprof: Rows Execution Plan TABLE ACCESS (BY INDEX ROWID) OF 'CLASSES' 2387 INDEX (RANGE SCAN) OF 'CLASSES_TYPE' (NON-UNIQUE) Index: CLASSES_TYPE on CLASSES(TYPE) This trace shows that 2387 rows was retrieved from the index row source (range scan on CLASSES_TYPE) and that all these rows (except for one caused by the index range scan) resulted in a row returned from the table access. Query 2: Select CLASS_ID From CLASSES Where TYPE = 'S/EC' and DAYS = 15 Output from tkprof: Rows Execution Plan TABLE ACCESS (BY INDEX ROWID) OF 'CLASSES' 2387 INDEX (RANGE SCAN) OF 'CLASSES_TYPE' (NON-UNIQUE) Same index as Query 1 This trace shows again that 2387 rows was retrieved from the index row source (range scan on CLASSES_TYPE). The difference is that now after retrieving the 2387 rows from the index these are used to retrieve the same number of rows from the table (minus the extra row from the range scan) just as before, but then most of these rows are filtered away (caused by the extra non-indexed predicate in the select) - only leaving 4 rows. Another way of describing this is that to execute the query some 99.8% of the rows retrieved are not returned as output and are just thrown away after further evaluation (the extra predicate) - hence the term throwaway. It should now be intuitively obvious that the tkprof output for Query 2 shows that there is unnecessary work done - and that it has something to do with how the predicates for CLASSES are evaluated. July 2000 Page 4

5 The experienced SQL tuner will of cause immediately spot the probable cause: the index used is an single column index and by adding an extra column - DAYS - to the index the predicate selectivity in the query will be matched by the selectivity in the index. Now, a more tricky example: Query 3: Select * From TABLE2 Where COL1 = 102 and COL2 = 23 (Index: I_COL1_COL2 on TABLE2(COL1, COL2)) A simple execution plan (by SQL*Plus AUTOTRACE or manual explain plan) would show: TABLE ACCESS (BY INDEX ROWID) OF TABLE2 INDEX ACCESS (RANGE SCAN) OF I_COL1_COL2 (NON-UNIQUE) This would lead most SQL tuners to the conclusion that this query was performing as good as it can (all predicates can be found in the leading columns of an concatenated index). The tkprof output is this case could show: Rows Execution Plan TABLE ACCESS (BY INDEX ROWID) OF TABLE INDEX ACCESS (RANGE SCAN) OF I_COL1_COL2 (NON- UNIQUE) According to the previous example this shows that there is work done that gets thrown away before output. This should only happen if not all predicates are used for the index retrieval. Now the problem is to determine why only a part of the predicates are used for index retrieval. A likely candidate would be to check for a implicit type conversion on the predicate corresponding to the non-leading column in the index - COL2 (the leading column will be used - otherwise the index would not have been used at all), This example shows that by using the Rows column from the execution plan in the tkprof output more information about the performance of a particular query can be obtained than by just using the execution plan alone. July 2000 Page 5

6 3. Defining Throwaway 3.1 Formal definition of throwaway After the initial examples it is time to formalize a definition of the term throwaway : There are two types of throwaway: Primary throwaway is the amount of rows from the input to a row source that can not be found in the output from that particular row source. Secondary throwaway is the amount of rows generated as output from a row source which are then thrown away in a following row source with primary throwaway. 3.2 Primary vs. secondary throwaway To illustrate the difference between primary throwaway and secondary throwaway consider following graphical representation of an execution plan: #R1 Row Source 1 #R2 Row Source 2 Row Source 2 generates #R2 number of rows which are then processed in Row Source 1 resulting in a final set of rows - #R1. Primary throwaway in Row Source 1 can be described as this row source has to process all the input rows (#R2), but only delivers #R1 worth of output - it is the row source itself that in processing the input rows is throwing away the ones not making it to the output. Row Source 2 will in this case generate #R2 number of rows as output - which represents a certain amount of work. The secondary throwaway is then the amount of this work already done which is thrown away in a following row source (Row Source 1 in this case). The distinction between these two types of throwaway is very important when analysing complex queries (for example joins). To evaluate the total work thrown away by an operation the implied secondary throwaway should be included in the evaluation. This will be further described in 6. Secondary Throwaway. July 2000 Page 6

7 3.3 Background - execution plans and row sources To analyze queries for throwaway a clear understanding of execution plans, row sources and the interpretation of the tkprof output is needed: Every line in the execution plan (except for the very top one which just describes what type of statement it is and informes about the optimizer approach) represents a row source. A row source either generates rows directly by accessing a data object or accepts one or more other row sources as input, manipulates these and then returns these as a new stream of rows. For purpose of this paper all row sources has an input - either from a database object or from one or more other row sources. If the execution plan is interpreted as a tree with the row sources being leafs and branches the leaf row sources will be row sources that accesses data and all branch row sources of the tree will be row sources that accepts a row source as input. The number of rows processed by a row source can be found left of the execution plan in the tkprof output. In this context it should be noted that this definition of rows processed is not consistent over different versions of Oracle (see 4. Oracle Version Dependencies ). The input rows is received from a row source which can be found down right in the execution plan and the output rows are delivered up left to a receiving row source. In above examples - Query 3 - the TABLE ACCESS (BY INDEX ROWID) row source receives 3401 rows as input and generates 71 rows output. This can also be described as the rows starts from a leaf row source and then walks up the tree through the branch row sources ending at the root. July 2000 Page 7

8 3.4 What row sources can introduce throwaway? It is not all row sources that can introduce throwaway - it depends on what processing the row source is doing on the input rows. The following table list the most common row sources and how throwaway can be identified for each Row source Number of input row sources Table access (full) Data access from table Table access (by index rowid) 1 (rowids from index) Table access (cluster) 1 (rowids from cluster index) Table access (hash) Data access from table Index access Data access from index Nested Loops 2 Merge (join) 2 Merge (cartesian) 2 Hash join 2 Filter Sort (aggregate) 1 Sort (unique) 1 Sort (group by) 1 Sort (join) 1 Sort (order by) 1 And-equal Concatenation Stop key 1 Connect by 3 Count 1 Minus 2 Intersection 2 Union-All 2 or more Group by 1 1 primary to be filtered and 0 or more secondary for executing the filtering 2-5 (rowids from indexes) 2 or more July 2000 Page 8

9 4. Oracle Version Dependencies Before going into details with the different row sources it should be noted that there are some version dependent issues on what numbers are reported for a row source. 4.1 Row source counts and calculation of throwaway in Oracle 7.3 and Oracle 8.0 In Oracle 7.3 and 8.0 the number reported for non-join operations is the total number of rows processed within the row source. For join operations the number reported basically is the number of rows processed in inner table access by the join operation. The result of this is that when running Query 2 from above following tkprof output would be generated under Oracle 7.3 and Oracle 8.0: Rows Execution Plan *) TABLE ACCESS (BY INDEX ROWID) OF 'CLASSES' 2387 INDEX (RANGE SCAN) OF 'CLASSES_TYPE' (NON-UNIQUE) *) In Oracle8i this was reported as 4. For Oracle 7.3 and 8.0 this basically means that for simple row sources (one input) the throwaway in a particular row source can be calculated as the number of rows processed by the row source of interest minus the number of rows processed by the receiving row source. In the case where there is no receiving row source (as the table access in above example) the number of rows output from the statement (this information can be found elsewhere in the tkprof output) is the number that should be subtracted. In the case where the receiving row source reports output rows (for example a join operation) the throwaway in the row source of interest can not always be determined - see later. In above example 4 rows are returned from the select and therefore the throwaway in the table access row source can be calculated as number of rows processed in table access operation minus number of rows from statement : = 2382 rows (or a throwaway of 99.8% of the rows processed). 4.2 Row source counts and calculation of throwaway in Oracle8i In Oracle8i the number of rows reported is always the number of rows output from the row source. Throwaway in simple row sources in Oracle8i can then be calculated as number of rows received from the input row source minus the number of rows from the row source of interest. In the case where the row source of interest is accessing data (full table scans and index scans) it becomes necessary to quantify the number of rows in the accessed data. In the Oracle8i version of above example the throwaway from the table access row source can be calculated as number of rows from index scan operation minus number of rows from table access operation : (2387-1) - 4 = 2382 rows (or a throwaway of 99.8% of the rows processed). The minus one from the formula comes from the range scan of the indes - see later. July 2000 Page 9

10 5. Detailed Description of Simple Row Sources In the following the most relevant simple row sources are described in further detail. By simple is meant that the row sources being described all are row sources that either accesses data (index or table) or accepts one row source as input. Not all simple row sources mentioned above will be described - only the ones relevant for statement tuning by elimination of throwaway. For each described row source the calculation of throwaway and a probable cause and cure for throwaway is described. 5.1 Throwaway in row source: TABLE ACCESS (FULL) The table access (full) row source process all rows from the specified table and filters away - throws away - the rows not satifying non-indexed predicates (if there are any). For full table scans the number of rows processed in the accessed data is the number of rows in the table multiplied by number of times the table was scanned during execution of the statement. A full table scan should only be repeated if the full table scan can be found somewhere as a inner row source of a nested loops join or if the full table scan is part of a filter operation. Calculating throwaway: Rows Execution plan A TABLE ACCESS (FULL) OF TABLE For Oracle 7.3 and 8.0 the throwaway can be calculated as: A - #rows output For Oracle8i the throwaway can be calculated as: #N * Card(TABLE) - A Where #N is the number of times the table was scanned (for example as the inner table in a nested loops join) and Card(TABLE) is the number of rows in TABLE. In some cases there is reported one row more than output when using Oracle8i. Actually this plus one can appear not on the full table scan, but later in one of the row sources processing the rows from the full table scan. In the real world this extra row does not matter, as it does not seem reasonable to elaborate on one single row more or less. Cure: Throwaway in a table access (full) operation can only be caused by predicates that does not use an index and the only solution is to use an index for all the predicates that results in (a significant part of) the throwaway. Limitation: Not all predicates can be indexed. July 2000 Page 10

11 5.2 Throwaway in row source: TABLE ACCESS (BY INDEX ROWID) This is one of the most commonly seen row sources: it accepts rowids comming from an index scan row source, retrieves the corresponding rows from the table and finally throws away the rows not satifying non-indexed predicates (if there are any). Thereby the index scan is also subjected to secondary throwaway. Calculating (primary) throwaway, scenario 1 - Index Range Scan: Rows Execution plan A TABLE ACCESS (BY INDEX ROWID) OF TABLE B INDEX (RANGE SCAN) OF For Oracle 7.3 and 8.0 the throwaway can be calculated as: A - #rows output For Oracle8i the throwaway can be calculated as: B - #N - A, where #N is the number of lookups in the index. The explanation for above #N is that Oracle 7.3, 8.0 and 8i reports one row extra from an index range scan per lookup - which in above case is 1 lookup. In the case where the index is used for several lookups - for example when being used for accessing the inner table in a nested loops join - #N will be the number of times the index is used to find rows in the table - which for the nested loops join means the number of rows gotten from the outer table (see 5.6 Throwaway in row sources: NESTED LOOPS join operation). Calculating (primary) throwaway, scenario 2 - Index Unique Scan: Rows Execution plan A TABLE ACCESS (BY INDEX ROWID) OF TABLE B INDEX (UNIQUE SCAN) OF For Oracle 7.3 and 8.0 the throwaway can be calculated as: A - #rows output For Oracle8i the throwaway can be calculated as: (B - #N) - A, where #N is the number of lookups in the index The explanation for above #N is that Oracle8i (but not Oracle 7.3 and 8.0) also reports one row extra from an index unique scan per lookup - just as for index range scans. Cure: Like the table access (full) row source throwaway can only be caused by non-indexed predicates - and the cure is to add the non-indexed predicates to the index already in use. Limitation: Not all predicates can be indexed. July 2000 Page 11

12 5.3 Throwaway row source: INDEX SCAN Currently only B*tree indexes are dealt with in this paper. An index scan row source can either be a UNIQUE, RANGE, FULL or FAST FULL scan of an B*tree index (a reverse key index can not be FULL scanned). The UNIQUE scan requires that all columns in an unique index is used for the index lookup. The FULL scan is used when all entries in the index is retrieved with the purpose of avoiding sorting the table rows after retrieval. There is a special version of the FULL scan - the FULL SCAN(MIN/MAX) introduced in Oracle8i for finding resp. the minimum or the maximum value from an index (aka: go directly to one end of the index ). All other index uses will be RANGE scans (and the FULL scan can be seen as a special case of the RANGE scan and was not reported as such before Oracle 7.3). Throwaway in index scan row sources can in normal cases only occur when doing index range scans on concatenated indexes. Sofar following three possibilities for throwaway have been discovered: 1. When a column between the leading column and the last used column from the index is not being addressed by a predicate. Example: Select * From CLASSES Where TYPE = 'S/EC' and DAYS = 15 (Index on CLASSES(TYPE, STATUS, DAYS)) The first predicate corresponding to the first column in the index is used for the lookup in the index. Hereafter all the rows satifying this predicate are evaluated using column values retrieved from the index to satify the last predicate and the STATUS column is not used at all. It should be noted that all the predicates are evaluated through the index - but only the first predicate can be used to navigate down the index tree and the last predicate has to be processed by retrieving the column value from the index, evaluate the condition and then finally filter away the rows not satifying the condition. This last filtering of retrieved rows from the index is throwaway. 2. When an indexed column is being processed by a function call. Example: Select * From CLASSES Where TYPE = 'S/EC' and STATUS = 'BOOK' and to_char(days) = '5' July 2000 Page 12

13 (Index on CLASSES(TYPE, STATUS, DAYS)) Here the two first predicates corresponding to the two first columns in the index are used for the lookup in the index. Hereafter all the rows satifying these predicates are evaluated to satify the last predicate. It should be noted that all the predicates are evaluated through the index - but the difference is that the two first predicates can be used to navigate down the index tree and the last predicate has to be processed by retrieving the column value from the index, execute the function (to_char) on the retrieved value, evaluate the condition and then finally filter away the rows not satifying the condition. This last filtering of retrieved rows from the index is throwaway. 3. When a column in the index is subjected to a range scan and there is a column placed later in the index which also is used for evaluating predicates. Example: Select * From REGISTRATIONS Where REG_DATE between sysdate-10 and sysdate and STATUS = 'HOLD' (Index on REGISTRATIONS(REG_DATE, STATUS)) In this case all index entries satisfying the first predicate will be scanned and those not satifying the second (equality) predicate will be filtered away, thus resulting in throwaway. Calculating throwaway, Index Range Scan: Rows Execution plan A TABLE ACCESS (BY INDEX ROWID) OF TABLE B INDEX (RANGE SCAN) OF For Oracle 7.3 and 8.0 the throwaway can be calculated as: (B - #N) - A, where #N is the number of lookups in the index. The explanation for above #N is the same as for table access (by index rowid). For Oracle8i the throwaway can NOT be calculated. In Oracle8i the rows reported for an index scan row source is (just as for a table access row source) the rows returned (and not the rows processed as in Oracle 7.3 and 8.0) and it is impossible (or very difficult) to determine the number of rows retrieved internally in the index as would be required to determine the throwaway. Cure: In the case where not all leading columns in the index is used for the index lookup (case 1 above) the solution could be to rearrange the sequence of the columns in the index to match the predicates used. July 2000 Page 13

14 In the case with a function disabling the full usage of predicates for index lookup (case 2 above) the only solution is to change the statement so that the function is not performed on the indexed column side of the predicate. In the case with a range scan on a leading column (case 3 above) the solution could be to rearrange the sequence of the indexed columns to move the column being range scanned to be the last column in the index. Limitations: Rearranging the column sequence in concatenated indexes migth result in unwanted behaviour for other statements previosly using the same index. Not all function calls can be avoided. With range scans on more columns in the index it can prove impossible to find a sequence that can not give any throwaway. July 2000 Page 14

15 5.4 Throwaway in row source: SORT (UNIQUE) There are several sort operations in Oracle - sort (order by), sort (group by), sort (aggregate), sort (unique) etc. - but only the sort (unique) can introduce throwaway. The sort (unique) row source is used to extract unique rows from the input row source - for example when using the distinct operator. The sort (aggregate) and sort (group by) operations both returns fewer rows than the input, but as all input rows is included in the final then throwaway is not introduced in these operations. Calculating primary throwaway: Rows Execution plan A SORT (UNIQUE) B TABLE ACCESS ( )OF For Oracle 7.3 and 8.0 the throwaway can be calculated as: A - #rows output For Oracle8i the throwaway can be calculated as: B - A Cure: Nothing can be done by changing the statement or by adding (or removing) indexes except if a predicate limiting the number of duplicate rows can be squeezed into the query to be evaluated before the sort(unique) operation. Some times it is a possibility is to change the data model or use the existing data model in another manner to avoid the possible duplicate rows and thereby avoiding the sort(unique) operation.. Limitations The cures described might - if possible at all - be very complex to implement. July 2000 Page 15

16 5.5 Throwaway in join operations, generic Join operation row sources always takes two row sources as input, throws away the rows from each input row source that can not be matched with a row from the other input row source and finally returns the matched sets of rows. This means that both input sources can be subjected to throwaway. It should be noted that it is dependent on the join operation whether both input row sources or only one of the input row sources can be subjected to secondary throwaway - this will be described under each join operation. It is not possible in all cases to quantify the amount of throwaway in join operations. Therefore there must be adopted some pragmatic rules covering the cases where there is no exact quantification possible. If the output rows from the join operation is less than the largest input row source then there without doubt are rows being thrown away, but it can not necessarily be determined from what input the rows are thrown away or said in another way: Throwaway in join operations can be identified by the output rows being less than an input row source. It is possible though to have throwaway from an input row source even if it is smaller than the output rows. July 2000 Page 16

17 5.6 Throwaway in row source: NESTED LOOPS join operation For the nested loops join operation it is necessary to distinguish between the outer (the driving row source) and the inner row source. Non-join predicates on the outer row source (in the case where the outer row source is a table access) will be applied before the join operation and throwaway caused by this is not considered as throwaway from the nested loops join operation, but rather as throwaway from the row source itself. If the outer row source is not a table access, but instead the result of another join operation then the non-join predicates has already been evaluated and can not cause this type of throwaway from the outer row source. There is subtle case where non-join predicates are applied on the outer row source just before the join operation even if this row source is the result of another join operation - and this is when the outer row source is evaluated in a non-merged view. Throwaway from the outer row source during join happens when a row is retrieved from the outer row source (after applying non-join predicates) and then a matching row from the inner row source can not be found. The amount of throwaway from the outer row source can therefore only be determined if the number of lookups in the inner row source that did not result in any rows can be determined. As the rows from the outer row source already has been retrieved, throwaway from the outer row source will imply secondary throwaway on the outer row source. A precise calculation of the number of thown away rows from the outer row source depends on the access path to the inner row source. To simplify the calculation of throwaway in nested loops join operations use following list of scenarios that all deals with both row sources being table accesses (the Card(table name) represents the number of rows in that particular table): Calculating throwaway, scenario 1 (inner table access via unique scan on index): Rows Execution plan A NESTED LOOPS B TABLE ACCESS (FULL) OF TABLE_O C TABLE ACCESS (BY INDEX ROWID) OF TABLE_I D INDEX ACCESS (UNIQUE SCAN) OF (UNIQUE) For Oracle 7.3 and 8.0 the throwaway can be calculated as: Throwaway from outer table (before join): B - D Throwaway from outer table (during join): D - A (Outer joins: always 0) Throwaway from inner table (during join): C - A Note that the output from a nested loops join operation is the number of row retrieved from the inner table and not the number of rows from the join operation. For normal (inner) joins these two numbers will be identical. In case of an outer join these two row count will not be identical and to determine the number of rows output from the nested loops operation use the number of rows from the outer table minus throwaway before join: B - (B - D) = D (and remember that this is for an index unique scan on the inner table). July 2000 Page 17

18 For Oracle8i the throwaway can be calculated as: Throwaway from outer table (before join): Throwaway from outer table (during join): Throwaway from inner table (during join): Card(TABLE_O) - B B - A D - B - C Calculating throwaway, scenario 2 (inner table access via non-unique scan on index): Rows Execution plan A NESTED LOOPS B TABLE ACCESS (FULL) OF TABLE_O C TABLE ACCESS (BY INDEX ROWID) OF TABLE_I D INDEX ACCESS (RANGE SCAN) OF (NON-UNIQUE) For Oracle 7.3 and 8.0 the throwaway can be calculated as: Throwaway from outer table (before join): B - (D - C) Throwaway from outer table (during join): If B > A then: At least B - A Otherwise indeterminable Always 0 for outer joins Throwaway from inner table (during join): C - A For Oracle8i the throwaway can be calculated as: Throwaway from outer table (before join): Throwaway from outer table (during join): Throwaway from inner table (during join): Card(TABLE_O) - B If B > A then: At least B - A Otherwise indeterminable Always 0 for outer joins D - B - C Calculating throwaway, scenario 3 (inner table access using full table scan): Rows Execution plan A NESTED LOOPS B TABLE ACCESS (FULL) OF TABLE_O C TABLE ACCESS (FULL) OF TABLE_I For Oracle 7.3 and 8.0 the throwaway can be calculated as: Throwaway from outer table (before join): B - (C / Card(TABLE_I) ) Throwaway from outer table (during join): If B > A then: At least B - A Otherwise indeterminable Always 0 for outer joins Throwaway from inner table (during join): C - A July 2000 Page 18

19 For Oracle8i the throwaway can be calculated as: Throwaway from outer table (before join): Throwaway from outer table (during join): Throwaway from inner table (during join): Card(TABLE_O) - B If B > A then: At least B - A Otherwise indeterminable Always 0 for outer joins B * Card(TABLE_I) - A In most pratical cases of this particular scenario only the throwaway from the inner table is important. Above formulas takes following peculiarity in Oracle8i into account: All index scans (both unique and range scans) reports one row extra per lookup (in Oracle 7.3 and 8.0 this only happens for range scans). Calculating throwaway, generic scenario: Not all nested loops falls into above categories (especially when dealing with joins with one or both row sources not being table accesses) and it is necessary to be able to determine throwaway from a generic nested loops operations: Rows Execution plan A NESTED LOOPS B Outer Row Source C Inner Row Source For all versions of Oracle following pragmatic rule can be formulated: If A < B then the throwaway from the outer row source is AT LEAST: B - A If A < C then the throwaway from the inner row source is AT LEAST: C - A That C > A should only happen for Oracle 7.3 or 8.0 as Oracle8i reports the retrieved rows for both the inner row source and the nested loops - and this should not be different. Cure: If the join operation is part of a larger join with several join operations, please refer to the section 6. Secondary Throwaway. Throwaway from the outer table before the nested loops join operation can be cured using the same principles as for curing throwaway from a table access (indexed or full table scan). The cure for throwaway from the inner table is the same as for throwaway from a table access (indexed or full table scan). If the join operation is throwing rows from the outer table (and thereby subjecting this table access to secondary throwaway) this can only be counteracted by reversing the join order. July 2000 Page 19

20 Whether this reversal will indeed reduce the number of rows processed depends on the predicates on both the inner and the outer table.. Limitations: Change of join order can not always remove (join based) throwaway from the outer table. Removal of throwaway from the inner table and the the outer table (before the join) is subjected to same limitations as throwaway from a table access. July 2000 Page 20

21 5.7 Throwaway in row source: SORT/MERGE join operation In a sort merge join the non-join predicates are applied before the sort operations and will not cause throwaway from the join operation itself. Throwaway from a sort merge join can therefore only be introduced by rows from the first sort operation not matching rows from the second sort operation (resulting in throwaway from one or both inputs). As both row sources are retrieved and sorted before the merge operation any throwaway in the join operation (actually the merge operation) will imply secondary throwaway in one or both of the row sources. Calculating throwaway: Rows Execution plan A MERGE JOIN B SORT (JOIN) C TABLE ACCESS (FULL) OF TABLE_O D SORT (JOIN) E TABLE ACCESS (FULL) OF TABLE_I For Oracle 7.3 and 8.0 the throwaway can be calculated as: Throwaway from outer table (before join): Throwaway from outer table (during join): Throwaway from inner table (during join): C - B If C > A then: At least C - A Otherwise indeterminable Always 0 for outer joins E - D For Oracle8i the throwaway can be calculated as: Throwaway from outer table (before join): Throwaway from outer table (during join): Throwaway from inner table (during join): Card(TABLE_O) - C If C > A then: At least C - A Otherwise indeterminable Always 0 for outer joins E - D Cure: Only throwaway from one table can be cured and this is done by changing the join operation to a nested loops operation with the row source being subjected to throwaway as the inner table and at the same time ensure that all join and non-join predicates on this table can be evaluated using an index. Limitations: Changing a sort/merge join operation to a nested loops operation with fully indexed predicates on the inner table is not always possible - for example not all predicates are indexable. Furthermore a change from a sort/merge join to a nested loops operation with indexed inner table access will change the I/O pattern from multiblock reads to single block access (by going from full table scans to indexed lookups) which easily can result in more time spend waiting for I/O. July 2000 Page 21

22 5.8 Throwaway in row source: HASH JOIN operation The hash join will act as a sort merge join regarding throwaway, but as fewer row sources are involved there is less possibility to determine throwaway and to distinguish between throwaway introduced by non-join predicates and the join operation itself. As for the sort merge join operation both input row sources are retrieved before being matched in the join operation, meaning that both row sources can be subjected to secondary throwaway in the case where the hash join operation discards rows not matching. Calculating throwaway: Rows Execution plan A HASH JOIN B TABLE ACCESS (FULL) OF TABLE_O C TABLE ACCESS (FULL) OF TABLE_I For Oracle 7.3 and 8.0 tests have shown that the number of rows from the hash join operation (which for nested loops and sort merge join operations are equal to the number of rows output) is somewhat unprecisely defined. All tests has resulted in numbers that are larger than the rows output and depends on the size of the row sources and can not be used for a precise determination of throwaway from the join operation. For Oracle8i the throwaway can be calculated as: Throwaway from outer table (before join): Throwaway from outer table (during join): Throwaway from inner table (during join): Card(TABLE_O) - B If B > A then: At least B - A Otherwise indeterminable Always 0 for outer joins C - A Cure and limitations: see 5.7 Throwaway in row source: SORT/MERGE join operation July 2000 Page 22

23 5.9 Throwaway in row source: FILTER A filter row source filters rows from being output. The filter row source will not be used for simple predicates on tables but is used for more complex predicates - for example having clauses and subqueries. The filter row source always has the row source to be filtered as input (for later reference this row source will be called the primary input row source). Example: select * from courses crs where not exists (select X from classes cls where cls.crs_id = crs.crs_id) Rows Execution Plan FILTER 1019 TABLE ACCESS (FULL) OF 'COURSES' 1018 INDEX (RANGE SCAN) OF 'CLASS_CRS' (NON-UNIQUE) The primary row source to the filter operation is the full table scan of COURSES (this is the row source being filtered). The filtering can be done using one or more subqueries. These subqueries are secondary input row sources to the filter row source and are executed very much like the row retrieval from the inner table in a nested loops join operation. In above example the index range scan on CLASS_CRS is executed for each row in the primary row source to determine what rows should be filtered away. The filter row source will always introduce throwaway - except when it does not filter anything away. Another source of throwaway from filter operations is the number of rows from the secondary row sources (those used for filtering). It can be disputed whether these secondary row sources are thrown away (they do not appear in the output) or are just separate queries requering work to be evaluated. No matter what terms are used these secondary row sources represents work done - and has been seen on several occations to process a bigger number of rows than the primary query itself. Therefore a separate tuning effort on the secondary row sources can be beneficial. Calculating throwaway: The amount of throwaway can be found by determing how much smaller the output rows is than the number of rows from the primary input row source. In above example this results in a throwaway of 432 rows ( ). Cure: Often a change from a filter operation to a join can help. Limitations: The filter operation is often caused by the data model not being able to satisfy specific requirements, and to change the filter into a join or removing it often requires major changes in the application. July 2000 Page 23

24 6. Secondary Throwaway In more complex statements it becomes less and less simple to quantify the amount of secondary throwaway. Consider following example: Rows #1 Rows #2 Operation #1 Rows #3 Operation #2 Operation #3 Rows #4 Rows #5 Operation #4 Operation #5 If Operation #1 throws away rows from Operation #2 and thereby not only subjecting Operation #2, but also Operation #4 and Operation #5 to secondary throwaway, then it can be difficult to determine precisely how many rows from Operation #4 and Operation #5 have been thrown away. To adopt a pragmatic approach to quantify this secondary throwaway it is assumed that the secondary throwaway is distributed evenly across all the row sources contributing to the row source being subjected to primary throwaway and that the fraction of secondary throwaway equals the primary throwaway. This leads to following formula for calculating secondary throwaway: Primary Throwaway (fraction of input) * sum(rows in contributing row sources) Based on the above example the secondary throwaway generated by the primary throwaway in Operation #1 can then be quantified by: This leads to: Primary Throwaway: Rows #2 - Rows #1 Primary Throwaway fraction: (Rows #2 - Rows #1)/Rows #2 Sum(rows in contributing row sources): Rows #3 + Rows #4 + Rows #5 Secondary throwaway: (Rows #2 - Rows #1)/Rows #2 * (Rows #3 + Rows #4 + Rows #5) July 2000 Page 24

25 Curing secondary throwaway: The primary throwaway can be cured (if indeed it is possible to design a cure) by following the suggestions given for each type of row source. This however can not be used to reduce the amount of secondary throwaway. The simplest way to describe this is that the rows thrown away by secondary throwaway are generated already when they arrive to the row source introducing the primary throwaway. This means that the only cure for secondary throwaway is to move the row source generating the primary throwaway which in turn is responsible for the secondary throwaway to an earlier evaluation in the execution plan. In a sense this is what happens when an unindexed predicate is changed to be evaluated in an index lookup - which is an evaluation of the predicate before the table access previously having the primary throwaway. Limitations: It is not always feasible to change the execution plan to accommodate a reduction in secondary throwaway. An often seen consequence of moving a row source that generates throwaway to another position in the execution plan (with the purpose of reducing secondary throwaway) is that the row source no longer can limit the amount of rows as it needs information from the row sources now positioned later in the execution plan to fully limit the amount of rows. July 2000 Page 25

26 6.1 Example on calculating secondary throwaway To illustrate the concept of primary versus secondary throwaway consider following example that is based on a thought case with joins with throwaway: Id Rows Execution plan ) 10 NESTED LOOPS 2) NESTED LOOPS 3) NESTED LOOPS 4) 110 TABLE ACCESS (BY INDEX ROWID) OF <A> 5) 111 INDEX ACCESS (RANGE SCAN) OF 6) TABLE ACCESS (BY INDEX ROWID) OF <B> 7) INDEX ACCESS (RANGE SCAN) OF 8) TABLE ACCESS (BY INDEX ROWID) OF <C> 9) INDEX ACCESS (RANGE SCAN) OF 10) 10 TABLE ACCESS (BY INDEX ROWID) OF <D> 11) INDEX ACCESS (RANGE SCAN) OF To ease the interpretation of what the execution plan shows following graphical representation is helpful: 1) Nested Loops #3 10 3) Nested Loops # ) Nested Loops # ) Table <C> 10 10) Table <D> ) Index Range 110 4) Table <A> ) Table <B> ) Index Range 111 5) Index Range 7) Index Range First let s determine the amount of throwaway in the row sources (the primary throwaway). Assuming Oracle8i the throwaway can be determined using the descriptions found in 5.6 Throwaway in row source: NESTED LOOPS join operation. July 2000 Page 26

27 TA from table A before join: = 0 (all rows from index lookup is returned) TA from table A during join: Not determinable (Join #1 returns more rows than outer row source) TA from table B during join: = 0 TA from NL #1 before join: none (would have been applied earlier) TA from NL #1 during join: Not determinable (Join #2 returns more rows than outer row source) TA from table C during join: = 0 TA from NL #2 before join: none (would have been applied earlier) TA from NL #2 during join: At least = at least TA from table D during join: = 0 ( TA : ThrowAway ) The only row source subjected to significant (primary) throwaway is marked in bold. As it now has been determined that there is throwaway from a row source which is generated by the combined work of several other row sources these row sources are subjected to secondary throwaway. As the primary throwaway fraction is at least / = then according to above quantification of secondary throwaway at least the fraction of all the rows in the two first join operations, the three first table accesses (tables <A>, <B> and <C>) and the corresponding index accesses are thrown away. According to above formula the secondary throwaway can be calculated as: primary throwaway fraction * sum(rows in contributing row sources) = * sum(row sources 2, 3, 4, 5, 6, 7, 8 and 9) = * ( ) rows = rows This means that the total throwaway introduced in the last join operation is (at least): rows (primary throwaway) rows (secondary throwaway) = rows out of the total rows processed in the query, which equals a throwaway of 99.93% of all the rows processed. July 2000 Page 27

28 7. Tuning SQL Queries by Eliminating Throwaway As described in the beginning of this paper the core method of tuning a single query is as follows: 1. Analyze query 2. Suggest changes to improve performance 3. Implement changes 4. Test improvement 5. Repeat until goal reached By using identification and elimination of throwaway for analysis and suggested changes the method can be expanded: 1. Calculate throwaway (primary and secondary) for relevant row sources in the execution plan 2. Identify row sources that introduce a significant amount of throwaway 3. Map row sources to the part of the statement they correspond to and determine the predicates for relevant row sources 4. Suggest changes in execution plan to reduce secondary throwaway. This must be done by moving the row source to be evaluated earlier in the execution plan 5. If a row source is introducing primary throwaway (or will be expected to do so after reducing secondary throwaway) then analyze whether it is possible to reduce the amount of throwaway 6. Identify the means to change the existing execution plan into the proposed one 7. Implement changes 8. Verify that expected execution plan is obtained 9. Test improvement 10. Repeat until goal reached or all throwaway has been eliminated Re 1): The calculation of throwaway follows the formulas described for the different row sources (for primary throwaway) and for complex statements (for secondary throwaway). Re 2): A row source can be said to introduce a significant amount of throwaway if the total amount of throwaway (primary + secondary throwaway) generated by that particular row source is a significant part of all the rows processed within the statement. Re 3): This part will not be described in sufficient detail to solve all possible scenarios in this version of the paper. The meaning of the step is to take the all row sources in the execution plan and then identify what part of the statement these row sources correspond to (: what part of the statement the row source is solving). It could be argued that only the relevant row sources needs to be mapped to the statement, but in practise this limitation will invariably lead to mistakes - especially when dealing with complex statements. It is normally straight forward to map row sources to the statement when the statement only addresses each table once, but in the cases where the same table is referenced several times in the statement (including views) it can be a challenge to identify exactly where a particular table access row source belongs in the statement. July 2000 Page 28

29 The interesting part of this mapping is the mapping of what predicates are in action for what row source. This might seem trivial, but consider following simple join: select cls.start_date, crs.short_name from classes cls, courses crs where cls.instr_id = crs.dev_id and cls.status = AVAI and crs.cat_id = 34; If the execution plan for above statement looks like: Execution plan NESTED LOOPS TABLE ACCESS (BY INDEX ROWID) OF CLASSES INDEX ACCESS (RANGE SCAN) OF TABLE ACCESS (BY INDEX ROWID) OF COURSES INDEX ACCESS (RANGE SCAN) OF Then the join order would be CLASSES - COURSES and the predicates for CLASSES and COURSES would be: CLASSES: status = AVAI COURSES: dev_id = <cls.instr_id> cat_id = 34 If on the other hand the join order is COURSES - CLASSES then the predicates for CLASSES and COURSES would be: COURSES: cat_id = 34 CLASSES: instr_id = <crs.dev_id> status = AVAI Above demonstrates that the predicates and therefore the optimal indexes (for eliminating primary throwaway) will depend on the join order and that focus on the predicates is important. Re 4): Secondary throwaway - which is often seen to play the biggest part in work wasted by throwaway in complex joins - needs as described above changes in the execution plan so that the row source introducing the (primary) throwaway is evaluated earlier in the execution plan. Moving a row source to an earlier evaluation in the execution plan will in most cases also change the predicates for that particular row source and potentially all other row sources between the old and the new position in the execution plan. Changing the predicates for a row source has a direct influence on the ability of the row source to throw rows away. A prerequisite for reducing secondary throwaway by moving the row source with the primary throwaway is that this row source is still capable of throwing rows away after having been moved to the new position in the execution plan. A second prerequsite is that the row sources having previously being subjected to secondary throwaway has predicates that after the change in execution plan can limit the number of rows processed. An other way of stating this second prerequsite is that there must be some predicates connecting the row source introducing the primary throwaway and the row source(s) subjected to secondary July 2000 Page 29

30 throwaway and that these predicates by being reversed by the proposed change in the execution plan can actually limit the number of rows processed in the row source(s) originally subjected to secondary throwaway. Therefore it is necessary to evaluate what predicates are available after the proposed change in execution plan for the both the row source introducing the primary throwaway and the row source(s) subjected to secondary throwaway. This is a partial repetition of step 3, but using the new order of evaluation in the execution plan. Re 5): As primary throwaway is local to one row source it is rather straight forward to verify if there is a cure available and what means can be used to implement the cure. The local nature of primary throwaway also makes it more likely that the cure can be implemented without side-effects in other parts of the execution plan which has the pleasant consequence of easing testing. Re 6) The means to implement the wanted execution plan includes: Creation of indexes Adding/changing hints (for specifying join execution plans the ORDERED, USE_NL, USE_HASH and INDEX hints often are quite usefull) Changing optimizer mode Changing other parameters influencing the optimizer Changing statistics Changing the where clause (for example: forcing join order by disabling index usage under the Rule Based Optimizer) Changing the statement to allow other access paths Changing table definitions (for example by changing a NULL column to NOT NULL in order to allow anti-join optimization) Re 8) It is recommended that the expected execution plan is verified before testing the result - especially if there is a possibility of getting long response times. For this purpose the AUTOTRACE TRACE EXPLAIN setting in SQL*Plus (which only outputs the execution plan) is sufficient and rather easy to use. Re 9) The actual test should be performed using SQL trace as this will verify that the expected elimination of throwaway has been successfull. July 2000 Page 30