awr学习

library hit
buffer hit

--这两项应该特别关注

报告的第一部分：它包含了一些数据库和实例的信息

sessions
--采集实例连接的会话数，了解并发用户的大概情况，判断数据库的类型很有用

db time
--这个数据比较重要，它表示用户操作花费的时间，包括cpu时间和等待时间，
eg:在60分钟的周期中，用户的时间占用了422分钟，这个比例是相关高的，说明数据库比较繁忙，如果我们看到这样的信息，那么应该到top5的等待部分去查看究竟是什么事件占用了系统如此多的时间

load profile中
--physical reads 可以看到数据库的运行情况有一个大概的了解，这个数据库看起来还是比较繁忙的，有比较大的io操作

instance efficient percentages
--这部分是内存效率的统计信息，这些值都应该可能接近100

如果这部分哪个数据偏低，就要做相关的分析研究：
 比如soft parse%偏低，说明系统中有些sql没有重用，最可能的原因就是没有绑定变量；
 buffer hit%太低，说明有很多数据块没有缓存到内存中，可能原因就是内存太小，
 buffer nowait%值太小，说明发生sql访问数据块时数据库正在别别的会话读入内存，需要等待这个操作完成，发生这样的事情通常是某些数据块变成了热快

top  5 timed events
--这一部分是awr最重要的一部分，基本上首先会看这儿

db file sequential read
--它通常指的是在访问索引数据块时会以db file sequential read方式来将数据块读入到内存中
db ```超过30%，从这个数据可以看出数据块中移动运行着非常多的大查询，这个等待时间通常是由sql语句造成的，看看它是否存在性能的问题

cpu
--time看起来比较高--4907，比1小时高，这个和机器的cpu有关

latch
--共享池争用等待事件，
可能是并发太多，也就是多个会话可能在争用相同的资源，

top5 timed events
如果这一部分显示前5位等待事件一共也没有等待多久，比如第一位在几分钟等待，那么就没必要做性能上的优化

--对一个系统来讲，我们可能需要多做几次这样的报告，以便得到所有事件段的性能数据

time model statistics
--这一部分信息列出了各种操作占用的数据库时间比例，这也是很有用的一部分，我们从这个列表立刻就发现，

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22815499/viewspace-719719/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22815499/viewspace-719719/