AWR数据库优化案例分享（OLAP）
分享一个案例，说说如何来看AWR。 提到优化，不得不提AWR？ 想起来刚接触Oracle的时候别人问我会不会优化，我说会呀，在高峰时段跑个AWR，然后分析TOP 10 SQL，现在想来，很是汗颜！ 经过一段时间的学习，又有了一些不成熟的想法，写了下来，也许再过两年来看得时候，会很有趣！ 话不多说，结合案例，进入正文。 一、关于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可能达到 了。 三、第二个部分：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、递归调用。 --看到这里，猜测可能是回收站引起的问题了，我们接下来再看。五、看TOP SQL
看到这里豁然开朗，果然是回收站引起的问题，那么第一步是关闭回收站； 找到第一个点以后，细心观察你会发现第二个点： Execution=0 因为此AWR的生成间隔是一个小时，所以Execution等于0表示某些SQL一个小时都没有跑完； 不难看出这是一个OLAP的数据库，OLTP一般是不会有这种SQL的，OLAP跑这么慢很有可能是没有开启nologging模式； OLAP如何解决慢的问题呢？ 1、创建表的时候nologging： --create table xxx nologging； 2、插入数据的时候开并行： --insert /*+ append */; 3、开启会话级的DML并行： --alter session enable parallel dml; 4、连接sql不走hash的让他强制走hash： --sql hint 走hash 那么此数据库的优化方案是： 1、关闭收站； 2、开启nologing； 3、并行插入； 4、改hash。 回顾上面的过程，再分享一些架构设计经验： OLAP的block块好要设置为16K； OLAP的PGA要尽量设置的够大，比如接近SGA的大小。
