SQL version 版本过高。

xuebao_zx

应该如何来看待version_count值，如何理解？

是否在v$sql_shared_coursor视图中找不到相同版本的SQL,就需要解析一次,而version_count值就会加1呢。

那么v$sql_shared_coursor中的部分SQL过旧，被挤了出去，那么现次执行相同的SQL，此时相同版本在v$sql_shared_coursor找不到，就需要再次解析，version_count值就加1吗？
不知道我理解是否正常，请高人指点。。。。。

qingcheng_yuan

I disagree with you.
could you please let me know how to identify that version_cout is equal to 2500?

inthirties2

关注一下

Yong Huang

xuebao_zx,

I'm confused about your words "证实一点，之前OPTIMIZER_MISMATCH 为Y的猜测是错的" in message #10. Earlier, you did not *猜测*, you actually showed it clearly you *had* OPTIMIZER_MISMATCH 为Y. See your message #7.

> 那么v$sql_shared_coursor中的部分SQL过旧，被挤了出去，那么现次执行相同的SQL，此时相同版本在
> v$sql_shared_coursor找不到，就需要再次解析，version_count值就加1吗？

Instead of saying "v$sql_shared_coursor中的部分SQL...被挤了出去", say SQLs in shared pool are aged out.

There're two cases. Normally when a SQL is aged out, the entire cursor, i.e. including its heap 0 and 6 are aged out. In that case, it makes no sense to talk about count of its remaining versions. But if only heap 6 is aged out, version_count stays unchanged. When the next parse occurs, version_count should not increase because Oracle simply adds a new heap 6 to an existing heap 0.

Also, don't ignore other people's messages, such as yanyp's message #9.

Yong Huang

棉花糖ONE

optimizer_mismatch不一定只是因为optimizer_mode不对,查查
v$sql_optimizer_env

xuebao_zx

Yong Huang
版主

通过测试已证实你所说的，
version_count与v$sql_shared_coursor过旧没有关系，当子游标过旧被挤出去时，下次执行会重新解析并放入v$sql_shared_coursor,而version_count不会发生变化.

xuebao_zx

原帖由 棉花糖ONE 于 2010-1-26 08:49 发表
optimizer_mismatch不一定只是因为optimizer_mode不对,查查
v$sql_optimizer_env

实验发现对session的优化模式做出语之后，sql_shared_coursor中会提示optimizer_mode_mismatch=Y,
而不是optimizer_mismatch=Y.

select version_count from v$sqlarea where sql_id='XXX';

可以看到version_count 值的增加。

xuebao_zx

感谢各位的参与，这个问题已解决，原来是绑定变量传入实参与定义的形参，
数据类型不同，执行过程中进行了隐含转换。

但想不通，为何会造成这么多的高版本，并且最终达到6000多个版本。
v$sql_shared_coursor给我的提示不光是，BIND_mismatch=Y，同时还有LANGUAGE_MISMATCH=Y,optimizer_mismatch=Y等等多个不匹配项，真奇怪！！！

Yong Huang

If you want to understand this more, you have to open an SR. V$sql_shared_cursor is actually quite incomplete. Many mismatches are incorrectly lumped into bind_mismatch.

Yong Huang

小颜Kevin

xuebao_zx 发表于 2010-1-24 11:04
通过测试明确一点，那就是绑定变量的传入值的改变，导致需要获取的数据量增加，从而使用ORACLE改变执行计划 ...

你说的这个是11g的自适应游标才这样吧。