对于数据库整体的性能问题，AWR的报告是一个非常有用的诊断工具。
一般来说，当检测到性能问题时，我们会收集覆盖了发生问题的时间段的AWR报告-但是***只收集覆盖1个小时时间段的AWR报告-如果时间过长，那么AWR报告就不能很好的反映出问题所在。
还应该收集一份没有性能问题的时间段的AWR报告，作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的，比如都是半个小时的，或者都是一个小时的。
Interpretation
在处理性能问题时，我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得***的好处。
AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息，可以让我们只关注主要的问题。
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件，如下：
Top 5 Events部分包含了一些跟Events(事件)相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间;这一部分是按照每个Event占总体call time的百分比来进行排序的。
根据Top 5 Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据 库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题;10个用户引起的1000万次的等待事件比 10,000个用户引起的相同的等待要更有问题。
就像上面的例子，将近60%的时间是在等待IO相关的事件。
- 事件"db file scattered read"一般表明正在做由全表扫描或者index fast full scan引起的多块读。
- 事件"db file sequential read"一般是由不能做多块读的操作引起的单块读(如读索引)
其他20%的时间是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的(或者这些SQL有可能用更少的资源完成同样的操作);对于这样的SQL，过多的IO操作也是一个症状。关于CPU使用方面，我们会在之后讨论。
在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它;若是正常的，检查下个等待事件。
过多的IO相关的等待一般会有两个主要的原因：
- 数据库做了太多的读操作
- 每次的IO读操作都很慢
Top 5 Events部分的显示的信息会帮助我们检查：
- 是否数据库做了大量的读操作：
上面的图显示了在这段时间里两类读操作都分别大于1000万，这些操作是否过多取决于报告的时间是1小时或1分钟。我们可以检查AWR报告的elapsed time
如果这些读操作确实是太多了，接下来我们需要检查AWR报告中 SQL Statistics 部分的信息，因为读操作都是由SQL语句发起的。
- 是否是每次的IO读操作都很慢：
上面的图显示了在这段时间里两类读操作平均的等待时间是小于8ms的
至于8ms是快还是慢取决于底层的硬件设备;一般来讲小于20ms的都可以认为是可以接受的。
我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息
如上图，我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读操作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。
- 虽 然高"db file scattered read"和"db file sequential read"等待可以是I / O相关的问题，但是很多时候这些等待也可能是正常的;实际上，对一个已经性能很好的数据库系统，这些等待事件往往在top 5等待事件里，因为这意味着您的数据库没有那些真正的“问题”。
诀窍是能够评估引起这些等待的语句是否使用了***的访问路径。如果"db file scattered read"比较高，那么相关的SQL语句可能使用了全表扫描而没有使用索引(也许是没有创建索引，也许是没有合适的索引);相应的，如果"db file sequential read"过多，则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。这些等待可 能说明SQL语句的执行计划不是***的。
接下来就需要通过AWR来检查这些top SQL是否可以进一步的调优，我们可以查看AWR报告中 SQL Statistics 的部分.
上面的例子显示了20%的时间花在了等待或者使用CPU上，我们也需要检查 SQL statistics 部分来进一步的分析。
需要注意，接下来的分析步骤取决于我们在TOP 5部分的发现。在上面的例子里，3个top wait event表明问题可能与SQL语句执行计划不好有关，所以接下来我们要去分析"SQL Statistics"部分。
同样的，因为我们并没有看到latch相关的等待，latch在我们这个例子里并没有引发严重的性能问题;那么我们接下来就完全不需要分析latch相关的信息。
一般来讲，如果数据库性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比较明显(不管它们之间的顺序如何)，我们总是需要检查Top SQL (by logical and physical reads)部分;调用SQL Tuning Advisor或者手工调优这些SQL来确保它们是有效率的运行。
SQL Statistics
AWR包含了一些不同的SQL统计值：
根据Top 5 部分的Top Wait Event不同，我们需要检查不同的SQL statistic。
在我们这个例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU;我们最需要关心的是SQL ordered by CPU Time, Gets and Reads。
我们会从"SQL ordered by gets"入手，因为引起高buffer gets的SQL语句一般是需要调优的对象。
对这些Top SQL,可以手工调优，也可以调用SQL Tuning Advisor。
分析：
- -> Total Buffer Gets: 4,745,943,815
假设这是一个一个小时的AWR报告，4,745,943,815是一个很大的值;所以需要进一步分析这个SQL是否使用了***的执行计划
- Individual Buffer Gets
上面的例子里单个的SQL的buffer get非常多，最少的那个都是8亿5千万。这三个SQL指向了两个不同的引起过多buffers的原因：
注意：对于某些非常繁忙的系统来讲，以上的数字可能都是正常的。这时候我们需要把这些数字跟正常时段的数字作对比，如果没有什么太大差别，那么这些SQL并不是引起问题的元凶(虽然通过调优这些SQL我们仍然可以受益)
# 单次执行buffer gets过多
SQL_ID为'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL语句总共被执行了168次，但是每次执行引起的buffer gets超过500万。这两个SQL应该是主要的需要调优的候选者。
# 执行次数过多
SQL_ID 'grr4mg7ms81' 每次执行只是引起16次buffer gets,减少这条SQL每次执行的buffer get可能并不能显著减少总共的buffer gets。这条语句的问题是它执行的太频繁了，6500万次。
改变这条SQL的执行次数可能会更有意义。这个SQL看起来是在一个循环里面被调用，如果可以让它一次处理的数据更多也许可以减少它执行的次数。
