那么结合我们的top 5的等待事件，我们可以来衡量不同等级的top

　　sql:1.消耗多CPU的(逻辑IO比较多的)2.导致过多物理I/O的(物理IO比较多的)3.执行次数较频繁的(Execution次数比较多的)4.执行时间较长的(Elapse time比较长的)

　　先看看我的机器上采集的结果。

　　control file sequential read

　　control file single write ：控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时，这两个事件会出现。如果等待比较明显，检查单个控制文件，看存放位置是否存在I/O 瓶颈。

　　control file parallel write：当server 进程更新所有控制文件时，这个事件可能出现。如果等待很短，可以不用考虑。如果等待时间较长，检查存放控制文件的物理磁盘I/O 是否存在瓶颈。

　　以XXX测试为例，我当时采集的是AWR报告中的一部分，和statspack基本一致，可以看到位的是 SQL 语句。不得不说oracle的分析报告非常智能，非常明细，能够帮助我们迅速找到问题，配合DBA来调优。

　　前面这些内容是报告中重要的部分，虽然不同的系统生成的报告都会不一样，但是解决问题的思路是一样的，根据前面的一手信息，我们能够了解到等待时间很长的事件，再去其他的部分查找原因。

　　下面简单说说后面报告的含义，Statistic表示各种操作占用数据库的时间比例，接下来是等待事件的明细，主要用来配合前面的top5事件来分析。等待事件(Wait Events)是Oracle中比较复杂难懂的概念。Oracle 的等待事件是衡量Oracle 运行状况的重要依据及指标。等待事件很多这里不一一赘述。常见的等待事件，一般都有对应的分析手段，大家可以参考oracle的资料学习。这里我们根据XXX测试中的实例来分析。可以看到排名第二位的事件是等待 "日志文件同步" 事件消耗了大量数据库时间。英文翻译是log file sync: 日志文件同步。当一个用户提交或回滚数据 时，LGWR (Log Writer)将session 会话的重做由redo buffer 写入到重做日志中。log file sync 必须等待这一过程成功完成(Oracle 通过写redo log file 保证commit 成功的数据不丢失)，这个事件说明提交可能过于频繁。为了减少这种等待事件，可以尝试每次提交更多的记录，将重做日志置于较快的磁盘上。

　　SQL统计信息一共有以下几部分。SQL ordered by Elapsed time按照sql执行时间从长到短的排序，SQL ordered by CPU表示按照消耗CPU排序。SQL ordered by Gets表示sql获取内存块的数量，SQL ordered by Reads表示执行物理读的信息，SQL ordered by Executions表示执行次数，SQL ordered by Parse Calls表示sql被分析的次数。Sql的统计信息不能孤立的来看待，而是要结合top5事件来分析。如果是sql位，我们能通过sql统计信息辅助分析了。SQL统计信息是一个很好的补充。对于OLTP系统来说，即使是软分析，也不能过多，依旧会消耗很多内存资源。如果top5事件中出现了很频繁的sql分析相关的Latch争用，可以来这里确认哪些sql分析很频繁。

　　Latch和锁起始还是有区分的，Latch更多的是等待，而锁更多的是阻塞。Latch是oracle为了保护内存结构而发明的。Latch一般出现在这样的情况。一个数据块被一个会话读取到内存中，与此同时另外一个会话也要读取这个数据块，为了保持数据一致性，通过Latch来控制。

　　由Latch引发的问题比较多，除了未绑定变量外，还有一种情况是，重复执行的sql频繁访问一些相同的数据，因此可以将这些sql查询的结果缓存起来，不用多次查询，导致数据库块被频繁访问，而增加了会话的等待时间。

　　Statspack报告还有很多内容，包括I/O，内存等方面，不做介绍了。

　　以上介绍了数据库报告的分析过程，虽然每个数据库的运行状况各异，但是大家只要掌握分析问题的方法和思路，能很快发现问题。