Query tuning by eliminating throwaway
|
|
- Ralf Rich
- 7 years ago
- Views:
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
Oracle Database 11g: SQL Tuning Workshop
Oracle University Contact Us: + 38516306373 Oracle Database 11g: SQL Tuning Workshop Duration: 3 Days What you will learn This Oracle Database 11g: SQL Tuning Workshop Release 2 training assists database
More informationOracle Database 11g: SQL Tuning Workshop Release 2
Oracle University Contact Us: 1 800 005 453 Oracle Database 11g: SQL Tuning Workshop Release 2 Duration: 3 Days What you will learn This course assists database developers, DBAs, and SQL developers to
More informationAdvanced Oracle SQL Tuning
Advanced Oracle SQL Tuning Seminar content technical details 1) Understanding Execution Plans In this part you will learn how exactly Oracle executes SQL execution plans. Instead of describing on PowerPoint
More informationChapter 9 Joining Data from Multiple Tables. Oracle 10g: SQL
Chapter 9 Joining Data from Multiple Tables Oracle 10g: SQL Objectives Identify a Cartesian join Create an equality join using the WHERE clause Create an equality join using the JOIN keyword Create a non-equality
More informationD B M G Data Base and Data Mining Group of Politecnico di Torino
Database Management Data Base and Data Mining Group of tania.cerquitelli@polito.it A.A. 2014-2015 Optimizer objective A SQL statement can be executed in many different ways The query optimizer determines
More informationOracle Database: SQL and PL/SQL Fundamentals
Oracle University Contact Us: +966 12 739 894 Oracle Database: SQL and PL/SQL Fundamentals Duration: 5 Days What you will learn This Oracle Database: SQL and PL/SQL Fundamentals training is designed to
More informationChapter 13: Query Processing. Basic Steps in Query Processing
Chapter 13: Query Processing! Overview! Measures of Query Cost! Selection Operation! Sorting! Join Operation! Other Operations! Evaluation of Expressions 13.1 Basic Steps in Query Processing 1. Parsing
More informationSQL Server Query Tuning
SQL Server Query Tuning Klaus Aschenbrenner Independent SQL Server Consultant SQLpassion.at Twitter: @Aschenbrenner About me Independent SQL Server Consultant International Speaker, Author Pro SQL Server
More informationAn Oracle White Paper May 2011. The Oracle Optimizer Explain the Explain Plan
An Oracle White Paper May 2011 The Oracle Optimizer Explain the Explain Plan Introduction... 1 The Execution Plan... 2 Displaying the Execution plan... 3 What is Cost... 8 Understanding the execution plan...
More informationTune That SQL for Supercharged DB2 Performance! Craig S. Mullins, Corporate Technologist, NEON Enterprise Software, Inc.
Tune That SQL for Supercharged DB2 Performance! Craig S. Mullins, Corporate Technologist, NEON Enterprise Software, Inc. Table of Contents Overview...................................................................................
More informationSQL Query Evaluation. Winter 2006-2007 Lecture 23
SQL Query Evaluation Winter 2006-2007 Lecture 23 SQL Query Processing Databases go through three steps: Parse SQL into an execution plan Optimize the execution plan Evaluate the optimized plan Execution
More information1Z0-117 Oracle Database 11g Release 2: SQL Tuning. Oracle
1Z0-117 Oracle Database 11g Release 2: SQL Tuning Oracle To purchase Full version of Practice exam click below; http://www.certshome.com/1z0-117-practice-test.html FOR Oracle 1Z0-117 Exam Candidates We
More informationOracle Database 10g: Introduction to SQL
Oracle University Contact Us: 1.800.529.0165 Oracle Database 10g: Introduction to SQL Duration: 5 Days What you will learn This course offers students an introduction to Oracle Database 10g database technology.
More informationGuide to Performance and Tuning: Query Performance and Sampled Selectivity
Guide to Performance and Tuning: Query Performance and Sampled Selectivity A feature of Oracle Rdb By Claude Proteau Oracle Rdb Relational Technology Group Oracle Corporation 1 Oracle Rdb Journal Sampled
More informationICAB4136B Use structured query language to create database structures and manipulate data
ICAB4136B Use structured query language to create database structures and manipulate data Release: 1 ICAB4136B Use structured query language to create database structures and manipulate data Modification
More informationOracle Database: SQL and PL/SQL Fundamentals NEW
Oracle University Contact Us: 001-855-844-3881 & 001-800-514-06-97 Oracle Database: SQL and PL/SQL Fundamentals NEW Duration: 5 Days What you will learn This Oracle Database: SQL and PL/SQL Fundamentals
More informationPartitioning under the hood in MySQL 5.5
Partitioning under the hood in MySQL 5.5 Mattias Jonsson, Partitioning developer Mikael Ronström, Partitioning author Who are we? Mikael is a founder of the technology behind NDB
More informationSQL Query Performance Tuning: Tips and Best Practices
SQL Query Performance Tuning: Tips and Best Practices Pravasini Priyanka, Principal Test Engineer, Progress Software INTRODUCTION: In present day world, where dozens of complex queries are run on databases
More informationOracle SQL. Course Summary. Duration. Objectives
Oracle SQL Course Summary Identify the major structural components of the Oracle Database 11g Create reports of aggregated data Write SELECT statements that include queries Retrieve row and column data
More informationOracle EXAM - 1Z0-117. Oracle Database 11g Release 2: SQL Tuning. Buy Full Product. http://www.examskey.com/1z0-117.html
Oracle EXAM - 1Z0-117 Oracle Database 11g Release 2: SQL Tuning Buy Full Product http://www.examskey.com/1z0-117.html Examskey Oracle 1Z0-117 exam demo product is here for you to test the quality of the
More informationOracle Database: SQL and PL/SQL Fundamentals
Oracle University Contact Us: 1.800.529.0165 Oracle Database: SQL and PL/SQL Fundamentals Duration: 5 Days What you will learn This course is designed to deliver the fundamentals of SQL and PL/SQL along
More informationOracle Database 12c: Introduction to SQL Ed 1.1
Oracle University Contact Us: 1.800.529.0165 Oracle Database 12c: Introduction to SQL Ed 1.1 Duration: 5 Days What you will learn This Oracle Database: Introduction to SQL training helps you write subqueries,
More informationOracle Database: SQL and PL/SQL Fundamentals NEW
Oracle University Contact Us: + 38516306373 Oracle Database: SQL and PL/SQL Fundamentals NEW Duration: 5 Days What you will learn This Oracle Database: SQL and PL/SQL Fundamentals training delivers the
More informationSQL Server Query Tuning
SQL Server Query Tuning A 12-Step Program By Thomas LaRock, Technical Evangelist and Head Geek Confio Software 4772 Walnut Street, Suite 100 Boulder, CO 80301 www.confio.com Introduction Query tuning is
More informationUseful Business Analytics SQL operators and more Ajaykumar Gupte IBM
Useful Business Analytics SQL operators and more Ajaykumar Gupte IBM 1 Acknowledgements and Disclaimers Availability. References in this presentation to IBM products, programs, or services do not imply
More informationPerformance Tuning for the Teradata Database
Performance Tuning for the Teradata Database Matthew W Froemsdorf Teradata Partner Engineering and Technical Consulting - i - Document Changes Rev. Date Section Comment 1.0 2010-10-26 All Initial document
More informationDuration Vendor Audience 5 Days Oracle End Users, Developers, Technical Consultants and Support Staff
D80198GC10 Oracle Database 12c SQL and Fundamentals Summary Duration Vendor Audience 5 Days Oracle End Users, Developers, Technical Consultants and Support Staff Level Professional Delivery Method Instructor-led
More informationIn this session, we use the table ZZTELE with approx. 115,000 records for the examples. The primary key is defined on the columns NAME,VORNAME,STR
1 2 2 3 In this session, we use the table ZZTELE with approx. 115,000 records for the examples. The primary key is defined on the columns NAME,VORNAME,STR The uniqueness of the primary key ensures that
More informationInside the PostgreSQL Query Optimizer
Inside the PostgreSQL Query Optimizer Neil Conway neilc@samurai.com Fujitsu Australia Software Technology PostgreSQL Query Optimizer Internals p. 1 Outline Introduction to query optimization Outline of
More informationExecution Plans: The Secret to Query Tuning Success. MagicPASS January 2015
Execution Plans: The Secret to Query Tuning Success MagicPASS January 2015 Jes Schultz Borland plan? The following steps are being taken Parsing Compiling Optimizing In the optimizing phase An execution
More informationDatabase Programming with PL/SQL: Learning Objectives
Database Programming with PL/SQL: Learning Objectives This course covers PL/SQL, a procedural language extension to SQL. Through an innovative project-based approach, students learn procedural logic constructs
More informationMOC 20461C: Querying Microsoft SQL Server. Course Overview
MOC 20461C: Querying Microsoft SQL Server Course Overview This course provides students with the knowledge and skills to query Microsoft SQL Server. Students will learn about T-SQL querying, SQL Server
More informationIntroduction to Querying & Reporting with SQL Server
1800 ULEARN (853 276) www.ddls.com.au Introduction to Querying & Reporting with SQL Server Length 5 days Price $4169.00 (inc GST) Overview This five-day instructor led course provides students with the
More informationDisplaying Data from Multiple Tables. Copyright 2006, Oracle. All rights reserved.
Displaying Data from Multiple Tables Objectives After completing this lesson, you should be able to do the following: Write SELECT statements to access data from more than one table using equijoins and
More informationBest Practices for DB2 on z/os Performance
Best Practices for DB2 on z/os Performance A Guideline to Achieving Best Performance with DB2 Susan Lawson and Dan Luksetich www.db2expert.com and BMC Software September 2008 www.bmc.com Contacting BMC
More informationFirst, here are our three tables in a fictional sales application:
Introduction to Oracle SQL Tuning Bobby Durrett Introduction Tuning a SQL statement means making the SQL query run as fast as you need it to. In many cases this means taking a long running query and reducing
More informationLive Event Count Issue
Appendix 3 Live Event Document Version 1.0 Table of Contents 1 Introduction and High Level Summary... 3 2 Details of the Issue... 4 3 Timeline of Technical Activities... 6 4 Investigation on Count Day
More informationD B M G Data Base and Data Mining Group of Politecnico di Torino
Politecnico di Torino Database Management System Oracle Hints Data Base and Data Mining Group of Politecnico di Torino Tania Cerquitelli Computer Engineering, 2014-2015, slides by Tania Cerquitelli and
More informationIB Math Research Problem
Vincent Chu Block F IB Math Research Problem The product of all factors of 2000 can be found using several methods. One of the methods I employed in the beginning is a primitive one I wrote a computer
More informationBusiness Application
137 Germain CRT Validation Rules for Siebel CRM 7.7,7.8,8.0,8.1,8.2 Validation Rule Name Validation Rule Description Business Application Siebel Repository Level Improve CPU Improve Memory GS-SBL-REP-JDBC-1001
More informationPeopleSoft Query Training
PeopleSoft Query Training Overview Guide Tanya Harris & Alfred Karam Publish Date - 3/16/2011 Chapter: Introduction Table of Contents Introduction... 4 Navigation of Queries... 4 Query Manager... 6 Query
More informationC H A P T E R 1 Introducing Data Relationships, Techniques for Data Manipulation, and Access Methods
C H A P T E R 1 Introducing Data Relationships, Techniques for Data Manipulation, and Access Methods Overview 1 Determining Data Relationships 1 Understanding the Methods for Combining SAS Data Sets 3
More informationa presentation by Kirk Paul Lafler SAS Consultant, Author, and Trainer E-mail: KirkLafler@cs.com
a presentation by Kirk Paul Lafler SAS Consultant, Author, and Trainer E-mail: KirkLafler@cs.com 1 Copyright Kirk Paul Lafler, 1992-2010. All rights reserved. SAS is the registered trademark of SAS Institute
More informationRelational Databases
Relational Databases Jan Chomicki University at Buffalo Jan Chomicki () Relational databases 1 / 18 Relational data model Domain domain: predefined set of atomic values: integers, strings,... every attribute
More information3.GETTING STARTED WITH ORACLE8i
Oracle For Beginners Page : 1 3.GETTING STARTED WITH ORACLE8i Creating a table Datatypes Displaying table definition using DESCRIBE Inserting rows into a table Selecting rows from a table Editing SQL buffer
More information(Refer Slide Time: 2:03)
Control Engineering Prof. Madan Gopal Department of Electrical Engineering Indian Institute of Technology, Delhi Lecture - 11 Models of Industrial Control Devices and Systems (Contd.) Last time we were
More informationExecution Strategies for SQL Subqueries
Execution Strategies for SQL Subqueries Mostafa Elhemali, César Galindo- Legaria, Torsten Grabs, Milind Joshi Microsoft Corp With additional slides from material in paper, added by S. Sudarshan 1 Motivation
More informationPrograma de Actualización Profesional ACTI Oracle Database 11g: SQL Tuning Workshop
Programa de Actualización Profesional ACTI Oracle Database 11g: SQL Tuning Workshop What you will learn This Oracle Database 11g SQL Tuning Workshop training is a DBA-centric course that teaches you how
More information3. Mathematical Induction
3. MATHEMATICAL INDUCTION 83 3. Mathematical Induction 3.1. First Principle of Mathematical Induction. Let P (n) be a predicate with domain of discourse (over) the natural numbers N = {0, 1,,...}. If (1)
More informationOracle Database: Develop PL/SQL Program Units
Oracle University Contact Us: 1.800.529.0165 Oracle Database: Develop PL/SQL Program Units Duration: 3 Days What you will learn This Oracle Database: Develop PL/SQL Program Units course is designed for
More informationEvaluation of view maintenance with complex joins in a data warehouse environment (HS-IDA-MD-02-301)
Evaluation of view maintenance with complex joins in a data warehouse environment (HS-IDA-MD-02-301) Kjartan Asthorsson (kjarri@kjarri.net) Department of Computer Science Högskolan i Skövde, Box 408 SE-54128
More informationTemperature Scales. The metric system that we are now using includes a unit that is specific for the representation of measured temperatures.
Temperature Scales INTRODUCTION The metric system that we are now using includes a unit that is specific for the representation of measured temperatures. The unit of temperature in the metric system is
More informationCourse 20461C: Querying Microsoft SQL Server Duration: 35 hours
Course 20461C: Querying Microsoft SQL Server Duration: 35 hours About this Course This course is the foundation for all SQL Server-related disciplines; namely, Database Administration, Database Development
More informationOracle Database 11g SQL
AO3 - Version: 2 19 June 2016 Oracle Database 11g SQL Oracle Database 11g SQL AO3 - Version: 2 3 days Course Description: This course provides the essential SQL skills that allow developers to write queries
More informationUnderstanding SQL Server Execution Plans. Klaus Aschenbrenner Independent SQL Server Consultant SQLpassion.at Twitter: @Aschenbrenner
Understanding SQL Server Execution Plans Klaus Aschenbrenner Independent SQL Server Consultant SQLpassion.at Twitter: @Aschenbrenner About me Independent SQL Server Consultant International Speaker, Author
More informationQuery Processing C H A P T E R12. Practice Exercises
C H A P T E R12 Query Processing Practice Exercises 12.1 Assume (for simplicity in this exercise) that only one tuple fits in a block and memory holds at most 3 blocks. Show the runs created on each pass
More informationOracle Database: Introduction to SQL
Oracle University Contact Us: 1.800.529.0165 Oracle Database: Introduction to SQL Duration: 5 Days What you will learn This Oracle Database: Introduction to SQL training teaches you how to write subqueries,
More informationQuerying Microsoft SQL Server 2012
Course 10774A: Querying Microsoft SQL Server 2012 Length: 5 Days Language(s): English Audience(s): IT Professionals Level: 200 Technology: Microsoft SQL Server 2012 Type: Course Delivery Method: Instructor-led
More informationCourse ID#: 1401-801-14-W 35 Hrs. Course Content
Course Content Course Description: This 5-day instructor led course provides students with the technical skills required to write basic Transact- SQL queries for Microsoft SQL Server 2014. This course
More information50439B: Basics of Transact SQL with SQL Server 2008 R2
50439B: Basics of Transact SQL with SQL Server 2008 R2 Duration: 3 days Class Description This instructor-led course provides students with the necessary knowledge to work with the data in SQL Server 2008R2.
More informationCourse 10774A: Querying Microsoft SQL Server 2012 Length: 5 Days Published: May 25, 2012 Language(s): English Audience(s): IT Professionals
Course 10774A: Querying Microsoft SQL Server 2012 Length: 5 Days Published: May 25, 2012 Language(s): English Audience(s): IT Professionals Overview About this Course Level: 200 Technology: Microsoft SQL
More informationCourse 10774A: Querying Microsoft SQL Server 2012
Course 10774A: Querying Microsoft SQL Server 2012 About this Course This 5-day instructor led course provides students with the technical skills required to write basic Transact-SQL queries for Microsoft
More informationUniversity of Aarhus. Databases 2009. 2009 IBM Corporation
University of Aarhus Databases 2009 Kirsten Ann Larsen What is good performance? Elapsed time End-to-end In DB2 Resource consumption CPU I/O Memory Locks Elapsed time = Sync. I/O + CPU + wait time I/O
More informationPerformance rule violations usually result in increased CPU or I/O, time to fix the mistake, and ultimately, a cost to the business unit.
Is your database application experiencing poor response time, scalability problems, and too many deadlocks or poor application performance? One or a combination of zparms, database design and application
More informationQuerying Microsoft SQL Server 20461C; 5 days
Lincoln Land Community College Capital City Training Center 130 West Mason Springfield, IL 62702 217-782-7436 www.llcc.edu/cctc Querying Microsoft SQL Server 20461C; 5 days Course Description This 5-day
More informationPart 1 Expressions, Equations, and Inequalities: Simplifying and Solving
Section 7 Algebraic Manipulations and Solving Part 1 Expressions, Equations, and Inequalities: Simplifying and Solving Before launching into the mathematics, let s take a moment to talk about the words
More informationEffective Use of SQL in SAS Programming
INTRODUCTION Effective Use of SQL in SAS Programming Yi Zhao Merck & Co. Inc., Upper Gwynedd, Pennsylvania Structured Query Language (SQL) is a data manipulation tool of which many SAS programmers are
More informationALGEBRA. sequence, term, nth term, consecutive, rule, relationship, generate, predict, continue increase, decrease finite, infinite
ALGEBRA Pupils should be taught to: Generate and describe sequences As outcomes, Year 7 pupils should, for example: Use, read and write, spelling correctly: sequence, term, nth term, consecutive, rule,
More informationThe Taxman Game. Robert K. Moniot September 5, 2003
The Taxman Game Robert K. Moniot September 5, 2003 1 Introduction Want to know how to beat the taxman? Legally, that is? Read on, and we will explore this cute little mathematical game. The taxman game
More informationQuerying Microsoft SQL Server 2012
Querying Microsoft SQL Server 2012 Duration: 5 Days Course Code: M10774 Overview: Deze cursus wordt vanaf 1 juli vervangen door cursus M20461 Querying Microsoft SQL Server. This course will be replaced
More informationOracle DBA Course Contents
Oracle DBA Course Contents Overview of Oracle DBA tasks: Oracle as a flexible, complex & robust RDBMS The evolution of hardware and the relation to Oracle Different DBA job roles(vp of DBA, developer DBA,production
More information2Creating Reports: Basic Techniques. Chapter
2Chapter 2Creating Reports: Chapter Basic Techniques Just as you must first determine the appropriate connection type before accessing your data, you will also want to determine the report type best suited
More informationOracle Database 10g: New Features for Administrators
Oracle Database 10g: New Features for Administrators Course ON10G 5 Day(s) 30:00 Hours Introduction This course introduces students to the new features in Oracle Database 10g Release 2 - the database for
More informationUnderstanding Query Processing and Query Plans in SQL Server. Craig Freedman Software Design Engineer Microsoft SQL Server
Understanding Query Processing and Query Plans in SQL Server Craig Freedman Software Design Engineer Microsoft SQL Server Outline SQL Server engine architecture Query execution overview Showplan Common
More informationProgramming with SQL
Unit 43: Programming with SQL Learning Outcomes A candidate following a programme of learning leading to this unit will be able to: Create queries to retrieve information from relational databases using
More informationRegistry Tuner. Software Manual
Registry Tuner Software Manual Table of Contents Introduction 1 System Requirements 2 Frequently Asked Questions 3 Using the Lavasoft Registry Tuner 5 Scan and Fix Registry Errors 7 Optimize Registry
More informationOracle Database: Introduction to SQL
Oracle University Contact Us: +381 11 2016811 Oracle Database: Introduction to SQL Duration: 5 Days What you will learn Understanding the basic concepts of relational databases ensure refined code by developers.
More informationOracle Database 11 g Performance Tuning. Recipes. Sam R. Alapati Darl Kuhn Bill Padfield. Apress*
Oracle Database 11 g Performance Tuning Recipes Sam R. Alapati Darl Kuhn Bill Padfield Apress* Contents About the Authors About the Technical Reviewer Acknowledgments xvi xvii xviii Chapter 1: Optimizing
More information5. CHANGING STRUCTURE AND DATA
Oracle For Beginners Page : 1 5. CHANGING STRUCTURE AND DATA Altering the structure of a table Dropping a table Manipulating data Transaction Locking Read Consistency Summary Exercises Altering the structure
More informationOracle9i Data Warehouse Review. Robert F. Edwards Dulcian, Inc.
Oracle9i Data Warehouse Review Robert F. Edwards Dulcian, Inc. Agenda Oracle9i Server OLAP Server Analytical SQL Data Mining ETL Warehouse Builder 3i Oracle 9i Server Overview 9i Server = Data Warehouse
More information1.6 The Order of Operations
1.6 The Order of Operations Contents: Operations Grouping Symbols The Order of Operations Exponents and Negative Numbers Negative Square Roots Square Root of a Negative Number Order of Operations and Negative
More informationSQL Performance for a Big Data 22 Billion row data warehouse
SQL Performance for a Big Data Billion row data warehouse Dave Beulke dave @ d a v e b e u l k e.com Dave Beulke & Associates Session: F19 Friday May 8, 15 8: 9: Platform: z/os D a v e @ d a v e b e u
More informationOptimizing Performance. Training Division New Delhi
Optimizing Performance Training Division New Delhi Performance tuning : Goals Minimize the response time for each query Maximize the throughput of the entire database server by minimizing network traffic,
More informationPaper TU_09. Proc SQL Tips and Techniques - How to get the most out of your queries
Paper TU_09 Proc SQL Tips and Techniques - How to get the most out of your queries Kevin McGowan, Constella Group, Durham, NC Brian Spruell, Constella Group, Durham, NC Abstract: Proc SQL is a powerful
More informationHandling customer returns in Microsoft Dynamics AX 2009
Microsoft Dynamics AX 2009 Handling customer returns in Microsoft Dynamics AX 2009 White Paper This paper describes the dedicated module for handling customer returns that was introduced in Microsoft Dynamics
More informationJet Data Manager 2012 User Guide
Jet Data Manager 2012 User Guide Welcome This documentation provides descriptions of the concepts and features of the Jet Data Manager and how to use with them. With the Jet Data Manager you can transform
More informationDBMS / Business Intelligence, SQL Server
DBMS / Business Intelligence, SQL Server Orsys, with 30 years of experience, is providing high quality, independant State of the Art seminars and hands-on courses corresponding to the needs of IT professionals.
More informationSolving Rational Equations
Lesson M Lesson : Student Outcomes Students solve rational equations, monitoring for the creation of extraneous solutions. Lesson Notes In the preceding lessons, students learned to add, subtract, multiply,
More informationCourse -Oracle 10g SQL (Exam Code IZ0-047) Session number Module Topics 1 Retrieving Data Using the SQL SELECT Statement
Course -Oracle 10g SQL (Exam Code IZ0-047) Session number Module Topics 1 Retrieving Data Using the SQL SELECT Statement List the capabilities of SQL SELECT statements Execute a basic SELECT statement
More informationUnit 1 Number Sense. In this unit, students will study repeating decimals, percents, fractions, decimals, and proportions.
Unit 1 Number Sense In this unit, students will study repeating decimals, percents, fractions, decimals, and proportions. BLM Three Types of Percent Problems (p L-34) is a summary BLM for the material
More informationBasics of Dimensional Modeling
Basics of Dimensional Modeling Data warehouse and OLAP tools are based on a dimensional data model. A dimensional model is based on dimensions, facts, cubes, and schemas such as star and snowflake. Dimensional
More informationCATIA V5 Surface Design
CATIA V5 Training Foils CATIA V5 Surface Design Version 5 Release 19 August 2008 EDU_CAT_EN_V5S_FI_V5R19 1 Lesson 1: Introduction to Generative Shape Design About this Course Introduction CATIA is a robust
More informationOracle 10g PL/SQL Training
Oracle 10g PL/SQL Training Course Number: ORCL PS01 Length: 3 Day(s) Certification Exam This course will help you prepare for the following exams: 1Z0 042 1Z0 043 Course Overview PL/SQL is Oracle's Procedural
More informationAV-005: Administering and Implementing a Data Warehouse with SQL Server 2014
AV-005: Administering and Implementing a Data Warehouse with SQL Server 2014 Career Details Duration 105 hours Prerequisites This career requires that you meet the following prerequisites: Working knowledge
More informationLecture 6: Query optimization, query tuning. Rasmus Pagh
Lecture 6: Query optimization, query tuning Rasmus Pagh 1 Today s lecture Only one session (10-13) Query optimization: Overview of query evaluation Estimating sizes of intermediate results A typical query
More informationSAP Business Objects Business Intelligence platform Document Version: 4.1 Support Package 7 2015-11-24. Data Federation Administration Tool Guide
SAP Business Objects Business Intelligence platform Document Version: 4.1 Support Package 7 2015-11-24 Data Federation Administration Tool Guide Content 1 What's new in the.... 5 2 Introduction to administration
More informationIntroduction to SQL Tuning. 1. Introduction to SQL Tuning. 2001 SkillBuilders, Inc. SKILLBUILDERS
Page 1 1. Introduction to SQL Tuning SKILLBUILDERS Page 2 1.2 Objectives Understand what can be tuned Understand what we need to know in order to tune SQL Page 3 1.3 What Can Be Tuned? Data Access SQL
More informationBuilding a Hybrid Data Warehouse Model
Page 1 of 13 Developer: Business Intelligence Building a Hybrid Data Warehouse Model by James Madison DOWNLOAD Oracle Database Sample Code TAGS datawarehousing, bi, All As suggested by this reference implementation,
More informationFallacies of the Cost Based Optimizer
Fallacies of the Cost Based Optimizer Wolfgang Breitling breitliw@centrexcc.com Who am I Independent consultant since 1996 specializing in Oracle and Peoplesoft setup, administration, and performance tuning
More informationQuerying Microsoft SQL Server Course M20461 5 Day(s) 30:00 Hours
Área de formação Plataforma e Tecnologias de Informação Querying Microsoft SQL Introduction This 5-day instructor led course provides students with the technical skills required to write basic Transact-SQL
More information