修改隱含參數形成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源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。