11g新特性之忽快忽慢的执行速度

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了11g新特性之忽快忽慢的执行速度，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1865字，纯文字阅读大概需要3分钟。

内容图文

今天在调一些固定的SQL，调整一下写法，加点注释，改几个别名什么的，本身没什么事情。 结果在其中某一个SQL的时候，忽然卡住了。一共是三个左连接一个EXISTS，每张表都不超过一百万行。按道理说，这种SQL就算慢，也不会超过一分钟，就得出结果。结果执行的

今天在调一些固定的SQL，调整一下写法，加点注释，改几个别名什么的，本身没什么事情。

结果在其中某一个SQL的时候，忽然卡住了。一共是三个左连接一个EXISTS，每张表都不超过一百万行。按道理说，这种SQL就算慢，也不会超过一分钟，就得出结果。结果执行的效果让我很困惑。头一次执行的时候很快，非常快，两秒出结果。再执行一次，就要很久了，反正我是没等到过结果。最长一次等了半小时，我中午饭都吃完了思密达。。。

看计划，没问题，一点问题都没有。看数据库的负载，也没什么问题。可以说库是很闲的。那这是为啥？能执行，能有速度快的，说明Oracle能找到基本正确的计划。但是为什么第二次会慢呢？一下子就想到了一个新特性，11g里对执行计划的新改进。

_OPTIMIZER_USE_FEEDBACK

简单可以理解为这是Oracle对CBO的一种持续改进。本身PLAN就是基于各种数据对实际执行时间的一种推测，COST也是基于一些算法得到的结果，不是一个确切的值。当Oracle执行过这个语句以后，可以在实际环境中得到一些采样结果，这些结果是实际跑出来的，不是推测或者算出来的。这些值比计算得到的COST和ROWS要来的靠谱的多，于是11g就打算用这些值来做动态推测，基于一个可信的执行计划的详细明细来得到更加贴切实际的计划改进。

但是俗话说的好，Oracle不到R2不要用，咳咳。。。

我的SQL就是被这个参数给搞了一下，Oracle依据首次执行的结果优化了，然后我郁闷了。。。

说说验证和解决办法吧。验证的话可以加HINT，OPT_PARAM(’_OPTIMIZER_USE_FEEDBACK‘，‘FALSE’)。如果加过以后，执行效果不再乱飘了，那么就去把这个隐含参数改成false吧。

提示一下，改隐含参数要加引号，写成“a“=b的样子，具体怎么改就不说了，能看到这里的人，改个参数还是会的，是吧。可以改session和system，都不用重启。

原文地址：11g新特性之忽快忽慢的执行速度, 感谢原作者分享。

内容总结

以上是互联网集市为您收集整理的11g新特性之忽快忽慢的执行速度全部内容，希望文章能够帮你解决11g新特性之忽快忽慢的执行速度所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端