ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一个参数引发的血案

一个参数引发的血案

原创 Linux操作系统 作者:fulzu 时间:2009-07-22 15:00:58 0 删除 编辑
新来公司,查看公司以前的故障文档,发现了这么一条:oracle原厂的人对生产库进行了参数调整,其中有一个参数为_no_or_expansion,默认值为false,被他们改成true。这条参数的作用是,在where条件后,本来是可以使用or条件,在这个参数的作用下,不会扩展成inlist,原来的是索引扫描,那么现在就是全表扫描。
   然后问题随之而来,库中有个最大的表,约为11亿条记录,恰好是用or写的条件,原来是index range scan,现在是full table scan。
   修改这个参数后,一切恢复正常。
   oracle原厂的人的解释是:OR expansion during optimization disabled. Very long inlists can cause problems for the Cost Based Optimizer especially when the inlist is expanded into a large number of UNION ALLed statements.
    关键现在的系统根本不存在他们说的这种情况,他们调整的依据是什么呢?如果真的有这种情况,我估计我最多加个no_expand,还没有想过用隐含参数来控制。
   同时问大家下,自己的库,都用什么隐含参数了?

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10805681/viewspace-609907/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-03-28

  • 博文量
    68
  • 访问量
    72638