KDB和Oracle的性能pk小记

在偶然的机会听到了KDB,然后带着好奇和新鲜感体验了一把这个传说中和Oracle 相似度达到99%的数据库。
其中一部分的驱动力在于这个活动的奖品很丰厚，参加活动后可以拿到一个iwatch,确实是很划算的一个活动。
而对于KDB的认识，也是在对比调优中认识到的，其实结果还是大大超出我的预期。
首先来简单说一下背景，我们一共十来个人，分成两队，红队和蓝队，然后红队调优Oracle,蓝队调优KDB,然后使用benchmark在同样的加压条件下的tpcc值作为参考来对比Oracle和KDB
乍一看Oracle这边的人很占便宜，至少调优的基准和方式方法感觉都是熟悉的，不用过多的花时间在熟悉KDB上面，而对于KDB这部分，其实我觉得还是占有一定的优势，因为两队都有专门的人来提供额外的信息咨询，原厂在这方面其实更有说服力，更有经验，支持力度更大，这个调优的玄妙之处就在于我们调试的Oracle系统是一个性能很差的一个环境，里面其实还是埋了不少的机关，需要在有限的时间里把tpcc的值跑上去。
所以分组之后大家简单做了分工，最开始我的脑海中的调优思路是内核调优，参数调优，文件调优，sql调优
结果一上来开始还是有些着急，其实大家的思路最后都是花更多的时间在数据库参数调优上了。
我本来准备先查看hugepage准备先查看一下，看没有调优的空间，结果一看aix的小机环境，配置不同，x86上的方式就不管用了，于是就果断放弃了，这个部分还是要好好补补。
大家抓取性能瓶颈的时候基本大致的一致是sga的部分，结果一时忽略了其实undo的部分是个硬伤，结果回过头来，调整的时候对方的tpcc已经远远领先我们了。这个时候我们所做的调优基本就是设置commit_write为nowait方式，然后调整sga_max_size,sga_target,然后一边开始准备在线调整redo的大小，把原本的redo 50M的日志文件加大到百兆，
抓取的addm报告中更多的是sql语句的调优建议，所以暂时没有深究。
所以第一阶段和第二阶段的调优对比效果还是不理想的。
这一轮下来，大家的士气也受到了影响，我们认真梳理了一下，在参数的调整上有几个层次，
隐含参数
我发现在数据库参数中埋了一个炸弹，就是把一个隐含参数给启用了，参数是_fast_cursor_reexecute而这个参数的默认值是false,所以简单评估之后就把这个值恢复了默认的值
在sga的调整上给了30G的sga，但是查看内存组件的使用情况，shared pool被压缩到了不到2G，在200多G的内存条件下，就把shared_pool的大小设置保持在10G以上，
pga的部分也进行了调整，把pga的大小进行为了一定的调整。
open_cursors的值太低，在1000个并发的条件下，当时的值是300，所以跑不上去，session_cached_cursors的值也比较低，做了小幅度的调整
audit_trail的部分是DB，其实这个部分暂时还没有这个需求，在这种情况下审计部分的开销就不必要了，果断去除，设置为none
对于异步io的设置,filesystemio_options设置为setall,尝试启用异步io和direct io
还有一个坑就是sql_trace给打开了，果断禁用。
对于sql cursor的解析方式，大家还是建议改为similar，这部分也修改了。
在曹组系统级，大家把原有的CPU超线程设置给取消了。原来是4个，改为了默认的2个。
等大体这几个部分完成之后，再去跑分，发现和KDB组的成绩很接近了，一段时间还暂时超过了他们，这个时候才感觉到了一丝动力。
继续调整，抓取的awr报告显示还是存在一定的并发瓶颈，有一些row lock contention,在这个时候我查看了相关的几个表的ini_trans，还是原来的默认值，就简单进行了调整，把ini_trans调大。
后面的部分，在这个基础上再进行调优，大家就相对比较谨慎了，大家纠结比较多的一个地方就是redo的大小，甚至考虑要把它设置为一个极大的值，根据监控的情况，在过去的一个小时内redo切换次数在7次左右，还是可以进行小幅度的调整即可，不过后来大家大胆尝试的把redo设置为一个极大的值，效果反而还是不够理想，所以就果断放弃了。后面的更多精力就没有放在sql语句上，等到发现的时候时间已经不够了，发现其中一个性能瓶颈在于一个slelect max(xxx) from xxx的查询，其实完全可以在关注更多的细节，比如收集统计信息，比如查看index的设置情况，对面的KDB组还甚至考虑了对表进行重新分区，这些细节的调整还是有很大的作用的，非常值得肯定。这些额外的细节和加分点也着实为KDB的tpcc贡献了一部分分数。
最后Oracle和KDB的第三轮跑分结果比较相似，tpcc都在近9万,KDB略微要高一些，浪潮团队的之前的测试结果也基本和这个差不多，了解了KDB和其它数据库的对比测试，跑分的差距还是很大的，KDB的性能还是很高。对于这次优化精力我的总结还是在粒度和细节上功夫下的不够，在调优的方法和方式上，还是需要先从整体再到细节部分，不忽略每一个部分潜在的可能的性能问题。逐步深入，调优的改进之处就会更加有条理。
这种调优方式对我的感触还是很大，因为这种对比pk的方式感受更加直观，对我们分析问题和解决问题是一个非常真实的案例。没有了基准和对比的参考，我们调优的幅度和动力就不会完全发挥出来。看来这种pk的方式可以多推广推广，也非常感谢浪潮本着开放的态度来组织这次活动，无论熟悉还是不熟悉KDB的朋友都会有一些认识和了解，因为时间关系，在集群，容灾，管理方式上还没有进行深入的测试，不过相信结果应该也不赖，相信他们的技术团队在这次活动之后，也经受了很大的压力和考验，可以好好休息一下了。再次感谢。