Execute to Parse

1、内存方面:db cache、shared pool、redo buffer的大小应该是足够的。
证据:
逻辑读远远高于物理读写,差了好几个数量级,并且物理读写的绝对值也很低。
几个buffer的noweait和命中率都接近100%

可以这么认为,内存参数没问题


疑问:
(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%以上)

转载于:https://www.cnblogs.com/afant/archive/2008/05/23/1205859.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值