Execution Plan

DbProf.
com
www.dbprof.com - 2012 Joe Seneganik Oracle ACE Director
1
Execution Plan Interpretation
SANGAM12, November 2-3 2012,
Bangalore, India
Joe Seneganik
joze.senegacnik@dbprof.com
DbProf.
com
2
About the Speaker
Joe Seneganik
Registered private researcher
First experience with Oracle Version 4 in 1988
24 years of experience with Oracle RDBMS.
Proud member of the OakTable Network www.oaktable.net
Oracle ACE Director
Co-author of the OakTable book Expert Oracle Practices by
Apress (Jan 2010)
VP of Slovenian OUG (SIOUG) board
CISA Certified IS auditor
Blog about Oracle: http://joze-senegacnik.blogspot.com
PPL(A) private pilot license PPL(A) / instrument rated IR/SE
Blog about flying: http://jsenegacnik.blogspot.com
Blog about Building Ovens, Baking and Cooking:
http://senegacnik.blogspot.com
DbProf.
com
3
Agenda
1. Execution Plan Interpretation
2. SQL Monitor Feature (11g)
3. How to find an execution plan
DbProf.
com
4
Query Optimization
Query optimization is performed in two phases
1. Logical optimization (query transformation)
Among others also constraints are used by the CBO to
generate additional clauses during the query transformation
phase.
2. Physical optimization finds information
Possible access method to every table (full scan, index
lookup,...)
Possible join method for every join (HJ, SM, NL)
Join order for the query tables ( join( join( A,B ), C ) or ( join(
join( C,B ), A ) ...
DbProf.
com
5
Why Query Transformations?
The goal of transformation is to enhance the query
performance.
Transformation generates semantically equivalent form
of statement, which produces the same results, but
significantly differs in performance.
Transformation rely on algebraic properties that are not
always expressible in SQL, e.g, anti-join and semi-join.
DbProf.
com
6
Query Optimization
Query Search Space
Execution Plan Search Space
Q T
1
(Q) T
2
(T
1
(Q))
P
1
P
2
P
3
...
...
Search Space
Query Parser
Query Optimizer
(transforms queries
and generates candidate
execution plans)
Cost estimator
Plan with
lowest cost
logical optimization
physical optimization
DbProf.
com
7
Interpreting Execution Plans
DbProf.
com
8
Old Instructions For Plan Interpretation
We start to interpret execution plan from right most
operation and from the bottom to top.
SQL> explain plan for select * from t1 where c1=2000;
Explained.
SQL> select * from table(dbms_xplan.display());
---------------------------------------------------------------------
| Id | Operation | Name |Rows |Bytes|Cost (%CPU)|
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1| 56| 13 (8)|
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 1| 56| 13 (8)|
|* 2 | INDEX SKIP SCAN | T1_I1 | 1| | 12 (9)|
---------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("T1"."C1"=2000)
filter("T1"."C1"=2000)
DbProf.
com
9
Interpretation Rules (1)
RULE 1:
Id PId Execution path
N This action happens second
N+1 N This action sends result to the action above and left
Example:
---------------------------------------------------------------
| Id |PId| Operation | Name | Rows |
---------------------------------------------------------------
| 0| | SELECT STATEMENT | | 1 |
| 1| 0| TABLE ACCESS BY INDEX ROWID | T3 | 1 |
| 2| 1| INDEX UNIQUE SCAN | T3_I1 | 1 |
---------------------------------------------------------------
DbProf.
com
10
RULE 2:
ID PID POS Execution path
N Description of combining the data sets
N+1 N 1 Row source 1
N+x N 2 Row source 2
...
N+y N z Row source n
EXAMPLE:
-----------------------------------------------
| Id | Operation | Name | Rows |
-----------------------------------------------
| 0 | SELECT STATEMENT | | 918K|
|* 1 | HASH JOIN | | 918K|
| 2 | INDEX FAST FULL SCAN| T1_I1 | 918K|
| 3 | INDEX FAST FULL SCAN| T2_I1 | 918K|
-----------------------------------------------
DbProf.
com
11
RULE 2 interpretation instructions:
no automatic interpretation
interpretation depends on how the parent operation
combines children (see next slide)
Each child may be executed to completion
OR
it may get a row from child 1 and then execute child 2
etc. And then get next row from child 1
Execution of child 2 or 3 (...) may be omitted if not
required.
Parent operation behaves according to the
circumstances.
DbProf.
com
12
Interpretation Example (1)
SQL Statement:
SELECT featureid, geometry FROM
(SELECT izpp.ID featureid, grkx.raba_id, grkx.gerk_pid,
sbv_gerk_util.url_encode( ste_export.ret_val_intersect_ (izpp.ID, 'E') ) raba_ukrepi,
sdo_geom.sdo_intersection (izpp.geometry, :1, 0.0005) geometry
FROM izm_poligon_poljin izpp,
izm_poligon_zahtevki izpz,
sbv_gk_e gk
WHERE izpp.obrazec = 'E'
AND izpz.izpp_id = izpp.ID
AND izpz.sifra_ukrepa = 'SOR'
AND gk.ID = izpp.gk_id
AND sdo_relate (izpp.geometry, :2, 'mask=CONTAINS+COVERS') = 'TRUE')
DbProf.
com
13
Execution Plan:
HASH JOIN (cr=6681 r=4804 w=0 time=9773968 us)
NESTED LOOPS (cr=863 r=4 w=0 time=3742738 us)
TABLE ACCESS BY INDEX ROWID IZM_POLIGON_POLJIN (cr=839 r=0 w=0 time=3722978 us)
DOMAIN INDEX IZPP_GEOM_I (cr=749 r=0 w=0 time=3723034 us)
INDEX UNIQUE SCAN GRKE_PK (cr=24 r=4 w=0 time=182420 us)
TABLE ACCESS FULL IZM_POLIGON_ZAHTEVKI (cr=5818 r=4800 w=0 time=1911345 us)
cr = consistent reads
r = physical reads
w = physical writes
time = time elapsed in microseconds (0.000001s)
The values are reported cumulatively for the current and all previous
steps.
DbProf.
com
14
Interpretation Step 1: We apply Rule 2
cr, r and w values for parent operation is sum of
child operations values
DbProf.
com
15
DbProf.
com
16
DbProf.
com
17
SQL> select count(*) from (
2 select /*+ no_merge */ id
3 from t3
4* order by id )
-------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)|
-------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 543 (2)|
| 1 | SORT AGGREGATE | | 1 | |
| 2 | VIEW | | 918K| 543 (2)|
| 3 | INDEX FAST FULL SCAN| T3_I1 | 918K| 543 (2)|
-------------------------------------------------------------
ORDER BY operation is missing CBO sees that the
operation can be omitted
DbProf.
com
18
Optional Steps In Execution Plan (1)
SQL>ALTER TABLE JOC.T1 ADD ( CONSTRAINT C4_CHECK CHECK (c4 in (10,20,30))
ENABLE VALIDATE );
SQL>explain plan for select * from t1 where c4 >= 31;
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 28 | 0 (0)| |
|* 1 | FILTER | | | | | |
|* 2 | TABLE ACCESS FULL| T1 | 10 | 280 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------
---------------------------------------------------
1 - filter(NULL IS NOT NULL)
2 - filter(C4>=31)
NOT EXECUTED AT ALL!!
DbProf.
com
19
Major Types Of Operations
Christian Antognini in his book Troubleshooting
Oracle Perfromance defines three major types
of operations:
Standalone operations
Unrelated-combine operations
Related-combine operations
DbProf.
com
20
Stand-alone operations (1)
Standalone operations have at most one child.
Most operations are of this type.
The rules governing the working of these
operations are the following:
Children are executed before their parents. (there are
some exceptions like always )
Every child is executed at most once.
Every child feeds its parent.
DbProf.
com
21
Stand-alone Operation (2)
SQL> explain plan for
2 select * from t2
3 where c1 = 1201;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 25 | 2 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| T2 | 1 | 25 | 2 (0)|
|* 2 | INDEX RANGE SCAN | T2_I1 | 1 | | 1 (0)|
--------------------------------------------------------------------------
---------------------------------------------------
2 - access("C1"=1201)
DbProf.
com
22
Unrelated-combine operations (1)
Operations having multiple children that are
independently executed are unrelated-combine
operations.
Some typical operations of this type: HASH JOIN,
INTERSECTION, MERGE JOIN, MINUS, UNION-ALL,
AND-EQUAL, BITMAP AND, BITMAP OR, BITMAP
MINUS, CONCATENATION, CONNECT BY WITHOUT
FILTERING,, MULTI-TABLE INSERT, SQL MODEL,
TEMP TABLE TRANSFORMATION
The characteristics of these operations are the following:
Children are executed before their parents.
Children are executed sequentially.
Every child is executed at most once and independently the
others.
Every child feeds its parent.
DbProf.
com
23
Unrelated-combine operations (2)
2 select t1.c1, t1.c2, t2.c2
3 from t1, t2
4 where t1.c1 = t2.c1
5 and t1.c1 between 1501 and 1600;
----------------------------------------------------------------------------
----------------------------------------------------------------------------
|* 1 | HASH JOIN | | 100 | 1200 | 7 (15)|
|* 3 | INDEX RANGE SCAN | T1_C1 | 101 | | 2 (0)|
----------------------------------------------------------------------------
---------------------------------------------------
1 - access("T1"."C1"="T2"."C1")
3 - access("T1"."C1">=1501 AND "T1"."C1"<=1600)
5 - access("T2"."C1">=1501 AND "T2"."C1"<=1600)
1
2
DbProf.
com
24
Related-Combine Operations (1)
Related-combine operations are operations with multiple
children where one of the children controls the execution
of all other children.
The most common operation of this type are NESTED
LOOPS and FILTER
Characteristics:
Children are executed before their parents.
The child with the smallest id controls the execution of the other
children.
Children are not executed sequentially. Instead, a kind of
interleaving is performed.
Only the first child is executed at most once. All other children
may be executed several times or not executed at all.
Not every child feeds its parent.
DbProf.
com
25
Related-Combine Operations Nested Loop
2 select t1.c2,t2.c2
3 from t1,t2
4 where t1.c1 = t2.c1(+)
5 and t1.c1 in (100, 101, 103);
----------------------------------------------------------------------------
----------------------------------------------------------------------------
| 1 | NESTED LOOPS OUTER | | 3 | 36 | 8 (0)|
| 2 | INLIST ITERATOR | | | | |
| 5 | TABLE ACCESS BY INDEX ROWID | T2 | 1 | 6 | 1 (0)|
|* 6 | INDEX UNIQUE SCAN | T2_C1 | 1 | | 0 (0)|
----------------------------------------------------------------------------
---------------------------------------------------
4 - access("T1"."C1"=100 OR "T1"."C1"=101 OR "T1"."C1"=103)
6 - access("T1"."C1"="T2"."C1"(+))
DbProf.
com
26
EXAMPLE OPERATION:
INDEX ACCESS
PATHS
and
HASH JOIN
DbProf.
com
27
INDEX FULL SCAN
, >=120
10,15,17
>=20, >=67 >=145, >=185
20,27,58 67,89,119 120,125 146,150,173 185,190,202
Table blocks
select key from t3 order by key
DbProf.
com
28
Index Fast Full Scan
LEGEND:
SH=segment header
R=root block
L=leaf block
B=branch block
R L L L L L B L L B L
...
SH
multiblock read multiblock read
discard discard discard
db_file_multiblock_read_count=5
DbProf.
com
29
HASH JOIN
HASH JOIN
join cost = (cost of accessing outer table) + (cost of building hash table) + (cost of accessing inner
table )
========================================================================================================================
| Id | Operation | Name | Rows | Cost | Execs | Rows | Activity |
| | | | (Estim) | | | (Actual) | (%) |
========================================================================================================================
| 0 | SELECT STATEMENT | | | | 1 | 1594 | |
| 1 | SORT ORDER BY | | 203 | 34258 | 1 | 1594 | |
| 2 | HASH JOIN | | 203 | 34257 | 1 | 1594 | |
| 3 | HASH JOIN | | 38 | 12 | 1 | 11 | |
| 4 | TABLE ACCESS FULL | C_TYPE | 13 | 4 | 1 | 14 | |
| 5 | TABLE ACCESS FULL | C_PROD_DEF | 78 | 7 | 1 | 78 | |
. . .
First data source is (considered) smaller and thus candidate for creating a hash table in memory.
The second data source is accessed and probved against the memory hash table.
29
DbProf.
com
30
HASH JOIN
X X
X X
X
X
X
X X
X X
X X
X
X
30
HASH JOIN
DATA SOURCE 1
FTS/INDEX RS/FFS
DATA SOURCE 2
FTS/INDEX RS/FFS
Memory Hash Table - like a single table hash cluster
1234
8892
8929
1937
2939
4855
.
Values are scattered according to the
hash function in order to prevent false
positives.
DbProf.
com
31
Watch for Query Transformations
One of possible query transformations is Join Elimination (JE)
Eliminate unnecessary joins if there are constraints defined on join
columns. If join has no impact on query results it can be eliminated.
e.departmens_id is foreign key and joined to primary key d.department_id
Eliminate unnecessary outer joins doesnt even require primary key
foreign key relationship to be defined.
SQL> select e.first_name, e.last_name, e.salary
from employees e,
departments d
where e.department_id = d.department_id;
--------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
--------------------------------------+-----------------------------------+
| 0 | SELECT STATEMENT | | | | 3 | |
| 1 | TABLE ACCESS FULL | EMPLOYEES| 106 | 2332 | 3 | 00:00:01 |
--------------------------------------+-----------------------------------+
Predicate Information:
----------------------
1 - filter("E"."DEPARTMENT_ID" IS NOT NULL)
31
DbProf.
com
32
Watch for Query Transformations
SELECT distinct p.prod_id, p.prod_name
FROM products p, sales s
WHERE p.prod_id = s.prod_id
AND s.quantity_sold < (SELECT AVG (quantity_sold)
FROM sales
WHERE prod_id = p.prod_id);
SELECT DISTINCT P.PROD_ID ITEM_1,
P.PROD_NAME ITEM_2,
CASE WHEN S.QUANTITY_SOLD <
AVG(S.QUANTITY_SOLD) OVER ( PARTITION BY S.PROD_ID)
THEN S.ROWID END VW_COL_3
FROM SH.SALES S,SH.PRODUCTS P
WHERE P.PROD_ID=S.PROD_ID
SU - unnesting
aggregated
sub-query
DbProf.
com
33
Execution Plan for Transformed Query
SELECT DISTINCT P.PROD_ID ITEM_1,
P.PROD_NAME ITEM_2,
CASE WHEN S.QUANTITY_SOLD <
AVG(S.QUANTITY_SOLD) OVER ( PARTITION BY S.PROD_ID)
THEN S.ROWID END VW_COL_3
FROM SH.SALES S,SH.PRODUCTS P
WHERE P.PROD_ID=S.PROD_ID
--------------------------------------------
| Id | Operation | Name |
--------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | HASH UNIQUE | |
|* 2 | VIEW | VW_WIF_1 |
| 3 | WINDOW SORT | |
|* 4 | HASH JOIN | |
| 5 | TABLE ACCESS FULL | PRODUCTS |
| 6 | PARTITION RANGE ALL| |
| 7 | TABLE ACCESS FULL | SALES |
--------------------------------------------
---------------------------------------------------
2 - filter("VW_COL_3" IS NOT NULL)
4 - access("P"."PROD_ID"="S"."PROD_ID")
DbProf.
com
34
Partition Pruning
CBO ability to eliminate partitions that do not need to be
scanned, and only access those which are concerned by
predicates
Used in
Range, LIKE, equality, and IN-list predicates on the range or list
partitioning columns
Equality and IN-list predicates on the hash partitioning columns.
Range partition level and at the hash or list subpartition level
using on composite partitioned objects
Reduces the amount of data retrieved from disk and shortens the
response time
Can be applied on tables and indexes
With a global partitioned index, partition pruning also
eliminates index partitions even when the partitions of the
underlying table cannot be eliminated.
DbProf.
com
35
Types of Partition Pruning
Static pruning
Occurs at statement compile-time - the partitions to be
accessed are known in advance
Constant literal on the partition key column is used
Dynamic pruning
Occurs at run-time - the exact partitions to be accessed
by a statement are not known in advance
example: bind variables, partitions determined by a
subquery,...
DbProf.
com
36
Static Partition Pruning
The partitions to be accessed are determined at
compile time.
Occurs when:
the predicates on the partitioning columns use un
equality or a range predicate.
the predicates must only use constants to enable
CBO to determine the start and stop partition at
compile time.
If static partition pruning is used the actual
partition numbers show up in the Pstart and
Pstop columns of the explain plan.
DbProf.
com
37
Partition Pruning Techniques
Basic Partition Pruning
equality, range, and IN-list are the most commonly
used cases of partition pruning.
Advanced partition pruning techniques
presence of more complex predicates or SQL
statements
bind variables depends on the current value of bind
variable - KEY
IN-list partition pruning - KEY(I)
Partition pruning based on subquery - cost-based decision -
KEY(SQ)
Partition pruning based on OR - KEY(OR)
Bloom filtering used in latest versions of 10g and in 11g
not documented yet!!! - :BF0000
DbProf.
com
38
Some examples of Dynamic Partition Pruning
The actual partitions are determined in runtime.
For IN-list predicate the plan output will show KEY(I) in the partition
start and stop column.
SQL> explain plan for select * from sales where time_id in ('23.11.01','25.11.01');
Explained.
----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1259 | 36511 | 186 (0)| 00:00:03 | | |
| 1 | INLIST ITERATOR | | | | | | | |
| 2 | PARTITION RANGE ITERATOR | | 1259 | 36511 | 186 (0)| 00:00:03 |KEY(I) |KEY(I) |
| 3 | TABLE ACCESS BY LOCAL INDEX ROWID| SALES | 1259 | 36511 | 186 (0)| 00:00:03 |KEY(I) |KEY(I) |
| 4 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 5 | BITMAP INDEX SINGLE VALUE | SALES_TIME_BIX | | | | |KEY(I) |KEY(I) |
----------------------------------------------------------------------------------------------------------------------
---------------------------------------------------
5 - access("TIME_ID"='23.11.01' OR "TIME_ID"='25.11.01')
DbProf.
com
39
PARTITION RANGE SUBQUERY (10g)
2 SELECT /*+ use_hash(s t) */ t.day_number_in_month, SUM(s.amount_sold)
3 FROM sales s, times t
4 WHERE s.time_id = t.time_id
5 AND t.calendar_month_desc='2000-12'
6 GROUP BY t.day_number_in_month;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows |Cost | Pstart| Pstop |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 20 | 645| | |
| 1 | HASH GROUP BY | | 20 | 645| | |
|* 2 | HASH JOIN | | 19153 | 637| | |
|* 3 | TABLE ACCESS FULL | TIMES | 30 | 17| | |
| 4 | PARTITION RANGE SUBQUERY| | 918K| 574|KEY(SQ)|KEY(SQ)|
| 5 | TABLE ACCESS FULL | SALES | 918K| 574|KEY(SQ)|KEY(SQ)|
--------------------------------------------------------------------------
---------------------------------------------------
2 - access("S"."TIME_ID"="T"."TIME_ID")
3 - filter("T"."CALENDAR_MONTH_DESC"='2000-12')
DbProf.
com
40
Same Statement with NL Join
2 SELECT t.day_number_in_month, SUM(s.amount_sold)
----------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------
| 1 | HASH GROUP BY | | 20 | 640 | 232 (1)| 00:00:03 | | |
| 2 | NESTED LOOPS | | | | | | | |
| 3 | NESTED LOOPS | | 19153 | 598K| 231 (0)| 00:00:03 | | |
|* 4 | TABLE ACCESS FULL | TIMES | 30 | 570 | 18 (0)| 00:00:01 | | |
| 5 | PARTITION RANGE ITERATOR | | | | | | KEY | KEY |
| 6 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 7 | BITMAP INDEX SINGLE VALUE | SALES_TIME_BIX | | | | | KEY | KEY |
| 8 | TABLE ACCESS BY LOCAL INDEX ROWID| SALES | 629 | 8177 | 231 (0)| 00:00:03 | 1 | 1 |
----------------------------------------------------------------------------------------------------------------------
---------------------------------------------------
DbProf.
com
41
Same Statement with Bloom Filter (11g)
2 SELECT /*+ use_hash(s t) */ t.day_number_in_month, SUM(s.amount_sold)
Explained.
---------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------
| 1 | HASH GROUP BY | | 20 | 640 | 517 (4)| 00:00:07 | | |
|* 2 | HASH JOIN | | 19153 | 598K| 515 (4)| 00:00:07 | | |
| 3 | PART JOIN FILTER CREATE | :BF0000 | 30 | 570 | 18 (0)| 00:00:01 | | |
| 5 | PARTITION RANGE JOIN-FILTER| | 918K| 11M| 493 (3)| 00:00:06 |:BF0000|:BF0000|
| 6 | TABLE ACCESS FULL | SALES | 918K| 11M| 493 (3)| 00:00:06 |:BF0000|:BF0000|
---------------------------------------------------------------------------------------------------------
---------------------------------------------------
:BF0000 stands for Bloom filter
DbProf.
com
42
How Bloom Filter Works?
---------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------
| 1 | HASH GROUP BY | | 20 | 640 | 517 (4)| 00:00:07 | | |
|* 2 | HASH JOIN | | 19153 | 598K| 515 (4)| 00:00:07 | | |
| 3 | PART JOIN FILTER CREATE | :BF0000 | 30 | 570 | 18 (0)| 00:00:01 | | |
| 5 | PARTITION RANGE JOIN-FILTER| | 918K| 11M| 493 (3)| 00:00:06 |:BF0000|:BF0000|
| 6 | TABLE ACCESS FULL | SALES | 918K| 11M| 493 (3)| 00:00:06 |:BF0000|:BF0000|
---------------------------------------------------------------------------------------------------------
---------------------------------------------------
Step 4 table TIMES is accessed and rows passing the filter
CALENDAR_MONTH_DESC"='2000-12 are returned
STEP 3 a bloom filter is created with the information which partitions contain the relevant
rows; at the same time a memory hash table is built for the outer data source
Step 5 and 6 only partitions which contain relevant data according to the bloom filter :BF0000
are accessed and the rows are probed against memory hash table and if they match
("S"."TIME_ID"="T"."TIME_ID") a join is preformed
DbProf.
com
43
SQL Monitoring
DbProf.
com
44
SQL Plan Monitor (1)
New 11gR1 feature requires Tuning pack licensing
New views V$SQL_MONITOR, V$SQL_PLAN_MONITOR
Automatically kicks in for statements running longer than 5 seconds.
Captures statistics about SQL execution every second.
For parallel execution every process involved gets separate entries in
V$SQL_MONITOR and V$SQL_PLAN_MONITOR
Enabled by default for long running statements if parameter
CONTROL_MANAGEMENT_PACK_ACCESS if it is set to
DIAGNOSTIC+TUNING and STATISTICS_LEVEL=ALL|TYPICAL
DbProf.
com
45
SQL Plan Monitor (2)
Can be enabled at statement level with /*+ MONITOR */
hint or disabled with /*+ NO_MONITOR */ hint
Defaults (hidden parameters):
_sqlmon_max_plan - Maximum number of plans entry that can be
monitored. Defaults to 20 per CPU
_sqlmon_max_planlines - Number of plan lines beyond which a plan
cannot be monitored (default 300)
DbProf.
com
46
V$SQL_MONITOR, V$SQL_PLAN_MONITOR
SQL> SELECT status, KEY, SID, sql_id, elapsed_time, cpu_time, fetches, buffer_gets,
2 disk_reads
3 FROM v$sql_monitor;
STATUS KEY SID SQL_ID ELAPSED_TIME CPU_TIME FETCHES BUFFER_GETS DISK_READS
--------- ----------- --- ------------- ------------ ---------- ------- ----------- ----------
EXECUTING 21474836481 170 b0zm3w4h1hbff 674281628 624578125 0 0 0
SQL> SELECT plan_line_id, plan_operation || ' ' || plan_options operation,
2 starts, output_rows
3 FROM v$sql_plan_monitor
4 ORDER BY plan_line_id;
PLAN_LINE_ID OPERATION STARTS OUTPUT_ROWS (A-Rows)
------------ --------------------- ---------- -----------
0 SELECT STATEMENT 1 0
1 SORT AGGREGATE 1 0
2 MERGE JOIN CARTESIAN 1 4283731363
3 MERGE JOIN CARTESIAN 1 156731
4 INDEX FAST FULL SCAN 1 3
5 BUFFER SORT 3 156731
7 BUFFER SORT 156731 4283731363
DbProf.
com
47
SQL Monitoring Output (1)
dbms_sqltune.report_sql_monitor
SQL Plan Monitoring Details (Plan Hash Value=2056254005)
=====================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs |
| | | | (Estim) | | Active(s) | Active | |
=====================================================================================================================
| 0 | SELECT STATEMENT | | | | 1 | +4 | 1 |
| 1 | SORT ORDER BY | | 24 | 39 | 1 | +4 | 1 |
| 2 | VIEW | EB_STMTEND | 24 | 38 | 1 | +4 | 1 |
| 3 | SORT UNIQUE | | 24 | 38 | 1 | +4 | 1 |
| 4 | UNION-ALL | | | | 1 | +4 | 1 |
| 5 | NESTED LOOPS | | | | 1 | +4 | 1 |
| 6 | NESTED LOOPS | | 1 | 6 | 1 | +4 | 1 |
| 7 | NESTED LOOPS | | 1 | 5 | 1 | +4 | 1 |
| 8 | TABLE ACCESS BY INDEX ROWID | EB_ACCOUNT_BAL | 1 | 3 | 1 | +4 | 1 |
| 9 | INDEX UNIQUE SCAN | EB_ACCT_BAL_UIDX | 1 | 2 | 1 | +4 | 1 |
| 10 | TABLE ACCESS BY INDEX ROWID | RB_STMT_MAST_SK | 1 | 2 | 1 | +4 | 1 |
| 11 | INDEX RANGE SCAN | RXM_INTERNAL_KEY_PK | 1 | 1 | 1 | +4 | 1 |
| 12 | INDEX UNIQUE SCAN | RSM_INTERNAL_KEY_PK | 1 | | 1 | +4 | 2 |
| 13 | TABLE ACCESS BY INDEX ROWID | RB_STMT | 1 | 1 | 1 | +4 | 2 |
| 14 | NESTED LOOPS | | | | 1 | +4 | 1 |
| 15 | NESTED LOOPS | | 23 | 30 | 1 | +4 | 1 |
| 16 | NESTED LOOPS | | 23 | 7 | 1 | +4 | 1 |
| 17 | TABLE ACCESS BY INDEX ROWID | EB_ACCOUNT_BAL | 1 | 3 | 1 | +4 | 1 |
| 18 | INDEX UNIQUE SCAN | EB_ACCT_BAL_UIDX | 1 | 2 | 1 | +4 | 1 |
| 19 | TABLE ACCESS BY INDEX ROWID | RB_STMT_MAST_HIST_SK | 23 | 4 | 4 | +1 | 1 |
| | | | | | | | |
| 20 | INDEX RANGE SCAN | RB_STMT_MAST_HIST_SK_I1 | 2 | 1 | 1 | +4 | 1 |
| 21 | INDEX UNIQUE SCAN | RSM_INTERNAL_KEY_PK | 1 | | 1 | +4 | 1133 |
| 22 | TABLE ACCESS BY INDEX ROWID | RB_STMT | 1 | 1 | 1 | +4 | 1133 |
=====================================================================================================================
DbProf.
com
48
SQL Monitoring Output (2)
dbms_sqltune.report_sql_monitor
========================================================================================================================
Operation | Name | Rows | Rows | Read | Read | Mem | Activity |
| | (Estim) | (Actual) | Reqs | Bytes | (Max) | (%) |
========================================================================================================================
SELECT STATEMENT | | | 1135 | | | | |
SORT ORDER BY | | 24 | 1135 | | | 178K | |
VIEW | EB_STMTEND | 24 | 1135 | | | | |
SORT UNIQUE | | 24 | 1135 | | | 195K | |
UNION-ALL | | | 1135 | | | | |
NESTED LOOPS | | | 2 | | | | |
NESTED LOOPS | | 1 | 2 | | | | |
NESTED LOOPS | | 1 | 2 | | | | |
TABLE ACCESS BY INDEX ROWID | EB_ACCOUNT_BAL | 1 | 1 | | | | |
INDEX UNIQUE SCAN | EB_ACCT_BAL_UIDX | 1 | 1 | | | | |
TABLE ACCESS BY INDEX ROWID | RB_STMT_MAST_SK | 1 | 2 | | | | |
INDEX RANGE SCAN | RXM_INTERNAL_KEY_PK | 1 | 2 | | | | |
INDEX UNIQUE SCAN | RSM_INTERNAL_KEY_PK | 1 | 2 | | | | |
TABLE ACCESS BY INDEX ROWID | RB_STMT | 1 | 2 | | | | |
NESTED LOOPS | | | 1133 | | | | |
NESTED LOOPS | | 23 | 1133 | | | | |
NESTED LOOPS | | 23 | 1133 | | | | |
TABLE ACCESS BY INDEX ROWID | EB_ACCOUNT_BAL | 1 | 1 | | | | |
INDEX UNIQUE SCAN | EB_ACCT_BAL_UIDX | 1 | 1 | | | | |
TABLE ACCESS BY INDEX ROWID | RB_STMT_MAST_HIST_SK | 23 | 1133 | 20 | 160KB | | 100.00 |
INDEX RANGE SCAN | RB_STMT_MAST_HIST_SK_I1 | 2 | 1134 | | | | |
INDEX UNIQUE SCAN | RSM_INTERNAL_KEY_PK | 1 | 1133 | | | | |
TABLE ACCESS BY INDEX ROWID | RB_STMT | 1 | 1133 | | | | |
========================================================================================================================
DbProf.
com
49
SQL Monitor Output In EM
DbProf.
com
50
How To Find An Execution Plan
DbProf.
com
51
Explain Plan Utility
Result stored in PLAN_TABLE which is Oracle version dependant!
This is a theoretical plan, actual runtime plan may differ due to bind
variable peeking, Adaptive Cursor Sharing, Automatic Feedback
Cardinality Tuning, ...
$ORACLE_HOME/rdbms/admin/utlxplan.sql creates PLAN_TABLE
Use DBMS_XPLAN package utility to format results of a explain plan
Autotrace uses the same package since 10.2
explain plan for select * from my_table;
select * from table(dbms_xplan.display);
DbProf.
com
52
Parent / Child Cursors
Each SQL statement has
Parent cursor
One or more child cursors
Each parent requires at least one child cursor
Parent
Cursor
Child
Cursor
0
Child
Cursor
1
Child
Cursor
2
Child
Cursor
3
DbProf.
com
53
DBMS_XPLAN
Displaying from cursor cache (V$SQL, V$SQL_PLAN)
We can obtain different run-time statistics like IOSTATS,
MEMSTATS, or statistics for the LAST run only.
Use hint /*+ gather_plan_statistics */
DBMS_XPLAN.DISPLAY_CURSOR( sql_id IN VARCHAR2 DEFAULT NULL,
child_number IN NUMBER DEFAULT NULL,
format IN VARCHAR2 DEFAULT 'TYPICAL');
DbProf.
com
54
DBMS_XPLAN (2)
DBMS_XPLAN.DISPLAY( table_name IN VARCHAR2 DEFAULT 'PLAN_TABLE',
statement_id IN VARCHAR2 DEFAULT NULL,
format IN VARCHAR2 DEFAULT 'TYPICAL',
filter_preds IN VARCHAR2 DEFAULT NULL);
DBMS_XPLAN.DISPLAY_AWR( sql_id IN VARCHAR2,
plan_hash_value IN NUMBER DEFAULT NULL,
db_id IN NUMBER DEFAULT NULL,
format IN VARCHAR2 DEFAULT TYPICAL);
To display a statements plan from AWR Runtime plans
Displaying explain plan from PLAN_TABLE Theoretical plan
DbProf.
com
55
DBMS_XPLAN(4) 11g
Used to display one or more execution plans for the
specified SQL handle of a SQL Plan Baseline
DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE (
sql_handle IN VARCHAR2 := NULL,
plan_name IN VARCHAR2 := NULL,
format IN VARCHAR2 := 'TYPICAL');
DbProf.
com
56
Execution Plan Differences (1)
dbms_xplan.diff_plan_cursor(
sql_id IN VARCHAR2,
cursor_child_num1 IN NUMBER,
cursor_child_num2 IN NUMBER)
RETURN VARCHAR2;
dbms_xplan.diff_plan_awr(
sql_id IN VARCHAR2,
plan_hash_value1 IN NUMBER,
plan_hash_value2 IN NUMBER)
RETURN VARCHAR2;
DbProf.
com
57
DBMS_XPLAN Parameters
DBMS_XPLAN format parameter:
basic | typical | serial | all | advanced
DBMS_XPLAN format modifiers:
alias | bytes | cost | outline | parallel | partition | peeked_binds |
predicate | projection | remote | rows
select * from table(
DBMS_XPLAN.DISPLAY_CURSOR
('8wccfj60yh0us',null,'TYPICAL +OUTLINE')
);
DbProf.
com
58
Event 10053 trace
Event 10053 switches on CBO trace
SQL> alter session set events
10053 trace name context forever, level 1;
Useful to find out why CBO has chosen certain execution
plan.
Hard to interpret no tools available!
See Metalink Note:338137.1 CASE STUDY: Analyzing
10053 Trace Files for explanation
Jonathan Lewis: Cost Based Oracle
Wolfgang Breitlings site http://www.centrexcc.com
DbProf.
com
59
References:
Christian Antognini, Interpreting Execution
Plans, 2009
Christian Antognini, Troubleshooting
Oracle Performance
DbProf.
com
60
Q&A
Thank you for your interest!

Execution Plan

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Execution Plan

Uploaded by

Copyright:

Available Formats

DbProf.

You might also like