Oracle SQL性能检测分析

1. 概要：
之前在网站性能优化实践-for循环中的数据库操作和网站性能优化实践-数据库分页和轻量级Session都提到了数据库操作在网站性能优化中的重要作用，对于mysql数据库，在
使用mysql的explain做select类型的sql语句的性能分析和优化
介绍了使用explain做SQL查询的性能分析和优化，这里，介绍下Oracle数据库的对应方式。
Oracle有多种方式获得一条SQL语句的查询计划，比如使用explain plan命令，在SQL Developer里面按F6快捷键等，但是作为SQL调优，比较简便的方式，还是在sqlplus中使用set autotrace on和set timing on的方式来得到SQL的实际运行时间和查询计划；

2. 使用方式
在sqlplus工具下，输入set timing on来设置打印sql语句的运行时间。
接着输入set autotrace on;// 这里需要一定的权限，如果开发自己搞的数据库，先搞个dba的role能跑起来再研究权限好了
然后在输入需要分析的sql语句，就可以看到相关的查询计划和统计信息了；

3. 例子：
hetaoblog@ORCL>set autotrace on;
hetaoblog@ORCL>set timing on;
hetaoblog@ORCL>
hetaoblog@ORCL>select count(*) from app_user;

COUNT(*)
———-
3000017

已用时间: 00: 00: 02.26

执行计划
———————————————————-
Plan hash value: 289886741

—————————————————————————–
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
—————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 1533 (5)| 00:00:19 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| APP_USER_PK | 1459K| 1533 (5)| 00:00:19 |
—————————————————————————–

统计信息
———————————————————-
365 recursive calls
0 db block gets
6652 consistent gets
6577 physical reads
0 redo size
416 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed

4. autotrace结果分析：
运行时间：
在这个例子中，因为之前设置了set timing on;，所以，就有这条sql语句的运行时间，这里是0.28秒；

接下来，因为设置了set autotrace on;所以sql语句运行后，该语句的执行计划和运行统计信息都打印出来了；

执行计划
通常看操作，比如，大表是否有全表扫描等；cost这项也是主要要看的，数字越小越好；最后一列时间，应该是预估的运行时间；

统计信息：
统计信息也是主要分析的地方，对于select，主要观察的是consistent gets和physical reads，其中尤其观察的是physical reads，这项越小越好；

由于缓存的存在，同一条sql，几次执行的统计信息会发生变化，尤其反应在physical reads和recrusive calls会变少； 这也是同一条SQL运行几次运行时间不一样的原因之一；

附：autotrace还可以设置只显示执行计划/统计信息/只显示trace信息不显示SQL结果，下面是3种情况对应的命令；
hetaoblog@ORCL>set autotrace on exp;
hetaoblog@ORCL>set autotrace on statistics;
hetaoblog@ORCL>set autotrace traceonly;

This entry was posted on 星期日, 3月 14th, 2010 at