标签：explain autotrace statistcis level dbms_xplan 10046trace
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；
步骤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.没有输出运行时的相关统计信息（产生多少逻辑读，多少次递归调用，多少次物理读的情况）；
2.无法判断是处理了多少行；
3.无法判断表被访问了多少次。
步骤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.无法看到表被访问了多少次。
步骤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.看不出递归调用的次数，看不出物理读的多少（不过逻辑读才是重点）
步骤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.无法判断表被访问了多少次。
步骤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.执行计划中的谓词部分不能清晰的展现出来。
步骤1：@?/rdbms/admin/awrsqrpt.sql
步骤2：选择你要的断点（beginsnap 和end snap)
步骤3：输入你的sql_id
本文出自 “90SirDB” 博客，请务必保留此出处http://90sirdb.blog.51cto.com/8713279/1793451
标签：explain autotrace statistcis level dbms_xplan 10046trace
原文地址：http://90sirdb.blog.51cto.com/8713279/1793451
