循序渐进解读Oracle AWR性能分析报告
作者介绍
韩锋，宜信技术研发中心数据库架构师。精通多种关系型数据库，曾任职于当当网、TOM在线等公司，曾任多家公司首席DBA、数据库架构师等职，多年一线数据库架构、设计、开发经验。著有《SQL优化最佳实践》一书。
Oracle 中的 AWR，全称为 Automatic Workload Repository，自动负载信息库。它收集关于特定数据库的操作统计信息和其他统计信息，Oracle 以固定的时间间隔(默认为 1 个小时)为其所有重要的统计信息和负载信息执行一次快照，并将快照存放入 AWR 中。这些信息在 AWR 中保留指定的时间(默认为 1 周)，然后执行删除。执行快照的频率和保持时间都是可以自定义的。
AWR 的引入，为我们分析数据库提供了非常好的便利条件(这方面 MySQL 就相差了太多)。曾经有这样的一个比喻——“一个系统，就像是一个黑暗的大房间，系统收集的统计信息，就如同放置在房间不同位置的蜡烛，用于照亮这个黑暗大房间。Oracle，恰到好处地放置了足够的蜡烛(AWR)，房间中只有极少的烛光未覆盖之处，性能瓶颈就容易定位。而对于蜡烛较少或是没有蜡烛的系统，性能优化就如同黑暗中的舞者。”
那如何解读 AWR 的数据呢？Oracle 本身提供了一些报告，方便进行查看、分析。下面就针对最为常见的一种报告——《AWR 数据库报告》进行说明。希望通过这篇文章，能方便大家更好地利用 AWR，方便进行分析工作。
一、MAIN
Database Information
Snapshot Information
(1)Sessions
表示采集实例连接的会话数。这个数可以帮助我们了解数据库的并发用户数大概的情况。这个数值对于我们判断数据库的类型有帮助。
(2)Cursors/session
每个会话平均打开的游标数。
(3)Elapsed
通过 Elapsed/DB Time 比较，反映出数据库的繁忙程度。如果 DB Time>>Elapsed，则说明数据库很忙。
(4)DB Time
表示用户操作花费的时间，包括 CPU 时间和等待事件。通常同时这个数值判读数据库的负载情况。
具体含义
db time = cpu time + wait time(不包含空闲等待)(非后台进程)
*db time 就是记录的服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间。对应于 V$SESSION 的 elapsed_time 字段累积。
"合集数据"
需要注意的是 AWR 是一个数据合集。比如在 1 分钟之内，1 个用户等待了 30 秒钟，那么 10 个用户等待事件就是 300 秒。CPU 时间也是一样，在 1 分钟之内，1 个 CPU 处理 30 秒钟，那么 4 个 CPU 就是 120 秒。这些时间都是以累积的方式记录在 AWR 当中的。
示例
DB CPU——这是一个用于衡量 CPU 的使用率的重要指标。假设系统有 N 个 CPU，那么如果 CPU 全忙的话，一秒钟内的 DB CPU 就是 N 秒。除了利用 CPU 进行计算外，数据库还会利用其它计算资源，如网络、硬盘、内存等等，这些对资源的利用同样可以利用时间进行度量。假设系统有 M 个 session 在运行，同一时刻有的 session 可能在利用 CPU，有的 session 可能在访问硬盘，那么在一秒钟内，所有 session 的时间加起来就可以表征系统在这一秒内的繁忙程度。一般的，这个和的最大值应该为 M。这其实就是 Oracle 提供的另一个重要指标:DB time，它用以衡量前端进程所消耗的总时间。
对除 CPU 以后的计算资源的访问，Oracle 用等待事件进行描述。同样地，和 CPU 可分为前台消耗 CPU 和后台消耗 CPU 一样，等待事件也可以分为前台等待事件和后台等待事件。DB Time 一般的应该等于"DB CPU + 前台等待事件所消耗时间"的总和。等待时间通过 vsystemevent视图进行统计，DBTime和DBCPU则是通过同一个视图，即vsys_time_model 进行统计。
--"Load Profile"中关于 DB Time 的描述
*这个系统的 CPU 个数是 8，因此我们可以知道前台进程用了系统 CPU 的 7.1/8=88.75%。DB Time/s 为 11.7，可以看出这个系统是 CPU 非常繁忙的。里面 CPU 占了 7.1，则其它前台等待事件占了 11.7 – 7.1 = 4.6 Wait Time/s。DB Time 占 DB CPU 的比重: 7.1/11.7= 60.68%
--"Top 5 Timed Events"中关于 DB CPU 的描述
按照 CPU/等待事件占 DB Time 的比例大小，这里列出了 Top 5。如果一个工作负载是 CPU 繁忙型的话，那么在这里应该可以看到 DB CPU 的影子。
*注意到，我们刚刚已经算出了 DB CPU 的 %DB time，60%。其它的 external table read、direct path write、PX Deq: read credit、PX Deq: Slave Session Stats 这些就是占比重 40 的等待事件里的 Top 4 了。
--"Top 5 Timed Foreground Events"的局限性
再研究下这个 Top 5 Timed Foreground Events，如果先不看 Load Profile，是不能计算出一个 CPU-Bound 的工作负载。要知道系统 CPU 的繁忙程序，还要知道这个 AWR 所基于两个 snapshot 的时间间隔，还要知道系统 CPU 的个数。要不系统可以是一个很 IDLE 的系统呢。记住 CPU 利用率 = DB CPU/(CPU_COUNT*Elapsed TIME)。这个 Top 5 给我们的信息只是这个工作负载应该是并行查询，从外部表读取数据，并用 insert append 的方式写入磁盘，同时，主要时间耗费在 CPU 的运算上。
** --解读"DB Time" > “DB CPU” + “前台等待事件所消耗时间” ——进程排队时间 **
上面提到，DB Time 一般的应该等于 DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计：
DB CPU = 6474.65
DB TIME = 10711.2
FG Wait Time = 1182.63
明显的，DB CPU + FG Wait Time < DB Time，只占了 71.5%
*其它的 28.5%被消耗到哪里去了呢?这里其实又隐含着一个 Oracle 如何计算 DB CPU 和 DB Time 的问题。当 CPU 很忙时，如果系统里存在着很多进程，就会发生进程排队等待 CPU 的现象。在这样，DB TIME 是把进程排队等待 CPU 的时间算在内的，而 DB CPU 是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time 的一个重要原因。如果一个系统 CPU 不忙，这这两者应该就比较接近了。不要忘了在这个例子中，这是一个 CPU 非常繁忙的系统，而 71.5%就是一个信号，它提示着这个系统可能是一个 CPU-Bound 的系统。
二、Report Summary
1.Cache Sizes
2.Load Profile
这两部分是数据库资源负载的一个明细列表，分隔成每秒钟的资源负载和每个事务的资源负载。
-
Redo size
每秒(每个事务)产生的日志大小(单位字节)
-
Logical reads
每秒(每个事务)产生的逻辑读(单位是 block)。在很多系统里 select 执行次数要远远大于 transaction 次数。这种情况下，可以参考 Logical reads/Executes。在良好的 oltp 环境下，这个应该不会超过 50，一般只有 10 左右。如果这个值很大，说明有些语句需要优化。
-
Block Changes
每秒(每个事务)改变的数据块数。
-
Physical reads
每秒(每个事务)产生的物理读(单位是 block)。一般物理读都会伴随逻辑读，除非直接读取这种方式，不经过 cache。
-
Physical writes
每秒(每个事务)产生的物理写(单位是 block)。
-
User calls
每秒(每个事务)用户调用次数。User calls/Executes 基本上代表了每个语句的请求次数，Executes 越接近 User calls 越好。
-
Parses
每秒(每个事务)产生的解析(或分析)的次数，包括软解析和硬解析，但是不包括快速软解析。软解析每秒超过 300 次意味着你的"应用程序"效率不高，没有使用 soft soft parse，调整 session_cursor_cache。
-
Hard parses
每秒(每个事务)产生的硬解析次数。每秒超过 100 次，就可能说明你绑定使用的不好。
-
Sorts
每秒(每个事务)排序次数。
-
Logons
每秒(每个事务)登录数据库次数。
-
Executes
每秒(每个事务)SQL 语句执行次数。包括了用户执行的 SQL 语句与系统执行的 SQL 语句，表示一个系统 SQL 语句的繁忙程度。
-
Transactions
每秒的事务数。表示一个系统的事务繁忙程度。目前已知的最繁忙的系统为淘宝的在线交易系统，这个值达到了 1000。
-
% Blocks changed per Read
表示逻辑读用于只读而不是修改的块的比例。如果有很多 PLSQL，那么就会比较高。
-
Rollback per transaction %
看回滚率是不是很高，因为回滚很耗资源。
-
Recursive Call %
递归调用 SQL 的比例，在 PL/SQL 上执行的 SQL 称为递归的 SQL。
3.Instance Efficiency Percentages (Target 100%)
这个部分是内存效率的统计信息。对于 OLTP 系统而言，这些值都应该尽可能地接近 100%。对于 OLAP 系统而言，意义不太大。因为在 OLAP 系统中，大查询的速度才是对性能影响的最大因素。
-
Buffer Nowait %
非等待方式获取数据块的百分比。
这个值偏小，说明发生 SQL 访问数据块时数据块正在被别的会话读入内存，需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。
Buffer Nowait<99%说明，有可能是有热块(查找 xbh的tch和vlatch_children 的 cache buffers chains)。
-
Redo NoWait %
非等待方式获取 redo 数据百分比。
-
Buffer Hit %
数据缓冲命中率，表示了数据块在数据缓冲区中的命中率。
Buffer Hit<95%，可能是要加 db_cache_size，但是大量的非选择的索引也会造成该值很高(大量的 db file sequential read)。
-
In-memory Sort %
数据块在内存中排序的百分比。总排序中包括内存排序和磁盘排序。当内存中排序空间不足时，使用临时表空间进行排序，这个是内存排序对总排序的百分比。
过低说明有大量排序在临时表空间进行。在 oltp 环境下，最好是 100%。如果太小，可以调整 PGA 参数。
-
Library Hit %
共享池中 SQL 解析的命中率。
Library Hit<95%，要考虑加大共享池，绑定变量，修改 cursor_sharing 等。
-
Soft Parse %
软解析占总解析数的百分比。可以近似当作 sql 在共享区的命中率。
这个数值偏低，说明系统中有些 SQL 没有重用，最优可能的原因就是没有使用绑定变量。
<95%：需要考虑到绑定
<80%：那么就可能 sql 基本没有被重用
-
Execute to Parse %
执行次数对分析次数的百分比。
如果该值偏小，说明解析(硬解析和软解析)的比例过大，快速软解析比例小。根据实际情况，可以适当调整参数 session_cursor_cache，以提高会话中 sql 执行的命中率。
round(100*(1-:prse/:exe),2) 即(Execute 次数 - Parse 次数)/Execute 次数 x 100%
prse = select value from v$sysstat where name = ‘parse count (total)’;
exe = select value from v$sysstat where name = ‘execute count’;
没绑定的话导致不能重用也是一个原因，当然 sharedpool 太小也有可能，单纯的加 session_cached_cursors 也不是根治的办法，不同的 sql 还是不能重用，还要解析。即使是 soft parse 也会被统计入 parse count,所以这个指标并不能反应出 fast soft(pga 中)/soft (shared pool 中)/hard (shared pool 中新解析) 几种解析的比例。只有在 pl/sql 的类似循环这种程序中使用使用变量才能避免大量 parse，所以这个指标跟是否使用 bind 并没有必然联系增加 session_cached_cursors 是为了在大量 parse 的情况下把 soft 转化为 fast soft 而节约资源。
-
Latch Hit %
latch 的命中率。
其值低是因为 shared_pool_size 过大或没有使用绑定变量导致硬解析过多。要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。
-
Parse CPU to Parse Elapsd %
解析总时间中消耗 CPU 的时间百分比。即:100*(parse time cpu / parse time elapsed)
解析实际运行事件/(解析实际运行时间+解析中等待资源时间)，越高越好。
-
% Non-Parse CPU
CPU 非分析时间在整个 CPU 时间的百分比。
100*(parse time cpu / parse time elapsed)= Parse CPU to Parse Elapsd %
查询实际运行时间/(查询实际运行时间+sql 解析时间)，太低表示解析消耗时间过多。
4.Shared Pool Statistics
-
Memory Usage %
共享池内存使用率。
应该稳定在 70%-90%间，太小浪费内存，太大则内存不足。
-
% SQL with executions>1
执行次数大于 1 的 SQL 比率。
若太小可能是没有使用绑定变量。
-
% Memory for SQL w/exec>1
执行次数大于 1 的 SQL 消耗内存/所有 SQL 消耗的内存(即 memory for sql with execution > 1)。
5.Top 5 Timed Events
三、RAC Statistics
这一部分只在有 RAC 环境下才会出现，是一些全局内存中数据发送、接收方面的性能指标，还有一些全局锁的信息。除非这个数据库在运行正常是设定了一个基线作为参照，否则很难从这部分数据中直接看出性能问题。
经验
Oracle 公司经验，下面 GCS 和 GES 各项指标中，凡是与时间相关的指标，只要 GCS 指标低于 10ms，GES 指标低于 15ms，则一般表示节点间通讯效率正常。但是，即便时间指标正常，也不表示应用本身或应用在 RAC 部署中没有问题。
1.Global Cache Load Profile
2.Global Cache Efficiency Percentages (Target local+remote 100%)
3.Global Cache and Enqueue Services - Workload Characteristics
4.Global Cache and Enqueue Services - Messaging Statistics
5.Global Cache Transfer Stats
*如果 CR 的 %Busy 很大，说明节点间存在大量的块争用。
四、Wait Events Statistics
1.Time Model Statistics
这部分信息列出了各种操作占用的数据库时间比例。
-
parse time elapsed/hard parse elapsed time
通过这两个指标的对比，可以看出硬解析占整个的比例。如果很高，就说明存在大量硬解析。
-
% Not-Parse CPU
花费在非解析上 CPU 消耗占整个 CPU 消耗的比例。反之，则可以看出解析占用情况。如果很高，也可以反映出解析过多(进一步可以看看是否是硬解析过多)。
示例 - 计算 CPU 消耗
Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds
再除以总的 BUSY_TIME + IDLE_TIME
% Total CPU = 1341.8/1941.76 = 69.1%，这刚好与上面 Report 的值相吻合。
其实，在 Load Profile 部分，我们也可以看出 DB 对系统 CPU 的资源利用情况。
用 DB CPU per Second 除以 CPU Count 就可以得到 DB 在前台所消耗的 CPU%了。
这里 5.3/8 = 66.25 %
比 69.1%稍小，说明 DB 在后台也消耗了大约 3%的 CPU。
2.Wait Class
这一部分是等待的类型。可以看出那类等待占用的时间最长。
3.Wait Events
这一部分是整个实例等待事件的明细，它包含了 TOP 5 等待事件的信息。
%Time-outs: 超时百分比（超时依据不太清楚?）
4.Background Wait Events
这一部分是实例后台进程的等待事件。如果我们怀疑那个后台进程(比如 DBWR)无法及时响应，可以在这里确认一下是否有后台进程等待时间过长的事件存在。
5.Operating System Statistics
(1)背景知识
如果关注数据库的性能，那么当拿到一份 AWR 报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是 CPU。而细分起来，CPU 可能指的是：
-
OS级的User%, Sys%, Idle%
-
DB所占OS CPU资源的Busy%
-
DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU
(2)11g
如果数据库的版本是 11g，那么很幸运的，这些信息在 AWR 报告中一目了然：
OS 级的 %User 为 75.4，%Sys 为 2.8，%Idle 为 21.2，所以 %Busy 应该是 78.8。
DB 占了 OS CPU 资源的 69.1，%Busy CPU 则可以通过上面的数据得到:%Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和报告的 87.7 相吻合。
(3)10g
如果是 10g，则需要手工对 Report 里的一些数据进行计算了。Host CPU 的结果来源于 DBA_HIST_OSSTAT，AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是厘秒-也就是 1/100 秒)。
解读输出
%User = USER_TIME/(BUSY_TIME+IDLE_TIME)*100 = 146355/(152946+41230)*100 = 75.37
%Sys = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100
%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100
ELAPSED_TIME
这里已经隐含着这个 AWR 报告所捕捉的两个 snapshot 之间的时间长短了。有下面的公式。正确的理解这个公式可以对系统 CPU 资源的使用及其度量的方式有更深一步的理解。
BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
推算出：ELAPSED_TIME = (152946+41230)/8/100 = 242.72 seconds //这是正确的。
时间统计视图 v$sys_time_model
至于 DB 对 CPU 的利用情况，这就涉及到 10g 新引入的一个关于时间统计的视图 - v$sys_time_model。简单而言，Oracle 采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括：
-
background elapsed time
-
background cpu time
-
RMAN cpu time (backup/restore)
-
DB time
-
DB CPU
-
connection management call elapsed time
-
sequence load elapsed time
-
sql execute elapsed time
-
parse time elapsed
-
hard parse elapsed time
-
hard parse (sharing criteria) elapsed time
-
hard parse (bind mismatch) elapsed time
-
failed parse elapsed time
-
failed parse (out of shared memory) elapsed time
-
PL/SQL execution elapsed time
-
inbound PL/SQL rpc elapsed time
-
PL/SQL compilation elapsed time
-
Java execution elapsed time
-
repeated bind elapsed time
我们这里关注的只有和 CPU 相关的两个: background cpu time 和 DB CPU。这两个值在 AWR 里面也有记录。
五、SQL Statistics
1.SQL ordered by Elapsed Time
这一部分是按照 SQL 执行时间从长到短的排序。
-
Elapsed Time(S)
SQL 语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个 SQL 跑的时间，而是监控范围内 SQL 执行次数的总和时间。单位时间为秒。Elapsed Time = CPU Time + Wait Time
-
CPU Time(s)
为 SQL 语句执行时 CPU 占用时间总时长，此时间会小于等于 Elapsed Time 时间。单位时间为秒。
-
Executions
SQL 语句在监控范围内的执行次数总计。如果 Executions=0，则说明语句没有正常完成，被中间停止，需要关注。
-
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 语句执行时间很长，而 CPU 时间很少，则说明 SQL 在 I/O 操作时(包括逻辑 I/O 和物理 I/O)消耗较多。可以结合前面 I/O 方面的报告以及相关等待事件，进一步分析是否是 I/O 存在问题。当然 SQL 的等待时间主要发生在 I/O 操作方面，不能说明系统就存在 I/O 瓶颈，只能说 SQL 有大量的 I/O 操作。
如果 SQL 语句执行次数很多，需要关注一些对应表的记录变化。如果变化不大，需要从前面考虑是否大多数操作都进行了 Rollback，导致大量的无用功。
2.SQL ordered by CPU Time
记录了执行占 CPU 时间总和时间最长的 TOP SQL(请注意是监控范围内该 SQL 的执行占 CPU 时间总和，而不是单次 SQL 执行时间)。这部分是 SQL 消耗的 CPU 时间从高到底的排序。
-
CPU Time (s)
-
SQL消耗的CPU时间。
-
Elapsed Time (s)
-
SQL执行时间。
-
Executions
-
SQL执行次数。
-
CPU per Exec (s)
-
每次执行消耗CPU时间。
-
% Total DB Time
-
SQL执行时间占总共DB time的百分比。
3.SQL ordered by Gets
这部分列出 SQL 获取的内存数据块的数量，按照由大到小的顺序排序。buffer get 其实就是逻辑读或一致性读。在 sql 10046 里面，也叫 query read。表示一个语句在执行期间的逻辑 IO，单位是块。在报告中，该数值是一个累计值。Buffer Get=执行次数 * 每次的 buffer get。记录了执行占总 buffer gets(逻辑 IO)的 TOP SQL(请注意是监控范围内该 SQL 的执行占 Gets 总和，而不是单次 SQL 执行所占的 Gets)。
-
Buffer Gets
-
SQL执行获得的内存数据块数量。
-
Executions
-
SQL执行次数。
-
Gets per Exec
-
每次执行获得的内存数据块数量。
-
%Total
-
占总数的百分比。
-
CPU Time (s)
-
消耗的CPU时间。
-
Elapsed Time (s)
-
SQL执行时间。
筛选 SQL 的标准
因为 statspack/awr 列出的是总体的 top buffer，它们关心的是总体的性能指标，而不是把重心放在只执行一次的语句上。为了防止过大，采用了以下原则。如果有 sql 没有使用绑定变量，执行非常差但是由于没有绑定，因此系统人为是不同的 sql。有可能不会被列入到这个列表中。
-
大于阀值buffer_gets_th的数值，这是sql执行缓冲区获取的数量(默认10000)。
-
小于define top_n_sql=65的数值。
4.SQL ordered by Reads
这部分列出了 SQL 执行物理读的信息，按照从高到低的顺序排序。记录了执行占总磁盘物理读(物理 IO)的 TOP SQL(请注意是监控范围内该 SQL 的执行占磁盘物理读总和，而不是单次 SQL 执行所占的磁盘物理读)。
-
Physical Reads
-
SQL物理读的次数。
-
Executions
-
SQL执行次数。
-
Reads per Exec
-
SQL每次执行产生的物理读。
-
%Total
-
占整个物理读的百分比。
-
CPU Time (s)
-
SQL执行消耗的CPU时间。
-
Elapsed Time (s)
-
SQL的执行时间。
5.SQL ordered by Executions
这部分列出了 SQL 执行次数的信息，按照从大到小的顺序排列。如果是 OLTP 系统的话，这部分比较有用。因此 SQL 执行频率非常大，SQL 的执行次数会对性能有比较大的影响。OLAP 系统因为 SQL 重复执行的频率很低，因此意义不大。
-
Executions
-
SQL的执行次数。
-
Rows Processed
-
SQL处理的记录数。
-
Rows per Exec
-
SQL每次执行处理的记录数。
-
CPU per Exec (s)
-
每次执行消耗的CPU时间。
-
Elap per Exec (s)
-
每次执行的时长。
6.SQL ordered by Parse Calls
这部分列出了 SQL 按分析次(软解析)数的信息，按照从高到底的顺序排列。这部分对 OLTP 系统比较重要，这里列出的总分析次数并没有区分是硬分析还是软分析。但是即使是软分析，次数多了，也是需要关注的。这样会消耗很多内存资源，引起 latch 的等待，降低系统的性能。软分析过多需要检查应用上是否有频繁的游标打开、关闭操作。
-
Parse Calls
-
SQL分析的次数。
-
Executions
-
SQL执行的次数。
-
% Total Parses
-
占整个分析次数的百分比。
7.SQL ordered by Sharable Memory
记录了 SQL 占用 library cache 的大小的 TOP SQL。
-
Sharable Mem (b)
-
占用library cache的大小。单位是byte。
8.SQL ordered by Version Count
这部分列出了 SQL 多版本的信息。记录了 SQL 的打开子游标的 TOP SQL。一个 SQL 产生多版本的原因有很多，可以查询视图 v$sql_sahred_cursor 视图了解具体原因。对于 OLTP 系统，这部分值得关注，了解 SQL 被重用的情况。
-
Version Count
-
SQL的版本数。
-
Executions
-
SQL的执行次数。
9.SQL ordered by Cluster Wait Time
记录了集群的等待时间的 TOP SQL。这部分只在 RAC 环境中存在，列出了实例之间共享内存数据时发生的等待。在 RAC 环境下，几个实例之间需要有一种锁的机制来保证数据块版本的一致性，这就出现了一类新的等待事件，发生在 RAC 实例之间的数据访问等待。对于 RAC 结构，还是采用业务分隔方式较好。这样某个业务固定使用某个实例，它访问的内存块就会固定地存在某个实例的内存中，这样降低了实例之间的 GC 等待事件。此外，如果 RAC 结构采用负载均衡模式，这样每个实例都会被各种应用的会话连接，大量的数据块需要在各个实例的内存中被拷贝和锁定，会加剧 GC 等待事件。
-
Cluster Wait Time (s)
-
集群等待时长。
-
CWT % of Elapsd Time
-
集群操作等待时长占总时长的百分比。
-
Elapsed Time(s)
-
SQL执行总时长。
10.Complete List of SQL Text
这部分是上面各部分涉及的 SQL 的完整文本。
六、Instance Activity Statistics
1.Instance Activity Stats
这部分是实例的信息统计，项目非常多。对于 RAC 架构的数据库，需要分析每个实例的 AWR 报告，才能对整体性能做出客观的评价。
CPU used by this session
这个指标用来上面在当前的性能采集区间里面，Oracle 消耗的 CPU 单位。一个 CPU 单位是 1/100 秒。从这个指标可以看出 CPU 的负载情况。
案例 - 分析系统 CPU 繁忙程度
在 TOP5 等待事件里，找到"CPU time"，可以看到系统消耗 CPU 的时间为 26469 秒。
在实例统计部分，可以看到整个过程消耗了 1813626 个 CPU 单位。每秒钟消耗 21 个 CPU 单位，对应实际的时间就是 0.21 秒。也就是每秒钟 CPU 的处理时间为 0.21 秒。
系统内 CPU 个数为 8。每秒钟每个 CPU 消耗是 21/8=2.6(个 CPU 单位)。在一秒钟内，每个 CPU 处理时间就是 2.6/100=0.026 秒。
*总体来看，当前数据库每秒钟每个 CPU 处理时间才 0.026 秒，远远算不上高负荷。数据库 CPU 资源很丰富，远没有出现瓶颈。
七、IO Stats
1.Tablespace IO Stats
表空间的 I/O 性能统计。
-
Reads
-
发生了多少次物理读。
-
Av Reads/s
-
每秒钟物理读的次数。
-
Av Rd(ms)
-
平均一次物理读的时间(毫秒)。一个高相应的磁盘的响应时间应当在10ms以内，最好不要超过20ms；如果达到了100ms，应用基本就开始出现严重问题甚至不能正常运行。
-
Av Blks/Rd
-
每次读多少个数据块。
-
Writes
-
发生了多少次写。
-
Av Writes/s
-
每秒钟写的次数。
-
Buffer Waits
-
获取内存数据块等待的次数。
-
Av Buf Wt(ms)
-
获取内存数据块平均等待时间。
2.File IO Stats
文件级别的 I/O 统计。
八、Advisory Statistics
顾问信息。这块提供了多种顾问程序，提出在不同情况下的模拟情况。包括 databuffer、pga、shared pool、sga、stream pool、java pool 等的情况。
1.Buffer Pool Advisory
Buffer pool 的大小建议。
-
Size for Est (M)
-
Oracle估算Buffer pool的大小。
-
Size Factor
-
估算值与实际值的比例。如果0.9就表示估算值是实际值的0.9倍。1.0表示buffer pool的实际大小。
-
Buffers for Estimate
-
估算的Buffer的大小(数量)。
-
Est Phys Read Factor
-
估算的物理读的影响因子，是估算物理读和实际物理读的一个比例。1.0表示实际的物理读。
-
Estimated Physical Reads
-
估计的物理读次数。
2.PGA Memory Advisory
PGA 的大小建议。
-
PGA Target Est (MB)
-
PGA的估算大小。
-
Size Factr
-
影响因子，作用和buffer pool advisory中相同。
-
W/A MB Processed
-
Oracle为了产生影响估算处理的数据量。
-
Estd Extra W/A MB Read/ Written to Disk
-
处理数据中需要物理读写的数据量。
-
Estd PGA Cache Hit %
-
估算的PGA命中率。
-
Estd PGA Overalloc Count
-
需要在估算的PGA大小下额外分配内存的个数。
3.Shared Pool Advisory
建议器通过设置不同的共享池大小，来获取相应的性能指标值。
-
Shared Pool Size(M)
-
估算的共享池大小。
-
SP Size Factr
-
共享池大小的影响因子。
-
Est LC Size (M)
-
估算的库高速缓存占用的大小。
-
Est LC Mem Obj
-
高速缓存中的对象数。
-
Est LC Time Saved (s)
-
需要额外将对象读入共享池的时间。
-
Est LC Time Saved Factr
-
对象读入共享池时间的影响因子。
-
表示每一个模拟的shared pool大小对重新将对象读入共享池的影响情况。当这个值的变化很小或不变的时候，增加shared pool的大小就意义不大。
-
Est LC Load Time (s)
-
分析所花费的时间。
-
Est LC Load Time Factr
-
分析花费时间的影响因子。
-
Est LC Mem Obj Hits
-
内存中对象被发现的次数。
4.
建议器对 SGA 整体的性能的一个建议。
-
SGA Target Size (M)
-
估算的SGA大小。
-
SGA Size Factor
-
SGA大小的影响因子。
-
Est DB Time (s)
-
估算的SGA大小计算出的DB Time。
-
Est Physical Reads
-
物理读的次数。
九、Latch Statistics
1.Latch Activity
Get Requests/Pct Get Miss/Avg Slps /Miss
表示愿意等待类型的 latch 的统计信息。
NoWait Requests/Pct NoWait Miss
表示不愿意等待类型的 latch 的统计信息。
Pct Misses
比例最好接近 0。
十、Segment Statistics
1.Segments by Logical Reads
2.Segments by Physical Reads
段的物理读情况。
3.Segments by Buffer Busy Waits
从这部分可以发现那些对象访问频繁。Buffer Busy Waits 事件通常由于某些数据块太过频繁的访问，导致热点块的产生。
4.Segments by Row Lock Waits
AWR 报告 Segment Statistics 部分的 Segments by Row Lock Waits，非常容易引起误解，它包含的不仅仅是事务的行级锁等待，还包括了索引分裂的等待。之前我一直抱怨为什么 v$segment_statistics 中没有统计段级别的索引分裂计数，原来 ORACLE 已经实现了。但是统计进这个指标中，你觉得合适吗？
十一、其他问题
