Oracle中如何得到真实的执行计划-白红宇

之前介绍过4种在Oracle数据库里查看执行计划的方法：

explain plan 命令

DBMS_XPLAN包

SQLPLUS中的AUTOTRACE开关

10046事件

其中除了第四种方法之外，其他三种方法得到的执行计划都有可能是不准确的。在Oracle中判断得到的执行计划是否是准确，就是看目标SQL是否被真正执行，真正执行过的SQL所对应的执行计划就是准确的，反之则有可能不准。但是这里的判断原则从严格意义上来说并不适用于AUTOTRACE开关，因为所有的AUTOTRACE开关所显示的执行计划都可能是不准的，即使对应的目标SQL实际上已经执行过。

下面我们就用上述原则来判断除第4种以外的其他三种方法中哪些得到的执行计划是准的，哪些方法得到的执行计划有可能不准。

1、explain plan命令

对这种方法得到的执行计划而言，因为此时的目标SQL并没有被实际执行，所以该方法得到的执行计划有可能是不准的，尤其是目标SQL包含绑定变量时。在默认开启绑定变量窥探(Bind Peeking)的情况，对含绑定变量的目标SQL使用explain plan得到的执行计划只是一个半成品，Oracle在随后对该SQL的绑定变量进行窥探后就得到了这些绑定变量具体的值，此时Oralce可能会对上述半成品的执行计划做调整，一量做了调整，使用explain plan命令得到的执行计划就不准了。

2、DBMS_XPLAN包

对于这种方法而言，针对不同的应用场景，可以选择如下四种方式中的一种：

select * from table(dbms_xplan.display);

select * from table(dbms_xplan.display_cursor(null,null,'advanced'));

select * from table(dbms_xplan.display_cursor('sql_id/hash_value',child_cursor_number,'advanced'));

select * from table(dbms_xplan.display_awr('sql_id'));

显然，执行select * from table(dbms_xplan.display)得到的执行计划可能是不准的，因为它只是用于查看使用explain plan命令得到的目标SQL的执行计划，目标SQL此时还没有被真正执行，所以用它得到的执行计划可能是不准的。使用剩下的三种方式得到的执行计划都是准的，因为此时目标SQL都已经被实际执行过了。

3、AUTOTRACE开关

使用这种方法，可以选择如下三种方式来开启TRACE开关

SET AUTOTRACE ON

SET AUTOTRACE TRACEONLY

SET AUTOTRACE TRACEONLY EXPLAIN

上述三种方法中，当使用SET AUTOTRACE ON和SET AUTOTRACE TRACEONLY时，目标SQL都已经被实际执行过了，正是因为被实际执行过，所以SET AUTOTRACE ON和SET AUTOTRACE TRACEONLY的情况下我们能看到目标SQL的实际资源消耗情况。当使用SET AUTOTRACE TRACEONLY EXPLAIN时，如果执行的是SELECT语句，则该SELECT语句并没有被Oracle实际执行，但如果执行的是DML语句，情况就不一样了，此时的DML语句会被Oracle实际执行的。虽然使用部分SET AUTOTRACE命令后目标SQL实际上已经执行过了，但所得到的执行计划有可能是不准的，因为使用SET AUTOTRACE命令所显示的执行计划都是来源于调用explain plan命令。

下面使用一个例子证明：

                         
scott@ORCL>
create
table
t1 
as
select
* 
from
dba_objects;
Table
created.
scott@ORCL>
insert
into
t1 
select
* 
from
t1;
86885 
rows
created.
scott@ORCL>
commit
;
Commit
complete.
scott@ORCL>
select
count
(*) 
from
t1;
  
COUNT
(*)
----------
    
173770
scott@ORCL>
create
index
idx_t1 
on
t1(object_id);
Index
created.
scott@ORCL>
exec
dbms_stats.gather_table_stats(ownname=>
'SCOTT'
,tabname=>
'T1'
,estimate_percent=>100,
cascade
=>
true
);
PL/SQL 
procedure
successfully completed.
scott@ORCL>var x number;
scott@ORCL>var y number;
scott@ORCL>
exec
:x := 0;
PL/SQL 
procedure
successfully completed.
scott@ORCL>
exec
:y := 100000;
PL/SQL 
procedure
successfully completed.
scott@ORCL>explain plan 
for
select
count
(*) 
from
t1 
where
object_id 
between
:x 
and
:y;
Explained.
scott@ORCL>
select
* 
from
table
(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2351893609
-----------------------------------------------------------------------------
| Id  | Operation      | 
Name
| 
Rows
| Bytes | Cost (%CPU)| 
Time
|
-----------------------------------------------------------------------------
|   0 | 
SELECT
STATEMENT   |       |     1 |      5 |      3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |     |     1 |      5 |         |     |
|*  2 |   FILTER     |     |       |       |        |     |
|*  3 |    
INDEX
RANGE SCAN| IDX_T1 |    434 |  2170 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified 
by
operation id):
---------------------------------------------------
   
2 - filter(TO_NUMBER(:Y)>=TO_NUMBER(:X))
   
3 - access(
"OBJECT_ID"
>=TO_NUMBER(:X) 
AND
"OBJECT_ID"
<=TO_NUMBER(:Y))
16 
rows
selected.
scott@ORCL>
select
count
(*) 
from
t1 
where
object_id 
between
:x 
and
:y;
  
COUNT
(*)
----------
    
173380
scott@ORCL>
select
* 
from
table
(dbms_xplan.display_cursor(
null
,
null
,
'ADVANCED'
));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  9dhu3xk2zu531, child number 0
-------------------------------------
select
count
(*) 
from
t1 
where
object_id 
between
:x 
and
:y
Plan hash value: 1410530761
---------------------------------------------------------------------------------
| Id  | Operation          | 
Name
| 
Rows
| Bytes | Cost (%CPU)| 
Time
|
---------------------------------------------------------------------------------
|   0 | 
SELECT
STATEMENT       |   |   |   |   107 (100)|      |
|   1 |  SORT AGGREGATE        | |     1 |     5 |        |     |
|*  2 |   FILTER         | |   |   |        |     |
|*  3 |    
INDEX
FAST 
FULL
SCAN| IDX_T1 |   172K|   843K|   107   (1)| 00:00:02 |
---------------------------------------------------------------------------------
......省略部分输出
scott@ORCL>
set
autotrace traceonly
scott@ORCL>
select
count
(*) 
from
t1 
where
object_id 
between
:x 
and
:y;
Execution Plan
----------------------------------------------------------
Plan hash value: 2351893609
-----------------------------------------------------------------------------
| Id  | Operation      | 
Name
| 
Rows
| Bytes | Cost (%CPU)| 
Time
|
-----------------------------------------------------------------------------
|   0 | 
SELECT
STATEMENT   |       |     1 |      5 |      3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |     |     1 |      5 |         |     |
|*  2 |   FILTER     |     |       |       |        |     |
|*  3 |    
INDEX
RANGE SCAN| IDX_T1 |    434 |  2170 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------
        
      

从上面显示内容可以看到，使用SET AUTOTRACE ON得到的执行计划和之前explain plan得到的执行计划也是一模一样的，即此时使用SET AUTOTRACE ON所得到的执行计划也是不准的。

另外，如果目标SQL的执行计划已经被age out出Shared Pool了，此时如何得到SQL的真实执行计划呢？

如果是Oracle 10g 及其以上版本，该SQL的执行计划已经被Oracle捕获并存储到了AWR Repository中，则可以使用AWR SQL报告来得到真实的历史执行计划。

如果是Oracle 9i，通常情况下已经没有办法再得到该SQL的执行计划，除非额外部署了Statspack报告，并且采集Statspack报告的level值大于或等于6。

使用AWR SQL报告来得到真实的历史执行计划参考：http://hbxztc.blog.51cto.com/1587495/1897981

参考《基于Oracle的SQL优化》

本文转自hbxztc 51CTO博客，原文链接：http://blog.51cto.com/hbxztc/1899175，如需转载请自行联系原作者