（1）execute to parse 太低，只有7％。eygle说过这个值为负或太低都说明shared pool设置不当或数据库性能不佳。并且给出了计算公式：
100％ * (1 - Parses/Executions) = Execute to Parse
但是library hit 是 99.2％，sotf parse是99.2％啊，怎么会有设置上的不当呢？
execute to parse 与DB设置无关，纯粹是application所控制的。发生在application call DB的阶段，降低这个值只能靠application.
（2）parse cpu to parse elapsd 这个参数。它的计算公式是：
100％*（parse time cpu / parse time elapsed） = Parse CPU to Parse Elapsd %
我的理解是cpu parse time 占总 parse time 的比例。
但是我想问的是：这个值是越高越好还是越低越好？
基本时越高越好，高说明parse 时没什么等待或者说征用。
但是，这个值低也未必一定就有问题，要看parse time elapsed的绝对总量或者parse time elapsed与整个DB的elspesd time的对比。
（3）Non-Parse CPU 这个参数。我没找到它的计算公式和解释。从字面上猜测，意思好像跟parse cpu to parse elapsd 相反，但是为什么这两个参数同时接近100％？这是好事还是坏事？
100- 100％*（parse time cpu / DB Total CPU）
当然越高越好，这个值低表明parse 成了DB的瓶颈了。通常有绑定变量问题。
通常这个值应该在95%以上（个人经验，根据不同应用会有所不同，有些地方甚至要求99%以上）
100％ * (1 - Parses/Executions) = Execute to Parse
但是library hit 是 99.2％，sotf parse是99.2％啊，怎么会有设置上的不当呢？
execute to parse 与DB设置无关，纯粹是application所控制的。发生在application call DB的阶段，降低这个值只能靠application.
（2）parse cpu to parse elapsd 这个参数。它的计算公式是：
100％*（parse time cpu / parse time elapsed） = Parse CPU to Parse Elapsd %
我的理解是cpu parse time 占总 parse time 的比例。
但是我想问的是：这个值是越高越好还是越低越好？
基本时越高越好，高说明parse 时没什么等待或者说征用。
但是，这个值低也未必一定就有问题，要看parse time elapsed的绝对总量或者parse time elapsed与整个DB的elspesd time的对比。
（3）Non-Parse CPU 这个参数。我没找到它的计算公式和解释。从字面上猜测，意思好像跟parse cpu to parse elapsd 相反，但是为什么这两个参数同时接近100％？这是好事还是坏事？
100- 100％*（parse time cpu / DB Total CPU）
当然越高越好，这个值低表明parse 成了DB的瓶颈了。通常有绑定变量问题。
通常这个值应该在95%以上（个人经验，根据不同应用会有所不同，有些地方甚至要求99%以上）
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/7301064/viewspace-429747/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
查看表大小
下一篇：
rollback segment
请登录后发表评论
登录
全部评论
