前阵子性能测试,跑一个过程时,特别特别慢
查询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博客 ” ，链接：https://blog.itpub.net/22861158/viewspace-676696/ ，如需转载，请注明出处，否则将追究法律责任。
