bulket过大的问题

前阵子性能测试,跑一个过程时,特别特别慢

查询v$session_wait和v$latch,后查询v$sqlarea发现有个sql的version_count竟然是20000多,可怕.

通过对视图v$sysstat可以获取数据库的解析情况

select name,value from v$sysstat  where name like 'parse%';

列 (parse count(total)-parse count(hard))/parse count(total) 经常作为数据库性能的衡量指标.

那么这些version_count究竟是否正常呢?

通过v$sql_shared_cursor视图查询.

select hash_value,sql_fulltext from v$sqlarea where version_count>500

select count(*) from v$sql where hash_value = :hash_value

结果只有5000多,

然后 alter session set events 'immediate trace name buffers level 6'

结果下来400多M,

没法打开了,只好按照网上的方法把timed_statistics 该为 false.

另外还要注意一个参数是cursor_sharing,当cursor_sharing为similar并且数据库存在相应的相关柱状图histograms时,对于每一条新执行的SQL语句,Oracle都通过硬解析,以获取精确的执行计划,这最终也会导致version_count过高.可以将cursor_sharing设置为Force或者Exact以避免此问题

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22861158/viewspace-676696/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22861158/viewspace-676696/