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

<h1 color:#000000;font-size:16px;margin:0px;padding:0px;white-space:normal;background-color:#ffffff;"="" style="word-wrap: break-word; margin: 0px; padding: 0px;">Oracle查看执行计划的几种方法：http://blog.itpub.net/26736162/viewspace-2136865/

一、  如何得到真实的执行计划？

在Oracle数据库中判断得到的执行计划是否准确，就是看目标SQL是否被真正执行过，真正执行过的SQL所对应的执行计划就是准确的，反之则有可能不准，因此，通过10046事件及如下的几种方式得到的执行计划是最准确的，而从其它方式获取到的执行计划都有可能不准确。

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ADVANCED ALLSTATS'));

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('sql_id/hash_value',CHILD_CURSOR_NUMBER, 'ADVANCED ALLSTATS'));

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id'));

这里需要注意的是，虽然SQL*Plus的AUTOTRACE功能有部分是真实执行了SQL语句的（例如所有DML语句），但是，由于该命令所显示的执行计划来源于调用EXPLAIN PLAN命令，所以，其得到的执行计划依然可能不准确（特别是在使用了绑定变量的情况下）。那么，为什么EXPLAIN PLAN命令里显示的预估执行计划与该SQL真实的执行计划不一样呢？原因有多个方面，常见的情况包括以下几个方面：

①　绑定变量窥视（Bind Peeking）：EXPLAIN PLAN里不会进行绑定变量窥视，但是Runtime Plan里会进行绑定变量窥视，所以，如果发生这种情况，那么会使这两个执行计划产生差异。

②　隐式转换：Explain Plan里不会考虑绑定变量的类型，但是Runtime Plan里会考虑类型，从而有可能会根据绑定变量的类型出现隐式转换，所以谓词（Predicate）会发生变化，使得执行计划也会产生差异。

③　优化器参数：执行Explain Plan的Session与Runtime Plan的Session不是同一个。如果各个Session之间存在优化器参数差异，那么执行计划也会产生差异。

④　统计信息收集参数：Explain Plan始终是用最新的统计信息产生执行计划，但是，Runtime Plan不一定会用最新的统计信息。因此也会产生执行计划差异。在收集统计信息时，一个与缓存的游标是否失效的很重要的参数为NO_INVALIDATE。在重新收集统计信息时，可以指定NO_INVALIDATE选项。该选项有TRUE、FALSE和DBMS_STATS.AUTO_INVALIDATE这3个值。如果取值为TRUE，那么表示收集统计信息后不进行游标失效动作，原有的Shared Cursor保持原有状态。如果取值为FALSE，那么表示将统计信息对象相关的所有Cursor全部失效，目标SQL语句在下次执行时就会使用硬解析。如果设置为AUTO_INVALIDATE，那么Oracle自己决定Shared Cursor失效动作，当SQL再次执行时间距离上次收集统计信息的时间超过5小时（隐含参数“_OPTIMIZER_INVALIDATION_PERIOD”决定）则对SQL重新做硬解析。AUTO_INVALIDATE为默认选项。有些DBA在收集统计信息时，没有使用NO_INVALIDATE=>FALSE选项，所以，即使收集了统计信息，执行计划也不会立即改变。可以在表级别设置让所有依赖于该表的游标不失效，设置方法为：

EXEC DBMS_STATS.SET_TABLE_PREFS('SH','SALES','NO_INVALIDATE','TRUE');--在收集SH.SALES表上的统计信息时，让所有依赖于该表的游标不失效


实验一：

CREATE TABLE TEST_EXPLAIN_LHR AS SELECT * FROM DBA_OBJECTS;

INSERT INTO TEST_EXPLAIN_LHR SELECT * FROM TEST_EXPLAIN_LHR;

COMMIT;

SELECT COUNT(*) FROM TEST_EXPLAIN_LHR;

CREATE INDEX IDX_OBJ_LHR ON  TEST_EXPLAIN_LHR(OBJECT_ID);

EXEC DBMS_STATS.GATHER_TABLE_STATS(USER,'test_explain_lhr',ESTIMATE_PERCENT => 100,CASCADE => TRUE);

VAR X NUMBER;

VAR Y NUMBER;

EXEC :X := 0;

EXEC :Y := 100000;

EXPLAIN PLAN FOR SELECT COUNT(*) FROM TEST_EXPLAIN_LHR T WHERE T.OBJECT_ID BETWEEN :X AND :Y ;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

SET AUTOT ON

SELECT COUNT(*) FROM TEST_EXPLAIN_LHR T WHERE T.OBJECT_ID BETWEEN :X AND :Y ;

SET AUTOT OFF

SELECT COUNT(*) FROM TEST_EXPLAIN_LHR T WHERE T.OBJECT_ID BETWEEN :X AND :Y ;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'advanced'));

下面实验验证了使用EXPLAIN PLAN FOR和SET AUTOT ON方式获取到的执行计划都是不准确的：

[email protected]> clear scr

[email protected]> CREATE TABLE test_explain_lhr AS SELECT * FROM Dba_Objects;

Table created.

[email protected]> INSERT INTO test_explain_lhr SELECT * FROM test_explain_lhr;

72503 rows created.

[email protected]> COMMIT;

Commit complete.

[email protected]> SELECT COUNT(*) FROM test_explain_lhr;

COUNT(*)

----------

145006

[email protected]> CREATE INDEX idx_obj_lhr ON  test_explain_lhr(object_id);

Index created.

[email protected]> EXEC dbms_stats.gather_table_stats(USER,'test_explain_lhr',estimate_percent => 100,cascade => TRUE);

PL/SQL procedure successfully completed.

[email protected]> VAR x NUMBER;

[email protected]> VAR y NUMBER;

[email protected]> EXEC :x := 0;

PL/SQL procedure successfully completed.

[email protected]> EXEC :y := 100000;

PL/SQL procedure successfully completed.

[email protected]> EXPLAIN PLAN FOR SELECT COUNT(*) FROM test_explain_lhr t WHERE t.object_id BETWEEN :x AND :y ;

Explained.

[email protected]> set line 9999

[email protected]> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT

---------------------------------------------------------------------------------------------

Plan hash value: 3299589416

----------------------------------------------------------------------------------

| 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_OBJ_LHR |   363 |  1815 |     3   (0)| 00:00:01 |

----------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter(TO_NUMBER(:X)<=TO_NUMBER(:Y))

3 - access("T"."OBJECT_ID">=TO_NUMBER(:X) AND

"T"."OBJECT_ID"<=TO_NUMBER(:Y))

17 rows selected.

[email protected]> set autot on

[email protected]> SELECT COUNT(*) FROM test_explain_lhr t WHERE t.object_id BETWEEN :x AND :y ;

COUNT(*)

----------

145006

Execution Plan

----------------------------------------------------------

Plan hash value: 3299589416

----------------------------------------------------------------------------------

| 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_OBJ_LHR |   363 |  1815 |     3   (0)| 00:00:01 |

----------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter(TO_NUMBER(:X)<=TO_NUMBER(:Y))

3 - access("T"."OBJECT_ID">=TO_NUMBER(:X) AND

"T"."OBJECT_ID"<=TO_NUMBER(:Y))

Statistics

----------------------------------------------------------

1  recursive calls

0  db block gets

329  consistent gets

0  physical reads

0  redo size

424  bytes sent via SQL*Net to client

419  bytes received via SQL*Net from client

2  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

1  rows processed

[email protected]> SET AUTOT OFF

[email protected]> SELECT COUNT(*) FROM test_explain_lhr t WHERE t.object_id BETWEEN :x AND :y ;

COUNT(*)

----------

145006

[email protected]> SELECT * FROM TABLE(dbms_xplan.display_cursor(NULL,NULL,'advanced'));

PLAN_TABLE_OUTPUT

----------------------------------------------------------------------------------------

SQL_ID  1r87sg98rdkuf, child number 0

-------------------------------------

SELECT COUNT(*) FROM test_explain_lhr t WHERE t.object_id BETWEEN :x

AND :y

Plan hash value: 2428225634

--------------------------------------------------------------------------------------

| Id  | Operation              | Name        | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT       |             |       |       |    90 (100)|          |

|   1 |  SORT AGGREGATE        |             |     1 |     5 |            |          |

|*  2 |   FILTER               |             |       |       |            |          |

|*  3 |    INDEX FAST FULL SCAN| IDX_OBJ_LHR |   145K|   708K|    90   (2)| 00:00:02 |

--------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):

-------------------------------------------------------------

1 - SEL$1

3 - SEL$1 / [email protected]$1

Outline Data

-------------

/*+

BEGIN_OUTLINE_DATA

IGNORE_OPTIM_EMBEDDED_HINTS

OPTIMIZER_FEATURES_ENABLE('11.2.0.1')

DB_VERSION('11.2.0.1')

ALL_ROWS

OUTLINE_LEAF(@"SEL$1")

INDEX_FFS(@"SEL$1" "T"@"SEL$1" ("TEST_EXPLAIN_LHR"."OBJECT_ID"))

END_OUTLINE_DATA

*/

Peeked Binds (identified by position):

--------------------------------------

1 - :X (NUMBER): 0

2 - :Y (NUMBER): 100000

Predicate Information (identified by operation id):

---------------------------------------------------

2 - filter(:X<=:Y)

3 - filter(("T"."OBJECT_ID">=:X AND "T"."OBJECT_ID"<=:Y))

Column Projection Information (identified by operation id):

-----------------------------------------------------------

1 - (#keys=0) COUNT(*)[22]

53 rows selected.

二、  如何在不执行SQL的情况下获取执行计划？

1、“EXPLAIN PLAN FOR SQL”不实际执行SQL语句，生成的计划未必是真实执行的计划。但是，必须要有PLAN_TABLE表，可以执行脚本“@?/rdbms/admin/utlxplan.sql”来创建。

2、SQL*Plus的AUTOTRACE功能，命令：SET AUTOTRACE TRACEONLY EXPLAIN。除SET AUTOTRACE TRACEONLY EXPLAIN外其它的AUTOTRACE方式均实际执行SQL。但是，如果该命令后执行的是DML语句，那么该DML语句是确实被Oracle实际执行过的。

三、  如何获取SQL历史执行计划？

历史执行计划只能从AWR中获取，如果AWR没有记录的话，那么就无法获取历史执行计划了，获取历史执行计划的命令如下所示：

SELECT  * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('&sqlid'));

对于历史计划，可以生成SQL报告，命令如下所示：

SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_SQL_REPORT_HTML(L_DBID => , L_INST_NUM => , L_BID => , L_EID => , L_SQLID => )) ;

其中，L_DBID代表数据库的DBID，L_INST_NUM代表数据库的实例号，单机环境为1，RAC环境填写具体的实例号，L_BID为开始的快照号，L_EID为结束的快照号，L_SQLID为要查看SQL的SQL_ID。

下面的例子可以直接从AWR中获取SQL_ID为“bsa0wjtftg3uw”的执行计划，可以看到历史有2种执行计划，一个是全表扫描，一个是索引范围扫描：

[email protected]> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR(SQL_ID => 'bsa0wjtftg3uw' )) ;

SQL_ID bsa0wjtftg3uw

--------------------

SELECT file# FROM file$ WHERE ts#=:1

Plan hash value: 690176192

-----------------------------------------------

| Id  | Operation                   | Name    |

-----------------------------------------------

|   0 | SELECT STATEMENT            |         |

|   1 |  TABLE ACCESS BY INDEX ROWID| FILE$   |

|   2 |   INDEX RANGE SCAN          | I_FILE2 |

-----------------------------------------------

Note

-----

- rule based optimizer used (consider using cbo)

SQL_ID bsa0wjtftg3uw

--------------------

SELECT file# FROM file$ WHERE ts#=:1

Plan hash value: 3494626068

---------------------------------------------------------------------------

| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |

---------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |       |       |       |     2 (100)|          |

|   1 |  TABLE ACCESS FULL| FILE$ |     1 |     6 |     2   (0)| 00:00:01 |

---------------------------------------------------------------------------

31 rows selected.

四、  给出一个执行计划的执行顺序

阅读如下的执行计划，给出SQL的执行顺序。

-----------------------------------------

| Id  | Operation

-----------------------------------------

|   0 | SELECT STATEMENT

|   1 |  SORT AGGREGATE

|   2 |   VIEW

|   3 |    UNION-ALL

|*  4 |     FILTER

|*  5 |      HASH JOIN

|   6 |       TABLE ACCESS FULL

|*  7 |       TABLE ACCESS FULL

|*  8 |      TABLE ACCESS BY INDEX ROWID

|*  9 |       INDEX UNIQUE SCAN

|  10 |     NESTED LOOPS

|  11 |      INDEX FULL SCAN

|  12 |      TABLE ACCESS CLUSTER

|* 13 |       INDEX UNIQUE SCAN

-------------------------------------------

分析：采用最右最上最先执行的原则看层次关系，在同一级如果某个动作没有子ID，那么就最先执行，首先，6、7、9、13最右，所以，6，7最先执行做HASH JOIN，为6，7，5。

第二，8有子节点，接下来是9，8。

第三，HASH的结果和8的结果做FILTER过滤。

第四，10这个节点根据原则是11，13，12，10。

第五，剩下依次是3，2，1，0。

所以，该图的执行顺序是6，7，5，9，8，4，11，13，12，10，3，2，1，0。

原文地址：http://blog.51cto.com/lhrbest/2104076

时间： 2024-12-10 17:37:14

在Oracle中，如何得到真实的执行计划？的相关文章

如何快速得到真实的执行计划

准备工作: create table zbdba as select * from dba_objects; create table zbdba1 as select * from dba_objects; create index zbdba_owner on zbdba(owner); create index zbdba1_owner on zbdba1(owner); exec dbms_stats.gather_table_stats(user, 'ZBDBA', method_op

如何得到真实的执行计划

通常,我们可以使用如下四种方法来得到目标sql的执行计划: (1)explain plan命令 (2)dbms_xplan包 (3)sqlplus中的autotrace开关 (4)10046事件 这其中除了第四种方法之外,其他三种方法得到的执行计划都可能是不准确的.在oracle数据库中判断得到的执行计划是否准确,就是看目标sql是否被真正执行,真正执行过的sql所对应的执行计划就是准确的,反之则可能不准.注意,这里判断原则从严格意义上来说并不适用于autotrace开关,因为所有使用autot

如何获取真实的执行计划 （上）

在ORACLE中,一条SQL的执行计划可以帮助我们了解该SQL的运行步骤,从而判断相应的执行计划是否合理,其瓶颈在何处等.所以,执行计划是我们调整SQL的一个重要参考.在说明如何获取真实的执行计划前,我们先看一下通常获取执行计划的几种方法:1.explain for ... 2.set autotrace on3. dbms_xplan.display_cursor4. 10046 trace跟踪5. awrsqrpt.sql 在进行具体的演示前,我们均以下面的SQL做为样例.  SELECT 

如何获取真实的执行计划 （下）

续 如何获取真实的执行计划(上) http://bfc99.blog.51cto.com/265386/1706835  方法4: 10046 trace跟踪 SQL> alter session set events '10046 trace name context  forever,level 12';  --打开跟踪 Session altered. SQL> SELECT  * FROM t1, t2 WHERE t1.id = t2.t1_id AND t1.n in(18,19)

Oracle 11g如何清除share pool中某条SQL的执行计划

以前在10g数据库上,如果遇到绑定窥探导致执行计划慢的情况,想要清除某条SQL的执行计划,让它硬解析,找了很久都没有找到直接操作share pool的方法(总不能alter system flush shared_pool),只能通过对表ddl使SQL硬解析.现在终于找到了,使用sys.dbms_shared_pool.purge,在11g下可以直接使用,但在10g上需要alter session set events '5614566 trace name context forever'.

【转】Oracle索引列NULL值引发执行计划该表的测试示例

有时开发进行表结构设计,对表字段是否为空过于随意,出现诸如id1=id2,如果允许字段为空,因为Oracle中空值并不等于空值,有可能得到意料之外的结果.除此之外,最关键的是,NULL会影响oracle的执行计划. 以下为NULL影响执行计划的测试示例. /*1.构建test表,其中create table方式建立的test表结构object_id非空*,走索引/ SELECT Count(*) FROM all_objects WHERE object_id IS NOT NULL; --41

Oracle学习笔记（三）----------执行计划

查看Oracle执行计划的几种方法 一.通过PL/SQL Dev工具 1.直接File->New->Explain Plan Window,在窗口中执行sql可以查看计划结果.其中,Cost表示cpu的消耗,单位为n%,Cardinality表示执行的行数,等价Rows. 2.先执行 EXPLAIN PLAN FOR select * from tableA where paraA=1,再 select * from table(DBMS_XPLAN.DISPLAY)便可以看到oracle的执

查看真实的执行计划 绑定变量对执行计划的影响--“绑定变量窥探”

--##################################################### --####     AWR执行计划                             #### --##################################################### SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('8qfs8857jc8fw',NULL,NULL,'ADVANCED')); SEL

Oracle中Select语句完整的执行顺序

oracle Select语句完整的执行顺序: 1.from 子句组装来自不同数据源的数据: 2.where 子句基于指定的条件对记录行进行筛选: 3.group by子句将数据划分为多个分组: 4.使用聚集函数进行计算: 5.使用having子句筛选分组: 6.计算所有的表达式: 7.使用order by对结果集进行排序.