由于各種各樣的原因，DBA有時會遇到SQL執行計劃突然變差的情況，導緻CPU和IO資源消耗過高，整個系統性能下降。
很多人遇到這種情況的通常做法是，立即收集表的統計資訊，讓優化器重新對SQL做硬解析，期待能夠恢複原來的執行計劃。
但是，這樣做有一些問題：
1、
如果是大表，收集統計資訊的時間會比較長，而且執行計劃變差一般伴随着CPU使用率高和IO繁忙，這個時間會更長；
2、
有些DBA在收集統計資訊時，沒有使用no_invalidate=>false選項，即使收集了統計資訊，執行計劃卻沒有立即改變。因為該參數的預設值是AUTO_INVALIDATE，優化器會選擇5個小時内的某個時間點來對SQL重新做硬解析。因為不了解這個參數，有人還會在收集完統計資訊後flush shared_pool來強制對所有SQL做硬解析。
3、
有些SQL執行計劃改變是跟統計資訊沒有關系的，即使重新收集了統計資訊，執行計劃還是無法恢複正常。
遇到執行計劃突然變差，劉老師的建議是：先用SQL profile（10g及以上版本）固定執行計劃為原來正常的執行計劃，讓業務先恢複正常，再慢慢查找原因。
很多DBA習慣于使用coe_xfr_sql_profile.sql腳本來固定sql 執行計劃，但是這個腳本操作起來比較麻煩，而且容易出錯。這個腳本的正确用途是用來做不同資料庫之間sql執行計劃的固定。
最友善的腳本是：coe_load_sql_profile.sql，使用這個腳本，隻需要輸入幾個參數，就能完成快速恢複執行計劃的任務。
具體步驟如下：
1、用DBA權限的使用者登入sqlplus （不能是sys使用者，可以是system使用者）
2、執行腳本 SQL>coe_load_sql_profile.sql
3、輸入第一個參數：需要恢複執行計劃的sql_id
4、輸入第二個參數：再輸入一次相同的sql_id
5、此時會顯示該sql_id對應的幾個執行計劃的plan_hash_value，第三個參數需要你選擇最優執行計劃對應的那個plan_hash_value
6、最後一步，輸入連接配接sqlplus使用者的密碼，導出sql profile資訊到一個表。如果不需要導出sql profile資訊，最後一步exp操作可以從原腳本中屏蔽（注釋掉以HOS exp開頭那一行）。
下面是一個具體的執行個體截圖（沒有最後做exp導出輸入密碼的步驟）：
注：
coe_load_sql_profile.sql 腳本可以從MOS網站下載下傳的sqlt工具包裡面擷取