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

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

注：紅框選中的為SQL的hash_value

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

這就有點(diǎn)奇怪了，為啥會(huì)這樣？接下來(lái)查看各執(zhí)行計(jì)劃有啥區(qū)別：

在表t_bh_tab1走了IDX_T_BH_TAB_1索引

在表t_bh_tab1走的是全表掃

在表t_bh_tab1走了IDX_T_BH_TAB_2索引

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

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

IDX_T_BH_TAB_1

IDX_T_BH_TAB_9

IDX_T_BH_TAB_10

少一個(gè)主鍵索引：
PK_T_BH_TAB

在確認(rèn)SQL表統(tǒng)計(jì)信息正常的情況下，發(fā)現(xiàn)執(zhí)行計(jì)劃1957363513走的索引是IDX_T_BH_TAB_1，但user0用戶下的該表沒(méi)有這個(gè)索引。但執(zhí)行計(jì)劃1001134107走的IDX_T_BH_TAB_2索引是三個(gè)用戶都有的。通過(guò)做sqlt發(fā)現(xiàn)執(zhí)行計(jì)劃1001134107比執(zhí)行計(jì)劃1957363513更高效。

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

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

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

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

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