一个Oracle小白的AWR报告分析（五）

SQL统计主要包括按运行时间排序的SQL、按CPU时间排序的SQL、按用户I/O等待时间排序的SQL、按Gets排序的SQL、按读取排序的SQL、按物理读取排序的SQL、按执行排序的SQL、按解析调用排序的SQL、按共享内存排序的SQL、按版本计数排序的SQL、SQL文本的完整列表。

1 SQL ordered by Elapsed Time

记录了监控范围内总执行时间的TopN的SQL，而不是单次SQL执行的时间Elapsed Time=CPU Time+Wait Time。

按运行时间排序的SQL的说明：

为PL/SQL代码报告的资源包括代码调用的所有SQL语句所使用的资源。

%总DB时间是SQL语句的运行时间除以总DB时间乘以100

%Total—运行时间占总DB时间的百分比

%CPU—CPU时间占运行时间的百分比

%IO—用户I/O时间占运行时间的百分比

捕获的SQL占总DB时间的73.9%：117341

捕获的PL/SQL占总DB时间的0.0%：117341

Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time

CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。

Executions: SQL语句在监控范围内的执行次数总计。

Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。

% Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。

SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。

SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。

SQL Text: 简单的sql提示，详细的需要点击SQL ID。

SQL ordered by Elapsed Time主要关注执行次数和平均每次运行时间、以及CPU占比和IO占比，特别是平均每次运行时间较长的语句，一般都是CPU和IO消耗大户，主要是由于会话堵塞和全表扫描导致。

2 SQL ordered by CPU Time:

记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。

为PL/SQL代码报告的资源包括代码调用的所有SQL语句所使用的资源。

%CPU总时间百分比

%CPU—CPU时间占运行时间的百分比

%IO—用户I/O时间占运行时间的百分比

捕获的SQL占总CPU时间的84.6%：12928

捕获的PL/SQL占CPU总时间的0.0%：12928

一般来说会关注CPU per Exec(s)和%CPU以及%IO

4 SQL ordered by User I/O Wait Time:

记录了执行占总用户IO等待时长的TOP SQL(请注意是监控范围内该SQL的执行占IO等待时长总和，而不是单次SQL执行所占的IO等待时长)。

这里重点关注UIO per Exec(s)和运行时间以及%IO，一般是会话堵塞和全表扫描。

4 SQL ordered by Gets:

记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。

这里重点关注Gets per Exec、%CPU、%IO指标

SQL ordered by Gets 是在内存中取数据，单位是次，是消耗CPU的主要源头，在调试SQL的时候，大部分时候都是通过它来衡量性能。

5 SQL ordered by Reads:

记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。

SQL ordered by Reads 去磁盘取数据，单位是次，如果太大，IO会导致整个数据库慢，在数据库top5的等待事件中，可以看到direct path read非常大。解决方案：调优SQL、调大SGA、调大_small_table_threshold

6 SQL ordered by Physical Reads(UnOptimized):物理读取排序的SQL（未优化）

未优化读请求=物理读请求-优化读请求

%Opt-优化的读取占SQL读取请求的百分比

%总计-未优化的读取请求占未优化读取请求总数的百分比

物理读取请求总数：7435800

捕获的SQL占总数的87.2%

未优化的读取请求总数：7435800

捕获的SQL占总数的87.2%

优化的读取请求总数：1

捕获的SQL占总数的0.0%

根据Physical Reads(UnOptimized)为Exadata上的指标，对其他系统没有参考意义，可以置之不理。

7 SQL ordered by Executions:

记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。

这里执行次数，每次执行行数，运行时间、%CPU、%IO需要均衡来看。

8 SQL ordered by Parse Calls:

记录了SQL的解析次数的TOP SQL。

这部分是按SQL语句的解析次数进行排序的

Parse Calls/Executions >1 说明每次执行需要多次解析

Parse Calls/Executions <1说明一次解析可供多次执行使用

在itpub上查了半天，也没找到真正的含义是什么。

9 SQL ordered by Sharable Memory:

记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，单位是byte。

10 SQL ordered by Version Count:

记录了SQL的打开子游标的TOP SQL。

SQL Statistics中最常用的还是根据SQL ordered by Elapsed Time、SQL ordered by CPU Time、SQL ordered by User I/O Wait Time、SQL ordered by Gets、SQL ordered by Reads，即运行时间、等待事件、物理读逻辑读、CPU等指标。

总的来说SQL Statistics从几个维度列举了系统执行比较慢的SQL，可以点击详情，然后拿SQL去调优，调优SQL可以用执行计划看看。