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包

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

1. select * from     table(dbms_xplan.display);

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

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

4. 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优化》