SQL执行计划COE绑定后依旧频繁变化问题分析

亲爱滴伙伴们，大家好。今天聊聊最近遇到的一个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执行计划恢复正常。

好了，本次分享结束，我们下次见。