修改隐含参数形成SQL性能降低案例之三

    周末，继续放轻松，了解点常识。

    常常在客户的生产系统发现_gby_hash_aggregation_enabled 这个参数被设置成false，对于通常的中小系统，数据量相对较少，这个参数的影响不会太大。若是数据量比较大，性能的差距就比较明显了，下面是在某个客户现场实测的数据。

设置 _gby_hash_aggregation_enabled = false，SQL执行时间接近10分钟：

设置 _gby_hash_aggregation_enabled = TRUE，SQL执行时间5分钟多一点，性能相差接近1倍：

注：为了减小数据缓存产生的偏差，每一个SQL都执行了两次，时间相差能够忽略不计。

再来看看两种状况的执行计划对比：

_gby_hash_aggregation_enabled = false，使用Sort group by：

_gby_hash_aggregation_enabled = True，使用Hash group by：

    这就是为何不建议将一些性能相关的优化器参数关闭的缘由了。

    _gby_hash_aggregation_enabled 这个隐含参数在10g的较早版本可能存在bug，被设置成了false；不少客户升级到11g后，仍保持该参数为false，建议检查bug修复列表，若是相关bug已修复，建议设置该参数为TRUE。

    若是遇到某些特定SQL确实遇到了bug，能够在SQL级别关闭该参数：

如 select /*+ OPT_PARAM('_gby_hash_aggregation_enabled' 'false') */ ......

也能够使用sql profile，不用修改SQL代码，也能够让参数设置生效。

本文分享自微信公众号 - 老虎刘谈oracle性能优化（sql_tigerliu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。