Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

关于该特性,其实并不是11gR2开始引入的,其实在11gR1就引入了,只不过其问题较多,
并未引起太多关注而已(bug不少)。该特性主要解决了哪些问题?
● data skew (数据倾斜)
● bind peeking (绑定变量窥视)– oracle 9i 引入

关于该特性也是通过几个隐含参数来控制的,11gR2 默认为true,如下:

在11.2的官方文档中,居然没有v$sql_cs_selectivity的说明,oracle也太扯淡了。
为什么说11gR2之前,这个新功能问题相对比较多多,metalink 搜索v$sql_cs_selectivity,居然有3个跟这个新特性相关的bug。

意外的收获是发现了一个查询V$SQL_CS_SELECTIVITY的 bug,如下:

不过这个bug不影响数据库正常使用。
补充:

跟11g自适应游标共享功能相关的有几个新的视图,平时我们可以借此来进行监控,如下:
V$SQL_CS_SELECTIVITY
V$SQL_CS_STATISTICS
V$SQL_CS_HISTOGRAM

关于这3个视图,oracle metalink的解释如下:

下面来查询一下看看;

从上面我们就可以很得出如下的结论:

V$SQL_CS_SELECTIVITY 用于查询cursor的最高值和最低值的选择性,oracle也正是根据其选择性来决定起执行计划的,不过内部机制现
在我还无法得知,比如 object_id 有1000个值,不可能每次不同的绑定变量值,oracle都去生成一个执行计划或产生一个child cursor,
那样的话,代价就非常高了。– 这个需要进一步研究。

V$SQL_CS_STATISTICS 从上面的查询,我们就可以看出,该视图用于查询每个child cursor的统计信息,比如buffer gets。
其实,从这个我们也可以用来判断sql的效率,这个不就是我们常说的逻辑读吗?

V$SQL_CS_HISTOGRAM 类似直方图一样,用于记录cursor的执行次数,从上面的查询,我们可以发现每个child cursor一共有3个bucket。
关于这里的bucket,目前还不知道是不是就是固定的3个bucket。– 这里也需要进一步研究证明。

另外如果修改了参数curso_sharing为similar或force的话,也可能会导致比较严重的后果,可能会出现大量的 mutex X waits for cursor等待。
故我们仍然建议设置为EXACT,从应用角度进行绑定变量。

既然我们说ACS功能很强悍,假如不想用这个功能呢,是否能关闭呢? 回答是肯定的,通过如下的方式:

另外我在阅读metalink 文档Adaptive Cursor Sharing Overview [ID 740052.1] 的时候,还发现了如下的信息:

换句话说,就是ACS功能,在上面几种情况下是起作用的。

    分享到:
18180207355
加Q咨询