帮客户优化时发现,同样是OPTIMIZER_FEATURES_ENABLE参数,在会话级设置和在HINT中指定的效果不同。
客户的数据库从11.1.0.6升级到最新的11.2.0.2之后,一些原本运行正常的SQL,查询性能变得比较差,尝试利用OPTIMIZER_FEATURES_ENABLE方式来恢复原始的执行计划,但是发现有时在会话级设置OPTIMIZER_FEATURES_ENABLE参数执行计划并没有改变,而如果直接在SQL中设置OPTIMIZER_FEATURES_ENABLE提示,则可以使得SQL的执行计划恢复到升级之前。
由于SQL 本身比较复杂,而且事实上和当前这个主题的关系不大,这里就不列出来了。一共针对6个性能变差的SQL进行调整,发现如果使用ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE = ’11.1.0.6’的方式,则有3个语句恢复11.1.0.6中的执行计划,而对于另外3个执行计划并没有改变。
而如果尝试在SQL中直接嵌入提示/*+ OPTIMIZER_FEATURES_ENABLE(’11.1.0.6’) */结果发现其中5个SQL恢复了11.1.0.6的执行计划,而只有1个SQL执行计划没有改变。
虽然一直都清楚,使用OPTIMIZER_FEATURES_ENABLE并不能100%保证SQL的执行计划恢复到指定版本,但是确实没有想到,OPTIMIZER_FEATURES_ENABLE在提示中指定和在会话级设置还会有所区别。如果说HINT的优先级更高会覆盖会话级设置,这可以理解,但是二者效果有所区别,就说不过去了。除非是OPTIMIZER_FEATURES_ENABLE在会话级的设置不足以覆盖某些其他的会话级参数设置,从而导致这个现象的产生。
-
Recent Posts
Recent Comments
- yangtingkun on 非空字段空值对查询的影响
- Eric Zong on 非空字段空值对查询的影响
- Kamus on Oracle Ace Director
- 设置全局死锁优先级 | yangtingkun on RAC全局死锁检测时间
- ORA-600(krbounotread_noctx)错误 | yangtingkun on ORA-600(krboReadBitmap_badbitmap)错误
Archives
- December 2020
- February 2019
- December 2018
- November 2018
- October 2018
- July 2018
- June 2018
- May 2018
- July 2016
- July 2013
- June 2013
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
Categories
Meta