4 2011-06-24 16:59:10 VARCHAR2(32) yyyy-mm-dd
1 2011-06-24 16:59:09 VARCHAR2(32) 22501165422
2 2011-06-24 16:59:09 NUMBER 103
3 2011-06-24 16:59:09 VARCHAR2(32) yyyy-mm-dd
4 2011-06-24 16:59:09 VARCHAR2(32) yyyy-mm-dd
1 2011-06-24 16:59:07 VARCHAR2(32) 12801165830
2 2011-06-24 16:59:07 NUMBER 103
3 2011-06-24 16:59:07 VARCHAR2(32) yyyy-mm-dd
4 2011-06-24 16:59:07 VARCHAR2(32) yyyy-mm-dd
1 2011-06-24 16:59:00 VARCHAR2(32) 235896734
2 2011-06-24 16:59:00 NUMBER 103
3 2011-06-24 16:59:00 VARCHAR2(32) yyyy-mm-dd
4 2011-06-24 16:59:00 VARCHAR2(32) yyyy-mm-dd
1 2011-06-24 16:58:56 varchar2(32) 978a62e0bbb767d99bda
2 2011-06-24 16:58:56 NUMBER 103
3 2011-06-24 16:58:56 VARCHAR2(32) yyyy-mm-dd
4 2011-06-24 16:58:56 VARCHAR2(32) yyyy-mm-dd
1 2011-06-24 16:58:34 VARCHAR2(32) 708888718@qq.com
2 2011-06-24 16:58:34 NUMBER 209
3 2011-06-24 16:58:34 VARCHAR2(32) yyyy-mm-dd
4 2011-06-24 16:58:34 VARCHAR2(32) yyyy-mm-dd
1 2011-06-24 16:57:51 varchar2(32) syyxQS20110624000364
2 2011-06-24 16:57:51 NUMBER 103
3 2011-06-24 16:57:51 VARCHAR2(32) yyyy-mm-dd
4 2011-06-24 16:57:51 VARCHAR2(32) yyyy-mm-dd
通过以上的查询结果，我们可以肯定是sql_id='9rwd4wkwm4bsy' SQL的第一绑定变量值的长度不同造成bind_mismatch, 从而产生大量的version_counts.
相关的bug信息如下：
Bug:9689310:
- Non sharability of cursors due to BIND_MISMATCH.
Bug:6981690:
- Non sharability of cursors due to PQ_SLAVE_MISMATCH
Bug:8981059:
- Non sharability of cursors due to USER_BIND_PEEK_MISMATCH.
对于Bug 9689310，在MOS上搜了一下，该bug存在的版本如下：
Affects:
Fixed:
MOS 上给了一个变通的解决方法：Workaround
Alter the client application code so that it uses constant sizes for the MAX bind lengths.
我的库是10.2.0.5的，这个没说修复，也没说存在bug，还真不好确定，看来还是需要测试一下。
过我这个库上的cursor_sharing 参数是设置为similar的，这样会将SQL 中的谓词值自动用变量来代替。 这样会增加cursor的数量。 为了减少cursor对library cache的占用，还是先将cursor_shring 参数改成了默认的exact模式。 这样version_count 会减少很多，但是硬解析的次数也会增加，可能会增加Library Cache Latch等待。 现在只能这样修改一下，在找个环境测试一下。