共享池之九：绑定变量与session_cached_cursors(二)

可以通过v$sql_bind_capture视图查看一下每次绑定变量的值：
select position,LAST_CAPTURED,datatype_string,value_string fromv$sql_bind_capture where sql_id='9rwd4wkwm4bsy' and rownum<50;

正常情况不会产生这么大量的子CURSOR。但是由于一些BUG，会导致问题。

如果没有补丁，一个临时性的解决方案，设置一个较大的BUFFER
SQL>ALTER SESSION SET EVENTS '10503 trace name context level, forever';

而这些具体的内容，可以通过视图来查看。查看上述的共享父游标对于的bind_metadata
selects.child_number,m.position,m.max_length,
decode(m.datatype,1,'VARCHAR2',2,'NUMBER',m.datatype)as datatype
from v$sql s,v$sql_bind_metadata m
where s.sql_id='94ka9mv232yxb'
and s.child_address=m.address;
CHILD_NUMBER POSITION MAX_LENGTH DATATYPE
------------ ---------- ----------------------------------------------
0 3 32 VARCHAR2
0 2 32 VARCHAR2
0 1 22 NUMBER
1 3 32 VARCHAR2
1 2 128 VARCHAR2
1 1 22 NUMBER

从绑定变量四个级别来看，最多生成4个子游标。但是为什么AWR报表中SQL ordered by Version Count的version count能高达好几十，甚至几百呢？而且不能共享的原因都是因为bind_mismatch.

关于:cursor_sharing

根据oracle官方建议在11g中不推荐使用cursor_sharing=SIMILAR,其实在所有版本中都不推荐,设置为该值很容易导致高版本问 题.而且该值会出现莫名其妙的,无法解释的高版本问题.而且根据oracle相关文档,在即将发布的12c版本中,将除掉SIMILAR值.对于客户库的 该问题,因为很多sql未绑定参数,为了减少硬解析,建议在业务低谷时设置cursor_sharing=FORCE,并刷新sharedpool.

如果cursor_sharing 参数是设置为similar的，这样会将SQL 中的谓词值自动用变量来代替。这样会增加cursor的数量。

为了减少cursor对library cache的占用，先将cursor_shring 参数改成了默认的exact模式。

这样version_count 会减少很多，但是硬解析的次数也会增加，可能会增加Library Cache Latch等待。