另一篇关于oracle使用基于成本进行执行计划的文章,可以看出oracle在这方面还是有很多指的改进的地方,必须开发者指定较优的执行计划优化器。所以请大家在遇到性能极差的sql语句时,请尝试根据执行计划寻找耗时的原因。
CBO对于Oracle SQL执行计划的影响(之一)
1. 原始SQL语句
这个SQL语句是一个动态查询语句的一部分,该查询根据不同条件生成不同的SQL语句。
本例为查询2003年以来的入库单据,很少的数据。
|
2. 执行计划
我们的数据库使用dbms_stats.gather_schema_stats分析过,具有足够及时的所有数据,然而在CBO的执行计划下,优化器选择了完全
不同的执行计划.
a. no hints
这是未加任何提示时,Oralce选择的执行路径,在实际程序中,用户说死掉了,通过执行计划我们知道,不是死掉了,是慢!!!
|
用足够的耐心,我们得到了该计划的执行结果。
|
可以看到,该执行计划消耗了大量的资源以及时间,这种情况是无法忍受的。
b. rule
在RBO条件下,该语句是执行很快的
加入rule提示,我们得到以下执行计划:
|
执行该计划,我们得到以下输出:
|
c. ordered
然后我想起了Ordered提示
使用该提示的执行计划如下:
|
很幸运,Ordered提示使Oracle选择了较好的执行计划。
所以会产生这样的效果,是因为在CBO的执行计划中,对于7张数据表,Oracle需要计算7!(5040)个连接顺序,然后比较各个顺序的
成本,最后选择成本较低的执行计划。
显然,在这一判断上耗费了大量的时间。当我们使用ordered hints的时候,Oracle就不需要这一计算步骤,它只需要使用我们指定的
顺序,然后快速的给出结果。然后问题迎刃而解。
CBO对于Oracle SQL执行计划的影响(之二)
初试化参数对于执行计划的影响
有几个初试化参数对于多表连接的执行计划有重要的关系。
在Oracle 8 release 8.0.5中引入了两个参数OPTIMIZER_MAX_PERMUTATIONS 和 OPTIMIZER_SEARCH_LIMIT
optimizer_search_limit参数指定了在决定连接多个数据表的最好方式时,CBO需要衡量的数据表连接组合的最大数目。
该参数的缺省值是5。
如果连接表的数目小于optimizer_search_limit参数,那么Oracle会执行所有可能的连接。可能连接的组合数目是数据表数目的阶乘。
我们刚才有7张表,那么有7!(5040)种组合。
optimizer_max_permutations参数定义了CBO所考虑的表连接的最大数目的上限。
当我们给这个参数设置很小的一个值的时候,Oracle的计算比较很快就可以被遏制。然后执行计划,给出结果。
optimizer_search_limit参数和optimizer_max_permutations参数和Ordered参数不相容,如果定义了ordered提示,那么
optimizer_max_permutations参数将会失效。
实际上,当你定义了ordered提示时,oracle已经无需计算了。
optimizer_search_limit参数和optimizer_max_permutations参数要结合使用,优化器将在optimizer_search_limit参数或
optimizer_max_permutations参数值超出之前,生成可能的表连接转换。当优化器停止对表连接的评估时,它将选择成本最低的组合。
例如,需要连接9个表的查询已经超出了optimizer_search_limit参数的限制,但是仍然可能要花费大量的时间去试图评估所有362880个
可能的连接顺序(9!),直到超过了optimizer_max_permutations参数的默认值(80000个表连接顺序)。
optimizer_max_permutations参数为CBO需要评估的排列数量的最大值。
optimizer_max_permutations的默认值是80000。
在确定查询排列评估数量的上限时,CBO采用的原则是:
如果查询中存在的非单一记录表的数目小于optimizer_search_limit+1,那么排列的最大值等于下面两个表达式中较大的数值:
optimizer_max_permutations
______________________________
(可能启动表的数目+1)
和
optimizer_search_limit!
___________________________
(可能启动表的数目+1)
例如5个表连接
排列的最大值= 80000/6=13333
____________________________
搜索限制=5!/6=120/6=20
较大值是13333,这就是优化器要考虑的排列的最大数值(当然实际的数值要比这个小的多,Oracle会排除掉大部分不可能组合)。
|
3. 其他
在有的系统视图查询中,很多时候会出现问题,比如以下的SQL:
|
这个语句用来查找锁,在Oracle7的年代,这样的SQL语句执行的很快,但是在Oracle8以后的数据库,如果碰巧你用的是CBO,那么
这样的语句执行结果可能是Hang了(其实不是死了,只是很多人没有耐心等而已),在Oracle7里,这样的语句毫无疑问使用RBO,
很快你就可以得到执行结果。可以对于CBO,你所看到的两个视图,对于数据库来说,实际上是6个表,单只6个表的可能顺序组合就有
6!(720)种,数据库时间都消耗在计算这些执行路径上了,所以你得到的就是hang的结果。
最简单的解决办法就是使用rule提示,或者使用ordered提示
我们可以看一下这两种方式的执行计划,如果你有兴趣的话,还可以研究一下X$视图:
|
对于Ordered提示:
|
类似的
|
以上问题对于CBO优化器普遍存在,对于Oracle9i2同样如此。
幸运的是在Oracle9i中,optimizer_max_permutations初始值降低到2000,从80000到2000,这是一个重大的进步