一、什么是执行计划?
执行计划是一条查询语句在oracle中的执行过程或访问路径的描述。
执行计划描述了sql引擎为执行sql语句进行的操作,分析sql语句相关的性能问题或仅仅质疑查询优化器的决定时,必须知道执行计划;所以执行计划常用语sql调优。
二、怎么获取执行计划?(6种方法)
方法1:explain plan for explain [ɪkˈspleɪn]解释,说明
(1)获取步骤
步骤1:explain plan for + 跟上你要执行的sql;
步骤2:select * from table(dbms_xplan.display());
(2)优点
无须真正执行,快捷方便
(3)缺点
1、没有输出运行时的相关统计信息(产生多少逻辑读;多少次递归调用;多少次物理读情况);
2、无法判断处理了多少行;
3、无法判断表被访问了多少次;
(4)应用场景
如果某sql执行很长时间才出结果或返回不了结果
--1、explain plan for + 跟上你要执行的sql explain plan for select a.*, b.* from emp a left join dept b on a.deptno = b.deptno where a.empno in ('7369', '7499'); --2、dbms_xplan包括一系列函数,主要用于显示sql语句的执行计划,且不用的情形下使用不同的函数来显示, --如预估的执行计划则使用display函数,而实际的执行计划则是用display_cursor函数 select * from table(dbms_xplan.display());
方法2:set autotrace on 【自动跟踪】 trace [treɪs] 追踪
(1)获取步骤
步骤1::set autotrace on/traceonly
步骤2:在此处执行你的sql
(2)优点
1、可以输出运行时的相关统计信息(产生多少逻辑读,多少递归调用,多少次物理读的情况);
2、虽然必须要等语句执行完毕后才可以输出执行计划,但是可以有traceonly开关来控制返回结果不大屏输出。
(3)缺点
1、必须要等语句真正执行完毕后,才可以出结果;
2、无法看到表被访问了多少次。
(4)应用场景
只能粗略知道recursive calls递归调用次数,详细用10046trace事件方法
recursive [rɪˈkɜːrsɪv] 递归
set autotrace traceonly select a.*, b.* from scott.emp a left join scott.dept b on a.deptno = b.deptno where a.empno in ('7369', '7499');
方法3:statistics_level=all statistics [stəˈtɪstɪks] 统计,level [ˈlevl] 层次,数量
(1)获取步骤
步骤1:alter session set statistics_level=all;
步骤2:在此处执行你的sql
步骤3:select * from table(dbms_xplan.display_cursor(null,null,‘allstats last’));
(2)优点
1、可以清晰地从stats得出表被访问多少次?
2、可以清晰地从e-rows和a-rows中得到预测的行数和真实的行数,从而可以准确判断oracle评估是否准确?
e-rows即为estimate-rows,是根据表的统计信息得来的预估行数;
a-rows即为actual-rows,是sql在执行过程中实际取到的行数。
3、虽然没有专门的输出运行时的相关统计信息,但是执行计划中的buffers就是真实的逻辑读的数值。
(3)缺点
1、必须要等到语句真正执行完毕后,才可以出结果;
2、无法控制输出记录展现与否,而autotrace有traceonly可以控制不将输出记录打屏;
3、看不出递归调用的次数,看不出物理读的数值。
(4)应用场景
想要获取表被访问的次数,只能用方法3
- starts:该sql执行的次数
- e-rows:为执行计划预计的行数
- a-rows:实际返回的行数,e-rows和a-rows作比较,就可以看出具体哪一步执行计划出问题了。
- a-time:每一步实际执行的时间,可以看出耗时的sql
- buffers:每一步实际执行的逻辑读或一致性读
方法4:dbms_xplan.display_cursor
(1)获取步骤
select * from table(dbms_xplan.display_cursor(‘&sq_id’));(该方法是从共享池里得到)
(2)优点
1、知道sql_id立即可得到执行计划,和explain plan for一样无须执行;
2、可以得到真实的执行计划。
(3)缺点
1、没有输出运行时的相关统计信息(产生多少逻辑读;多少次递归调用;多少次物理读情况);
2、无法判断处理了多少行;
3、无法判断表被访问了多少次;
(4)应用场景
观察某条sql有多条执行计划的情况
方法5:事件10046trace跟踪
(1)获取步骤
步骤1:alter session set events’10046 trace name context forever,level 12’;(开启跟踪)
步骤2:执行你的语句
步骤3:alter session set events ‘10046 trace name context off’;(关闭跟踪)
步骤4:exit(退出当前窗口)
步骤5:找到跟踪后产生的文件 路径:此电脑/d/app/administrator/diag/rdbms/prcl/trace
步骤6:tkprof trc 文件目标文件 【tkprof 是oracle自带的一个命令行工具,主要作用是将原始的跟踪文件转换为格式化的文本文件】
“ tkprof全称:tool kit profiler trace kernel profiler” 工具包探查器跟踪内核探查器
trace文件(*.trc格式)对开发者来说是不可读的格式,需要把跟踪文件转换为为可读的格式,tkprof命令用是把跟踪文件格式的工具。
tkprof d:\app\administrator\diag\rdbms\orcl\orcl\trace/orcl_ora_4308.trc d:\10046.txt sys=no sort=prsela,exeela,fchela
(2)优点
1、可以看出sql语句对应的等到事件;
2、如果sql语句中有函数调用,sql中有sql,都将会被列出,无处循形;
3、可以方便地看出处理的行数,产生的物理逻辑读;
4、可以方便地看出解析时间和执行时间;
5、可以跟踪整个程序包
(3)缺点
1、步骤烦琐,比较麻烦;
2、无法判断表被访问了多少次;
3、执行计划中的谓词部分不能清晰地展现出来
(4)应用场景
如果sql中含有函数,函数中又嵌套sql等,即存在多层调用,想准确分析只能用该方法
方法6:awrsqrpt.sql
awr全称叫automatic workload repository-自动负载信息库,awr 是通过对比两次快照(snapshot)收集到的统计信息。
awrsqrpt可以生成指定快照区间目标sql语句的统计报表,可以查看多个执行计划。
这个脚本可以很方便地取出某个sql在某两个快照间隔内,消耗cpu时间,执行次数,逻辑读,物理读,sql的执行计划以及sql的full sql text,对调优非常方便。
报告关注点:sql id部分的执行计划个数、plan statistics 计划统计、execution plan 执行计划
automatic [ˌɔːtəˈmætɪk] 自动的;workload 工作量;repository 知识宝典
(1)获取步骤
步骤1:以管理员用户的身份登录
sqlplus / as sysdba
步骤2:执行@?/rdbms/admin/awrsqrpt.sql 生产awr报告
步骤3:填写要生成的报告格式,支持html和text,html是默认值可直接回车。
步骤4:要求输入要列出snap id的天数,一般最大保存了一个月的快照。依据自己的需要的时间段输入要列出最近几天的快照。
步骤5:要输入awr报告启和止的snap_id,依据自己要的时间段输入snap id即可
步骤6:sql的id:0k8522rmdzg4k 默认值
查询sql_id,sql_text可以从awr报告拿
select sql_text, last_load_time, t.sql_id from v$sql t where last_load_time is not null and sql_text like 'select count(*) from%' order by t.last_load_time desc
步骤7:最后要求输入报告名称
填写awrsqrpt报告的名称,我可以填写awrsqrpt_20190421.html,然后在打印的日志里有文件保存的路径:,比如:
d:\oracle\product\11.2.0\dbhome_1\rdbms\admin\awrsqrpt.html
(2)优点
可以方便地看到多个执行计划
(3)缺点
获取的过程比较麻烦
(4)应用场景
想观察某条sql的多个执行计划用该方法
总结
到此这篇关于oracle获取执行计划的六种方法的文章就介绍到这了,更多相关oracle获取执行计划内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
发表评论