分享一个案例，说说如何来看AWR。
提到优化，就不得不提AWR？
经过一段时间的学习，又有了一些不成熟的想法，就写了下来，也许再过两年来看得时候，会很有趣！
话不多说，结合案例，进入正文。
一、关于AWR的生成时间跨度问题：
首先：AWR的生成跨度一般不要超过一个小时，超过一个小时则没有参考价值；
其次：AWR的生成跨度在一个小时以内的，最好结合ASH来看；
再次：AWR的生成跨度在半个小时以内的，可以不需要ASH；
小贴士：
1、如何生成ASH？
@?/rdbms/admin/ashrpt.sql
2、修改awr生成间隔及保留周期（30分钟，10天）
exec dbms_workload_repository.modify_snapshot_settings(interval=>30,Retention=>10*24*60);
二、第一个参数：DB Time
dbtime是看AWR第一个需要注意的参数，请看上图：（本例中使用的所有图片均为同一个AWR报告）
dbtime的计算公式是：dbtime=cpu核数*60秒=32*60=1920（本例中CPU核数为32）
实际的DB Time超过了1920，那么表示CPU可能达到 100%了。
三、第二个部分：Load Profile
参数说明：
Redo size --单位：Byte；大小：约31M；由此可知此系统的Redo Size 的写入频率为31M/S；
--以此例说明一下redo日志组的大小计算问题：
如果Redo的写入速度是31M/S，那么redo log的大小应该设置为多少？
已知Redo是3秒写入一次的，虽然目前的写入速度是31M/S，但是按照经验我们一般Double一下，Redo log的大小设置为180M左右。
Logic Read --本例逻辑读的单位是块，大小是8K。
--本例中逻辑读为：1852985*8/1024/1024=14.13G /S
--根据与其他DBA的交流经验，一个CPU1秒大概能处理1G左右的数据，那么光逻辑读此系统就消耗了15个CPU，占了CPU总数的一半；
Block Change --每秒的块变化数，物理读与物理写还不算特别严重，没有太多IO消耗，每秒读约60M左右的数据；
--看到这里可以得出一个结论了，那就是此系统IO不是问题，CPU是问题。
下来看到硬解析，如下图：
Hard parses --硬解析sql 一个CPU大概能支撑10个左右的Hard Parses（SQL），平均30个硬解析sql占用3个CPU
--结论：又增加了CPU负担
四、等待事件：
做优化现在命令率啥的，一般都可以不看了，一般都开等待事件；
Cache buffer chains --CBC可以理解为热点快，唯一有可能解决CBC的方法就是SQL优化；
row cache lock --行缓存锁；
--引起原因有四个
1、sequence没加cache；
2、开了回收站；
3、用多了同义词；
4、递归调用。
--看到这里，就猜测可能是回收站引起的问题了，我们接下来再看。
