Table Of Contents
1.0 Introduction
2.0 Overview
3.0 The Main Course
4.0 Simplify
5.0 Filling the Gaps
6.0 Looking at the numbers
7.0 Predicate Information
8.0 Resolution
9.0 Summary
Footnote
1.0 Introduction
1.1 In a comment to a recent post on reading a non-trivial execution someone asked me to repeat the exercise using a plan I had published a few days previously in a post about tweaking the hints in an outline. The query in question involved a number of subqueries and transformations of different types, which means it’s going to take a little work explaining the details, and it’s probably going to be a fairly long read.
1.2 Here’s the query that produced the plan we’re going to examine. I’ve done some cosmetic alteration to make it a little easier to read (though it’s still not perfect according to my standards). I’ve also made one very important addition to the query to make it easier to follow my walkthrough of the execution plan; the original text didn’t specify any query block names (/*+ qb_name() */ hints) even though it starts off with 9 separate query blocks, so I’ve walked through the text very carefully adding in the query block names that Oracle would have used (sel$NN) for each query block. In this case I got lucky because there were no views of other recursive problems involved so all I had to do was find each occurence of the word “select” in literal text order and increment the NN in sel$NN for each one.
SELECT /*+ QB_NAME(SEL$1) */
COUNT(applicant_id)
FROM (
SELECT /*+ QB_NAME(SEL$2) */
applicant_id,
academic_year,
applicant_gender,
medium_of_study,
education_type,
college_id,
course_id,
medium_id,
hostel_required,
preference_order,
status_flag,
attribute7, -- Added on 7-mar-20
college_status_flag,
percentage,
caste_category,
alloted_category,
NULL allotment_type
FROM (
SELECT /*+ QB_NAME(SEL$3) */
adt.applicant_id,
lmt_gender.lov_code applicant_gender,
adt.medium_of_study,
act.college_id,
lmt_education_type.lov_code education_type,
act.course_id,
act.medium_id,
act.hostel_required,
act.preference_order,
act.status_flag,
act.attribute7, -- Added on 7-mar-20
adt.college_status_flag,
adt.academic_year,
adt.percentage,
adt.applicant_dob,
adt.legacy_appln_date,
adt.caste_category,
act.attribute1 alloted_category,
DECODE (lmt_pass.lov_code, 'ATTFIRST', 1, 'COMPARTL', 2, 3) order_of_pass,
DECODE (late_entry_flag, 'N', 1, 'Y', 2, 3) order_of_entry,
DECODE (lmt_appearance.lov_code, 'REGULAR', 1, 'PRIVATE', 2, 3) order_of_appearance,
DECODE (adt.is_ttd_employ_ward, 'Y', 1, 'N', 2, 3) order_of_ttd_emp,
DECODE (adt.is_balbhavan_studnt, 'Y', 1, 'N', 2, 3) order_of_schooling,
act.attribute3 course_qe_priority,
adt.is_local_canditature_valid,
adt.is_ttd_emp_ward_info_valid,
adt.is_sv_bm_student_info_valid,
adt.is_social_ctgry_info_valid,
DECODE(adt.college_status_flag,'B',1,'O',2,'N',3) order_of_status
FROM
xxadm.xxadm_applicant_details_tbl adt,
xxadm.xxadm_applicant_coursprefs_tbl act,
xxadm.xxadm_college_master_tbl cmt,
xxadm.xxadm_course_master_tbl crmt,
xxadm.xxadm_medium_master_tbl mmt,
xxadm.xxadm_lov_master_tbl lmt_gender,
xxadm.xxadm_lov_master_tbl lmt_pass,
xxadm.xxadm_lov_master_tbl lmt_appearance,
xxadm.xxadm_lov_master_tbl lmt_religion,
xxadm.xxadm_lov_master_tbl lmt_education_type
WHERE
adt.applicant_id = act.applicant_id
AND act.college_id = cmt.college_id
AND act.course_id = crmt.course_id
AND act.medium_id = mmt.medium_id
AND adt.applicant_gender = lmt_gender.lov_id
AND adt.pass_type = lmt_pass.lov_id
AND adt.appearance_type = lmt_appearance.lov_id
AND adt.religion = lmt_religion.lov_id
AND cmt.education_type = lmt_education_type.lov_id
AND adt.status = 'Active'
AND 1 = (CASE
WHEN act.hostel_required = 'Y'
THEN (CASE
WHEN adt.distance_in_kms >20
AND lmt_religion.lov_code = 'HINDU'
AND adt.caste_category NOT IN (
SELECT /*+ QB_NAME(SEL$4) */
category_id
FROM xxadm.xxadm_category_master_tbl
WHERE category_code IN ('BACKWRDC', 'BACKWRDE')
)
THEN 1
ELSE 2
END
)
ELSE 1
END
)
AND 1 = (CASE
WHEN act.hostel_required = 'Y'
THEN (CASE
WHEN ( lmt_education_type.lov_code = 'COEDUCOL'
AND mt_gender.lov_code = 'FEMALE'
)
THEN 2
ELSE 1
END
)
ELSE 1
END
)
AND adt.course_applied_for = 'DEG'
AND (adt.college_status_flag IS NULL OR adt.college_status_flag IN ('N','T','C','B','O'))
AND act.preference_order <= NVL( -- > comment to avoid WordPress format issue
(SELECT /*+ QB_NAME(SEL$5) */
preference_order
FROM xxadm.xxadm_applicant_coursprefs_tbl act1
WHERE act1.applicant_id = adt.applicant_id
AND status_flag IN('B','T','C','O')
), act.preference_order
)
AND act.preference_order >= NVL(
(SELECT /*+ QB_NAME(SEL$6) */
preference_order
FROM xxadm.xxadm_applicant_coursprefs_tbl act2
WHERE act2.applicant_id = adt.applicant_id
AND status_flag = 'C'
), act.preference_order
)
AND act.preference_order NOT IN (
SELECT /*+ QB_NAME(SEL$7) */
act3.preference_order
FROM xxadm.xxadm_applicant_coursprefs_tbl act3
WHERE act3.applicant_id = adt.applicant_id
AND act3.status_flag = 'O'
)
AND act.preference_order NOT IN (
SELECT /*+ QB_NAME(SEL$8) */
act1.preference_order
FROM xxadm.xxadm_applicant_coursprefs_tbl act1
WHERE act1.applicant_id = adt.applicant_id
AND act1.status_flag IN ('C','B')
AND act1.attribute1 IN (
SELECT /*+ QB_NAME(SEL9) */
category_id
FROM xxadm.xxadm_category_master_tbl
WHERE category_code IN ('OPENMERT')
)
AND NVL(act1.attribute7,'N') = 'N'
)
AND cmt.college_id = :p_college_id
AND crmt.course_id = :p_course_id
AND mmt.medium_id = :p_medium_id
AND act.hostel_required = :p_hostel_required
ORDER BY
order_of_pass,
course_qe_priority,
percentage DESC,
applicant_dob,
legacy_appln_date
)
WHERE
ROWNUM <= :p_seats
)
WHERE
applicant_id = :p_applicant_id
;
Figure 1-1
1.3 This query first came to light in a thread on the Oracle Developer forums with an extract from a tkprof file showing that it had executed 842,615 times. That number should be ringing alarms and flashing warning lights, but if we assume that there really is no way of doing some sort of batch processing to get through the data we need to do a little bit of arithmetic to see how much of a threat this query is and how much is matters.
1.4 For every extra 0.01 seconds it takes to execute this query the total run-time goes up by8,426 seconds, which is 2 hours and 20 minutes. If the average execution time is a mere 0.06 seconds you’ll be at it all night long – and it will be a long, long night.
2.0 Overview
2.1 Before we look at the execution plan let’s take a moment to pick out a few points from the query. You may want to re-open this post in a separate window so that you can switch easily between the SQL and my comments.
2.2 We start off with a simple select from an inline view – and if we replace the inline view the simple “object name” V_THING we get the following query:
select count(applicant_id)
from V_THING
where applicant_id = :p_applicant_id
;
Figure 2-1
2.3 This should prompt two questions
- First, how far into the view V_THING will the optimizer be able to push that predicate, possibly the entire content of the view will have to be constructed before the predicate can apply, possibly the nature of the view is such that the optimizer could do a simple filter pushdown to apply the predicate very early. That still leaves (or leads on to) the question of whether the optmizer might then be able to generate further uses of the predicate through transitive closure.
- Secondly, if the view V_THING is a multiable view will we be able to work out which table applicant_id comes from by the time it becomes visible in the view. It’s possible that changing the table from which applicant_id comes will change the execution plan.
2.4 Digging down one layer we see that our V_THING is also a simple select from an inline view – let’s call it V_ANOTHER – so if we again forget about the complexity of the inner view we’re looking at a query that goes:
select /*+ QB_NAME(SEL$1) */
count(applicant_id)
from (
select /*+ QB_NAME(SEL$2) */
applicant_id,
{15 more columns}
null allotment_type
from
V_OTHER
where
rownum <= :p_seats
) V_THING
where
applicant_id = :p_applicant_id
;
Figure 2-2
2.5 A couple of details hit the eye when you look at this: Why are we selecting 17 columns from a complex view, and then counting only one of them and discarding the rest. Let’s hope the optimizer is smart enough to discard the excess columns at the earliest possible moment (which might allow it to do some index-only accesses instead of visiting tables for columns we don’t really need).
2.6 Stranger still, one of those columns is a delberately generated NULL! This hints at the possibility that the client code is doing something like “count how many query X will give me, then run query X”– giving us the pattern “select count(*) from (inlne query X); execute query X” Maybe this whole query is a waste of time, but if it can’t be avoided maybe it should be edited down to the smallest query that will get the correct count.
2.7 Another thought about this layer of the query, the predicate “rownum <= :bind_variable” may be pushing the optimizer into first_rows(n) optimization and this might be enough to make it choose a bad execution plan. I’d have to check, and check for specific versions, but off the top of my head I think that when comparing rownum with a bind variable the optimizer will optimizer for first_rows(10) unless there’s some other reason for choosing anything else.)
2.8 I’m also a little curious about a requirement that seems to say – “pick at most N rows, then tell me how many you’ve picked”. What’s it actually trying to do and why?
2.9 Let’s dig one layer deeper before we get into the complex stuff. Here’s a version of the code that expands V_OTHER in an extremely stripped down form:
SELECT /*+ QB_NAME(SEL$1) */
COUNT(applicant_id)
FROM (
SELECT /*+ QB_NAME(SEL$2) */
applicant_id,
{15 more columns}
NULL allotment_type
FROM (
SELECT /*+ QB_NAME(SEL$3) */
{lots of columns}
FROM
{lots of tables}
WHERE
{lots of predicates}
ORDER BY
order_of_pass,
course_qe_priority,
percentage DESC,
applicant_dob,
legacy_appln_date
)
WHERE
ROWNUM <= :p_seats
)
WHERE
applicant_id = :p_applicant_id
;
Figure 2-3
2.10 At this point we can start to see reasons for the layering of inline views – we need to select data in the right order before we apply the rownum predicate; as for the excess columns in the select list – even if we selected only the applicant_id in the outer layers the optimizer would still have to acquire the five columns in the order by clause.
2.11 But this emphasises the oddity of the query. If we’re only counting applicant_id to see whether we got :p_seats or fewer rows for a specific applicant_id why does the order matter – surely the order will only matter when we “repeat” the query to get the actual rows (if that’s what we do). As it is, to count a small number of rows this query might have to fetch and sort a large number, then discard most of them. (Some statistics from other posts by the OP indicated that the underlying query might fetch anything between a few hundred and a couple of thousand rows. This particular run showed the query finding 171 rows to sort and then restricting the rowsource to the first two sorted rows)
3.0 The Main Course
3.1 To make it a little easier to discuss the detail of the execution plan I’ve laid it out in a small number of sections corresponding to the final (outline_leaf) query blocks the optimizer generated. To do this I applied two sets of information – the Query Block / Object Alias information (which follows the body of the plan) and any appearances of the VIEW operation in the plan.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 574 (100)| 1 |00:00:00.02 | 3822 | | | |
| 1 | SORT AGGREGATE | | 1 | 1 | | 1 |00:00:00.02 | 3822 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
select count(applicant_id) - above
select where rownum less than - below
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 2 | VIEW | | 1 | 1 | 574 (2)| 0 |00:00:00.02 | 3822 | | | |
|* 3 | COUNT STOPKEY | | 1 | | | 2 |00:00:00.02 | 3822 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Start of "real" main query, query block SEL$7E0D484F
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 4 | VIEW | | 1 | 1 | 574 (2)| 2 |00:00:00.02 | 3822 | | | |
|* 5 | SORT ORDER BY STOPKEY | | 1 | 1 | 574 (2)| 2 |00:00:00.02 | 3822 | 2048 | 2048 | 2048 (0)|
|* 6 | FILTER | | 1 | | | 171 |00:00:00.02 | 3822 | | | |
| 7 | NESTED LOOPS | | 1 | 1 | 568 (2)| 182 |00:00:00.02 | 3128 | | | |
| 8 | NESTED LOOPS | | 1 | 1 | 568 (2)| 182 |00:00:00.02 | 2946 | | | |
| 9 | NESTED LOOPS | | 1 | 1 | 567 (2)| 182 |00:00:00.02 | 2942 | | | |
| 10 | NESTED LOOPS | | 1 | 1 | 566 (2)| 182 |00:00:00.02 | 2938 | | | |
| 11 | NESTED LOOPS ANTI | | 1 | 1 | 565 (2)| 182 |00:00:00.02 | 2752 | | | |
| 12 | NESTED LOOPS ANTI | | 1 | 1 | 562 (2)| 182 |00:00:00.02 | 2388 | | | |
|* 13 | HASH JOIN | | 1 | 5 | 557 (2)| 182 |00:00:00.02 | 2022 | 1599K| 1599K| 1503K (0)|
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
join index transformation query block SEL$082F290F
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 14 | VIEW | index$_join$_008 | 1 | 127 | 2 (0)| 127 |00:00:00.01 | 8 | | | |
|* 15 | HASH JOIN | | 1 | | | 127 |00:00:00.01 | 8 | 1368K| 1368K| 1522K (0)|
| 16 | INDEX FAST FULL SCAN | XXADM_LOVS_CODE_UK | 1 | 127 | 1 (0)| 127 |00:00:00.01 | 4 | | | |
| 17 | INDEX FAST FULL SCAN | XXADM_LOVS_PK | 1 | 127 | 1 (0)| 127 |00:00:00.01 | 4 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Continuation of "real" main query, query block SEL$7E0D484F
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 18 | HASH JOIN | | 1 | 478 | 555 (2)| 182 |00:00:00.01 | 2014 | 1245K| 1245K| 1277K (0)|
| 19 | NESTED LOOPS | | 1 | 478 | 243 (2)| 209 |00:00:00.01 | 883 | | | |
| 20 | NESTED LOOPS | | 1 | 1 | 2 (0)| 1 |00:00:00.01 | 4 | | | |
| 21 | TABLE ACCESS BY INDEX ROWID| XXADM_COLLEGE_MASTER_TBL | 1 | 1 | 1 (0)| 1 |00:00:00.01 | 2 | | | |
|* 22 | INDEX UNIQUE SCAN | XXADM_COLLEGES_PK | 1 | 1 | 0 (0)| 1 |00:00:00.01 | 1 | | | |
| 23 | TABLE ACCESS BY INDEX ROWID| XXADM_LOV_MASTER_TBL | 1 | 1 | 1 (0)| 1 |00:00:00.01 | 2 | | | |
|* 24 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 1 | 1 | 0 (0)| 1 |00:00:00.01 | 1 | | | |
|* 25 | TABLE ACCESS FULL | XXADM_APPLICANT_COURSPREFS_TBL | 1 | 478 | 241 (2)| 209 |00:00:00.01 | 879 | | | |
|* 26 | TABLE ACCESS FULL | XXADM_APPLICANT_DETAILS_TBL | 1 | 6685 | 311 (2)| 10488 |00:00:00.01 | 1131 | | | |
|* 27 | TABLE ACCESS BY INDEX ROWID | XXADM_APPLICANT_COURSPREFS_TBL | 182 | 8881 | 1 (0)| 0 |00:00:00.01 | 366 | | | |
|* 28 | INDEX UNIQUE SCAN | XXADM_APPLCNT_PREF_ORDER_UK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 184 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Unnested subquery SEL$A75BE177 (from sel$8, sel$9)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 29 | VIEW PUSHED PREDICATE | VW_SQ_1 | 182 | 1 | 3 (0)| 0 |00:00:00.01 | 364 | | | |
| 30 | NESTED LOOPS | | 182 | 1 | 3 (0)| 0 |00:00:00.01 | 364 | | | |
|* 31 | TABLE ACCESS BY INDEX ROWID | XXADM_APPLICANT_COURSPREFS_TBL | 182 | 1 | 2 (0)| 0 |00:00:00.01 | 364 | | | |
|* 32 | INDEX UNIQUE SCAN | XXADM_APPLCNT_PREF_ORDER_UK | 182 | 1 | 1 (0)| 182 |00:00:00.01 | 184 | | | |
|* 33 | TABLE ACCESS BY INDEX ROWID | XXADM_CATEGORY_MASTER_TBL | 0 | 1 | 1 (0)| 0 |00:00:00.01 | 0 | | | |
|* 34 | INDEX UNIQUE SCAN | XXADM_CATEGORY_PK | 0 | 1 | 0 (0)| 0 |00:00:00.01 | 0 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Start of "real" main query, query block SEL$7E0D484F
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 35 | TABLE ACCESS BY INDEX ROWID | XXADM_LOV_MASTER_TBL | 182 | 1 | 1 (0)| 182 |00:00:00.01 | 186 | | | |
|* 36 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 4 | | | |
|* 37 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 4 | | | |
|* 38 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 4 | | | |
| 39 | TABLE ACCESS BY INDEX ROWID | XXADM_LOV_MASTER_TBL | 182 | 1 | 1 (0)| 182 |00:00:00.01 | 182 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Filter subquery, query block SEL$5
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 40 | TABLE ACCESS BY INDEX ROWID BATCHED | XXADM_APPLICANT_COURSPREFS_TBL | 182 | 1 | 3 (0)| 29 |00:00:00.01 | 507 | | | |
|* 41 | INDEX RANGE SCAN | XXADM_APPLCNT_PREFS_UK | 182 | 5 | 2 (0)| 1450 |00:00:00.01 | 191 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Filter subquery, query block SEL$6
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 42 | TABLE ACCESS BY INDEX ROWID BATCHED | XXADM_APPLICANT_COURSPREFS_TBL | 171 | 1 | 2 (0)| 0 |00:00:00.01 | 173 | | | |
|* 43 | INDEX RANGE SCAN | XXADM_APPLCNT_APPLICANT_STATUS | 171 | 1 | 1 (0)| 0 |00:00:00.01 | 173 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Filter subquery SEL$F665FE1B (from sel$4 with tranform for index join)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 44 | VIEW | index$_join$_014 | 6 | 1 | 0 (0)| 0 |00:00:00.01 | 14 | | | |
|* 45 | HASH JOIN | | 6 | | | 0 |00:00:00.01 | 14 | 1519K| 1519K| 666K (0)|
|* 46 | INDEX RANGE SCAN | XXADM_CATEGORY_PK | 6 | 1 | 0 (0)| 6 |00:00:00.01 | 6 | | | |
| 47 | INLIST ITERATOR | | 6 | | | 12 |00:00:00.01 | 8 | | | |
|* 48 | INDEX UNIQUE SCAN | XXADM_CATEGORY_CODE_UK | 12 | 1 | 0 (0)| 12 |00:00:00.01 | 8 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
1 - SEL$1
2 - SEL$2 / from$_subquery$_001@SEL$1
3 - SEL$2
4 - SEL$7E0D484F / from$_subquery$_002@SEL$2
5 - SEL$7E0D484F
14 - SEL$082F290F / LMT_GENDER@SEL$3
15 - SEL$082F290F
16 - SEL$082F290F / indexjoin$_alias$_001@SEL$082F290F
17 - SEL$082F290F / indexjoin$_alias$_002@SEL$082F290F
21 - SEL$7E0D484F / CMT@SEL$3
22 - SEL$7E0D484F / CMT@SEL$3
23 - SEL$7E0D484F / LMT_EDUCATION_TYPE@SEL$3
24 - SEL$7E0D484F / LMT_EDUCATION_TYPE@SEL$3
25 - SEL$7E0D484F / ACT@SEL$3
26 - SEL$7E0D484F / ADT@SEL$3
27 - SEL$7E0D484F / ACT3@SEL$7
28 - SEL$7E0D484F / ACT3@SEL$7
29 - SEL$A75BE177 / VW_SQ_1@SEL$67DC521B
30 - SEL$A75BE177
31 - SEL$A75BE177 / ACT1@SEL$8
32 - SEL$A75BE177 / ACT1@SEL$8
33 - SEL$A75BE177 / XXADM_CATEGORY_MASTER_TBL@SEL$9
34 - SEL$A75BE177 / XXADM_CATEGORY_MASTER_TBL@SEL$9
35 - SEL$7E0D484F / LMT_PASS@SEL$3
36 - SEL$7E0D484F / LMT_PASS@SEL$3
37 - SEL$7E0D484F / LMT_APPEARANCE@SEL$3
38 - SEL$7E0D484F / LMT_RELIGION@SEL$3
39 - SEL$7E0D484F / LMT_RELIGION@SEL$3
40 - SEL$5 / ACT1@SEL$5
41 - SEL$5 / ACT1@SEL$5
42 - SEL$6 / ACT2@SEL$6
43 - SEL$6 / ACT2@SEL$6
44 - SEL$F665FE1B / XXADM_CATEGORY_MASTER_TBL@SEL$4
45 - SEL$F665FE1B
46 - SEL$F665FE1B / indexjoin$_alias$_001@SEL$F665FE1B
48 - SEL$F665FE1B / indexjoin$_alias$_002@SEL$F665FE1B
Outline Data
-------------
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('12.1.0.2')
DB_VERSION('12.1.0.2')
OPT_PARAM('_optimizer_use_feedback' 'false')
OPT_PARAM('_optimizer_dsdir_usage_control' 0)
OPT_PARAM('_optimizer_adaptive_plans' 'false')
OPT_PARAM('_optimizer_gather_feedback' 'false')
ALL_ROWS
OUTLINE_LEAF(@"SEL$F665FE1B")
OUTLINE_LEAF(@"SEL$4")
OUTLINE_LEAF(@"SEL$5")
OUTLINE_LEAF(@"SEL$6")
OUTLINE_LEAF(@"SEL$A75BE177")
PUSH_PRED(@"SEL$7E0D484F" "VW_SQ_1"@"SEL$67DC521B" 16 15)
OUTLINE_LEAF(@"SEL$082F290F")
OUTLINE_LEAF(@"SEL$7E0D484F")
UNNEST(@"SEL$9D10C90A")
UNNEST(@"SEL$7")
OUTLINE_LEAF(@"SEL$2")
OUTLINE_LEAF(@"SEL$1")
OUTLINE(@"SEL$180402DE")
OUTLINE(@"SEL$7E0D484F")
UNNEST(@"SEL$9D10C90A")
UNNEST(@"SEL$7")
OUTLINE(@"SEL$67DC521B")
OUTLINE(@"SEL$9D10C90A")
UNNEST(@"SEL$9")
OUTLINE(@"SEL$7")
OUTLINE(@"SEL$C04829E0")
ELIMINATE_JOIN(@"SEL$3" "CRMT"@"SEL$3")
ELIMINATE_JOIN(@"SEL$3" "MMT"@"SEL$3")
OUTLINE(@"SEL$8")
OUTLINE(@"SEL$9")
OUTLINE(@"SEL$3")
NO_ACCESS(@"SEL$1" "from$_subquery$_001"@"SEL$1")
NO_ACCESS(@"SEL$2" "from$_subquery$_002"@"SEL$2")
INDEX_RS_ASC(@"SEL$7E0D484F" "CMT"@"SEL$3" ("XXADM_COLLEGE_MASTER_TBL"."COLLEGE_ID"))
INDEX_RS_ASC(@"SEL$7E0D484F" "LMT_EDUCATION_TYPE"@"SEL$3" ("XXADM_LOV_MASTER_TBL"."LOV_ID"))
FULL(@"SEL$7E0D484F" "ACT"@"SEL$3")
FULL(@"SEL$7E0D484F" "ADT"@"SEL$3")
INDEX_JOIN(@"SEL$7E0D484F" "LMT_GENDER"@"SEL$3" ("XXADM_LOV_MASTER_TBL"."LOV_CODE") ("XXADM_LOV_MASTER_TBL"."LOV_ID"))
INDEX_RS_ASC(@"SEL$7E0D484F" "ACT3"@"SEL$7" ("XXADM_APPLICANT_COURSPREFS_TBL"."APPLICANT_ID" "XXADM_APPLICANT_COURSPREFS_TBL"."PREFERENCE_ORDER"))
NO_ACCESS(@"SEL$7E0D484F" "VW_SQ_1"@"SEL$67DC521B")
INDEX_RS_ASC(@"SEL$7E0D484F" "LMT_PASS"@"SEL$3" ("XXADM_LOV_MASTER_TBL"."LOV_ID"))
INDEX_RS_ASC(@"SEL$7E0D484F" "LMT_APPEARANCE"@"SEL$3" ("XXADM_LOV_MASTER_TBL"."LOV_ID"))
INDEX(@"SEL$7E0D484F" "LMT_RELIGION"@"SEL$3" ("XXADM_LOV_MASTER_TBL"."LOV_ID"))
LEADING(@"SEL$7E0D484F" "CMT"@"SEL$3" "LMT_EDUCATION_TYPE"@"SEL$3" "ACT"@"SEL$3" "ADT"@"SEL$3" "LMT_GENDER"@"SEL$3" "ACT3"@"SEL$7" "VW_SQ_1"@"SEL$67DC521B"
"LMT_PASS"@"SEL$3" "LMT_APPEARANCE"@"SEL$3" "LMT_RELIGION"@"SEL$3")
USE_NL(@"SEL$7E0D484F" "LMT_EDUCATION_TYPE"@"SEL$3")
USE_NL(@"SEL$7E0D484F" "ACT"@"SEL$3")
USE_HASH(@"SEL$7E0D484F" "ADT"@"SEL$3")
USE_HASH(@"SEL$7E0D484F" "LMT_GENDER"@"SEL$3")
USE_NL(@"SEL$7E0D484F" "ACT3"@"SEL$7")
USE_NL(@"SEL$7E0D484F" "VW_SQ_1"@"SEL$67DC521B")
USE_NL(@"SEL$7E0D484F" "LMT_PASS"@"SEL$3")
USE_NL(@"SEL$7E0D484F" "LMT_APPEARANCE"@"SEL$3")
USE_NL(@"SEL$7E0D484F" "LMT_RELIGION"@"SEL$3")
NLJ_BATCHING(@"SEL$7E0D484F" "LMT_RELIGION"@"SEL$3")
SWAP_JOIN_INPUTS(@"SEL$7E0D484F" "LMT_GENDER"@"SEL$3")
PQ_FILTER(@"SEL$7E0D484F" SERIAL)
INDEX_RS_ASC(@"SEL$A75BE177" "ACT1"@"SEL$8" ("XXADM_APPLICANT_COURSPREFS_TBL"."APPLICANT_ID" "XXADM_APPLICANT_COURSPREFS_TBL"."PREFERENCE_ORDER"))
INDEX_RS_ASC(@"SEL$A75BE177" "XXADM_CATEGORY_MASTER_TBL"@"SEL$9" ("XXADM_CATEGORY_MASTER_TBL"."CATEGORY_ID"))
LEADING(@"SEL$A75BE177" "ACT1"@"SEL$8" "XXADM_CATEGORY_MASTER_TBL"@"SEL$9")
USE_NL(@"SEL$A75BE177" "XXADM_CATEGORY_MASTER_TBL"@"SEL$9")
INDEX_RS_ASC(@"SEL$6" "ACT2"@"SEL$6" ("XXADM_APPLICANT_COURSPREFS_TBL"."APPLICANT_ID" "XXADM_APPLICANT_COURSPREFS_TBL"."STATUS_FLAG"))
BATCH_TABLE_ACCESS_BY_ROWID(@"SEL$6" "ACT2"@"SEL$6")
INDEX_RS_ASC(@"SEL$5" "ACT1"@"SEL$5" ("XXADM_APPLICANT_COURSPREFS_TBL"."APPLICANT_ID" "XXADM_APPLICANT_COURSPREFS_TBL"."COLLEGE_ID"
"XXADM_APPLICANT_COURSPREFS_TBL"."COURSE_ID" "XXADM_APPLICANT_COURSPREFS_TBL"."MEDIUM_ID" "XXADM_APPLICANT_COURSPREFS_TBL"."HOSTEL_REQUIRED"))
BATCH_TABLE_ACCESS_BY_ROWID(@"SEL$5" "ACT1"@"SEL$5")
INDEX_JOIN(@"SEL$4" "XXADM_CATEGORY_MASTER_TBL"@"SEL$4" ("XXADM_CATEGORY_MASTER_TBL"."CATEGORY_ID") ("XXADM_CATEGORY_MASTER_TBL"."CATEGORY_CODE"))
END_OUTLINE_DATA
*/
Figure 3-1
3.2 There’s no rigid rule I can give you about an approach for looking for query blocks and transformations, but it’s worth checking to see which of your original query blocks still exist in the final execution plan and which have disappeared thanks to some transformation.
3.3 If we look down the Query Block Name list above we can see that sel$1, sel$2, sel$5 and sel$6 have “survived” the machinations of the optimizer. We’ve already noted that sel$1 and sel$2 are simply “select from {inline view}” as far as the optimizer is concerned; sel$5 and sel$6 are simple subqueries that appeared as filter subqueries in the original query text and have kept that status by the end of the optimizer’s transformation stage.
3.4 Tracking down the other query blocks that we named we can see the following:
- sel$3 – most of its tables appear in a new query block called SEL$7E0D484F but one of them appears in a query block called SEL$082F290F; a closer look at SEL$082F290F shows us that it ranges from operations 14 to 17 and holds a “single table” transformation where the optimizer has chosen to use an index join of two indexes on the xxadm_lov_master_tbl rather than doing a tablescan. The index join is represented as a VIEW of a hash join, hence the separate query block. Another little detail we note – the xxadm_lov_master_tbl appears five times in the query, so we need to know which occurrence this is: fortunately the Object Alias information tells us at operation it’s the LMT_GENDER alias.
- sel$4 is the scalar subquery inside a CASE expression, involving table xxadm_category_master_tbl. We can find the table name (which hasn’t been given an alias) and the query block name in the Object Alias information at operation 44 in a query block called SEL$F665FE1B. There are two points of interest about this query block – it has come into existence because it’s another example where the optimizer has used an index join to avoid a full tablescan; and it has been used in a filter subquery (the parent of operation 44 is the FILTER at operation 6).
- sel$7 appeared in the original text as a NOT IN subquery against xxadm_applicant_coursprefs_tbl with an alias of act3. The Query Block / Object Alias information tells us that ACT3@SEL$7 appears at operations 27 and 28 – and when we track up the plan from operation 27 we see that it is the second child of operation 12 which is a nested loop anti. The optimizer has unnested the subquery and turned it into an anti join as one of the steps that produced query block SEL$7E0D484F
- sel$8 appeared in the original text as a NOT IN subquery against xxadm_applicant_coursprefs_tbl aliased as act1 (OUCH – that’s the second time the alias act1 has appeared in this query!). But the subquery had it’s own subquery, named sel$9, against xxadm_category_master_tbl which didn’t have an alias (more OUCH!). When we search for ACT1@SEL$8 and XXADM_CATEGORY_MASTER_TBL@SEL$9 in the Query Block / Object Alias information we find that they both appear in a query block called SEL$A75BE177 which ranges from operations 29 to 34, and a check of the plan shows that operation 29 is a view pushed predicate of a view called VW_SQ_1 – a name that identifies the view as an internally generated non-mergeable view that was created as the result of unnestingn a subquery. The view contains a join between xxadm_applicant_coursprefs_tbl and xxadm_category_master_tbl, so we can say that the optimizer has unnested our sel$9 to create a NOT IN subquery that is a join subquery, then it has unnested again to produce an inline non-mergeable view, and it has then allowed “join predicate pushdown (JPPD)” so that the non-mergeable view can be the second table of a nested loop. To confirm the last comment we track up the plan to discover that operation 29 is the second child of operation 11 which is, indeed, a nested loop and (since the subquery was a NOT IN subquery) a nested loop anti.
- sel$9 – see sel$8.
3.5 As you can see, when you’re using the execution plan output to identify what’s happened to the individual query blocks from your original query you’re likely to jump around from the query to the plan body, to the Query Block / Object Alias information in a fairly arbitrary way.
3.6 I’ll close this chapter of the analysis with a quick look at the Outline Data – in particular two of the hint types that appear: OUTLINE() and OUTLINE_LEAF() – which I’ve extracted and sorted for ease of reading:
OUTLINE(@"SEL$3")
OUTLINE(@"SEL$7")
OUTLINE(@"SEL$8")
OUTLINE(@"SEL$9")
OUTLINE(@"SEL$180402DE")
OUTLINE(@"SEL$67DC521B")
OUTLINE(@"SEL$7E0D484F")
OUTLINE(@"SEL$9D10C90A")
OUTLINE(@"SEL$C04829E0")
OUTLINE_LEAF(@"SEL$1")
OUTLINE_LEAF(@"SEL$2")
OUTLINE_LEAF(@"SEL$4")
OUTLINE_LEAF(@"SEL$5")
OUTLINE_LEAF(@"SEL$6")
OUTLINE_LEAF(@"SEL$082F290F")
OUTLINE_LEAF(@"SEL$7E0D484F")
OUTLINE_LEAF(@"SEL$A75BE177")
OUTLINE_LEAF(@"SEL$F665FE1B")
Figure 3-2
3.7 In this context an OUTLINE() is a query block that existed at some point in the optimization sequence that got us to the final execution plan but did not appear as a query block in the final plan. In the previous paragraphs we described how the original query blocks sel$3, sel$4, sel$7, sel$8 and sel$9 disappeared through transformation so (apart from sel$4 which is a bit of an anomaly that I’ll pick up in a moment) they appear in an OUTLINE() hint. I described how sel$9 would have been unnested into sel$8 to create a join which would still have been a filter subquery until that too was unnested – that join subquery would have been one of the five OUTLINE() query blocks above with the 8 character hexadecimal names.
3.8 An OUTLINE_LEAF() is a “final” query block – one that is present in the final execution plan. If you ignore sel$4, you’ll see that the other 8 query blocks correspond to the 8 query block names that appear in the Query Block Name / Object Alias information. The appearance of sel$4 as an OUTLINE_LEAF() looks like an anomaly to me; I can’t think of a good reason why it should be in the list.
4.0 Simplify
4.1 We’re just about ready to do a full read-through of the execution plan. We’ve taken the two outer layers off the query/plan because they represent such simple in-line views, and we’ve discussed the disappearance of some of our initial query blocks and identified and explained all the different query blocks that have appeared in the final plan. So with the extra bits of information in hand let’s take a couple more steps in simplifying the execution plan.
4.2 First I’ll replace each of the three VIEW operations and their descendants with a single line that says “this is a rowsource”. I’ll distinguish between the two variants of the operation (VIEW and VIEW PUSHED PREDICATE) by calling them BULK ROWSOURCE and PRECISION ROWSOURCE respectively: it’s not a perfect description but broadly speaking we expect a VIEW to be called once by its parent to produce a “large” data set and we expect a VIEW PUSHED PREDICATE to be called many times by its parent to produce (each time) a “small” data set using extremely efficient methods.
4.3 Then I’ll remind you that a multichild FILTER operation calls the first child once to supply a rowsource then, for each row returned, calls the other child operations in turn to determine whether or not to keep the row from the first child. This means we can examine just the first child in isolation to see how the optimizer wants to get the driving bulk of the data (and we can examine the other children later, bearing in mind how often they might need to be called and checking how efficient each call is likely to be).
4.4 Finally I’ll note that query block SEL$7E0D484F (the “real main query” as I labelled it in the plan above) starts: “VIEW -> SORT ORDER BY STOPKEY -> FILTER” – after we’ve filtered our data we simply sort it with the intention of keeping only the “top few” rows. That part of the plan is so simple we’ll ignore those lines of the plan and focus on just the first child of the FILTER- leaving the core plan looking like this:
-----------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------------------------------------------------------
| 7 | NESTED LOOPS | | 1 | 1 | 568 (2)| 182 |00:00:00.02 | 3128 |
| 8 | NESTED LOOPS | | 1 | 1 | 568 (2)| 182 |00:00:00.02 | 2946 |
| 9 | NESTED LOOPS | | 1 | 1 | 567 (2)| 182 |00:00:00.02 | 2942 |
| 10 | NESTED LOOPS | | 1 | 1 | 566 (2)| 182 |00:00:00.02 | 2938 |
| 11 | NESTED LOOPS ANTI | | 1 | 1 | 565 (2)| 182 |00:00:00.02 | 2752 |
| 12 | NESTED LOOPS ANTI | | 1 | 1 | 562 (2)| 182 |00:00:00.02 | 2388 |
|* 13 | HASH JOIN | | 1 | 5 | 557 (2)| 182 |00:00:00.02 | 2022 |
| 14 | BULK ROWSOURCE | index$_join$_008 | 1 | 127 | 2 (0)| 127 |00:00:00.01 | 8 |
|* 18 | HASH JOIN | | 1 | 478 | 555 (2)| 182 |00:00:00.01 | 2014 |
| 19 | NESTED LOOPS | | 1 | 478 | 243 (2)| 209 |00:00:00.01 | 883 |
| 20 | NESTED LOOPS | | 1 | 1 | 2 (0)| 1 |00:00:00.01 | 4 |
| 21 | TABLE ACCESS BY INDEX ROWID| XXADM_COLLEGE_MASTER_TBL | 1 | 1 | 1 (0)| 1 |00:00:00.01 | 2 |
|* 22 | INDEX UNIQUE SCAN | XXADM_COLLEGES_PK | 1 | 1 | 0 (0)| 1 |00:00:00.01 | 1 |
| 23 | TABLE ACCESS BY INDEX ROWID| XXADM_LOV_MASTER_TBL | 1 | 1 | 1 (0)| 1 |00:00:00.01 | 2 |
|* 24 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 1 | 1 | 0 (0)| 1 |00:00:00.01 | 1 |
|* 25 | TABLE ACCESS FULL | XXADM_APPLICANT_COURSPREFS_TBL | 1 | 478 | 241 (2)| 209 |00:00:00.01 | 879 |
|* 26 | TABLE ACCESS FULL | XXADM_APPLICANT_DETAILS_TBL | 1 | 6685 | 311 (2)| 10488 |00:00:00.01 | 1131 |
|* 27 | TABLE ACCESS BY INDEX ROWID | XXADM_APPLICANT_COURSPREFS_TBL | 182 | 8881 | 1 (0)| 0 |00:00:00.01 | 366 |
|* 28 | INDEX UNIQUE SCAN | XXADM_APPLCNT_PREF_ORDER_UK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 184 |
| 29 | PRECISION ROWSOURCE | VW_SQ_1 | 182 | 1 | 3 (0)| 0 |00:00:00.01 | 364 |
| 35 | TABLE ACCESS BY INDEX ROWID | XXADM_LOV_MASTER_TBL | 182 | 1 | 1 (0)| 182 |00:00:00.01 | 186 |
|* 36 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 4 |
|* 37 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 4 |
|* 38 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 182 | 1 | 0 (0)| 182 |00:00:00.01 | 4 |
| 39 | TABLE ACCESS BY INDEX ROWID | XXADM_LOV_MASTER_TBL | 182 | 1 | 1 (0)| 182 |00:00:00.01 | 182 |
-----------------------------------------------------------------------------------------------------------------------------------------------------
Figure 4-1
4.5 We need to examine a plan of only 25 lines with no complicated bits (because we’ve hidden any bits that looked complicated and will get back to them later). The thing now looks like a single query block which means we can think “First Child First”, so:
- operation 7 calls operation 8 which calls operation 9 which calls operation 10 which calls operation 11 which calls operation 12 which calls operation 13 which calls operation 14 which is the first operation to produce a rowsource (though we don’t care how at present).
- Operation 13 is a hash join, so the rowsource from operation 14 becomes its “build” table, and we call operation 18 to supply the “probe” table.
- Operaion 18 calls operation 19 which calls operation 20 which calls operation 21 which is a table access by rowid that has to call operation 22 to get rowids. So operation 22 supplies the second rowsource (in our collapsed plan). It’s an INDEX UNIQUE SCAN of the index that appears (judging from its name)to be the primary key index of a table, so operation 22 will produce at most one rowid that is passed up to operation 21 that will use that rowid to get the one row from the table. (Operation 21 supplies the 3rd rowsource).
- Operation 21 passes a row up to operation 20 which calls operation 23 which calls operation 24 (4th rowsource) to do another unique scan of a unique index to get a rowid to pass up to operation 23 to find (and test) a row from the table (5th rowsource) which it passes up to operation 20 to do the join and pass the result up (6th rowsource) to operation 19.
- Operation 19 calls its second child (operatiomn 25) for each row it receives – but because of the primary key/unique scans the optimizer knows that the first child will return at most one row and sees no problem with using a full tablescan as the second child of the nested loop. So the tablescan of XXADM_APPLICANT_COURSPREFS_TBL is the 7th rowsource. Any rows survinging the join are passed up to operation 18 (making operation 19 the 8th rowsource).
- Operation 18 uses the incoming rowsource to build its in-memory hash table, and calls operation 26 to supply its second (probe table) rowsource. Operation 26 is the the 9th rowsource, executing a full tablescan of XXADM_APPLICANT_DETAILS_TBL and passing the results up to operation 18, which performs the join and passes the results up to its parent, making it the 10th rowsource.
- Operation 18 was the second child of the hash join at operation 13, which now uses the incoming data as the probe table to generate the 11th rowsource and pass the results up to operation 12.
- Operation 12 is a nested loop anti-join and operation 13 has just supplied it with its first child rowsource, so operation 12 will now call its second child once for each row in the first child. Its second child is operation 27 (table access by rowid) which calls its first child (operation 28 index range scan) which fetches rowids from the index passes them up to operation 27 which fetches table rows and passes them up to operation 12. So operation 28 supplies the 12th rowsource, operation 27 the 13th. Since operation 12 is an ANTI join a row from the first child survives if operation 27 doesn’t find a row to return. Operation 12 passes any survivors (14th rowsource) up to operation 11.
- Operation 11 is another ANTI-join nested loop so for each row from operation 12 it will call its second child, passing in values from its first child to drive an efficient access path and forwarding any rows from the first child where the second child returns no rows. Its second child is operation 29 – our “precision rowsource” – and we can postpone worrying about the exact details of how that works. Operation 29 produces the 15th rowsource in our reduced plan, which it passes up to operation 11.
- Operation 11 is the first child of the nested loop at operation 10 – and from this point onwards we have 4 nested loop joins and we can simply list through the order of operation. Operation 11 produces the 16th rowsource, then Operation 10 calls its second child (operation 35) which calls operation 36 which passes rowids (17th rowsource) up to operation 35 which passes rows (18th rowsource) up to operation 10.
- Operation 10 passes its data (19th rowsource) up to operation 9 which calls operation 37 as its second child. Operation 37 (20th rowsource) passes index entries up to operation 9 which performs the join and passes the result (21st rowsource) up to operation 8.
- Operation 8 calls operation 38 as its second child. Operation 38 (22nd rowsource) passes index entries up to operation 8 which performs the join and passes the result (23rd rowsource) up to operation 7.
- Operation 7 calls operation 39 as its second child. Operation 39 (24th rowsource) passes index entries up to operation 7 which performs the join and that’s the final (25th) rowsource as far as our reduced execution plan is concerned.
4.6 Here’s the reduced plan, cut back to minimum width, with the order of rowsource generation included:
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Order |
-----------------------------------------------------------------------------------------------
| 7 | NESTED LOOPS | | 25 |
| 8 | NESTED LOOPS | | 23 |
| 9 | NESTED LOOPS | | 21 |
| 10 | NESTED LOOPS | | 19 |
| 11 | NESTED LOOPS ANTI | | 16 |
| 12 | NESTED LOOPS ANTI | | 14 |
|* 13 | HASH JOIN | | 11 |
| 14 | BULK ROWSOURCE | index$_join$_008 | 1 |
|* 18 | HASH JOIN | | 10 |
| 19 | NESTED LOOPS | | 8 |
| 20 | NESTED LOOPS | | 6 |
| 21 | TABLE ACCESS BY INDEX ROWID| XXADM_COLLEGE_MASTER_TBL | 3 |
|* 22 | INDEX UNIQUE SCAN | XXADM_COLLEGES_PK | 2 |
| 23 | TABLE ACCESS BY INDEX ROWID| XXADM_LOV_MASTER_TBL | 5 |
|* 24 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 4 |
|* 25 | TABLE ACCESS FULL | XXADM_APPLICANT_COURSPREFS_TBL | 7 |
|* 26 | TABLE ACCESS FULL | XXADM_APPLICANT_DETAILS_TBL | 9 |
|* 27 | TABLE ACCESS BY INDEX ROWID | XXADM_APPLICANT_COURSPREFS_TBL | 13 |
|* 28 | INDEX UNIQUE SCAN | XXADM_APPLCNT_PREF_ORDER_UK | 12 |
| 29 | PRECISION ROWSOURCE | VW_SQ_1 | 15 |
| 35 | TABLE ACCESS BY INDEX ROWID | XXADM_LOV_MASTER_TBL | 18 |
|* 36 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 17 |
|* 37 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 20 |
|* 38 | INDEX UNIQUE SCAN | XXADM_LOVS_PK | 22 |
| 39 | TABLE ACCESS BY INDEX ROWID | XXADM_LOV_MASTER_TBL | 24 |
-----------------------------------------------------------------------------------------------
Figure 4-2
4.7 Once we’ve got this image sorted out we still have a few details to fill in before we’ve gpt the full picture of the execution plan.
- What does Oracle do to generate the “bulk rowsource” at operation 14
- What does Oracle do on every call to the “precision rowsource” at operation 29
- We know that the reduced plan above is the first child of a FILTER operation and if we refer back to previous “real main query” we know that there are three further children to the FILTER that might have to execute once for each row produced by the first child. So that’s another 3 (small) query blocks we need to examine in detail.
- We need to bring in the predicates to see how the optimizer has used them
- We need to look at the Starts and A-Rows to compare what happened with the optimizer’s expectation
- We need to look at disk reads and buffer gets to see how much excess work we did to acquire the data
5.0 Filling the Gaps
5.1 After getting the overall shape of the query’s execution we can go back and examine the bits we have so far postponed view. There are three pieces to consider
- the “bulk rowsource” at operation 14 that was the first child of a hash join.
- the “precision rowsource” at operation 29 that was the second child of a nested loop anti-join
- the filter subqueries that were the 2nd, 3rd and 4th children of the explicit FILTER at operation 6
5.2 We start with the “bulk rowsource” that was a VIEW with a highly suggestive name of index$_join$_008. This shows Oracle finding a way of selecting data from a table without visiting the table, using a couple of indexes as if they were skinny tables that could be scanned and joined. In effect Oracle has transformed “select key1, key2 from tableX” into something like:
select ix1.key1, ix2.key2
from
(select key1, rowid r1 from tableX) ix1,
(select key2, rowid r2 from tableX) ix2
where
ix1.r1 = ix2.r2
;
5.3 This strategy can only be used when Oracle knows that every relevant row will appear in the two indexes – which basically means you have to be careful about NULLs. In the simplest case you might have to have a NOT NULL constraint on at least one column in each of the target indexes; or a predicate in each inline view that ensures that Oracle can use just the index without losing some of the rowids that it needs. After acquiring key values and rowids from each index in turn, Oracle then joins the two sets of data using a hash join. Technically there is no limit to the number of indexes that Oracle can join in this fashion, the choice of strategy depends largely on how big the table is compared to the sum of the sizes of the indexes that could be used instead; practically (as in our main query) it’s rare to see more than two indexes used for this “index join” mechanism.
join index transformation query block SEL$082F290F, with parent
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 13 | HASH JOIN | | 1 | 5 | 557 (2)| 182 |00:00:00.02 | 2022 | 1599K| 1599K| 1503K (0)|
| 14 | VIEW | index$_join$_008 | 1 | 127 | 2 (0)| 127 |00:00:00.01 | 8 | | | |
|* 15 | HASH JOIN | | 1 | | | 127 |00:00:00.01 | 8 | 1368K| 1368K| 1522K (0)|
| 16 | INDEX FAST FULL SCAN | XXADM_LOVS_CODE_UK | 1 | 127 | 1 (0)| 127 |00:00:00.01 | 4 | | | |
| 17 | INDEX FAST FULL SCAN | XXADM_LOVS_PK | 1 | 127 | 1 (0)| 127 |00:00:00.01 | 4 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
5.4 Moving on to the “precision rowsource” that appears in the original plan as a VIEW PUSHED PREDICATE. This means that Oracle has optimised a non-mergeable view allowing for an input value from its parent. If you take operations 30 to 34 in complete isolation it’s just a simple nested loop join and you might wonder why the view is non-mergable. But when you look back at the parent you discover that it’s an ANTI-join, so Oracle has to say (for each driving row) “join these two tables and see if you get any rows as a result”, it doesn’t have a generic mechanism for doing two separate but consecutive (anti-)join operations at this point.
Unnested subquery SEL$A75BE177 (from sel$8, sel$9) with parent and its first child
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 11 | NESTED LOOPS ANTI | | 1 | 1 | 565 (2)| 182 |00:00:00.02 | 2752 | | | |
| 12 | Driving Rowsource | | 1 | 1 | 562 (2)| 182 |00:00:00.02 | 2388 | | | |
| 29 | VIEW PUSHED PREDICATE | VW_SQ_1 | 182 | 1 | 3 (0)| 0 |00:00:00.01 | 364 | | | |
| 30 | NESTED LOOPS | | 182 | 1 | 3 (0)| 0 |00:00:00.01 | 364 | | | |
|* 31 | TABLE ACCESS BY INDEX ROWID | XXADM_APPLICANT_COURSPREFS_TBL | 182 | 1 | 2 (0)| 0 |00:00:00.01 | 364 | | | |
|* 32 | INDEX UNIQUE SCAN | XXADM_APPLCNT_PREF_ORDER_UK | 182 | 1 | 1 (0)| 182 |00:00:00.01 | 184 | | | |
|* 33 | TABLE ACCESS BY INDEX ROWID | XXADM_CATEGORY_MASTER_TBL | 0 | 1 | 1 (0)| 0 |00:00:00.01 | 0 | | | |
|* 34 | INDEX UNIQUE SCAN | XXADM_CATEGORY_PK | 0 | 1 | 0 (0)| 0 |00:00:00.01 | 0 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
5.5 Finally we have the three filter subqueries, which I’ve shown with their parent FILTER and a one-liner for the driving rowsource. For each row in operation 7 we call operations 40, 42 and 44 in turn although the parent filter may decide after calling operation 40 that it doesn’t need to call the other two and can simply move on to the next row from operation 7. Similarly the filter might call operations 40 and 42 and not need to call operation 44. It’s also possible that, thanks to scalar subquery caching, Oracle can say “I’ve already called operation 40 for this value, so I know the result and don’t need to call it again”. When we look at the Starts and A-Rows columns for the three operations we will get some idea of how the “notional” execution sequence turned into an actual workload.
Filter subqueries SEL$5, SEL$6 and SEL$F665FE1B, with their parent and its first child
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|* 6 | FILTER | | 1 | | | 171 |00:00:00.02 | 3822 | | | |
| 7 | "Simplify" Plan | | 1 | 1 | 568 (2)| 182 |00:00:00.02 | 3128 | | | |
|* 40 | TABLE ACCESS BY INDEX ROWID BATCHED | XXADM_APPLICANT_COURSPREFS_TBL | 182 | 1 | 3 (0)| 29 |00:00:00.01 | 507 | | | |
|* 41 | INDEX RANGE SCAN | XXADM_APPLCNT_PREFS_UK | 182 | 5 | 2 (0)| 1450 |00:00:00.01 | 191 | | | |
| 42 | TABLE ACCESS BY INDEX ROWID BATCHED | XXADM_APPLICANT_COURSPREFS_TBL | 171 | 1 | 2 (0)| 0 |00:00:00.01 | 173 | | | |
|* 43 | INDEX RANGE SCAN | XXADM_APPLCNT_APPLICANT_STATUS | 171 | 1 | 1 (0)| 0 |00:00:00.01 | 173 | | | |
|* 44 | VIEW | index$_join$_014 | 6 | 1 | 0 (0)| 0 |00:00:00.01 | 14 | | | |
|* 45 | HASH JOIN | | 6 | | | 0 |00:00:00.01 | 14 | 1519K| 1519K| 666K (0)|
|* 46 | INDEX RANGE SCAN | XXADM_CATEGORY_PK | 6 | 1 | 0 (0)| 6 |00:00:00.01 | 6 | | | |
| 47 | INLIST ITERATOR | | 6 | | | 12 |00:00:00.01 | 8 | | | |
|* 48 | INDEX UNIQUE SCAN | XXADM_CATEGORY_CODE_UK | 12 | 1 | 0 (0)| 12 |00:00:00.01 | 8 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
5.6 The operations for the first two subqueries (40,41) and (42,43) shouldn’t need any explanation. The third set of operations (44 to 48) is a little more complex. In fact it’s similar to the mechanism that appeared in our first “bulk rowsource” – we have Oracle turning a table access into an “index (only) join”, collecting key values and rowids from two different indexes and doing a hash join on the rowids. The plan is just a little more subtle, though – instead of getting their data from “index fast full scans”, one index is accessed by a range scan (possibly using a predicate value passed in by the filter operation) and the other is using an INLIST ITERATOR with unique scan. In the second case we must be handling a predicate of the form: “key_column in {list of values}”. (Taking a first look at the Starts column we can see that the INLIST ITERATOR runs 6 times calling the INDEX UNIQUE SCAN a total of 12 times so it’s fairly obvious that there are exactly two elements in the list in this case.)
6.0 Looking at the Numbers
6.1 Rather than walking through the entire plan again putting the pieces together I’m going to assume that I can carry on to the next stage of analysis, and assume that the pieces will fall into place as we talk about some of the critical numbers.
6.2 It’s probably best to open a copy of the note in a separate window so that you can examine the plan and read my comments at the same time. Starting at the top we apply “first child first”, noting in passing that the examples of the VIEW operations we have in this plan don’t have a significicant impact on the order of operation as we work down the plan – they simply remind us that there are “non-mergeable” parts of the plan. Eventually we get to operation 13 which is a hash join and operations 14 through 17 give us the build (first) table – a quick check shows 127 rows for estimated (E-rows) and actual (A-rows); then we see the probe (second) table is itself a hash join returning 182 rows (estimate 487, so in the right ballpark) and the hash join at operation 13 produces a result set of 182 rows.
6.3 At this point a quick check back UP the plan tells us that the 182 rows survive all the way up to operation 6, where a FILTER eliminates just a few of them; then the result set drops to just 2 rows at operation 5. Then a quick check of operation 5 (with a cross reference to the query) reminds us that we have an inline view that does an “order by” followed by a “rownum < :bind” predicate – so the sort order by stop key at operation 5 is sorting all the data but only passing on the first two rows: so there’s no way we could have modified the join order to eliminate the redundant rows sooner.
6.4 So we see that we get the right volume of data at about the right moment in the plan, and probably can’t do much to avoid the volume of data access – but let’s check how we got the 182 rows at operation 18. Using “first child first” – we see a nested loop joining two “single row by unique index” rowsources, then a nested loop to a full tablescan of XXADM_APPLICANT_COURSPREFS_TBL. The knee-jerk reaction to a “full tablescan as the second table in a nested loop” is that it must be bad – but in this case we know that it will happen no more than once, so we don’t need to panic immediately. Applying a little more thought (and arithmetic): we note that the tablescan returns 209 rows (estimated 478) using 879 buffer gets; that’s not an extreme number of buffer gets per row (especially if the 478 is a reasonably accurate average for the operation). We’ll postpone worrying about the tablescan for the moment but take note that it might be worth revisiting.
6.5 The second child to the hash join at operation 18 is another full tablescan (of XXADM_APPLICANT_DETAILS_TBL) which requires 1,141 buffer gets. Again, though this might not be a bad move, since the alternative would be an actual 209 index probes (or an estimated average 478 index probes). The workload is, again, in the right ballpark but, again, something we might come back to. In fact in both tablescans it might be more important to worry about the work done at each row by the row predicates rather than worrying about the fact that the operation is a tablescan; a predicate involving a CPU-intensive PL/SQL function might be the thing that makes 478 index probes to 478 rows a better option than a tablescan of (say) 100,000 rows.
6.6 From this point onwards (operation 13) we have 6 nested loop joins (though the first two are anti-joins) so it’s “call the second child for each row in the first child” all the way down, and we’ve seen that we don’t eliminate any data as we go. If we want to make the execution plan any faster by “local” tweaking we’ll just have to make sure each “second child” operation is as efficient as possible, which tends to mean looking for cases where we supply a lots of rows (rowids) from an index range scan but find that we then discard the table rows after visiting the table. So …
6.6.1 Operation 12 – nested loop anti join – calls 28/27 (table access by unique index). We find an index entry on each call, but the table row doesn’t qualify – which is what we want for a “successful” anti-join. We could make this a little more efficient by adding a column to the (already unique) index and avoid visiting the table.
6.6.2 Operation 11 – nested loop anti join – calls operation 29 (view with pushed predicate) which operates a high-precision nested loop join at operation 30. The first child of operation 30 is a table access by index, but the table never returns a row (which is nice) so we never call the second child of operation 30. Again we could make this view access a little more efficient by adding extra columns to (already unique) indexes to avoid any need to visit tables.
6.6.3 Operations 10, 9, 8, 7 – nested loop joins – operating very efficiently, some not even visiting tables to acquire data. The order of operation at this point is: 11, 36, 35, 10, 37, 9. 38, 8, 19, 7. And then we get to the FILTER operation, which has 3 subqueries to operate in turn,
6.7 Operation 6 executes in turn the two subqueries we named sel$5 and sel$6 respectively, the first one 182 times, the second one 171 times. Since operation 6 produces 171 rows it seems likely that the initial 182 rows dropped to 171 rows as a consequence of the sel$5 subquery resulting in the smaller number of calls to the sel$6 subquery. It’s worth noting here that operation 41, the index range scan, returned 1,450 rowids, but the subsequent table accesses returned a total of only 29 rows after an additional 316 buffer gets (507 – 191). There may be an opportunity here (yet again) for adding an extra column to the index so that we visit the table only 29 times rather than visiting it 1,450 times. In fact, though it’s not obvious in this SQL Monitor report, the indications from other examples from the same query suggested that this subquery was the single more resource intensive part of the plan.
6.8 The last subquery executed by Operation 6 is the one identified by query block sel$4. The sub-plan starts with a VIEW operation because the table (identified as originating in sel$4 in the query block / object alias information) is “accessed” by way of an index hash join. This subquery is executed only 6 times. Given that there are (at least) 171 rows for which this subquery could be called this means one of two things. First we can from the query text that this subquery is part of a complex CASE expression – so maybe the simple conditions in the expression mean we rarely need to call the subquery;. secondly it could mean the run-time engine has managed to take advantage of scalar subquery caching and the query doesn’t have many distinct inputs for this subquery – and when we check the predicate section we can see the relevant predicate for a query against the XXADM_CATEGORY table was “category_id = {correlation variable}” which has the look of a table with a few rows and distinct ids..
6.9 In summary, then, there may be a few “localised” tweaks that we can to do improve performance of this plan – largely by adding columns to existing indexes and using them effectively. There are indications that one of the filter subqueries might be a particularly good target for this type of tweak; after which we might want to look at what could be done with the two tablescans which are in that grey area where it’s not easy to decide whether an indexed access or a tablescan is the better option. We have to remember, though, that this query was originaly reported as executing 842,000 times – so maybe we need to do much better than just a little tweaking.
7.0 Predicate Information
7.1 Why are we running a query 842,000 times in a batch? The right way to find an answer to that question is to ask the right person – if you can find them. A slightly more long winded way is to find out what is driving the 842,000 executions – and you might be able to do that if you have the full tkprof output from the trace file. (Hint: statement X runs 842,000 times, and if statement Y executes 13 times and produces 842,000 rows maybe Y is driving X.) Sometimes, though, you don’t have the people, or the full data set, or the access you need, so you might take a look at the query and the predicates and start making some reasonable guesses.
7.2 Here’s the tail end of the query, conveniently capturing all the input bind variables:
AND cmt.college_id = :p_college_id
AND crmt.course_id = :p_course_id
AND mmt.medium_id = :p_medium_id
AND act.hostel_required = :p_hostel_required
ORDER BY
order_of_pass,
course_qe_priority,
percentage DESC,
applicant_dob,
legacy_appln_date
)
WHERE
ROWNUM <= :p_seats
)
WHERE
applicant_id = :p_applicant_id
7.3 There are two things we can note about these predicates – first they don’t follow the pattern of “:Bnnn” so they’re not from a statement statically embedded in PL/SQL, secondly the names are intelligible and meaningful, so we might draw some tentative conclusions from them, in particular how many distinct values there might be and how this lead to 842,000 executions of the query.
7.4 The variable name that stands out is :p_applicant_id. We seem to be looking at a query about applicants for courses at colleges – and the latter pair probably gives us a relatively small number of combinations. The variable :p_hostel_required is surely just going to be a “yes/no/maybe/null” option. The :p_medium_id is a bit of a puzzle but scanning through the query it looks like it’s the id for the “medium of study” so probably another variable with a small number of values. So where in the plan do these variables get used? Here’s the full list of predicates from the plan, followed by an extra few lines showing just the predicates that reference the bind variables:
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("APPLICANT_ID"=:P_APPLICANT_ID)
3 - filter(ROWNUM<=:P_SEATS) -- > comment added to avoid wordpress format issue
5 - filter(ROWNUM<=:P_SEATS) -- > comment added to avoid wordpress format issue
6 - filter(( "ACT"."PREFERENCE_ORDER"<=NVL(,"ACT"."PREFERENCE_ORDER") -- > comment added to avoid wordpress format issue
AND "ACT"."PREFERENCE_ORDER">=NVL(,"ACT"."PREFERENCE_ORDER") AND CASE "ACT"."HOSTEL_REQUIRED"
WHEN 'Y' THEN CASE WHEN ("ADT"."DISTANCE_IN_KMS">20 AND "LMT_RELIGION"."LOV_CODE"='HINDU' AND IS NULL) THEN 1 ELSE 2 END ELSE 1 END =1))
13 - access("ADT"."APPLICANT_GENDER"="LMT_GENDER"."LOV_ID")
filter(CASE "ACT"."HOSTEL_REQUIRED" WHEN 'Y' THEN CASE WHEN ("LMT_EDUCATION_TYPE"."LOV_CODE"='COEDUCOL' AND "LMT_GENDER"."LOV_CODE"='FEMALE') THEN 2 ELSE 1 END
ELSE 1 END =1)
15 - access(ROWID=ROWID)
18 - access("ADT"."APPLICANT_ID"="ACT"."APPLICANT_ID")
22 - access("CMT"."COLLEGE_ID"=:P_COLLEGE_ID)
24 - access("CMT"."EDUCATION_TYPE"="LMT_EDUCATION_TYPE"."LOV_ID")
25 - filter(("ACT"."COURSE_ID"=:P_COURSE_ID AND "ACT"."COLLEGE_ID"=:P_COLLEGE_ID AND "ACT"."MEDIUM_ID"=:P_MEDIUM_ID AND "ACT"."HOSTEL_REQUIRED"=:P_HOSTEL_REQUIRED))
26 - filter(("ADT"."STATUS"='Active' AND "ADT"."COURSE_APPLIED_FOR"='DEG' AND (INTERNAL_FUNCTION("ADT"."COLLEGE_STATUS_FLAG") OR "ADT"."COLLEGE_STATUS_FLAG" IS
NULL)))
27 - filter("ACT3"."STATUS_FLAG"='O')
28 - access("ACT3"."APPLICANT_ID"="ADT"."APPLICANT_ID" AND "ACT"."PREFERENCE_ORDER"="ACT3"."PREFERENCE_ORDER")
31 - filter((INTERNAL_FUNCTION("ACT1"."STATUS_FLAG") AND NVL("ACT1"."ATTRIBUTE7",'N')='N'))
32 - access("ACT1"."APPLICANT_ID"="ADT"."APPLICANT_ID" AND "ACT1"."PREFERENCE_ORDER"="ACT"."PREFERENCE_ORDER")
33 - filter("CATEGORY_CODE"='OPENMERT')
34 - access("CATEGORY_ID"=TO_NUMBER("ACT1"."ATTRIBUTE1"))
36 - access("ADT"."PASS_TYPE"="LMT_PASS"."LOV_ID")
37 - access("ADT"."APPEARANCE_TYPE"="LMT_APPEARANCE"."LOV_ID")
38 - access("ADT"."RELIGION"="LMT_RELIGION"."LOV_ID")
40 - filter(("STATUS_FLAG"='B' OR "STATUS_FLAG"='C' OR "STATUS_FLAG"='O' OR "STATUS_FLAG"='T'))
41 - access("ACT1"."APPLICANT_ID"=:B1)
43 - access("ACT2"."APPLICANT_ID"=:B1 AND "STATUS_FLAG"='C')
44 - filter(("CATEGORY_ID"=:B1 AND INTERNAL_FUNCTION("CATEGORY_CODE")))
45 - access(ROWID=ROWID)
46 - access("CATEGORY_ID"=:B1)
48 - access(("CATEGORY_CODE"='BACKWRDC' OR "CATEGORY_CODE"='BACKWRDE'))
2 - filter("APPLICANT_ID"=:P_APPLICANT_ID)
3 - filter(ROWNUM<=:P_SEATS) -- > comment added to avoid wordpress format issue
5 - filter(ROWNUM<=:P_SEATS) -- > comment added to avoid wordpress format issue
22 - access("CMT"."COLLEGE_ID"=:P_COLLEGE_ID)
25 - filter(("ACT"."COURSE_ID"=:P_COURSE_ID AND "ACT"."COLLEGE_ID"=:P_COLLEGE_ID AND "ACT"."MEDIUM_ID"=:P_MEDIUM_ID AND "ACT"."HOSTEL_REQUIRED"=:P_HOSTEL_REQUIRED))
Figure 7-1
7.5 Apart from the predicates in the final shortlist you probably noticed further bind variables at operation 41, 43, 44, and 46 – but these are all named :B1, which is Oracle flagging up the need to pass correlating values into filter subqueries.
7.6 Operation 25 (where we test almost all the predicates) is one of the first operations to drive the query while operation 2 (where we test the :p_applicant_id) is close to the very last thing we do in the execution plan. So we generate a load of data for a college, course, and couple of other predicates, sort it then – at the last moment – decide that we only want a few (:p_seats) rows and count how many rows we’ve found for the specific applicant – and we do that a very large number of times. This takes me back to section 2 where I asked a couple of critical questions:
7.6.1 (2.3) First, how far into the view V_THING will the optimizer be able to push that predicate, possibly the entire content of the view will have to be constructed before the predicate can apply,
7.6.2 (2.8) I’m also a little curious about a requirement that seems to say – “pick at most N rows, then tell me how many you’ve picked”. What’s it actually trying to do and why?
7.7 We now know the answer to the first query – that predicate isn’t going anywhere, and we recognise why not, of course: it’s a consequence of the “rownum” pseudo-column which has to be evaluated for all the generated data before the rownum restriction can be applied: “select for the applicant then apply the rownum” is very different from “apply the rownum (column and predicate) then restrict to the applicant”. That brings us to the second question – why would you generate all the data, then order it, then restrict it to the first N, and then count how many times a specific applicant appeared? And there’s one “valid” answer to the last bit of the question – what if you’re not really trying to count how many times the applicant appeared, you’re only trying to find out whether the count is zero or non-zero.
7.8 The intent of the query is to answer the question: “does this applicant appear in the first N candidates”. Once you’ve realised this the underlying performance problem with the query becomes clear. In the monitored example show here the query found 171 applicants that matched the initial predicates – and at some point in the batch it’s going to do the same work all over again for each of the other 170 applicants that we’ve discarded. For each combination of the initial predicates (excluding applicant id and seat count) we run the query N times if there are N candidates that match that combination. It’s bad enough that this query took 0.02 seconds to run and would have run 172 times (for a total of 3,4 seconds) but another sample run took 0.05 seconds to run identifying 1,835 applicants (which means another 1,834 executions for a total of 91 seconds run time).
8.0 Resolution
8.1 There is a serious flaw in the design of this application. We are seeing a piece of code running once per applicant_id when (with some minor variations) it looks as if it should be running no more than once per set of distinct combinations of (course_id, college_id, medium_id, hostel_required). In fact, if the set of distinct combinations could be generated by a simple query, you could imagine the entire required result set as a join between two non-mergable views, with a little row-by-row post processing – but that might be too ambitious a change to implement in the short term.
8.2 Realistically (as a low-risk strategy) it might be possible to keep a very large percentage of the existing code structure for whatever this task does but precede it with a PL/SQL loop that steps through each of the distinct combinations required, populating a table (perhaps an IOT) with {applicant_id, (combination columns), “rownum”); and then replace our problem query by a simple primary key look up to find the saved “rownum” for each applicant and combination, to check whether the stored “rownum” was fell within the required seat count.
9.0 Summaryi
9.1 For a DBA working on-site, or a consultant on a short-term visit, the analysis shown in this post is probably not how things would have progressed. I could imagine the sequence of events being more like:
9.1.1 This “start of year / start of term” batch job takes too long
9.1.2 What is it trying to achieve (business overview) – sketch an outline of the process (technical overview)
9.1.3 Trace the job and discover most of the time went on this query
9.1.4 Investigate the logic of this query and why it is run for every applicant_id
9.1.5 Recognise the fundamental design threat then choose between three possible strategies:
9.1.5.1 make the query much faster
9.1.5.2 re-engineer this part of the batch completely
9.1.5.3 subvert this section of the batch to pre-build a “materialized result” and use a much simpler query to query it
9.2 Effectively, however, we’ve come in at 9.1.5.1 and run the consultation backwards. As we did so we raised an early question about the applicant_id and pushing predicates and the oddity of counting a limited list, and we finally came back to those points towards the end of the post with an educated guess about what the query was trying to achieve and how it should be reduced from “once per applicant” to “once per combination”.
9.3 Despite the post starting at the wrong place it’s quite possible that we would have reached 9.1.5.1 by following a sensible order of problem analysis, and still want to think about how the query might run more quickly – so this investigation wasn’t a total waste of time and it’s allowed us to work through a real-world query and plan in a realistic way which we can sum up in the following stages:
9.3.1 Simplify: cross-referencing between the overall plan shape, the Query Block / Object Alias information, and original query we can take out sections of the plan (sub-plans) and analyse them separately. In particular we can identify and reduce to a minimum the core of the plan that generates the final result set, calling on the various sub-plans as it goes.
9.3.2 Follow the workload: in this case we didn’t get much help from the timing information, but buffer gets, disk reads and A-rows also supply clues to where most work is done. Critically we noted that the volume of data we picked up early on in the query was needed all the way through the query – until the last moment – and we didn’t waste resources carrying and processing unnecessary rows. Along the way, of course, we compare Oracle’s predictions of data volume with the actual data volume (A-Rows = Starts * E-Rows as a guideline). We also noted a couple of opportunities where modifying indexes might eliminate table visits, potentially reducing I/O and buffer gets.
9.3.3 Check the predicates: which goes hand in hand with following the workload – how and where are our predicates used. What predicates have been generated (or eliminated) by transitive closure; which predicates are (or could be) pushed further down the plan tree to eliminate data earlier; will multiple predicates result in bad optimizer estimates followed by bad choices for access paths.
9.4 It would be nice to think that there was a simple progression, a fixed sequence of steps that one could follow to interpret an execution plan quickly and accurately. Unfortunately (like the optimisation process itself) interpretation requires a measure of looping and recursion. It’s probably always best to start with simplifying – but how much you simplify and how you pick which subplan to simplify (or start analysing in detail) depends on being able to spot where the biggest workload appears; and before you get stuck too deeply into a sub-plan you might glance down at the use of predicates because a change in one predicate might make the optimizer completely re-engineer its choice of plan. And maybe, before anything else, you’ll see a single operation which you know should (for exanple) generate about 10 rows when the optimizer is predicting 25,000 rows (or vice versa) and you’ll want to check why there’s such a bad estimate at one point in the plan before you tackle any of the harder questions.
9.5 The bottom line with execution plans is simply this: the more you practice the faster you get at spotting the clues that are worth pursuing; and the faster you spot the clues the less time you waste unpicking every little detail, and the less time you spend on the preripheral pieces of the plan the easier it becomes to keep the big picture in your mind and see how the optimizer got to where it is, and how you might want to redirect it. So pick a couple of random queries each week that produce plans of about 20 lines and use them to exercise your interpretation skills; and increase the complexity of the queries every couple of weeks.
The End
Footnote
I think I’ve spent more than 20 hours writing a detailed description of something that would normally take me a few minutes to do [and some poeple wonder why I’ve not yet written another book on the optimizer]. In part the difference in time is because with practice the “intuitive” skill grows and the pattern of reading is more like –
- How does it start (ignoring the “trivial” bits around the edges)
- How does it end ( ditto )
- Where do we do most work reading and discarding data
What I’ve done in this note is talk about every single query block and every single line whereas in real-life I might have scanned the plan, examined about 10 lines, and done a quick check on the corresponding predicates as the first step to deciding whether or not the plan was reasonably efficient.
