oracle获取的执行计划区别及获取真实执行计划
2017-06-30 15:05
561 查看
oracle查看真实的执行计划
oracle查看到的执行计划,偶尔并不是真实的执行计划,
查看是否是真实的执行计划,就是看SQL有没有真正的执行,若没有被执行,那么由于统计信息与实际直接误差,或其他原因,执行计划可能是不准确的。
10046获取的是执行计划
explain plan,dbms_xplan,autotrace这三种方法获取到的执行计划,可能不是真实的执行计划
1.10046
10046事件获取到的是oracle sql真实的执行计划
使用10046查看执行计划方法
开启:
SQL> alter session set events ‘10046 trace name context forever, level 12’;
或
SQL> oradebug event 10046 trace name context forever, level 12
关闭:
SQL> alter session set events ‘10046 trace name context off’;
或
SQL> oradebug event 10046 trace name context off
SQL> select * from v$mystat where rownum=1;
SQL> SELECT tracefile FROM v$process WHERE addr IN (SELECT paddr FROM v$session WHERE sid=’xxx’);
tkprof转换格式
trc文件中查看执行计划
2.explain plan
目标sql并没有实际被执行,所以获取到的执行计划是不准确的
若有绑定变量,则获取到的执行计划,可以看作是个半成品,有时并不准确
3.dbms_xplan
select * from table(dbms_xplan.display)
select * from table(dbms_xplan.display_cursor(null,null,’advanced’));
select * from table(dbms_xplan.display_cursor(‘sql_id/hash_value’,child_cursor_number,’advanced’))
select * from table(dbms_xplan.display_awr(‘sql_id’))
select * from table(dbms_xplan.display)获取到的执行计划可能是不准的,因为它获取的是explain plan的执行结果
剩下3种获得的执行计划是准确的
select * from table(dbms_xplan.display_cursor(null,null,’advanced’));
select * from table(dbms_xplan.display_cursor(‘sql_id/hash_value’,child_cursor_number,’advanced’))
select * from table(dbms_xplan.display_awr(‘sql_id’))
4.autotrace
set autotrace on与set autotrace traceonly 目标sql已经执行,可以查看到资源消耗情况,但执行计划依然可能是不准确的,这是因为,实际来源的是explain plan
使用set autotrace traceonly explain 解析执行select操作时,sql并没有真正执行。获取的执行计划可能是不准的
EXECUTIONS为0,说明没有真正的执行
oracle查看到的执行计划,偶尔并不是真实的执行计划,
查看是否是真实的执行计划,就是看SQL有没有真正的执行,若没有被执行,那么由于统计信息与实际直接误差,或其他原因,执行计划可能是不准确的。
10046获取的是执行计划
explain plan,dbms_xplan,autotrace这三种方法获取到的执行计划,可能不是真实的执行计划
1.10046
10046事件获取到的是oracle sql真实的执行计划
使用10046查看执行计划方法
开启:
SQL> alter session set events ‘10046 trace name context forever, level 12’;
或
SQL> oradebug event 10046 trace name context forever, level 12
关闭:
SQL> alter session set events ‘10046 trace name context off’;
或
SQL> oradebug event 10046 trace name context off
SQL> select * from v$mystat where rownum=1;
SQL> SELECT tracefile FROM v$process WHERE addr IN (SELECT paddr FROM v$session WHERE sid=’xxx’);
SQL> alter session set events '10046 trace name context forever, level 12'; Session altered. SQL> select * from test; .... SQL> alter session set events '10046 trace name context off'; Session altered. SQL> select * from v$mystat where rownum=1; SID STATISTIC# VALUE ---------- ---------- ---------- 1 0 0 SQL> SELECT tracefile FROM v$process WHERE addr IN (SELECT paddr FROM v$session WHERE sid='1'); TRACEFILE -------------------------------------------------------------------------------- /oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2905.trc
tkprof转换格式
tkprof /oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2905.trc orcl_ora_2905.trc
trc文件中查看执行计划
Sort options: default ----默认排序 ----参数说明 ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ******************************************************************************** ----SQL ID 已经hash值 SQL ID: c99yw1xkb4f1u Plan Hash: 1357081020 ----执行的SQL select * from test call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 0.00 0.00 0 3 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.00 0.00 0 3 0 1 ----优化器访问数据单位方式,为默认的all_rows Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: 91 ----这里可以看到实际的资源消耗: cr每一步所消耗的逻辑读 pr物理读 pw物理写 time好肥的时间 card实际返回的函数 size返回的数据大小 这里可以看到,该test经过3次逻辑读,没有回磁盘读,总共返回一行数据 执行计划执行一步操作TABLE ACCESS FULL TEST 全表扫描 Rows Row Source Operation ------- --------------------------------------------------- 1 TABLE ACCESS FULL TEST (cr=3 pr=0 pw=0 time=0 us cost=3 size=181 card=1) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 2 0.00 0.00 Disk file operations I/O 1 0.00 0.00 SQL*Net message from client 2 7.76 7.77 ******************************************************************************** SQL ID: 06nvwn223659v Plan Hash: 0 alter session set events '10046 trace name context off' ......
2.explain plan
目标sql并没有实际被执行,所以获取到的执行计划是不准确的
若有绑定变量,则获取到的执行计划,可以看作是个半成品,有时并不准确
3.dbms_xplan
select * from table(dbms_xplan.display)
select * from table(dbms_xplan.display_cursor(null,null,’advanced’));
select * from table(dbms_xplan.display_cursor(‘sql_id/hash_value’,child_cursor_number,’advanced’))
select * from table(dbms_xplan.display_awr(‘sql_id’))
select * from table(dbms_xplan.display)获取到的执行计划可能是不准的,因为它获取的是explain plan的执行结果
剩下3种获得的执行计划是准确的
select * from table(dbms_xplan.display_cursor(null,null,’advanced’));
select * from table(dbms_xplan.display_cursor(‘sql_id/hash_value’,child_cursor_number,’advanced’))
select * from table(dbms_xplan.display_awr(‘sql_id’))
4.autotrace
set autotrace on与set autotrace traceonly 目标sql已经执行,可以查看到资源消耗情况,但执行计划依然可能是不准确的,这是因为,实际来源的是explain plan
使用set autotrace traceonly explain 解析执行select操作时,sql并没有真正执行。获取的执行计划可能是不准的
SQL> set autotrace traceonly explain; SQL> select count(*) from test; Execution Plan ---------------------------------------------------------- Plan hash value: 1950795681 ------------------------------------------------------------------- | Id | Operation | Name | Rows | Cost (%CPU)| Time | ------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | | | | 2 | TABLE ACCESS FULL| TEST | 1 | 3 (0)| 00:00:01 | ------------------------------------------------------------------- SQL> set autotrace off; SQL> select a.SQL_TEXT,a.EXECUTIONS from v$sqlarea a where a.SQL_TEXT like 'select count(*)%'; SQL_TEXT EXECUTIONS -------------------------------------------------------------------------------- ---------- select count(*) from test 0
EXECUTIONS为0,说明没有真正的执行
相关文章推荐
- oracle_执行计划_谓词信息和数据获取(access and filter区别) (转)
- Oracle 从缓存里面查找真实的执行计划
- Oracle获取执行计划的方法
- Oracle 执行计划的获取-2
- [Oracle]获取执行计划的各个方法总结
- [Oracle]获取执行计划的各个方法总结
- Oracle 从缓存里面查找真实的执行计划
- [Oracle] 获取执行计划的几种方法
- Oracle中获取执行计划的几种方法分析
- Oracle中获取执行计划的几种方法分析
- [Oracle]获取执行计划的各个方法总结
- Oracle 从缓存里面查找真实的执行计划
- Oracle 从缓存里面查找真实的执行计划
- [Oracle] 获取执行计划的各方法总结
- Oracle 从缓存里面查找真实的执行计划
- Oracle 从缓存里面查找真实的执行计划
- Oracle 获取执行计划
- oracle 执行计划获取的几种方式
- [Oracle]获取执行计划的各个方法总结
- [Oracle]获取执行计划的各个方法总结