execute to parse , statspack

execute to parse below 20%:

http://www.oracle.com.cn/viewthread.php?tid=1796

statspack explain:

http://wenku.baidu.com/view/80cd4c0f76c66137ee06193b.html

-- some piece from artile :

100 * (1 - Parses/Executions) = Execute to Parse
Low vaule for this ratio can also be caused by the snapshot boundary occurring during a period of high parsing so that the executions have not occurred before the end of the snapshot. Check the next snapshot to see if there are enough executes to account for the parses in this report.

你可以去找sprepins.sql找出Execute to Parse 的计算方法。
看了就知道了 --- biti_rainy

系统不是太慢，但是cpu利用率居高不下。稍微多点连接cpu就上去，并且慢。
主要是想找到解决cpu 瓶颈的方法。

最大的原因是你的应用不使用bind导致，shared pool的活就让cpu累的够呛了

这个值的高低跟 bind var没有必然联系
建议你做的是增加 session_cached_cursors 到 100 或者 200，pga足够的话 --- biti_rainy

即使是soft parse 也会被统计入 parse count,所以这个指标并不能反应
出 fast soft(pga 中)/soft (shared pool中)/hard (shared pool 中新解析)
几种解析的比例。只有在pl/sql的类似循环这种程序中使用使用变量才能避免大量parse
所以这个指标跟是否使用bind并没有必然联系
增加session_cached_cursors 是为了在大量parse的情况下把soft转化为fast soft而节约资源 --- biti_rainy

[@more@]

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

转载于:http://blog.itpub.net/350519/viewspace-1041565/