Recost for order by (using index)引起的SQL Tunning的问题

问题来源于http://www.itpub.net/thread-957261-1-1.html。

mihawk 对10053 trace name文件解释的挺好的。

[@more@]

这个问题以前也听同事们讲过，但由于没有看过10053的trace 文件，开始还以为是oracle cbo选择错了。

今天看了这个trace文件，才发现并不是oracle的cbo出了问题，也不是统计信息不正确，看起来是这个recost for order by 的cost比较上面出了些问题，也许有隐含参数就像optimizer_index_cost_adj这个参数一样，可以控制这个recost for order by的cost成本。

于是查找x$ksppi，还真发现一个隐含参数_SORT_ELIMINATION_COST_RAT，其解释如下：

When using an index access plan for a query that has an ORDER BY clause, the final sorting can be avoided. For example, if the value were set to 5, it would mean that a plan that avoids a sort may not be 5 times more expensive than a plan that does not avoid it. Hence, the optimizer will then compare the cost of all queries accordingly and pick the low cost execution plan. A value of 0 would mean that an execution plan with ORDER BY sort elimination be chosen even if it is more expensive than queries that do a final sorting.

从中可以看出，这个参数设为0时，oracle始终选择可吧sort elimination的执行计划。这显然是有问题。于是把该参数设为1，也就是说sort elimination的cost和前面得出的执行计划的cost正常的做比较。如果设为5，也就是说如果sort elimination的cost小于前面得出的执行计划cost的1/5时，才选用sort elimination。

很奇怪,oracle为什么会将该参数的默认值设为0。

建议大家把该参数设为1.不要怕不敢在生产库使用隐含参数。

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

转载于:http://blog.itpub.net/100091/viewspace-1001320/