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

登上環(huán)境檢查發(fā)現(xiàn)該sql_id的執(zhí)行計劃一直在頻繁變化。

注：紅框選中的為SQL的hash_value

哥們我在使用COE腳本對執(zhí)行計劃1957363513綁定之后發(fā)現(xiàn)執(zhí)行計劃還是一直在變化。

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

在表t_bh_tab1走了IDX_T_BH_TAB_1索引

在表t_bh_tab1走的是全表掃

在表t_bh_tab1走了IDX_T_BH_TAB_2索引

看到這兒我們會發(fā)現(xiàn)SQL各執(zhí)行計劃區(qū)別在于t_bh_tab1表上掃描方式不一樣，通過查詢v$sql_plan發(fā)現(xiàn)該SQL對應(yīng)的表所屬用戶有user1,user2,user0。

接下來我們查看這三個用戶下t_bh_tab1表的索引情況：(基于安全要求，索引情況未做截圖)通過比對發(fā)現(xiàn)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表統(tǒng)計信息正常的情況下，發(fā)現(xiàn)執(zhí)行計劃1957363513走的索引是IDX_T_BH_TAB_1，但user0用戶下的該表沒有這個索引。但執(zhí)行計劃1001134107走的IDX_T_BH_TAB_2索引是三個用戶都有的。通過做sqlt發(fā)現(xiàn)執(zhí)行計劃1001134107比執(zhí)行計劃1957363513更高效。

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

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

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

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

好了，本次分享結(jié)束，我們下次見。