Optimising through Understanding Presented By: Oracle University Optimising through Understanding Push_subq.sql and (especially) no_push_subq.sql Some subqueries in 9i will not unnest, but will push. C_ordered for tables Cost permutations.sql Gets unnest in 10g, semijoin, right semi We are going to examine variations of a single query, involving a couple of subqueries, to help us understand the what Oracle can do with a query, what it can’t do, and how we can determine what we want it to do. Who am I ? Before we begin, I’ll just give you a brief introduction to who I am. Highlights Over the course of the next hour, we are going to start with the basic framework of a complex query, and gradually take it apart looking at different optimizer options in isolation. Once we’ve done that, we can put the query back together and examine the optimizer’s basic strategy, and what this means in terms of what is and is not possible. Finally we note that the “best” execution path may be one that we choose because we have a solid understanding of the data. We may even decide on an execution path that the optimizer is literally unable to produce unaided. Template SQL: So this is the basic structure of our query. We have a simple join between two tables, with some simple filter conditions on both tables, and two subqueries, one operating against each table. In it’s most general form, the predicates could be combined with a mixture of Ands and ORs; the subqueries could be INs, EXISTS, or their negation; or could simple be atithmetic comparisons on correlated, or non-correlated subqueries. Example Here, to make the general structure more concrete, is an example with a couple of simple correlated existence tests. We could imagine all sorts of ways in which the optimizer (or we) might choose to operate this query to get the result set with the minimum amount of work. Before we look at the whole thing, though, let’s take parts of it in isolation. Use of qb_name() We’ll start with a 10g feature – the qb_name() hint. Every single query block (roughly speaking every subquery) in a SQL statement can be given a name with the qb_name() hint. Once a query block has been named, we can make references to object in that query block from higher levels of the statement in the hints that we write. Every hint (probably) can have a new ‘first parameter’ which is the name of the query block to which it applies. The name has to be preceded with the @ sign. Tables can then be qualified with the query block name (again with the @ sign) . In this example, you’ll also notice the enhanced version of the leading() hint in 10g – you can specify every table in the query in the right order, and if there is a legal way to get to that order, Oracle will use it as the single join order it examines to optimize the query. We haven’t included t4 in the leading() hint because it is set to “not unnest” and. So it is going to run as a late subquery. Effect of @qb_name Here’s the execution plan for our original query with the leading() hint from the previous slide included. leading(t1@main, t3@main, t2@subq2) Note that the order is t1, t3, then t2 with a semi-join, and t4 (no_unnest) as a filter. One of the options for dbms_xplan.display() allows use to see table aliases and query block names – so we can see that we have a transformed block of three tables, plus one block which has not been transformed. (Could we use no_query_transformation(@subq4) ? YES !! Semi-join: Let’s go back to the transformations available for a single subquery). In this case we could have a small volume of data in t1 that can be accessed very efficiently by an index on n2; and an efficient access path to find the corresponding rows in t2. So Oracle converts the query into a nested loop join – stopping at the first success at t2 for every row it hits on t1. Unnesting: But if there is no efficient access path into t2, the plan has to change. It could become a hash semi-join into t2. However, we have an independent predicate on t2 that returns a few rows very efficiently, and we have an efficient way of getting into t1 based on the value of n1. So the optimizer can generate a unique set of values from t2, then use those as the outer table in a nested loop join into t1. Access subquery: In this case (which uses a completely different table structure) we have a unique index on (id_parent, id_child), and we are doing a classic: “most recent of” query. The subquery is executed first, and the single result is used as an access predicate to allow Oracle a unique access into a unique index. Filter subquery: In this case, because of the OR clause, the optimizer cannot unnest the subquery – it has to pick up all the rows where n2 between 100 and 200, but also has to examine every other row in the table to check the subquery. In principle, Oracle will run the subquery once for EVERY single row in the table (except the ones that have already passed the n2 test). Subquery with OR: Sometimes you just write the unnest manually. In this case we use OR expansion (not yet implemented) to get two non-colliding results. Watch out for NULL effects. (Scalar) Subquery caching: There is some aid from the problem of running a filter subquery for every row in the table. A feature (from 8.0) known as scalar subquery caching. In general it is quite good to go for unnesting, because filter subqueries are unpredictable due to the hash algorithm used for caching. How many times could this run ? Min 6, max 20,000. Response time 0.01 -> 150 seconds CPU. A small change in the actual data (a rogue value appearing) could make a massive difference in the number of times the query runs. In 8i and 9i you get 256 values in the hash table. In 10g you get seem to get 1024 for numbers, but the table size is limited to 64KB in 10g, which means problems for unconstrained text values which deemed to be 4,000 bytes each. Demo (Scalar) Subquery caching: There is some aid from the problem of running a filter subquery for every row in the table. A feature (from 8.0) known as scalar subquery caching. In general it is quite good to go for unnesting, because filter subqueries are unpredictable due to the hash algorithm used for caching. How many times could this run ? Min 6, max 20,000. Response time 0.01 -> 150 seconds CPU. A small change in the actual data (a rogue value appearing) could make a massive difference in the number of times the query runs. In 8i and 9i you get 256 values in the hash table. In 10g you get seem to get 1024 for numbers, but the table size is limited to 64KB in 10g, which means problems for unconstrained text values which deemed to be 4,000 bytes each. Scalar Subquery solution ? If you cannot unnest, and if you have wild fluctuations in performance because of hash collisions, you could ensure the values supplied to the subquery appear in order – then oracle run-time simply remembers the return values from “the previous” row. But this is a little dangerous – you should not depend on internal mechanisms. Filter Postponement (1) Another feature to be aware of with filter subqueries is there effect on the arithmetic, and how this is incompatible with their impact at runtime. We have a query here where I can include or exclude the subquery. The query joins t1 and t3, but the subquery is against t1. Check the plans and the cardinality. Filter Postponement (2) Without the subquery, the cardinality of t1 is 157, and the join cardinality it 173. With the subquery, the cardinality of t1 drops to 5% of 157 – which reduces the join cardinality to 9. But the subquery does not run until AFTER the join has been operated. So the number of calls to the subquery is 20 times larger than the number costed for. This type of change could result in an indexed nested loop instead of a hash join – have two subqueries against t1 and it becomes very likely, as you get the selectivity down to 5% of 5%. Filter Postponement (3) 10g behaves much better than 9i in this timing/costing split. But you can improve 9i (and earlier) by using the push_subq hint – which changes its use in 10g: current 9i use of this hint WILL NOT WORK on the next upgrade. Filter Postponement (4) Without pushing, the 10g plan shows a late running subquery – but the t1 cardinality and join cardinality have not suffered the 5% factor. When the subquery is pushed, the 5% appears in the right place. Note – however – that the FILTER operation has gone missing. It has been squashed into the tablescan of t1 – which really ought to be the filter line, and the scan of t1 should be one line down and one step to the right. Filter Subquery join effects Another aspect of filter subqueries if we do not push them is that the number of times the subquery runs can be affected by the join method that takes place before the subquery. We can see operation counts by enabling rowsource execution statistics. This can be expensive on CPU usage, and should be done rarely. It populates the view v$sql_plan_statistics – and there is a hint in 10g to make this easy. Filter Subquery join effects Querying dbms_xplan.display_cursor(null,null,’ALLSTATS LAST’) we can see the statistics for the last run of the most recent statement we executed. (You need to have serveroutput off for this to work, or the last statement will be the call to dbms_output.get_lines). With the nested loop join, the data order of the driving column for the subquery s dictated by the first table – and this maximises the benefit of scalar subquery caching. With the hash join, the data order of the driving column for the subquery is dictated by the second table. And this can mean we run the subquery more times. Join Orders (1) It’s not just run-time that can be affected. It’s worth checking how hard the optimizer has to work when handling a statement with subqueries. It changes with version of Oracle. A simple check in the 10053 trace file (CBO trace) is to look for the number of lines where Oracle reports a ‘Join Order’ to see how many get examined. Consider this query where we want the employees that earn more than the average salary for their department. 9i and 10g produced the same plan (unnest, inline view and hash join) for this query – although 10g did a hash group by – but how did they get to that decision. Join Orders (2) The plans In Oracle 9, there are two stages only: Work out the strategy of the inline view Work out the cost of joining the view to the base table In 10g we then work out the cost of doing complex view merging between the view and the base table. Then we work out half a dozen other options. The optimization CPU, memory, and latch activity goes up significantly. Join Orders (3) This might look like a threat in the case of our sample query – how many different things will the optimizer try to work out ? In fact, because we have simple existence subqueries with non-null columns and primary keys all over the place, we find that Oracle has invoked ‘non-costed’ transformation to turn the query into a straight four-table join. This means it only looks at one general plan – with 24 (4 * 3 * 2 * 1) join orders. This “non-costed” approach is not necessarily the right thing to do with multiple subqueries (in my opinion), and there are execution plans which simply cannot be created from a 4-table join. Join Orders (4) These are the join orders examined – you will note that a few are skipped. This is because the initial stages of a previous join are the same, and the previous join order was aborted early as being more expensive than the current best option. Forcing Join orders (1) Despite some orders being skipped, we can force Oracle to evaluate and use the paths (or at least display them). This only works for very simple cases. What happens if you have multiple complex query blocks – you only get on choice of permutation number. Forcing Join orders (2) It is worth noting that the execution plans can appear to contradict the join orders. This is a common reason why people sometimes think that Oracle has ignored a hint. With HASH joins specifically, when you ‘join the next table’ – Oracle can choose whether that new table should be the build (hash) table or the probe (second) table. There is a hint swap_join_inputs() in 9i which forces it to be the build table; and a 10g hint no_swap_join_inputs() that forces it to be the probe table. Forcing Join orders (3) It is also interesting to note that, although there are three (four) different strategies that Oracle could choose to transform a subquery, sometimes the options are constrained by the previous actions in the join order. In this case we see t4 used as an in-line view (because that’s the only way you can join t1 and t4 through the necessary cartesian merge join), and t3 being access through a semi-join. Being 10g, the semi-join has been set as a hash semi-join, which can then be reversed (to become an outer join the wrong way around). Every version brings new little details. The meaning of the query (1) The best way to work out the most efficient operation is to know the data. Looking at t1, could join to t3 could filter against t2 What if … (1) If we decide that the subquery against t2 eliminates more data than the join to t3, then we could force the subquery to run before the join. What if … (2) But, the subquery may be fairly expensive on disk or CPU, to so we might want to minise the number of times it runs. Conversely, the nature of the join to t3 (hence the cost of the join) may be unchanged by the fact that we have filtered data out already – so there may be no benefit in running the subquery early. So we could choose to join then filter. In this case, by filtering early, we changed the join to t3 from a hash join (expensive) to a nested loop (possibly cheaper – if it is a precise nested loop). The meaning of the query (2) But notice that both subqueries have their own filter-only predicates. How much data would we get from each subquery, and how efficiently, if we started with one of these subquery tables. What if … (3) If we can’t get from t1 to t2 efficiently, maybe we can pick a small amount ofdata from t2 and then use an efficient access path into t1. In this case we then hash join to t3 What if … (4) But a hash join to t3 might be very expensive What if join from t4 to t3 is as efficient at the join from t2 to t1. What if the number of rows from t4 and t2 are both small – a cartesian join of the selected data from t2 and t4 could be small and efficiently acquired, and a highly efficient path to t1 and t3 might then be very effecive. This is a path that few humans would think of – but it just falls out of the machines implacable processing of the join orders. It happens to be the default path for my query. Impossible path But there are still cases where none of the 24 join orders work well. Bushy Tree SQL We can make Oracle do something it doesn’t want to do. Create a couple of intermediate results and join them. For example – compare this summary of this week’s sales with the same week last year. Oracle will tend to join two big sets and aggregate when we can see that we want to aggregate two sets and join. The no_merge hint (or possibly subquery factoring with the /*+ materialize */ hint) can work for use here. Note that the materialize will cause global temporary tables to be dumped to the temp tablespace, whereas no_merge uses PGA memory. Bushy Tree SQL (alt) We can make Oracle do something it doesn’t want to do. Create a couple of intermediate results and join them. For example – compare this summary of this week’s sales with the same week last year. Oracle will tend to join two big sets and aggregate when we can see that we want to aggregate two sets and join. The no_merge hint (or possibly subquery factoring with the /*+ materialize */ hint) can work for use here. Note that the materialize will cause global temporary tables to be dumped to the temp tablespace, whereas no_merge uses PGA memory. Bushy Tree plan This is the execution plan. VIEW means “in memory result set generated”. Then we hash join the two sets. Bushy Tree picture The bushy tree picture. Know your Data General principles Sketch out the picture of the data in E/R form to help, then walk from table to table. Conclusion Know thy data.