复合索引查询时WHERE条件的书写? 对A表建立了复合索引(cdsc_id,cpl_DT)如果在查询时,cpl_Dt比cdsc_id靠近WHERE,会不会影响使用效果.对查询时出现在WHERE中的位置是不是有讲究?查询时,是不是可以隔开一个条件? 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 据说在RBO优化器模式下无影响(10G开始,缺省为RBO优化器模式),而在CBO优化器模式下有影响, 再问下,如何通过命令知道是RBO模式还是CBO模式? ORACLE自动根据结果进行判断,也可以强行用HINT提示进行RBO,CBO的执行 根据结果来选择用RBO或CBO,文档上不是说,这个要配置过么? 在Itpub上有朋友问到这样一个问题:拿expert 的例子在10g上测验绑定变量的问题.发现如果不使用绑定慢许多(这个没问题),我们的机器肯定要好于当时作者的机器,(但是)结果(却比作者慢很多)如下:不使用绑定变量要36.33秒..使用绑定变量0.50秒..而作者的测试分别为:不使用绑定变量14.86 seconds...使用绑定变量1.27 seconds...到底是什么原因差距这么大?首先我们需要知道,使用绑定变量,降低硬解析,通常可以提高系统的性能。对于这个问题,我们需要知道,从Oracle9i到Oracle10g,Oracle有一个非常显著的变化,那就是放弃RBO,全面引入了CBO。正是这一变化导致了以上差异的存在。在Oracle9i中,通常我们不会收集系统的统计信息,这使得对于all_objects的查询会使用RBO,而在Oracle10g中,缺省的会使用CBO优化器。对于反复的硬解析,统计信息、柱状图信息的判断以及执行计划的选择使得性能急剧下降。 是的,说反了,CBO没有影响,RBO有影响。不知LZ的数据库版本是那个,稍微高点,没有区别,查看执行计划即可知道。 ORACLE 7i开始有CBO的概念,不成熟;ORACLE 8i逐步CBO开始成熟起来;ORACLE 9i开始默认启用CHOOSE模式,没有统计信息的情况下,一般使用RBO,在有统计信息的时候一般使用CBO;ORACLE 10g或确认为CBO。RBO为基于规则的优化器,按照执行路径尝试手段,提取最优路径,可以认识较为复杂的索引,一般执行效率较高,但是多个表的情况下,由于路径太多,可能会导致计算路径的开销很大。CBO基于成本优化器,根据统计信息计算最优路径,而不是去尝试,这个过程依赖于在一定数据量发生变化后需要人工去维护这系统统计信息(当然可以编写成脚本,形成自动化维护)。至于ITPUB上你说的信息,一般是在大批量DML操作会形成那样悬殊的对比,使用绑定参数的平均性能会高于直接拼SQL的平均性能的10倍以上,在我的博客中也有所介绍,是关于共享池的问题,其实你也说到了,原因之一就是减少硬解析,还有另外就是:造成共享池长期征用,共享池内部包含大量垃圾SQL,可能会导致SQL注入,尤其在高并发应用中体现得非常明显。 创建函数索引后列的对应关系 oracle怎样改变表结构 获取同一个transaction中的所有SQL 游标修改 各位前辈,高手,下面的存储过程怎么改啊??超简单,但不知道怎么改,改好送分 请教高手们:急 请问如何解决oracle发邮件时的中文乱码问题? 大家都来帮帮忙!看看这个数据库的表该如何建立!!!!谢谢 哪里有DEVELOPER/2000的电子版本的教材下载! oracle怎么查询从两张表抽取出来的字段合成一张表的结果 oracle 10g isqlplus 链接不上 数据库已装好 请教exists的用法
也可以强行用HINT提示进行RBO,CBO的执行
发现如果不使用绑定慢许多(这个没问题),我们的机器肯定要好于当时作者的机器,(但是)结果(却比作者慢很多)如下:不使用绑定变量要36.33秒..
使用绑定变量0.50秒..而作者的测试分别为:
不使用绑定变量14.86 seconds...
使用绑定变量1.27 seconds...到底是什么原因差距这么大?首先我们需要知道,使用绑定变量,降低硬解析,通常可以提高系统的性能。对于这个问题,我们需要知道,从Oracle9i到Oracle10g,Oracle有一个非常显著的变化,那就是放弃RBO,全面引入了CBO。
正是这一变化导致了以上差异的存在。在Oracle9i中,通常我们不会收集系统的统计信息,这使得对于all_objects的查询会使用RBO,而在Oracle10g中,缺省的会使用CBO优化器。
对于反复的硬解析,统计信息、柱状图信息的判断以及执行计划的选择使得性能急剧下降。
ORACLE 7i开始有CBO的概念,不成熟;ORACLE 8i逐步CBO开始成熟起来;ORACLE 9i开始默认启用CHOOSE模式,没有统计信息的情况下,一般使用RBO,在有统计信息的时候一般使用CBO;ORACLE 10g或确认为CBO。RBO为基于规则的优化器,按照执行路径尝试手段,提取最优路径,可以认识较为复杂的索引,一般执行效率较高,但是多个表的情况下,由于路径太多,可能会导致计算路径的开销很大。CBO基于成本优化器,根据统计信息计算最优路径,而不是去尝试,这个过程依赖于在一定数据量发生变化后需要人工去维护这系统统计信息(当然可以编写成脚本,形成自动化维护)。至于ITPUB上你说的信息,一般是在大批量DML操作会形成那样悬殊的对比,使用绑定参数的平均性能会高于直接拼SQL的平均性能的10倍以上,在我的博客中也有所介绍,是关于共享池的问题,其实你也说到了,原因之一就是减少硬解析,还有另外就是:造成共享池长期征用,共享池内部包含大量垃圾SQL,可能会导致SQL注入,尤其在高并发应用中体现得非常明显。