Oracle获取执行计划方法

获取执行计划的6种方法

1. explain plan for获取；

2. set autotrace on ；

3. statistics_level=all;

4. 通过dbms_xplan.display_cursor输入sql_id参数直接获取

5. 10046 trace跟踪

6. awrsqrpt.sql

适用场合分析

1.如果某SQL执行非常长时间才会出结果，甚至慢到返回不了结果，这时候看执行计划就只能用方法1；

2.跟踪某条SQL最简单的方法是方法1，其次就是方法2，方法2要执行；

3.如果想观察到某条SQL有多条执行计划的情况，只能用方法4和方法6；

4.如果SQL中含有多函数，函数中套有SQL等多层递归调用，想准确分析，只能使用方法5；

5.要想确保看到真实的执行计划，不能用方法1和方法2；

6.要想获取表被访问的次数，只能使用方法3；

explain plan for

步骤1：explain plan for "你的SQL"

步骤2：select * from table(dbms_xplan.display());

SQL> explain plan for

2  SELECT  *

3  FROM t1, t2

4  WHERE t1.id = t2.t1_id

5  AND t1.n in(18,19);

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

Explained.

优点

  1. 无需真正执行，快捷方便

缺点

1.没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；

2.无法判断是处理了多少行；

3.无法判断表被访问了多少次。

set autotarce on

步骤1：set autotrace on

步骤2：在此处执行你的SQL即可，后续自然会有结果输出

SQL> set autotrace on

SQL> SELECT  *

2  FROM t1, t2

3  WHERE t1.id = t2.t1_id

4  AND t1.n in(18,19);

set autotrace on                 (得到执行计划，输出运行结果）

set autotrace traceonly          (得到执行计划，不输出运行结果）

set autotrace traceonly explain  (得到执行计划，不输出运行结果和统计信息部分，仅展现执行计划部分）

set autotrace traceonl statistics(不输出运行结果和执行计划部分，仅展现统计信息部分）

优点

1.可以输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；

2.虽然必须要等语句执行完毕后才可以输出执行计划，但是可以有traceonly开关来控制返回结果不打屏输出。

缺点

1.必须要等到语句真正执行完毕后，才可以出结果；

2.无法看到表被访问了多少次。

statistics level=all

步骤1：alter session set statistics_level=all ;

步骤2：在此处执行你的SQL

步骤3：select * fromtable(dbms_xplan.display_cursor(null,null,‘allstats last‘));

1. 如果你用 /*+gather_plan_statistics */的方法，可以省略步骤1，直接步骤2,3。

2. 关键字解读：

Starts为该sql执行的次数。

E-Rows为执行计划预计的行数。

A-Rows为实际返回的行数。A-Rows跟E-Rows做比较，就可以确定哪一步执行计划出了问题。

A-Time为每一步实际执行的时间（HH：MM：SS.FF），根据这一行可以知道该sql耗时在了哪个地方。

Buffers为每一步实际执行的逻辑读或一致性读。

Reads为物理读。

OMem:当前操作完成所有内存工作区(Work Aera)操作所总共使用私有内存(PGA)中工作区的大小，这个数据是由优化器统计数据以及前一次执行的性能数据估算得出的

1Mem:当工作区大小无法满足操作所需的大小时，需要将部分数据写入临时磁盘空间中(如果仅需要写入一次就可以完成操作，就称一次通过，One-Pass;否则为多次通过，Multi_Pass).该列数据为语句最后一次执行中，单次写磁盘所需要的内存大小，这个由优化器统计数据以及前一次执行的性能数据估算得出的

User-Mem:语句最后一次执行中，当前操作所使用的内存工作区大小，括号里面为(发生磁盘交换的次数,1次即为One-Pass,大于1次则为Multi_Pass,如果没有使用磁盘，则显示OPTIMAL)

OMem、1Mem为执行所需的内存评估值，0Mem为最优执行模式所需内存的评估值，1Mem为one-pass模式所需内存的评估值。

0/1/M 为最优/one-pass/multipass执行的次数。Used-Mem耗的内存

SQL> set autotrace off

SQL> alter session setstatistics_level=all ;

Session altered.

SQL> SELECT  *

2  FROM t1, t2

3  WHERE t1.id = t2.t1_id

4  AND t1.n in(18,19);

SQL> select * fromtable(dbms_xplan.display_cursor(null,null,‘allstats last‘));

优点

1.可以清晰的从STARTS得出表被访问多少。

2.可以清晰的从E-ROWS和A-ROWS中得到预测的行数和真实的行数，从而可以准确判断Oracle评估是否准确。

3.虽然没有专门的输出运行时的相关统计信息，但是执行计划中的BUFFERS就是真实的逻辑读的多少

缺点

1.必须要等到语句真正执行完毕后，才可以出结果。

2.无法控制记录输屏打出，不像autotrace有 traceonly 可以控制不将结果打屏输出。

3.看不出递归调用的次数，看不出物理读的多少（不过逻辑读才是重点）

dbms_xplan.display_cursor

步骤1： select  * fromtable(dbms_xplan.display_cursor(‘&sq_id‘));

sql_id获取方式多种，如相关的性能视图中、AWR等报告中。

注：如果有多个执行计划

select * fromtable(dbms_xplan.display_cursor(‘cyzznbykb509s‘,0));

select * from table(dbms_xplan.display_cursor(‘cyzznbykb509s‘,1));

select * from table(dbms_xplan.display_cursor(‘cyzznbykb509s‘,2));

优点

1.知道sql_id立即可得到执行计划，和explainplan for 一样无需执行；

2.可以得到真实的执行计划。

缺点

1.没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；

2.无法判断是处理了多少行；

3.无法判断表被访问了多少次。

10046trace

步骤1：alter session set events ‘10046 trace name context  forever,level 12‘; （开启跟踪）

步骤2：执行你的语句

步骤3：alter session set events ‘10046 trace name context off‘;   （关闭跟踪）

步骤4：找到跟踪后产生的文件

步骤5：tkprof  trc文件  目标文件  sys=no sort=prsela,exeela,fchela  （格式化命令）

SQL> alter session setstatistics_level=typical;

Session altered.

SQL> alter session set events ‘10046trace name context  forever,level 12‘;

Session altered.

SQL> set autotrace off

SQL> SELECT  *

2  FROM t1, t2

3  WHERE t1.id = t2.t1_id

4  AND t1.n in(18,19);

SQL> alter session set events ‘10046trace name context off‘;

Session altered.

select d.value

|| ‘/‘

|| LOWER(RTRIM(i.INSTANCE, CHR(0)))

|| ‘_ora_‘

|| p.spid

|| ‘.trc‘ trace_file_name

from (select p.spid

from v$mystat m,v$session s, v$process p

where m.statistic#=1 and s.sid=m.sid and p.addr=s.paddr) p,

(select t.INSTANCE

FROM v$thread t,v$parameter v

WHERE v.name=‘thread‘

AND(v.VALUE=0 ORt.thread#=to_number(v.value))) i,

(select value

from v$parameter

where name=‘user_dump_dest‘) d;

/u01/oracle/diag/rdbms/ocp11g/ocp11g/trace/ocp11g_ora_22508.trc

tkprof/u01/oracle/diag/rdbms/ocp11g/ocp11g/trace/ocp11g_ora_22508.trc 10046test.txtsys=no sort=prsela,exeela,fchela

查看10046test.txt文本即可

优点

1.可以看出SQL语句对应的等待事件

2.如果SQL语句中有函数调用，SQL中有SQL，将会都被列出，无处遁形。

3.可以方便的看出处理的行数，产生的物理逻辑读。

4.可以方便的看出解析时间和执行时间。

5.可以跟踪整个程序包

缺点

1.步骤繁琐，比较麻烦

2.无法判断表被访问了多少次。

3.执行计划中的谓词部分不能清晰的展现出来。

awrsqrpt.sql

步骤1：@?/rdbms/admin/awrsqrpt.sql

步骤2：选择你要的断点（beginsnap 和end snap)

步骤3：输入你的sql_id

时间： 2024-12-26 01:56:21

Oracle获取执行计划方法的相关文章

ORACLE 获取执行计划的方法

一.获取执行计划的6种方法(详细步骤已经在每个例子的开头注释部分说明了): 1. explain plan for获取: 2. set autotrace on : 3. statistics_level=all; 4. 通过dbms_xplan.display_cursor输入sql_id参数直接获取 5. 10046 trace跟踪 6. awrsqrpt.sql 二.适用场合分析 1.如果某SQL执行非常长时间才会出结果,甚至慢到返回不了结果,这时候看执行计划就只能用方法1: 2.跟踪某条

mysql 获取执行计划的方法

mysql 获取执行计划方法:1.通过explain进行查看sql的执行计划:2.通线程正在执行的sql查看该sql的执行计划: explain进行查看sql的执行计划相对简单,其实通线程正在执行的sql查看执行计划也很简单,那么为什么还需要第二种方式呢? 因为日常工作会发现很多sql一直在执行,执行发生异常,如果把该sql拿出来执行又很快,于是我们想获取该sql执行异常时候的执行计划,同时因为数据在时刻的变化,统计信息也有可能变化,有可能导致执行计划发生改变,好在mysql5.7开始已经可以通

获得执行计划方法-一 ORACLE AUTOTRACE

ORACLE sql trace AUTOTRACE 命令 1 SET AUTOTRACE OFF                   此为默认值,即关闭Autotrace2 SET AUTOTRACE ON                    产生结果集和解释计划并列出统计3 SET AUTOTRACE ON EXPLAIN            显示结果集和解释计划不显示统计4 SETAUTOTRACE TRACEONLY              显示解释计划和统计,尽管执行该语句但您将

oracle各种执行计划优缺点

一. 获取oracle执行计划的方法有6种,各自的优缺点如下,根据实际情况进行选择使用: explain plan for 方式 步骤1:explain plan for 后跟着SQL语句 步骤2:select * from table(dbms_xplan.display()); 优点: 1.不需要真正的去执行语句,快捷方便缺点: 1.虽然快捷但是因为没有真正去运行,所以没有输出运行时的相关统计信息(逻辑读,递归调用,物理读)2.不知道被处理的行数3.不知道表被访问的次数 set autotr

获得执行计划方法三-sql_trace

1 追踪这个sesion SQL> alter session set sql_trace=true ; Session altered. 2 执行想要跟踪的语句 SQL> select * from scott.emp ;      EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM ---------- ---------- --------- ---------- --------- --------

获得执行计划方法四-使用10046事件

我们也可以通过设置10046事件来进行SQL跟踪,并且可以设置不同的跟踪级别,比使用SQL_TRACE获得更多的信息. 10046事件不但可以跟踪用户会话(trace文件位于USER_DUMP_DEST ),也可以跟踪background进程(trace文件位于BACKGROUND_DUMP_DEST ).trace文件的大小决定于4个因素:跟踪级别,跟踪时长,会话的活动级别和MAX_DUMP_FILE_SIZE参数. 启用跟踪事件10046 1.在全局设置 修改初始化参数 EVENT = "1

Oracle SQL执行计划基线总结（SQL Plan Baseline）

一.基础概念 Oracle 11g开始,提供了一种新的固定执行计划的方法,即SQL plan baseline,中文名SQL执行计划基线(简称基线),可以认为是OUTLINE(大纲)或者SQL PROFILE的改进版本,基本上它的主要作用可以归纳为如下两个: 1.稳定给定SQL语句的执行计划,防止执行环境或对象统计信息等等因子的改变对SQL语句的执行计划产生影响! 2.减少数据库中出现SQL语句性能退化的概率,理论上不允许一条语句切换到一个比已经执行过的执行计划慢很多的新的执行计划上! 注意:

如何获取执行计划

如何oracle的获取执行计划 1.获取普通执行计划,效果类似于先执行set autot on exp;然后执行sql. explan plan for your_sql; select * from table(dbms_xplan.display); 2.获取具有outline信息的执行计划,用sqlprofile调优时非常有用,或者用这个执行计划了解更多oracle内部的hint explan plan for your_sql; select * from table(dbms_xpla

oracle稳定执行计划1

稳定执行计划 1 策略: Oracle的sql 执行计划在一些场景下会发生变化,导致系统会发生不可知的情况,影响系统的稳定性,特别是关键业务的sql. 比如下面的场景: 统计信息过老,重新收集了统计信息. 为表添加了新的分区,删除分区. 而oracle提供的稳定执行计划的策略也大致有: 存储纲要(stored outlines) Sql 基线(sql baseline 11g) Sql profile Hint 在这几种方式中,在应用端任何的sql变动都会使stored outlines, sq