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)得到的执行计划可能是不准的，因为它只是用于查看使用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>createtablet1asselect*fromdba_objects; Tablecreated. scott@ORCL>insertintot1select*fromt1; 86885rowscreated. scott@ORCL>commit; Commitcomplete. scott@ORCL>selectcount(*)fromt1; COUNT(*) ---------- 173770 scott@ORCL>createindexidx_t1ont1(object_id); Indexcreated. scott@ORCL>execdbms_stats.gather_table_stats(ownname=>'SCott',tabname=>'T1',estimate_percent=>100,cascade=>true); PL/sqlproceduresuccessfullycompleted. scott@ORCL>varxnumber; scott@ORCL>varynumber; scott@ORCL>exec:x:=0; PL/sqlproceduresuccessfullycompleted. scott@ORCL>exec:y:=100000; PL/sqlproceduresuccessfullycompleted. scott@ORCL>explainplanforselectcount(*)fromt1whereobject_idbetween:xand:y; Explained. scott@ORCL>select*fromtable(dbms_xplan.display); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Planhashvalue:2351893609 ----------------------------------------------------------------------------- |Id|Operation |Name|Rows|Bytes|Cost(%cpu)|Time| ----------------------------------------------------------------------------- |0|SELECTSTATEMENT| | 1| 5| 3(0)|00:00:01| |1|SORTAGGREGATE| | 1| 5| | | |*2|FILTER | | | | | | |*3|INDExrangeSCAN|IDX_T1| 434|2170| 3(0)|00:00:01| ----------------------------------------------------------------------------- Predicateinformation(identifiedbyoperationid): --------------------------------------------------- 2-filter(TO_NUMBER(:Y)>=TO_NUMBER(:X)) 3-access("OBJECT_ID">=TO_NUMBER(:X)AND"OBJECT_ID"<=TO_NUMBER(:Y)) 16rowsselected. scott@ORCL>selectcount(*)fromt1whereobject_idbetween:xand:y; COUNT(*) ---------- 173380 scott@ORCL>select*fromtable(dbms_xplan.display_cursor(null,'ADVANCED')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ sql_ID 9dhu3xk2zu531,childnumber0 ------------------------------------- selectcount(*)fromt1whereobject_idbetween:xand:y Planhashvalue:1410530761 --------------------------------------------------------------------------------- |Id|Operation |Name |Rows |Bytes|Cost(%cpu)|Time | --------------------------------------------------------------------------------- |0|SELECTSTATEMENT| | | |107(100)| | |1|SORTAGGREGATE| |1|5| | | |*2|FILTER | | | | | | |*3|INDEXFASTFULLSCAN|IDX_T1|172K|843K|107(1)|00:00:02| --------------------------------------------------------------------------------- ......省略部分输出 scott@ORCL>setautotracetraceonly scott@ORCL>selectcount(*)fromt1whereobject_idbetween:xand:y; ExecutionPlan ---------------------------------------------------------- Planhashvalue:2351893609 ----------------------------------------------------------------------------- |Id|Operation |Name|Rows|Bytes|Cost(%cpu)|Time| ----------------------------------------------------------------------------- |0|SELECTSTATEMENT| | 1| 5| 3(0)|00:00:01| |1|SORTAGGREGATE| | 1| 5| | | |*2|FILTER | | | | | | |*3|INDExrangeSCAN|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优化》
