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

48jp1lg0h0

　　自打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，一方面还研究昂贵的企业版。真.矫情！