连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。
如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询,会发现很多和该参数有关的 Bug ,执行计划的出错特征是也走了索引,但是走了索引全扫描(INDEX FULL SCAN),如果做 10053 Trace ,会发现有个烦人的 Recost for ORDER BY 步骤,然后就会引到错误的执行计划上。
在 9i 升级到 10g 最容易遇到这个问题(原来好好的,到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发,更多的时候优化器模式是 FIRST ROWS — 这样 Oracle 会尽量消除排序,默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题:
ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5
其它可能的解决办法:对索引里面的排序保持和 SQL 里的 ORDER by 一致。
其实说白了,很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的,因为不具备普遍性,所以在某些版本中作为隐含参数出现。在生产数据库上,个别的时候启用隐含参数倒也不是不行的,只要明白了相应的隐含参数到底是干啥的就成了。
题外话:_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现,倒是感觉和 Oracle 内部代码管理有关,本来应该消除掉的,怎么后面的版本又跑了出来?
目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ,有中文译本:《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。
–EOF–
恩 下面那个中文译本也不贵,值得购买啊 :)