当前位置:首页 > 开发 > 数据库 > 正文

Oracle性能优化笔记——并行&位图索引

发表于: 2013-12-04   作者:clxy   来源:转载   浏览:
摘要:   自打2003掉进某公司的DB维护项目组,到今天断断续续接触Oracle已经是十年了。尽管它依然是数一数二的RDBMS,但Oracle数据库在我这里的声望始终是仇恨。这次遇到的性能调试如下:     一个业务表,数据级别在千万行,检索条件只有一个业务年月字段,但是有多达十个的group by,且掺杂了roll_up及cube。客户要调优建议。  

  自打2003掉进某公司的DB维护项目组,到今天断断续续接触Oracle已经是十年了。尽管它依然是数一数二的RDBMS,但Oracle数据库在我这里的声望始终是仇恨。这次遇到的性能调试如下:

 

  一个业务表,数据级别在千万行,检索条件只有一个业务年月字段,但是有多达十个的group by,且掺杂了roll_up及cube。客户要调优建议。

 

  SQL文很简单,select where group by连个结合都没,索引也建了一大票。一方面受限于时间,环境和...一些因素,另一方面还是因为有趣,仅仅尝试了下面两个方向。

 

==============

= 并行

------------------

测试数据量较小,只找到个百万级别的,也贴了索引。

本地跑下SQL,只有大概10秒左右。

试着尝试并行,根本没变化!

 

尝试改变条件,估计是由于目标数据量的缘故,从index range scan变成了table access full。

再次尝试并行,有用了。并行度设置成3(本地虚拟机只4核)时,从120秒降到60秒。

SELECT  /*+ parallel(tbl, 3) */ ... from tbl

尝试增加并行度,

- 4的时候最优。

- 6的时候开始下降。

听那老爷机发出的种种奇怪的呻吟声,想来是资源到了极限。

 

 

==============

= bitmap index

------------------

由于业务字段是年月,按道理讲基数(cardinality)应该比较小。5年共60个月除以千万,应该适合bitmap才对。

但加上后,效果不理想。结果如下

 

1. 只加bitmap —— 110秒加。

2. 只并行(度=4) —— 55秒加。

3. 并行 + bitmap —— 75秒加。

4. 无 —— 115秒加

 

查了下测试数据,百万条的测试数据里有150+的年月,按理讲基数也不大。可是效果如上,不给力!

我估摸着性能开销不在检索数据上,而是在统计上的缘故。

去掉统计,只留下检索时,并行就慢于bitmap。

 

 

除了上述的简单优化外,还提了些架构方面的建议,不过那是另个话题了。

 

 

注:这测试是在PC机上跑的VM进行的,差不多也就只能做个参考。

注:这两个功能都是需要企业版。正如M大人所言,一方面讨厌Oracle,一方面还研究昂贵的企业版。真.矫情!

 

Oracle性能优化笔记——并行&位图索引

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号