同学让我帮他分析下他们数据库的AWR报告，说命中率非常低，我看了下命中率已经很不错了，下面是AWR报告的基本信息。

从DB Time看，这个数据库并不忙，数据库压力不大，下面是负载信息。

从上面的负载信息可以看到，每秒redo的生成量非常小，逻辑不也不高，每秒解析217.46次，每秒SQL运行218.84次，平均每秒有10.63个事务，但是从Instance Activity Stats部分看，平均每秒回滚的次数偏高。

从上表可以看出，每秒10.63个事务，其中8.62个事务被回滚，这很可能存在问题，在正常的系统中，很少有80%的事务被回滚的，这很可能是中间件的策略问题，有些中间件(比如weblogic)在一个SESSION连接上数据库时，默认会发出一条SELECT 1 FROM DUAL的SQL，然后ROLLBACK，中间件默认以这种方式来验证与数据库的连接和保证异常中断的会话被回滚，这有可能就会给数据库带来严重的性能问题，在繁忙的系统中建议禁掉这个操作。

下面在看看本文的主题，命中率部分。

从上表可以看到，实例具有较好的性能， buffer、cache等都保持了比较好的命中率，都在99.6%以上。我同学说的命中率非常低指的是Execute to Parse %:，严格来说这不算命中率，Execute to Parse %是指SQL语句执行与解析的比例，如果要SQL重用率高，则这个比例会很高，该值越高表示一次解析后被重复执行的次数越多，Execute to parse＝100 * (1 – Parses/Executions)，结合上文负载信息的数据，可以验证下这个公式。

Execute to parse＝100 * (1 - Parses/Executions)

Execute to parse＝100 * (1 -217.46/218.84）=0.63%

正好是0.63%，说明当前 数据库SQL重用率非常低，这说明当前数据库运行的不一样的SQL非常多，也可能是应用程序没有使用环境变量，从本文的数据分析，猜测这应该是OLTP系统，那么就应该是应用程序没有使用环境变量所致。

本文固定链接: http://www.dbdream.com.cn/2013/03/awr%e6%8a%a5%e5%91%8a%e5%88%86%e6%9e%90execute-to-parse/ | 信春哥，系统稳，闭眼上线不回滚！