Escolar Documentos
Profissional Documentos
Cultura Documentos
Document 46234.1
Type: FAQ
Note: This article was developed under the Oracle 8i time frame but much of the information contained herein is still relevant on more recent
A new version of this article has been created as follows:
Document 1616894.1 Interpreting Explain Plan (10g and Above)
Predicate
Tuples
- rows
Driving Table - This is the row source that we use to seed the query.
If this returns a lot of rows then this can have a negative
affect on all subsequent operations
Probed Table - This is the object we look-up data in after we have retrieved
relevant key data from the driving table.
How does Oracle access data?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At the physical level Oracle reads blocks of data.
The smallest amount of data read is a single Oracle block, the largest is
constrained by operating system limits (and multi-block i/o).
Logically Oracle finds the data to read by using the following methods:
Full Table Scan (FTS)
Index Look-up (unique & non-unique)
Rowid
Explain plan Hierarchy
~~~~~~~~~~~~~~~~~~~~~~
Simple explain plan:
Query Plan
----------------------------------------SELECT STATEMENT
[CHOOSE] Cost=1234
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
1/15
6/24/2014
Document 46234.1
[CHOOSE] Cost=1234
However the explain plan below indicates the use of the RBO because the cost
field is blank:
SELECT STATEMENT
[CHOOSE] Cost=
The cost field is a comparative cost that is used internally to determine the
best cost for particular plans. The costs of different statements are not
really directly comparable.
[:Q65001] indicates that this particular part of the query is being executed
in parallel. This number indicates that the operation will be processed by a
parallel query slave as opposed to being executed serially.
[ANALYZED] indicates that the object in question has been analyzed and there
are currently statistics available for the CBO to use. There is no indication
of the 'level' of analysis done.
More about Plans and the order of execution
===========================================
To understand plans and the order of execution, it is necessary to
understand the PARENT -- CHILD relationships involved:
PARENT
FIRST CHILD
SECOND CHILD
In this example, the FIRST CHILD is executed first followed by the
SECOND CHILD, then the PARENT collates the output in some way.
A more complex case is:
PARENT1
FIRST CHILD
FIRST GRANDCHILD
SECOND CHILD
Here the same principles apply, the FIRST GRANDCHILD is the initial operation
then the FIRST CHILD followed by the SECOND CHILD and finally the PARENT
collates the output.
These priniples can be applied to real operations as in the examples below.
Consider the following query:
EXAMPLE 1
=========
set autotrace traceonly explain
select ename,dname
from emp, dept
where emp.deptno=dept.deptno
and dept.dname in ('ACCOUNTING','RESEARCH','SALES','OPERATIONS');
15 rows selected.
This produces the following explain plan:
Execution Plan
---------------------------------------------------------0
SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=8 Bytes=248)
1
0 HASH JOIN (Cost=3 Card=8 Bytes=248)
2
1
TABLE ACCESS (FULL) OF 'DEPT' (Cost=1 Card=3 Bytes=36)
3
1
TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=16 Bytes=304)
In the Execution Plan above, there are 2 columns of numbers that precede
the plan text of each line. The first number is the Statement ID
(usually known simply as "ID"), the second number is the Parent ID
of the line (The first line of the plan shows no parent because,
as the first line, it has no parent). The ID and PARENT ID are what
the plan generator uses to construct the explain plan.
The steps in the explain plan are indented to indicate the hierarchy of
operations and which steps are dependent on which other steps.
What follows is a walk-through of the plan above:
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
2/15
6/24/2014
Document 46234.1
EXAMPLE 2
=========
select /*+ RULE */ ename,dname
from dept , emp
where emp.deptno=dept.deptno
and dept.dname in ('ACCOUNTING','RESEARCH','SALES','OPERATIONS');
Execution Plan
---------------------------------------------------------0
SELECT STATEMENT Optimizer=HINT: RULE
1
0 NESTED LOOPS
2
1
TABLE ACCESS (FULL) OF 'EMP'
3
1
TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'
4
3
INDEX (UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
3/15
6/24/2014
Document 46234.1
Index lookup
~~~~~~~~~~~~
Data is accessed by looking up key values in an index and returning rowids.
A rowid uniquely identifies an individual row in a particular data block.
This block is read via single block i/o.
In this example an index is used to find the relevant row(s) and then the
table is accessed to lookup the ename column (which is not included in the
index):
SQL> explain plan for select empno,ename from emp where empno=10;
Query Plan
-----------------------------------SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX UNIQUE SCAN EMP_I1
Notice the 'TABLE ACCESS BY ROWID' section. This indicates that the table data
is not being accessed via a FTS operation but rather by a rowid lookup. In this
case the rowid has been produced by looking up values in the index first.
The index is being accessed by an 'INDEX UNIQUE SCAN' operation. This is
explained below. The index name in this case is EMP_I1.
If all the required data resides in the index then a table lookup may be
unnecessary and all you will see is an index access with no table access.
In the following example all the columns (empno) are in the index. Notice that
no table access takes place:
SQL> explain plan for select empno from emp where empno=10;
Query Plan
-----------------------------------SELECT STATEMENT [CHOOSE] Cost=1
INDEX UNIQUE SCAN EMP_I1
Indexes are presorted so sorting may be unecessary if the sort order required
is the same as the index.
e.g.
SQL> explain plan for
select empno,ename
from emp
where empno > 7876 order by empno;
Query Plan
-------------------------------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=1
TABLE ACCESS BY ROWID EMP [ANALYZED]
INDEX RANGE SCAN EMP_I1 [ANALYZED]
In this case the index is sorted so ther rows will be returned in the order of
the index hence a sort is unecessary.
explain plan for
select /*+ Full(emp) */ empno,ename
from emp
where empno> 7876 order by empno;
Query Plan
-------------------------------------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=9
SORT ORDER BY
TABLE ACCESS FULL EMP [ANALYZED] Cost=1 Card=2 Bytes=66
Because we have forced a FTS the data is unsorted and so we must sort the data
after it has been retrieved.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
4/15
6/24/2014
Document 46234.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
5/15
6/24/2014
Document 46234.1
Rowid
~~~~~
This is the quickest access method available.
Oracle retrieves the specified block and extracts the rows it is
interested in.
Most frequently seen in explain plans as Table access by Rowid
Access by rowid :
SQL> explain plan for select * from dept where rowid = ':x';
Execution Plan
---------------------------------------------------------0
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=18)
1
0 TABLE ACCESS (BY USER ROWID) OF 'DEPT' (Cost=1 Card=1 Bytes=18)
(BY USER ROWID) shows that the user provided the rowid.
Table is accessed by rowid following index lookup:
SQL> explain plan for
select empno,ename from emp where empno=10;
Execution Plan
---------------------------------------------------------0
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=19)
1
0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (Cost=1 Card=1 Bytes=19)
2
1
INDEX (RANGE SCAN) OF 'EMP_PK' (UNIQUE) (Cost=1 Card=1)
(BY INDEX ROWID) shows that the rowid comes from the index access in the
step with ID = 2.
Joins
=====
A Join is a predicate that attempts to combine 2 row sources
We only ever join 2 row sources together:
At a given time only one Join Step is performed even though underlying
row sources may have been accessed in parallel. Once 2 row sources have been
the resultant row source can start to be joined it to other row sources.
Note that some join methods (such as nested loops) allow a batch of
fetched rows to be returned to the higher levels before fetching the next batch.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
6/15
6/24/2014
Document 46234.1
If the row sources are already (known to be) sorted then the sort operation is
unecessary as long as both 'sides' are sorted using the same key.
Presorted row sources include indexed columns and row sources that have already
been sorted in earlier steps.
Although the merge of the 2 row sources is handled serially, the row sources
could be accessed in parallel.
SQL> explain plan for
select /*+ ordered */ e.deptno,d.deptno
from emp e,dept d
where e.deptno = d.deptno
order by e.deptno,d.deptno;
Query Plan
------------------------------------SELECT STATEMENT [CHOOSE] Cost=17
MERGE JOIN
SORT JOIN
TABLE ACCESS FULL EMP [ANALYZED]
SORT JOIN
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
7/15
6/24/2014
Document 46234.1
-- Probe ->
-- Probe ->
-- Probe ->
Row source 2
Row source 2
Row source 2
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
8/15
6/24/2014
Document 46234.1
~~~~~~
There are a number of different operations that promote sorts
order by clauses
group by
sort merge join
Note that if the row source is already appropriately sorted then no sorting is
required. This is now indicated in 7.3:
SORT GROUP BY NOSORT
INDEX FULL SCAN .....
In this case the group by operation simply groups the rows it does not do the
sort operation as this has already been completed.
Sorts are expensive operations especially on large tables where the rows do
not fit in memory and spill to disk. By default sort blocks are placed into the
buffer cache. This may result in aging out of other blocks that may be reread
by other processes. To avoid this you can use the parameter
<Parameter:SORT_DIRECT_WRITES> which does not place sort blocks into the buffer
cache.
Filter
~~~~~~
Has a number of different meanings
used to indicate partition elimination
may also indicate an actual filter step where one row source is filtering
another
functions such as min may introduce filter steps into query plans
In this example there are 2 filter steps. The first is effectively like a NL
except that it stops when it gets something that it doesn't like
(i.e. a bounded NL). This is there because of the not in.
The second is filtering out the min value:
SQL> explain plan for
select *
from emp
where empno not in (select min(empno) from big_emp group by empno);
Query Plan
-----------------SELECT STATEMENT [CHOOSE] Cost=1
FILTER
**** This is like a bounded nested loops
TABLE ACCESS FULL EMP [ANALYZED]
FILTER **** This filter is introduced by the min
SORT GROUP BY NOSORT
INDEX FULL SCAN BE_IX
This example is also interesting in that it has a NOSORT function. The group
by does not need to sort because the index row source is already pre sorted.
Views
=====
When a view cannot be merged into the main query you will often see a
projection view operation. This indicates that the 'view' will be selected
from directly as opposed to being broken down into joins on the base tables.
A number of constructs make a view non mergeable. Inline views are also
non mergeable.
In the following example the select contains an inline view which cannot be
merged:
SQL> explain plan for
select ename,tot
from emp,
(select empno,sum(empno) tot from big_emp group by empno) tmp
where emp.empno = tmp.empno;
Query Plan
-----------------------SELECT STATEMENT [CHOOSE]
HASH JOIN
TABLE ACCESS FULL EMP [ANALYZED]
VIEW
SORT GROUP BY
INDEX FULL SCAN BE_IX
In this case the inline view tmp which contains an aggregate function cannot be
merged into the main query. The explain plan shows this as a view step.
Sometimes genreated VIEWs can be seen in the execution plan:
VIEW in the FROM clause (INLINE VIEW)
------------------------------------If a view cannot be merged into the main query then a VIEW keyword will
be shown in the plan to represent this.
explain plan for
select ename,tot
from emp,
(select empno x, sum(empno) tot from big_emp group by empno)
where emp.empno = x;
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
9/15
6/24/2014
Document 46234.1
---------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes |TempSpc| Cost |
---------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
16 | 720 |
|
46 |
|* 1 | HASH JOIN
|
|
16 | 720 |
|
46 |
| 2 | TABLE ACCESS FULL | EMP
|
16 | 304 |
|
1|
| 3 | VIEW
|
| 10000 | 253K|
|
44 |
| 4|
SORT GROUP BY
|
| 10000 | 30000 | 248K|
44 |
| 5|
TABLE ACCESS FULL| BIG_EMP
| 10000 | 30000 |
|
24 |
---------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------1 - access("EMP"."EMPNO"="from$_subquery$_002"."X")
"from$_subquery$_002" is the generated name of the inline view that is
produced in id=3 line. If the inline view was aliased in the from clause then
the system generated name ("from$_subquery$_002") would be replaced by this
alias.
Subquery isunnested but resultant view is not merged:
----------------------------------------------------In preoptimization there is a stage where subqueries can be unnested (combined
with base query). There are numerous and complex ruled governing this activity
which are beyond the scope of this article. However, if successful, a subquery
may be unnested to produce an inline view which represents the subquery. This
view is subject to view merging. If the view is non-mergeable then a VIEW keyword
will appear in the plan.
explain plan for
select ename
from emp
where emp.empno in (select empno x from big_emp group by empno);
---------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes |TempSpc| Cost |
---------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
16 | 512 |
|
46 |
|* 1 | HASH JOIN SEMI
|
|
16 | 512 |
|
46 |
| 2 | TABLE ACCESS FULL | EMP
|
16 | 304 |
|
1|
| 3 | VIEW
| VW_NSO_1
| 10000 | 126K|
|
44 |
| 4|
SORT GROUP BY
|
| 10000 | 30000 | 248K|
44 |
| 5|
TABLE ACCESS FULL| BIG_EMP
| 10000 | 30000 |
|
24 |
---------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------1 - access("EMP"."EMPNO"="VW_NSO_1"."X")
In this example, the subquery is unnested but the resultant inline view
cannot be merged due to the 'group by'. This unmergeable view is given the
system generated name of "VW_NSO_1".
Note: In later versions, as with any code, certain inline views may be mergeable following
code improvements or as new features are introduced.
Partition Views
===============
Partition views are a legacy technology that were superceded by
the partitioning option. This section of the article is provided as
reference for such legacy systems.
Allows a large table to be broken up into a number of smaller partitions
which can be queried much more quickly than the table as a whole
a union all view is built over the top to provide the original functionality
Check constraints or where clauses provide partition elimination capabilities
SQL> explain plan for
select /*+ use_nl(p1,kbwyv1) ordered */ sum(prc_pd)
from parent1 p1, kbwyv1
where p1.class = 22
and kbwyv1.bitm_numb = p1.bitm_numb
and kbwyv1.year = 1997
and kbwyv1.week between 32 and 33 ;
Query Plan
----------------------------------------SELECT STATEMENT [FIRST_ROWS] Cost=1780
SORT AGGREGATE
NESTED LOOPS [:Q65001] Ct=1780 Cd=40 Bt=3120
TABLE ACCESS FULL PARENT1 [:Q65000] [AN] Ct=20 Cd=40 Bt=1040
VIEW KBWYV1 [:Q65001]
UNION-ALL PARTITION [:Q65001]
FILTER [:Q64000]
TABLE ACCESS FULL KBWYT1 [:Q64000] [AN] Ct=11 Cd=2000 Bt=104000
TABLE ACCESS FULL KBWYT2 [:Q63000] [AN] Ct=11 Cd=2000 Bt=104000
TABLE ACCESS FULL KBWYT3 [:Q62000] [AN] Ct=11 Cd=2000 Bt=104000
FILTER [:Q61000]
TABLE ACCESS FULL KBWYT4 [:Q61000] [AN] Ct=11 Cd=2000 Bt=104000
KBWYV1 is a view on 4 tables KBWYT1-4.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
10/15
6/24/2014
Document 46234.1
KBWYT1-4 contain rows for week 31-34 respectively and are maintained by check
constraints.
This query should only return rows from partions 2 & 3. The filter operation
indicates this. Partitions 1 & 4 are eliminated at execution time.
The view line indicates that the view is not merged. The union-all partion
information indicates that we have recognised this as a partition view.
Note that the tables can be accessed in parallel.
Partition handling
==================
The examples are based on a simple range partitioned table:
create table range_part (col1 number(9))
partition by range (col1)
(partition p1 values less than (10) ,
partition p2 values less than (20) ,
partition p3 values less than(30) ,
partition p4 values less than (MAXVALUE)) ;
Eliminated partitions can be determined at parse time
=====================================================
As optimizer can check the partition ranges in the dictionary, in some
cases it knows which partitions should be used and the others are
"elliminated" when the select is optimized.
This activity is reflected in the following plan_table columns:
PARTITION_START
PARTITION_STOP
Example:
explain plan for select * from range_part where col1=15;
start $ORACLE_HOME/rdbms/admin/utlxpls.sql
-----------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
-----------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
1|
13 |
1|
|
|
|* 1 | TABLE ACCESS FULL | RANGE_PART |
1|
13 |
1|
2|
2|
-----------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------1 - filter("RANGE_PART"."COL1"=15)
The Pstart and Pstop columns show that the optimizer believes that
only partition 2 is required to satisfy this query.
Eliminated partitions can only be determined at run time
========================================================
In this example, since the partition key references a bind variable,
the actual partition numbers cannot be determined during optimization.
The optimizer can only determine that there is a possibility that
partitions can be eliminated at runtime. The
PARTITION_START and PARTITION_START columns in the plan table will contain
either KEY or ROW LOCATION depending on the nature of the query and the partition
itself.
Example:
explain plan for select * from range_part where col1= :x;
start $ORACLE_HOME/rdbms/admin/utlxpls.sql
-------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
-------------------------------------------------------------------------------------| 0 | SELECT STATEMENT
|
|
1|
13 |
1|
|
|
| 1 | PARTITION RANGE SINGLE|
|
|
|
| KEY | KEY |
|* 2 | TABLE ACCESS FULL
| RANGE_PART |
1|
13 |
1 | KEY | KEY |
-------------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------2 - filter("RANGE_PART"."COL1"=TO_NUMBER(:Z))
You can see more examples in
Note:179518.1 Partition Pruning and Joins
Remote Queries
==============
Only shows remote in the OPERATION column
OTHER column shows query executed on remote node
OTHER_NODE shows where it is executed
Different operational characteristics for RBO & CBO
RBO - Drags everything across the link and joins locally
CBO - Uses cost estimates to determine whether to execute remotely or locally
SQL> explain plan for
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
11/15
6/24/2014
Document 46234.1
select *
from dept@loop_link;
Query Plan
------------------------------------------------------SELECT STATEMENT REMOTE [CHOOSE] Cost=1
TABLE ACCESS FULL DEPT [SJD.WORLD] [ANALYZED]
In this case the whole query has been sent to the remote site. The other column
shows nothing.
SQL> explain plan for
select a.dname,avg(b.sal),max(b.sal)
from dept@loop_link a, emp b
where a.deptno=b.deptno
group by a.dname
order by max(b.sal),avg(b.sal) desc;
Query Plan
----------------------------------------------------SELECT STATEMENT [CHOOSE] Cost=20
SORT ORDER BY [:Q137003] [PARALLEL_TO_SERIAL]
SORT GROUP BY [:Q137002] [PARALLEL_TO_PARALLEL]
NESTED LOOPS [:Q137001] [PARALLEL_TO_PARALLEL]
REMOTE [:Q137000] [PARALLEL_FROM_SERIAL]
TABLE ACCESS FULL EMP [:Q137001] [ANALYZED]
[PARALLEL_COMBINED_WITH_PARENT]
OTHER (for REMOTE)
---------------------------------------------------------------SELECT "DEPTNO","DNAME" FROM "DEPT" A
For more details on remote queries see Note:33838.1
Bind Variables
==============
Bind variables are recommended in most cases because they promote sharing of
sql code
During optimization, the optimizer has NO IDEA what the bind variable contains.
With RBO this makes no difference but with CBO, which relies on accurate
statistics to produce plans, this can be a problem.
To check the execution plan of a query using bind variables in sqlplus, the
following can be used:
variable x varchar2(18);
begin
end;
/
:x := 'hello';
Parallel Query
==============
Main indicators that a query is using PQO:
o [:Q1000004] entries in the explain plan
o Checkout the other column for details of what the slaves are executing
o v$pq_slave will show any parallel activity
Columns to look in for information
other - contains the query passed to the slaves
other_tag - describes the contents of other
object_node - indicates order of pqo slaves
Parallel Query operates on a producer/consumer basis.
When you specify parallel degree 4 oracle tries to allocate 4 producer slaves
and 4 consumer slaves. The producers can feed any of the consumers.
If there are only 2 slaves available then we use these.
If there is only 1 slave available then we go serial
If there are none available then we use serial.
If parallel_min_percent is set then we error ora 12827 instead of using a lower
number of slaves or going serial
Consumer processes typically perform a sorting function. If there is no
requirement for the data to be sorted then the consumer slaves are not produced
and we end up with the number of slaves used matching the degree of parallelism
as opposed to being 2x the degree.
Parallel Terms
~~~~~~~~~~~~~~
PARALLEL_FROM_SERIAL
PARALLEL_TO_PARALLEL
PARALLEL_COMBINED_WITH_PARENT
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
12/15
6/24/2014
Document 46234.1
as PARALLEL_COMBINED_WITH_PARENT because the
sort and the merge are handled as 1 operation.
The source of the data is parallel but it is
passed to a serial consumer.
This typically will happen at the top of the
explain plan but could occur anywhere.
PARALELL_TO_SERIAL
Serial
Parallel
Parallel, with forced optimization to
RULE and forced usage of DEPT_INDX
OBJECT_NODE OTHER
----------- ------:Q55004
:Q55003
:Q55002
:Q55002
:Q55001
:Q55002
:Q55000
**[7]**
**[6]**
**[5]**
**[4]**
**[2]**
**[3]**
**[1]**
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
13/15
6/24/2014
Document 46234.1
SELECT A1.C0 C0, A1.C1 C1, A1.C2 C2
FROM :Q55003 A1
ORDER BY A1.CO, A1.C1 DESC
(:Q58000) "PARALLEL_COMBINED_WITH_PARENT"
(:Q58000) "PARALLEL_COMBINED_WITH_PARENT"
(:Q58000) "PARALLEL_COMBINED_WITH_PARENT"
(:Q58000) "PARALLEL_TO_PARALLEL"
SELECT /*+ ORDERED USE_NL(A2) INDEX(A2) */
A2."DNAME" C0, A1.C0 C1
FROM
(SELECT /*+ ROWID(A3) */
A3."SAL" CO, A3."DEPTNO" C1
FROM "EMP" A3
WHERE ROWID BETWEEN :1 AND :2) A1,
"DEPT" A2
WHERE A2."DEPTNO" = A1.C1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
14/15
6/24/2014
Document 46234.1
REFERENCES
NOTE:179518.1 - Partition Pruning and Joins
NOTE:209197.1 - Using Statspack to Record Explain Plan Details
NOTE:235530.1 - * How to Obtain a Formatted Explain Plan - Recommended Methods
NOTE:236026.1 - Display Execution Plans with DBMS_XPLAN.DISPLAY
NOTE:237287.1 - How To Verify Parallel Execution is Running
NOTE:33838.1 - Determining the execution plan for a distributed query
NOTE:41634.1 - TKProf Basic Overview
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=155z6b9yjo_681&id=46234.1
15/15