听人讲过一个故事 : 某优化团队准备招聘一个人,国内的面试已经基本通过了, 刚好国外的大老板到中国出差, 想亲自跟应聘者聊聊. 为了不让国外老板把好不容易找到的合适人选给否决, 国内的负责人特意嘱咐应聘者, 老板要是让你谈优化, 千万不要跟他提改参数优化的案例. 故事的结局是应聘失败, 中间过程你们自己脑补.
今天在某平台看到一篇名为<Oracle调优参数详解>的文章, 里面介绍了一些参数优化方法, 阅读次数超过了1500人次, 应该被很多人作为参考, 我来谈谈我的看法(带标号的截图是原文, 下面部分是我的观点).
tiger:
这个参数的默认值是300, 写成50应该是原作者的笔误. 正常情况, 一个session一般不会打开超过300个游标, 设置过大没有意义. 如果实际open_cursor数量超过了300, 非常有可能是出现了游标泄漏, 需要开发人员检查并修复代码,及时关闭游标. 如果设置很大,比如文章中的20000, 测试时很难发现游标泄漏这些问题, 会把隐患带到生产系统, 这种设置我认为不可取.设置成1000已经足够大了.
tiger:
上面两个参数的修改, 我在不少生产系统见过, 也遇到一些导致性能变差的案例, 有几个案例在我之前的公众号文章和培训课程里都有介绍,总结为一句话就是不要改这两个参数,保持默认值. 靠修改这两个参数,让优化器勉强使用一些低效索引, 可能适得其反. 正确的做法是深入了解索引, 创建高效索引.
tiger:
普通的RAC心跳网络, 可能千兆网居多,如果没有做好业务分区,节点之间数据交换会比较多, 修改这个参数确实没问题. 但是也不能一概而论, 如果是infiniband 网络(比如oracle 的Exadata), 而且是OLAP系统, 这个参数是没有必要修改的.
tiger:
上面参数出现了两次,都是建议改成16. 很多人把这个值改小, 也是为了让优化器倾向使用索引, 而不是全表扫描,官方文档也是这样说的,但官方文档没有建议修改(如果16是最佳, 那么默认参数就可能早就改成16了). oracle大量的性能测试, 都是使用的默认参数,如果修改了默认参数, 那么可选项就变多了, oracle不可能把各种非默认参数都做大规模的性能测试. 还是上面那句话, 尽量创建高效索引, 参数改小只是为了让优化器更容易选择低效索引, 而且这种改动还不利于全表扫描的情况(大部分系统都是OLTP和OLAP混合的).
tiger:
对于参数的解释没有问题, 但是为什么要取消资源管理器的使用呢? 该用的时候还是要用的, 设置不合适的地方可以调整, 而不是一禁了之.
补充:
还有很多人喜欢修改很多optimizer开头的优化器参数(包括_optimizer开头的隐含参数), 都是不建议的, 除非这些参数会导致大面积的bug. 大部分情况这些参数产生的bug也只会影响少量的特殊SQL, 对这些SQL做特殊处理就好了, 不建议在系统级修改这些默认参数.
