概述：

AWR 全称叫Automatic Workload Repository（自动负载信息库）。是Oracle提供的性能收集和分析工具，进行Oracle性能调优的利器。能提供一个时间段内整个系统资源使用情况的报告，通过报告，可以了解系统的整个运行情况，就像一个人全面的体检报告。

Oracle启动后，后台会有个进程去每小时采集一次系统的快照信息，AWR通过对比两次快照(snapshot)收集到的统计信息，来生成报表数据。

信息采集来源为： V$active_Session_History视图。该视图可以展示最近活动会话的历史记录。并将采集到的信息保存8天。

快照由MMON和MMNL的进程自动地每隔固定时间采集一次。MMON进程负责执行多种和管理相关的后台任务，MMNL负责执行轻量级且高频率的管理相关的后台任务。

1. WORKLOAD REPOSITORY report for

• 这是DB的一些基本信息，DB name，instance name, instance number, DB version以及是否是RAC安装。
• 此表显示抓取时间为2020/8/1 8:00:20至9:00:26，共计60.11分钟。开始sessions（即连接数）是135个，结束是sessions是134个。
• Cursors/Session是指平均每个session open的cursors数量。
• 对于大多数系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。
• DB TIME：代表了此统计期间的数据库负载，是所前台session花费在database调用上的总和时间（包括CPU时间、IO Time、和其他一系列非空闲等待时间）。如果 DB Time 接近于 Elapsed Time*cpu 数,表明数据库比较忙,cpu 负载也许比较大
• cpu利用率为：DB Time /(Elapsed* NUM_CPUS)=657/(60*160) *100%=6.8%。

2. Load Profile

• 显示数据库负载概况，将之与基线数据比较才具有更多的意义，如果每秒或每事务的负载变化不大，说明应用运行比较稳定。单个的报告数据只说明应用的负载情况，绝大多数据并没有一个所谓"正确"的值，然而Logons大于每Redo size：每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。
• 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：每次排序的行数

3.Instance Efficiency Percentages (Target 100%)

• Buffer Nowait %：session申请一个buffer(兼容模式)在db buffer cache中不等待的次数比例。
• Buffer Hit %：数据块在数据缓冲区中的命中率，小于90%可能是要加db_cache_size，但这个指标即便99% 也不能说明物理读等待少了，但是指标小于90%，那肯定是存在大量物理读
• Library Hit %：申请一个library cache object例如一个SQL cursor时，其已经在library cache中的比例（表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率），低的library hit ratio会导致过多的解析，增加CPU消耗。比例过小则需要增加shared pool大小
• Execute to Parse %：表示sql语句解析后被重复执行的命中率，如果该值偏小，说明分析（硬分析和软分析）的比例较大，快速分析较少，其公式为 1-(parse/execute)
• Parse CPU to Parse Elapsd %：解析CPU时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time)【解析实际运行时间/(解析实际运行时间+解析中等待资源时间)】；若该指标水平很低，那么说明在整个解析过程中 实际在CPU上运算的时间是很短的，而主要的解析时间都耗费在各种其他非空闲的等待事件上了（有时候Parse CPU to Parse Elapsd%会超过100%，这是由于四舍五入造成的，CPU Time是一点一点记录，并累加的（按SQL Parse 中的每个Call）而Elapsed Time 是一段一段纪录，并累加的（按SQL 一次parse）比如说，现在开始一个 parse , 中间有100次call, 本来每次应该是 0.8 微秒，但是，Oracle 记录时每次计成是 1 微秒，结果，这一次的parse CPU 被记录成 100 微妙。而Elapsed Time 纪录的是整个的时间，等于 0.8 *100 + （wait time）,结果就可能小于 100 微妙。而最终结果就是 Parse CPU to Parse Elapsd% > 100%）
• Redo NoWait %：session获取buffer 在redo buffer cache中不用等待的比例，redo相关的资源如redo space request争用可能造成生成redo时需求等待。
• In-memory Sort %：排序在内存PGA中的比例。（不是workarea中所有的操作类型只是排序，所以现在越来越鸡肋了），比例过小则需要增加PGA_AGGREGATE_TARGET值
• Soft Parse %：软解析的百分比，softs/(softs+hards), 太低则需要调整应用使用绑定变量
• Latch Hit %：有申请不要等待的比例
• % Non-Parse CPU：非解析cpu比例，公式为 (DB CPU – Parse CPU)/DB CPU， 若大多数CPU都用在解析上了，则可能好钢没用在刃上了。

4.Top 10 Foreground Events by Total Wait Time

• 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（空间管理锁）。

5.Wait Classes by Total Wait Time

6.Host CPU

7.Instance CPU

8.IO Profile

9.Memory Statistics

10. Cache Sizes

• Buffer Cache也叫数据库缓冲区高速缓存，是SGA中用来缓存已从数据文件中检索到的数据块的副本。是缓存最常用的段，以便尽可能减少访问数据时物理磁盘I/O的次数。基本上Buffer Cache越大越好。
• Shared Pool主要包括library cache和dictionary cache。library cache用来存储最近解析（或编译）过的SQL、PL/SQL语句及它们对应的hash值和执行计划等。library cache用来存储最近引用的数据字典。发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。因此shared pool的设置要确保最近使用的数据都能被cache。
• Std Block Size是数据块大小。
• Log Buffer是重做日志缓冲区大小。

11. 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%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。

总结：

AWR的引入，为我们分析数据库提供了非常好的便利条件。曾经有这样的一个比喻——“一个系统，就像是一个黑暗的大房间，系统收集的统计信息，就如同放置在房间不同位置的蜡烛，用于照亮这个黑暗大房间。Oracle，恰到好处地放置了足够的蜡烛(AWR)，房间中只有极少的烛光未覆盖之处，性能瓶颈就容易定位。而对于蜡烛较少或是没有蜡烛的系统，性能优化就如同黑暗中的舞者。”