十二.性能测试-AWR报告简要分析

AWR 是 Oracle 10g 版本推出的新特性，全称叫 Automatic Workload Repository自动负载信息库 , AWR 是通过对比两次快照 (snapshot) 收集到的统计信息，来生成报表数据，生成的报表包括多个部分。

一、Report Summary

DB Time 不包括 Oracle后台进程消耗的时间。如果 DB Time 远远小于 Elapsed 时间，说明数据库比较空闲。 db time= cpu time + wait time（不包含空闲等待）（非后台进程）说白了就是 db time 就是记录的服务器花在数据库运算 (非后台进程 )和等待(非空闲等待 )上的时间 DB time = cpu time + all of nonidle wait event time 在 79 分钟里（其间收集了 3 次快照数据），数据库耗时 11 分钟， RDA 数据中显示系统有 8 个逻辑 CPU（4 个物理 CPU），平均每个 CPU耗时 1.4 分钟， CPU 利用率只有大约 2%（1.4/79）。说明系统压力非常小。
列出下面这两个来做解释： Report A: Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1 End Snap: 4612 24-Jul-08 23:00:25 17 1.7 Elapsed: 59.51 (mins) DB Time: 466.37 (mins)
Report B: Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6 End Snap: 3102 13-Nov-07 22:00:15 40 16.4 Elapsed: 59.63 (mins) DB Time: 19.49 (mins) 服务器是 AIX 的系统， 4 个双核 cpu,共 8 个核: /sbin> bindprocessor -q The available processors are: 0 1 2 3 4 5 6 7 先说 Report A, 在 snapshot间隔中，总共约 60 分钟， cpu 就共有 608=480 分钟， DB time 为 466.37 分钟，则：
cpu 花费了 466.37 分钟在处理 Oralce 非空闲等待和运算上 (比方逻辑读 ) 也就是说 cpu 有 466.37/480100% 花费在处理 Oracle 的操作上，这还不包括后台进程看 Report B，总共约 60 分钟， cpu 有 19.49/480*100% 花费在处理 Oracle 的操作上很显然， 2 中服务器的平均负载很低。从 awr report 的 Elapsed time 和 DB Time 就能大概了解 db 的负载。

可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。

二.Cache Sizes

显示 SGA 中每个区域的大小（在 AMM 改变它们之后），可用来与初始参数值比较。 shared pool主要包括 library cache和 dictionary cache。library cache用来存储最近解析（或编译）后 SQL、PL/SQL 和 Java classes等。library cache用来存储最近引用的数据字典。发生在 library cache或 dictionary cache的 cache miss代价要比发生在 buffer cache的代价高得多。因此 shared pool的设置要确保最近使用的数据都能被 cache。

三.Load Profile

显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓“正确”的值，然而 Logons 大于每秒 1~2 个、Hard parses大于每秒 100、全部 parses超过每秒 300 表明可能有争用问题。 Redo size：每秒产生的日志大小 (单位字节 ) ，可标志数据变更频率 , 数据库任务的繁重与否。 Logical reads：每秒 /每事务逻辑读的块数 .平决每秒产生的逻辑读的 block 数。 Logical Reads= Consistent Gets + DB Block Gets Block changes：每秒 /每事务修改的块数 Physical reads：每秒 /每事务物理读的块数 Physical writes：每秒 /每事务物理写的块数 User calls：每秒 /每事务用户 call 次数
Parses：SQL 解析的次数 .每秒解析次数，包括 fast parse，soft parse和 hard parse 三种数量的综合。软解析每秒超过 300 次意味着你的 "应用程序 "效率不高，调整 session_cursor_cache 。在这里，fast parse指的是直接在 PGA 中命中的情况（设置了 session_cached_cursors=n）；soft parse是指在 shared pool中命中的情形； hard parse则是指都不命中的情况。
Hard parses：其中硬解析的次数，硬解析太多，说明 SQL 重用率不高。每秒产生的硬解析次数 , 每秒超过 100 次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数 cursor_sharing=similar|force ，该参数默认值为 exact 。但该参数设置为 similar 时，存在 bug，可能导致执行计划的不优。 Sorts：每秒 /每事务的排序次数 Logons：每秒 /每事务登录的次数 Executes：每秒 /每事务 SQL 执行次数 Transactions：每秒事务数 .每秒产生的事务数，反映数据库任务繁重与否。
Blocks changed per Read：表示逻辑读用于修改数据块的比例 .在每一次逻辑读中更改的块的百分比。 Recursive Call：递归调用占所有操作的比率 .递归调用的百分比，如果有很多 PL/SQL，那么这个值就会比较高。 Rollback per transaction：每事务的回滚率 .看回滚率是不是很高，因为回滚很耗资源 , 如果回滚率过高 , 可能说明你的数据库经历了太多的无效操作 , 过多的回滚可能还会带来 Undo Block 的竞争该参数计算公式如下 : Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。 Rows per Sort：每次排序的行数注: Oracle的硬解析和软解析。
提到软解析 (soft prase)和硬解析 (hard prase)，就不能不说一下 Oracle对 sql 的处理过程。当你发出一条 sql 语句交付 Oracle，在执行和获取结果前， Oracle 对此 sql 将进行几个步骤的处理过程：
1、语法检查 (syntax check) 检查此 sql 的拼写是否语法。
2、语义检查 (semantic check) 诸如检查 sql 语句中的访问对象是否存在及该用户是否具备相应的权限。
3、对 sql 语句进行解析 (prase) 利用内部算法对 sql 进行解析，生成解析树 (parse tree)及执行计划 (execution plan)。
4、执行 sql，返回结果 (execute and return) 其中，软、硬解析就发生在第三个过程里。 Oracle利用内部的 hash算法来取得该 sql的 hash值，然后在 library cache里查找是否存在该 hash值；假设存在，则将此 sql 与 cache中的进行比较；假设“相同”，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。这也就是软解析的过程。诚然，如果上面的 2 个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。这个过程就叫硬解析。创建解析树、生成执行计划对于 sql 的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。

四.Instance Efficiency Percentages (Target 100%)

本节包含了 Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中 Buffer Hit Ratio 也称 Cache Hit Ratio，Library Hit ratio 也称 Library Cache Hit ratio。同 Load Profile 一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的 DSS环境， 20%的 Buffer Hit Ratio 是可以接受的，而这个值对于一个 OLTP 系统是完全不能接受的。根据 Oracle 的经验，对于 OLTP 系统，Buffer Hit Ratio 理想应该在 90% 以上。 Buffer Nowait 表示在内存获得数据的未等待比例。在缓冲区中获取 Buffer 的未等待比率。 Buffer Nowait 的这个值一般需要大于 99%。否则可能存在争用，可以在后面的等待事件中进一步确认。 buffer hit 表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的 OLTP 系统，如果此值低于 80%，应该给数据库分配更多的内存。数据块在数据缓冲区中的命中率，通常应在 95%以上。
否则小于 95%，需要调整重要的参数，小于 90%可能是要加 db_cache_size 。一个高的命中率，不一定代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造成命中率很高的假相（大量的 db file sequential read），但是一个比较低的命中率，一般就会对这个系统的性能产生影响，需要调整。命中率的突变，往往是一个不好的信息。如果命中率突然增大，可以检查 top buffer get SQL，查看导致大量逻辑读的语句和索引，如果命中率突然减小，可以检查 top physical reads SQL，检查产生大量物理读的语句，主要是那些没有使用索引或者索引被删除的。 Redo NoWait 表示在 LOG 缓冲区获得 BUFFER 的未等待比例。如果太低（可参考 90%阀值），考虑增加 LOG BUFFER。当 redo buffer 达到 1M时，就需要写到 redo log 文件，所以一般当 redo buffer 设置超过 1M，不太可能存在等待 buffer 空间分配的情况。当前，一般设置为 2M的 redo buffer ，对于内存总量来说，应该不是一个太大的值。 library hit 表示 Oracle从 Library Cache中检索到一个解析过的 SQL 或 PL/SQL 语句的比率，当应用程序调用 SQL 或存储过程时， Oracle检查 Library Cache 确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle 解析此语句，并在 Library Cache 中为它分配共享 SQL 区。低的 library hit ratio 会导致过多的解析，增加 CPU 消耗，降低性能。如果 library hit ratio 低于 90%，可能需要调大 shared pool区。STATEMENT在共享区的命中率，通常应该保持在 95%以上，否则需要要考虑：加大共享池；使用绑定变量；修改 cursor_sharing 等参数。 Latch Hit：Latch 是一种保护内存结构的锁，可以认为是 SERVER 进程获取访问内存数据结构的许可。要确保 Latch Hit>99%，否则意味着 Shared Pool latch 争用，可能由于未共享的 SQL，或者 Library Cache太小，可使用绑定变更或调大 Shared Pool解决。要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和 latch 分析来查找解决问题。 Parse CPU to Parse Elapsd：解析实际运行时间 /(解析实际运行时间 +解析中等待资源时间 )，越高越好。计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed) 。即：解析实际运行时间 /( 解析实际运行时间 +解析中等待资源时间 )。如果该比率为 100%，意味着 CPU等待时间为 0，没有任何等待。 Non-Parse CPU ：SQL 实际运行时间 /(SQL 实际运行时间 +SQL 解析时间 )，太低表示解析消耗时间过多。计算公式为： % Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的 CPU时间过多。与 PARSE_CPU相比，如果 TOT_CPU很高，这个比值将接近 100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。 Execute to Parse ：是语句执行与分析的比例，如果要 SQL 重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。计算公式为： Execute to Parse =100 * (1 - Parses/Executions) 。本例中，差不多每 execution 5 次需要一次 parse。所以如果系统 Parses > Executions ，就可能出现该比率小于 0 的情况。该值<0通常说明 shared pool 设置或者语句效率存在问题，造成反复解析， reparse 可能较严重 , 或者是可能同 snapshot 有关，通常说明数据库性能存在问题。 In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大 PGA(10g)。如果低于 95%，可以通过适当调大初始化参数 PGA_AGGREGATE_TARGET 或者 SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的， SORT_AREA_SIZE是针对每个 session 设置的， PGA_AGGREGATE_TARGET则时针对所有的 sesion 的。 Soft Parse：软解析的百分比（ softs/softs+hards），近似当作 sql 在共享区的命中率，太低则需要调整应用使用绑定变量。sql 在共享区的命中率，小于 <95%, 需要考虑绑定，如果低于 80%，那么就可以认为 sql 基本没有被重用。

五.Shared Pool Statistics

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在 75%-90%间，如果太小，说明 Shared Pool有浪费，而如果高于 90，说明共享池中有争用，内存不足。这个数字应该长时间稳定在 75%～90%。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果 SQL语句被再次执行，这将使得 SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于 75%到略低于 90%的范围内 . SQL with executions>1：执行次数大于 1 的 sql 比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多 SQL 解析。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的 SQL语句。在共享池中，在观察期间将有一组未被执行过的 SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的 SQL语句组，这个数字才会接近 100%。 Memory for SQL w/exec>1：执行次数大于 1 的 SQL 消耗内存的占比。这是与不频繁使用的 SQL语句相比，频繁使用的 SQL语句消耗内存多少的一个度量。这个数字将在总体上与 % SQL with executions>1 非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有 75%～85%的共享池被使用。如果 Statspack 报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的 SQL语句的百分率应该接近于 100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。

六.Top 10 Foreground Events by Total Wait Time

db file scattered read等待事件是当SESSION等待multi-block I/O时发生的，通过是由于full table scans或index fast full scans。发生过多读操作的Segments可以在“Segments by Physical Reads”和 “SQL ordered by Reads”节中识别（在其它版本的报告中，可能是别的名称）。如果在OLTP应用中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。

DB file sequential read等待意味着发生顺序I/O读等待（通常是单块读取到连续的内存区域中），如果这个等待非常严重，应该使用上一段的方法确定执行读操作的热点SEGMENT，然后通过对大表进行分区以减少I/O量，或者优化执行计划（通过使用存储大纲或执行数据分析）以避免单块读操作引起的sequential read等待。通过在批量应用中，DB file sequential read是很影响性能的事件，总是应当设法避免。

Log File Parallel Write事件是在等待LGWR进程将REDO记录从LOG 缓冲区写到联机日志文件时发生的。虽然写操作可能是并发的，但LGWR需要等待最后的I/O写到磁盘上才能认为并行写的完成，因此等待时间依赖于OS完成所有请求的时间。如果这个等待比较严重，可以通过将LOG文件移到更快的磁盘上或者条带化磁盘（减少争用）而降低这个等待。

Buffer Busy Waits事件是在一个SESSION需要访问BUFFER CACHE中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个原因是：1）另一个SESSION正在将数据块读进BUFFER。2）另一个SESSION正在以排它模式占用着这块被请求的BUFFER。可以在“Segments by Buffer Busy Waits”一节中找出发生这种等待的SEGMENT，然后通过使用reverse-key indexes并对热表进行分区而减少这种等待事件。

Log File Sync事件，当用户SESSION执行事务操作（COMMIT或ROLLBACK等）后，会通知 LGWR进程将所需要的所有REDO信息从LOG BUFFER写到LOG文件，在用户SESSION等待LGWR返回安全写入磁盘的通知时发生此等待。减少此等待的方法写Log File Parallel Write事件的处理。

Enqueue Waits是串行访问本地资源的本锁，表明正在等待一个被其它SESSION（一个或多个）以排它模式锁住的资源。减少这种等待的方法依赖于生产等待的锁类型。导致Enqueue等待的主要锁类型有三种：TX（事务锁）, TMD（ML锁）和ST（空间管理锁）。

七.SQL Statistics-SQL ordered by Elapsed Time

SQL ordered by Elapsed Time部分可以最准确定位到某个导致的性能问题。重点关注3个参数的值：

(1).Elapsed Time(S)表示sql执行的总时间。

(2).Executions表示sql执行次数。

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

其他详细指标本文不在详细描述，大家可以根据需要具体研究相关资料。