聽人講過一個故事 : 某優化團隊準備招聘一個人,國内的面試已經基本通過了, 剛好國外的大老闆到中國出差, 想親自跟應聘者聊聊. 為了不讓國外老闆把好不容易找到的合适人選給否決, 國内的負責人特意囑咐應聘者, 老闆要是讓你談優化, 千萬不要跟他提改參數優化的案例. 故事的結局是應聘失敗, 中間過程你們自己腦補.
今天在某平台看到一篇名為<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做特殊處理就好了, 不建議在系統級修改這些預設參數.