Oracle基础：sql执行计划分析(1)

 

第一讲：初识 set autotrace

     查看sql执行计划，方法有很多；通过pl/sql工具、通过sqlplus 的autotrace功能、dbms_xplan 、AWR报告 等。

今天主要是讲autotrace。

 

--创建测试表
create table t_objects_new as select * from dba_objects ;

 

说明：

     1. table access full： 代表全表扫描

     2. recursive calls: 递归查询操作； 数据库第一次执行该sql时，sql编译、权限检查等操作；  406 代表：406次查询

     3.db block size:从内存(buffer cache)中读取的block的数量

     4.consistent gets:从内存(buffer cache)中读取undo数据的block的数量 (db block size + consistent gets =逻辑读)

       4025 代表：从内存读取4025个块，每个块8k。

     5.physical reads:物理读，即从磁盘读取block块数据到内存

     6.redo size:重做日志大小。本例是select查询，不存在redo问题

     7.sorts (memory):在内存执行的排序量

     8.sorts (disk):在磁盘上执行的排序量

     9. rows processed: 查询结果返回记录数 

 

再次执行该sql，查看执行计划：

因为第一次已经编译过，这次的 recursive calls =0；

因为数据已经在内存中，这次的 consistent gets 由上次的 4025---> 3973

         从consistent gets的变化，我们可以得出：如果我们sql 固定不变，该sql查询的数据就会持续在内存中，这样，就能够提高sql执行效率。

         我们查看sql执行计划的目的：查看这些参数的变化，有效降低逻辑读。

 

下面就上面一些其他的细节进行说明：

1.查询栏目列，显示结果有些错位问题

错位的原因是：

SQL> show linesize
linesize 80

oracle默认的行宽度是80

 

我们调整后效果：

 

2.  recursive calls的问题

    上面已经说了，第一次执行sql，是硬编译过程，之后就不需要编译了。如果想sql执行多次后，模拟硬编译，如何操作？

 清空内存即可；

说明：

1. buffer_cache:清除缓冲区

2.shared_pool: 强制刷新共享池，强制老化SQL，释放共享池。（实际环境中，不推荐使用）