Oracle中如何得到真实的执行计划

前端之家收集整理的这篇文章主要介绍了Oracle中如何得到真实的执行计划前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

  • explain plan 命令

  • DBMS_XPLAN

  • sqlPLUS中的AUTOTRACE开关

  • 10046事件

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

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

1explain plan命令

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

2DBMS_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都已经被实际执行过了。

3AUTOTRACE开关

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

  • SET AUTOTRACE ON

  • SET AUTOTRACE TRACEONLY

  • SET AUTOTRACE TRACEONLY EXPLAIN

上述三种方法中,当使用SET AUTOTRACE ONSET AUTOTRACE TRACEONLY时,目标sql都已经被实际执行过了,正是因为被实际执行过,所以SET AUTOTRACE ONSET 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 outShared 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优化》

原文链接:https://www.f2er.com/oracle/210506.html

猜你在找的Oracle相关文章