因爲各類各樣的緣由，DBA有時會遇到SQL執行計劃忽然變差的狀況，致使CPU和IO資源消耗太高，整個系統性能降低。sql
不少人遇到這種狀況的一般作法是，當即收集表的統計信息，讓優化器從新對SQL作硬解析，期待可以恢復原來的執行計劃。數據庫
可是，這樣作有一些問題：性能優化
一、微信
若是是大表，收集統計信息的時間會比較長，並且執行計劃變差通常伴隨着CPU利用率高和IO繁忙，這個時間會更長；oracle
二、工具
有些DBA在收集統計信息時，沒有使用no_invalidate=>false選項，即便收集了統計信息，執行計劃卻沒有當即改變。由於該參數的默認值是AUTO_INVALIDATE，優化器會選擇5個小時內的某個時間點來對SQL從新作硬解析。由於不瞭解這個參數，有人還會在收集完統計信息後flush shared_pool來強制對全部SQL作硬解析。性能
三、優化
有些SQL執行計劃改變是跟統計信息沒有關係的，即便從新收集了統計信息，執行計劃仍是沒法恢復正常。網站
遇到執行計劃忽然變差，劉老師的建議是：先用SQL profile（10g及以上版本）固定執行計劃爲原來正常的執行計劃，讓業務先恢復正常，再慢慢查找緣由。spa
不少DBA習慣於使用coe_xfr_sql_profile.sql腳原本固定sql 執行計劃，可是這個腳本操做起來比較麻煩，並且容易出錯。這個腳本的正確用途是用來作不一樣數據庫之間sql執行計劃的固定。
最方便的腳本是：coe_load_sql_profile.sql，使用這個腳本，只須要輸入幾個參數，就能完成快速恢復執行計劃的任務。
具體步驟以下：
一、用DBA權限的用戶登陸sqlplus （不能是sys用戶，能夠是system用戶）
二、執行腳本 SQL>coe_load_sql_profile.sql
三、輸入第一個參數：須要恢復執行計劃的sql_id
四、輸入第二個參數：再輸入一次相同的sql_id
五、此時會顯示該sql_id對應的幾個執行計劃的plan_hash_value，第三個參數須要你選擇最優執行計劃對應的那個plan_hash_value
六、最後一步，輸入鏈接sqlplus用戶的密碼，導出sql profile信息到一個表。若是不須要導出sql profile信息，最後一步exp操做能夠從原腳本中屏蔽（註釋掉以HOS exp開頭那一行）。
下面是一個具體的實例截圖（沒有最後作exp導出輸入密碼的步驟）：
注：
coe_load_sql_profile.sql 腳本能夠從MOS網站下載的sqlt工具包裏面獲取，或者加入劉老師的QQ羣16778072 索取
本文分享自微信公衆號 - 老虎劉談oracle性能優化（sql_tigerliu）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。