发表于: 2008.03.22 18:06
分类: Oracle技术
出处: http://logzgh.itpub.net/post/3185/457946
---------------------------------------------------------------
问题来源于http://www.itpub.net/thread-957261-1-1.html。
mihawk 对10053 trace name文件解释的挺好的。
这个问题以前也听同事们讲过，但由于没有看过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.不要怕不敢在生产库使用隐含参数。
new.txt;1;7