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%以上）
证据：
逻辑读远远高于物理读写，差了好几个数量级，并且物理读写的绝对值也很低。
几个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%以上）
