因为各类各样的缘由，DBA有时会遇到SQL执行计划忽然变差的状况，致使CPU和IO资源消耗太高，整个系统性能降低。sql
不少人遇到这种状况的一般作法是，当即收集表的统计信息，让优化器从新对SQL作硬解析，期待可以恢复原来的执行计划。数据库
可是，这样作有一些问题：性能优化
一、微信
若是是大表，收集统计信息的时间会比较长，并且执行计划变差通常伴随着CPU利用率高和IO繁忙，这个时间会更长；oracle
二、工具
有些DBA在收集统计信息时，没有使用no_invalidate=>false选项，即便收集了统计信息，执行计划却没有当即改变。由于该参数的默认值是AUTO_INVALIDATE，优化器会选择5个小时内的某个时间点来对SQL从新作硬解析。由于不了解这个参数，有人还会在收集完统计信息后flush shared_pool来强制对全部SQL作硬解析。性能
三、优化
有些SQL执行计划改变是跟统计信息没有关系的，即便从新收集了统计信息，执行计划仍是没法恢复正常。网站
遇到执行计划忽然变差，刘老师的建议是：先用SQL profile（10g及以上版本）固定执行计划为原来正常的执行计划，让业务先恢复正常，再慢慢查找缘由。spa
不少DBA习惯于使用coe_xfr_sql_profile.sql脚原本固定sql 执行计划，可是这个脚本操做起来比较麻烦，并且容易出错。这个脚本的正确用途是用来作不一样数据库之间sql执行计划的固定。
最方便的脚本是：coe_load_sql_profile.sql，使用这个脚本，只须要输入几个参数，就能完成快速恢复执行计划的任务。
具体步骤以下：
一、用DBA权限的用户登陆sqlplus （不能是sys用户，能够是system用户）
二、执行脚本 SQL>coe_load_sql_profile.sql
三、输入第一个参数：须要恢复执行计划的sql_id
四、输入第二个参数：再输入一次相同的sql_id
五、此时会显示该sql_id对应的几个执行计划的plan_hash_value，第三个参数须要你选择最优执行计划对应的那个plan_hash_value
六、最后一步，输入链接sqlplus用户的密码，导出sql profile信息到一个表。若是不须要导出sql profile信息，最后一步exp操做能够从原脚本中屏蔽（注释掉以HOS exp开头那一行）。
下面是一个具体的实例截图（没有最后作exp导出输入密码的步骤）：
注：
coe_load_sql_profile.sql 脚本能够从MOS网站下载的sqlt工具包里面获取，或者加入刘老师的QQ群16778072 索取
本文分享自微信公众号 - 老虎刘谈oracle性能优化（sql_tigerliu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。