親愛滴伙伴們，大家好。今天聊聊最近遇到的一個SQL使用COE腳本綁定執行計劃后，執行計劃依舊跳大繩樣的頻繁變化的問題。故事得從值班同事收到告警短信：“racdb1SQL_ID:fhupp15vwzxt1執行計劃頻繁改變”說起。

登上環境檢查發現該sql_id的執行計劃一直在頻繁變化。

注：紅框選中的為SQL的hash_value

哥們我在使用COE腳本對執行計劃1957363513綁定之后發現執行計劃還是一直在變化。

這就有點奇怪了，為啥會這樣？接下來查看各執行計劃有啥區別：

在表t_bh_tab1走了IDX_T_BH_TAB_1索引

在表t_bh_tab1走的是全表掃

在表t_bh_tab1走了IDX_T_BH_TAB_2索引

看到這兒我們會發現SQL各執行計劃區別在于t_bh_tab1表上掃描方式不一樣，通過查詢v$sql_plan發現該SQL對應的表所屬用戶有user1,user2,user0。

接下來我們查看這三個用戶下t_bh_tab1表的索引情況：(基于安全要求，索引情況未做截圖)通過比對發現user1跟user2是完成一致的，都是10個索引，但user0上只有8個，其中7個索引是相同的，有一個主鍵索引是獨有的。user1,user2比user0多三個索引：

IDX_T_BH_TAB_1

IDX_T_BH_TAB_9

IDX_T_BH_TAB_10

少一個主鍵索引：
PK_T_BH_TAB

在確認SQL表統計信息正常的情況下，發現執行計劃1957363513走的索引是IDX_T_BH_TAB_1，但user0用戶下的該表沒有這個索引。但執行計劃1001134107走的IDX_T_BH_TAB_2索引是三個用戶都有的。通過做sqlt發現執行計劃1001134107比執行計劃1957363513更高效。

于是將執行計劃1957363513解綁，并使用coe_xfr_sql_profile.sql腳本對執行計劃1001134107進行綁定

圖中我們選中了一個消耗最少的執行計劃。然后會生成綁定執行計劃的sql腳本

運行腳本即完成了SQL執行計劃的綁定，注意在綁定之后要讓SQLcursor失效重新解析就會使用綁定的執行計劃。

至此SQL執行計劃就未再發生改變，也就是所有用戶的該SQL執行計劃恢復正常。

好了，本次分享結束，我們下次見。