修改隐含参数造成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代码，也可以让参数设置生效。