我们上面从程序员的角度上讲述了如何共享执行计划。下面再来看看作为DBA可以为共享执行计划做什么事。首先我们要知道，每条语句的执行计划是保存在库缓存中的，优化器在解析语句时，先要到库缓存中，以语句的文本为条件，查找有没有此语句的执行计划，如果已经有了，就直接取出来交给服务器进程执行，这就是软解析。如果库缓存中不存在相同的语句，优化器就为此语句生成执行计划，再把生成的计划存入库缓存，这就硬解析。那么库缓存的大小是有一定限制的，如果你有非常多的语句，不可能每条语句的执行计划都能被存放到库缓存中。假设用户又发出了一条新的语句A，优化器经过查找，没有在库缓存中发现同样的语句，优化器开始硬解析，生成了执行计划A。优化器将计划A存入库缓存时，发现库缓存已经没有空闲空间了，优化器就会把原来的某条语句的执行计划从库缓存中清除掉，腾出可用的空间以容纳计划A。被清除的计划我们称为牺牲者，清除操作我们称为语句的“老化”。老化的语句再次执行时，又要重新硬解析。如果你的库缓存大小设置的比较小，就会频繁的有语句被老化。这无形中增加了硬解析的次数。因此，库缓存不能设置的太小。如果库缓存太多了呢，这也不行，因为白白的占用了宝贵的内存资源。那么，库缓存到底多大的大小才算合适呢？这没有统一的标准，你仍然只能借助历史数据观察。观察的标准就是软、硬解析的数量。
资料视图中的软、硬解析资料我们已经说过了。下面，来看看STATSPACK报告中的软、硬解析数据。在报告中，有个Load profile部分，我们称之为概要信息，在概要信息中就包含有软、硬解析的信息：
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 16,233.08 422,060.00（每秒或每事务产生的日志数量，单位字节）redo size
Logical reads: 1,413.08 36,740.00（每秒或每事务的逻辑读块数，单位 数据库块）session logical reads
Block changes: 43.19 1,123.00（每秒或每事务块改变的数量）db block changes
Physical reads: 1,198.92 31,172.00（每秒或每事务的物理读数量，单位：块）physical reads
Physical writes: 0.00 0.00（每秒或每事务的物理写数量，单位：块）physical writes
User calls: 0.96 25.00（每秒或每事务用户调用次数）user calls
Parses: 0.65 17.00（每秒或每事务的解析数量，包括软软、软和硬解析）parse count (hard)
Hard parses: 0.04 1.00（每秒或每事务和硬解析解析数量）parse count (hard)
Sorts: 2.38 62.00（每秒或每事务产生的排序次数）sorts (memory)、sorts (disk)
Logons: 0.00 0.00（每秒或每事务登录的次数）logons cumulative
Executes: 1.88 49.00（每秒或每事务执行的次数）execute count
Transactions: 0.04（每秒产生的事务数）
这里Hard parses就是硬解析的次数。在一般的中型规模的OLTP应用中，此值应该控制在100以内。如果超过了100，说明硬解析太多，执行计划没有共享。没有共享计划的原因可能是没有使用绑定变量，或者是库缓存太小，语句老化的太快。这个值只是给你一个参考，准确的你还应该根据历史资料来分析。
Parses减去Hard parses就是软解析的次数了，这个值也不应该太多，中型规模的OLTP一般每秒也就是几百次，大型OLTP应用每秒软解析可能很有上千次。（这个值太大的话，应该使用无解析）
除概要信息外，还有一部分“实例有效性”中，也包含解析数据：
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 15.16 In-memory Sort %: 100.00
Library Hit %: 99.01 Soft Parse %: 94.12
Execute to Parse %: 65.31 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 100.00 % Non-Parse CPU: 99.41
这其中和库缓存、软硬解析相关的有：
Library Hit %：Library cache中的命中比率，软解析就是库缓存命中。这个比例通常应该保持在90%以上，否则就是库缓存太小或没有使用绑定变量。
Soft Parse %：计算公式100×(1－parse count (hard) / parse count (total))，软解析在所有解析中的比例。这个值小于<95%说明硬解析有点多，需要注意。如果低于80%，执行计划的共享就出了严重问题，解决方法当然还是加大库缓存或使用绑定变量。
Execute to Parse %：语句执行和分析了次数的度量。这个资料对我们这节课的内容没什么帮助。写在这里是想让大家了解他一下就行了。解析次数/执行次数
最后还有两个解析时间的比例，这个对我们帮助也不是太大：
Parse CPU to Parse Elapsd %：100×parse time cpu / parse time elapsed，即解析时间/解析时墙上壁钟时间。
% Non-Parse CPU：计算公式：100×(1-(parse time cpu / CPU used by this session)) 。表示了非解析时间在会话所占用CPU总时间的比例。如此值太低，表示解析消耗时间过多。
最后，还应该注意报告中的共享资料部分：
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 52.76 54.75
% SQL with executions>1: 65.90 77.17
% Memory for SQL w/exec>1: 86.34 92.30
1) Memory Usage %：这一项资料虽和解析无关，不过它也是共享池资料的一部分，我们也在这里介绍一下。它是正在使用的共享池的百分率。这个数字应该稳定在75%至90%左右。就是我们不能让共享池占用太多内存而又闲置着，这将带来更多的管理负担。大共享池的管理负担也更大，如果你