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可能达到 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、递归调用。

--看到这里，就猜测可能是回收站引起的问题了，我们接下来再看。

四、看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的大小。

##欢迎联系我，我的QQ是156580801，期待与您的交流！！
##我是MUST，我喂自己袋盐！！

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

转载于:http://blog.itpub.net/30268819/viewspace-1683994/