从AWR报告中，有以下几个问题需要注意：
1、对比dbtime和elapsed，数据库当前时段负载极低
2、从Load Profile可以看中，数据库比较繁忙，每妙事务数为48.5，每妙执行的SQL为543.8，加上top5中的log file sync等待事件，建议减少应用commit次数或者提升服务器配置
2、top5中db file sequential read、db file parallel read及db file scattered read等待时间较长，说明发生大量的物理IO，需要优化相关SQL
3、read by other session表示当一个会话读取一个buffer时，这个buffer正在被其他会话从磁盘读取到内存，通常大量全表扫会出现该等待，建议优化相关SQL或者控制并发，同时direct path read也通常是全表扫描出现的等待。
4、sql优化对象主要看SQL报告中的SQL，优化之后数据库IO压力很有很大提升。
评论
有用 0你取第二个awr时间跨度太大了。
第一个AWR，log file switch (checkpoint incomplete)，结合log file parallel write，后台等待平均并不长，有可能redo设置过小导致。
评论 有用 0从AWR看：
首先取的AWR的时间跨度过大，可以只取问题时间段的1小时就可以，时间跨度大不利于分析。
从第一个AWR看：
1.从前台等待事件的平均等待看主要是log file switch (checkpoint incomplete)，recovery area: computing obsolete files两个等待事件。
log file switch(checkpoint incomplete):指的是当redo需要向下一组redo group切换的时候，发现下组日志是active的，也就是说下组日志中对应的一些buffer cache中的脏块尚未写入到数据文件中，因此必须等待这些脏块被完毕后，才可以复用下一组redo group，从平均等待事件来看，这个等待相对比较长，说明redo日志切换比较频繁，事务量比较大，或者redo日志比较小。
从日志的切换频率看：每小时切换次数为14次，相对有点频繁。
建议：增加redo日志组，增大redo日志组的大小。
recovery area: computing obsolete files：
这个有检查一下快速恢复区的空间以及磁盘的IO情况。
从整理的来看：整个系统整体负载是比较低的。
评论 有用 0
