---execute to parse的说明及计算方法
Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。理想的百分比为100%及接近于只执行而不解析，最近巡检的数据库很多百分比都比较低，存在部分数据库硬解析较高，或者解析未执行比如语法语义错误，对象不存在但是应用反复调用（之前生产上真遇到过这种低级错误），看到相关文档说该比值在60-70就算正常的。
这个参数的值，主要是体现的解析次数与执行次数的比率，而且这里的解析包括硬解析和软解析及软软解析。
计算方法： execute to parse %= round(100* (1- parse / execute),2)
parse = select value from v$sysstat where name = 'parse count (total)'
execute = select value from v$sysstat where name = 'execute count';
可以看出这个比值是需要1-来运算的，也可以根据awr中的load prfile中的parse(sql) 和 execute(sql)来运算。
关于正负值的情况：如果系统的parse大于execute，就可能出现该比率是负数的情况，通常说明shared pool设置或者语句执行效率存在问题，造成反复解析或解析未执行，
reparse可能较严重，或者是可能同snapshot有关，通常情况下数据库性能存在一定问题。
---理解执行解析比
在oracle中解析往往是执行的先提工作，但是通过游标共享可以解析一次执行多次，执行解析可能分成多种场景：
1、先进行一次解析，然后执行语句，且以后再也不在同一个会话中执行它的系统中，这个比值为0。
2、使用绑定变量但是仍需要软解析，软解析一次，执行一次。这种情况时执行解析比(这里的parse，包含了软解析和硬解析)仍是1：1，执行解析比为0，但是软解析比例可能很高。
3、使用静态SQL、动态绑定、session_cached_cursor、open cursors等技术实现的快速解析，其解析一次，执行多次， 执行解析比为N:1，则执行解析比接近100%。
如果系统Parses > Executions，就可能出现该比率小于0的情况，该值<0通常说明shared pool设置或效率存在问题，造成反复解析。
---execute to parse的影响因素
1、session_cached_cursor（一个session可以缓存的cursor，让后续相同的sql语句不再打开游标，从而避免软解析的过程来提高性能，这种是非常理想高效的方式）
2、open_cursor（对于一个session同时可最多使用的游标数）
3、使用绑定变量避免硬解析
4、可能存在的sql语法语义错误或者对象不存在，而应用反复调用
---下面可以查询session_cached_cursor和open_cursor的使用情况Select 'session_cached_cursors' Parameter,
Lpad(Value, 5) Value,
Decode(Value, 0, ' n/a', To_Char(100 * Used / Value, '990') || '%') Usage
From (Select Max(s.Value) Used
From V$statname n, V$sesstat s
Where n.Name = 'session cursor cache count'
And s.Statistic# = n.Statistic#),
(Select Value From V$parameter Where Name = 'session_cached_cursors')
union all
Select 'open_cursors',
Lpad(Value, 5),
To_Char(100 * Used / Value, '990') || '%'
From (Select Max(Sum(s.Value)) Used
From V$statname n, V$sesstat s
Where n.Name In
('opened cursors current', 'session cursor cache count')
And s.Statistic# = n.Statistic#
Group By s.Sid),(Select Value From V$parameter Where Name = 'open_cursors');
--session_cached_cursors利用率已经达到了100%，说明会话打开的游标数已充分利用，但是value是否合理需要看另外一个比值cursor cache hits/parse count(total)，
--二者比值越高，性能越好。如果比例比较低，并且有较多剩余内存的话，可以考虑加大该参数
--cursor cache hits 就是系统在高速缓存区中找到相应 cursors 的次数
--parse count(total) 就是总的解析次数
select round((select to_char(value) from v$sysstat where name = 'session cursor cache hits')/
(select to_char(value) from v$sysstat where name = 'parse count (total)'),2) from dual;
---总结
awr报告中execute to parse %的大小不能直观做出判断数据库中解析存在性能问题，需要结合soft parse %，再结合hit与parse的比值来分析。
