3．库缓存的大小
我们上面从程序员的角度上讲述了如何共享执行计划。下面再来看看作为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%左右。就是我们不能让共享池占用太多内存而又闲置着，这将带来更多的管理负担。大共享池的管理负担也更大，如果你用不着这么大，还是调小点好。反过来，我们也不能让共享池内存占用的太多而没有一点的空余，这会使共享池内部的数据出现你不希望的老化。根据经验，在通常的OLTP应用中，此数值应该在75%到略低于90%的范围内。
2) % SQL with executions>1：此资料的计算公式是：100×(1－只执行一次的SQL数量 / 所有SQL数量)，它是共享池中执行次数大于一次的SQL语句在所有SQL语句的百分比。这个数字当然越大越好。越大说明你的执行计划共享的越有效。
3) % Memory for SQL w/exec>1：此资料的计算公式是：100×(1－只执行一次的SQL所占内存 / 所有SQL所占内存)。此资料很好理解了，执行次数大于一次的语句所占内存与总语句所占内存的一个比例。
好了，STATSPACK中解析有关解析的资料就说的这里，软、硬解析的比例，在一定程度上代表了你的库缓存是否够大。还有一点，如果库缓存不够大，DBA是不能直接调大库缓存的，库缓存是共享池的重要部分之一。我们可以通过调节共享池的大小，来改变库缓存或共享池中其他部分的大小。
4．库缓存命中率与V$librarycache视图
在上面的Statspack报告中，已经提到了库缓存命中率这个概念，下面我们用视图说一下库缓存的命中率，视图中的信息比Statspack报告中的更详细一些。我们可以通过V$librarycache视图来查看库缓存的一些情况。在介绍此视图前，我们要先来介绍几个有关库缓存的概念。
（1）、库缓存句柄和库缓存内存块。
每一个进入库缓存的对象，在库缓存中都被按照本身内容分割成多块进行存贮，这就好像一只整鸡被分割成鸡腿、鸡翅、鸡爪等等。Oracle这样做的目的是为了更灵活的内存管理，因为在内存寻找大块连续的内存，总比寻找小块连续内存更慢一些，这个我们在此处就不深入讨论了。继续刚才的话题，如果一个库缓存对象（如一条SQL语句的执行计划），它所占的内存被切割成4个小块，它们分别被存放在库缓存的各处，并且互不相连。为了将这4个小块组合起来，Oracle另外这个库缓存对象分配一小块内存，这块内存中存有其他4个小块内存的地址，并且，还有一些有关此库缓存对象的基本信息，如名字、类型等等，这块内存就叫库缓存对象句柄。
在访问库缓存对象时，比如软解析时，要从库缓存中读取执行计划。Oracle首先找到句柄，读取句柄中的信息，这就叫做一次库缓存Get。如果库缓存中不包括对象的句柄信息，Oracle就要重新在库缓存中分配内存、构造句柄，这就是库缓存句柄未命中（Get Miss）。相反，如果在库缓存中找到了对象句柄，就是库缓存句柄命中（Get Hit）。硬解析时，就会发生Get Miss。而软解析则是Get Hit。
在取出句柄中的其他内存块地址后，每访问一个内存块，都叫做一次库缓存Pin。如果相应的内存块已经不在内存中了，这就是Pin Miss，Pin的未命中。相反就是Pin Hit。
当库缓存中对象发生改变后，会引起其他一些对象的无效（Invalidation）。比如，你修改了一个表的结构，那么，选择了这个表的SQL语句的执行计划就会变的无效。其实大部分对表的DDL操作，都会造成相关SQL语句执行计划的无效。就连Grant（授权）、Revoke（撤消权限）这样看来跟执行计划耗无关系的操作，都会引起无效。如果有一个表TAB1，你发布了 “Grant 某权限 on tab1 to 某用户”，或“revoke 某权限 on tabl from 某用户”这样的操作，那么，所有和TAB1表有关的执行计划都将无效。无效之后，库缓存对象除句柄外的所有内存块，都将被清除。再使用到对象后，必须重新加载对象。如上例，如果你对TAB1使用了DDL语句，那么所有使用了TAB1表语句的执行计划都将无效，你再使用这些语句时，就必须重新硬解析语句。
因此，使用DDL语句是需要注意的，如果没有要求立即使用DDL，我们最好等到数据库并不繁忙的时刻，再执行DDL。作为DBA，这一点一定要牢记，除非要求立即执行，否则等到数据库并不繁忙时再执行任何DDL。
再补充一点，无效和库缓存对象的老化并不一样。老化是连句柄带对象的所有内存块都被清除出去了。而无效是只在库缓存中保留对象句柄，但所有其他内存块都被清除出去。对于无效的对象，当再次重新调用到它时，Oracle会再次将它调入到库缓存中，这个操作被称为Reload。一般说来，Reload与Get是无关的，因为Reload是在对象无效后才发生的，而对象的无效并不影响对象句柄。好，说了这么多，下面我们来看这些值的意义。
我们已经讲述了Get、Pin与它们的命中、未命中，还有什么是Invalidation和Reload。在OLTP系统中，Get的命中率应该在90%之上。而Reload和Pin的次数的比值，应该小于1%。如果超出了这些数值范围，就说明库缓存的使用有问题。问题的原因主要有两个，没有使用绑定变量或是库缓存太小。不过Reload和Pin的比例过高，也可能是在繁忙时执行了DDL所导致的。
另外，V$librarycache的第一列是NAMESPACE，也就是名称空间。它相当于存储在库缓存中对象的类型。具体的名称空间是什么意思呢？就是对象的名字所在的范围，比如表和列的名字就不在一个范围内。也就是说表名和列名可以重复，还有用户名和表、列也不在同一范围内，用户名也可以和表、列名相同。我可以有个叫做AA的表，也可以有叫做AA的用户。这两个AA处在不同的范围内，也就明它们的名称空间不同。这就好像在北京有个电话号码是12345678，在上海也有个12345678，这两个电话号码虽然相同，但不会引起问题，因为它们在不同的范围内。这个范围，也可以说是类型。
我显示一下V$librarycache的所有行（列只有一部分）：
SQL> select * from v$librarycache;
NAMESPACE GETS GETHITS GETHITRATIO PINS PINHITS
--------------- ---------- ---------- ----------- ---------- ----------
SQL AREA 21811 4149 .190225116 120258 105272
TABLE/PROCEDURE 25152 16372 .650922392 60649 46008
BODY 4360 4098 .939908257 5931 5537
TRIGGER 320 251 .784375 1655 1576
INDEX 453 128 .282560706 2065 1531
CLUSTER 755 728 .964238411 2339 2296
OBJECT 0 0 1 0 0
PIPE 0 0 1 0 0
JAVA SOURCE 0 0 1 0 0
JAVA RESOURCE 0 0 1 0 0
JAVA DATA 0 0 1 0 0
可以看在库缓存中共有11个名称空间，我们基本上可以说库缓存中有11种类型的信息。有一个非常重要的指标，就是库缓存命中率，这个命中率就是库缓存中所有对象的GETHITRAIO，它的计算方法如下：
select 1-sum(gethits)/sum(gets) from v$librarycache;
这个比率应该在90%以上。 还有一个比率也很重要，就是Reload和Pin的比值，这个比值应该小于1%。
如果没有达到这些比例，解决方法很简单，问题或者是SQL语句没有共享，或者是共享池太小。
有关库缓存命中率，也可以查看STATSPACK报告中的Library Hit %项。这个我们上面已经说过了。
三、Library cache lock、Library cache pin等待事件
我们再补充一点，SG中没提，我们在调优的课程中，有很多内容将不再按SG顺序讲。当然我们也会补充很多实践性比较强的内容。所以我们一定要多记才行。
等待事件在Oracle中无处不在，为了记录这些数据，是损失了一些性能。但是你是想出了问题一愁么展好，还是可以利用等待事件或各种资料轻松的查找出问题在哪好呢？而且，这些等待事件和资料你即使不去用它，Oracle一样会消耗CPU去记载它们。因此，一个好的DBA一定要对各种等待事件、资料了如指掌。下面，我们介绍两个和库缓存相关的等待事件，如题，就是Library cache lock和Library cache pin。
我们上面说到库缓存中的对象在库缓存中被切割成多个内存块，另有一个对象句柄记录了各个内存块的地址和其他的一些信息。当你要修改句柄中的信息时，需要在句柄上加独占锁，而如果另一个进程恰好在这时要求读、写句柄中的信息，它就必须等待。此时的等待就被Oracle记入Library cache lock事件。而读、写对象内存块也是无法同时进行的，有人如果正在写，你的读操作就必须等待，读写内存块的等待事件就是Library cache pin。如果这两个等待事件过多，同样说明了库缓存过小或没有共享执行计划。或者，当你在数据库繁忙时使用DDL时，也会有这两个等待事件。
四、库缓存视图
有一个视图可以看到缓存在库缓存中对象的信息，它是V$db_object_cache。
OWNER ：对象所有者
NAME ：对象名
DB_LINK：数据库链接名
NAMESPACE：名称空间。如果是SQL游标，它的名称空间是CURSOR。名称空间和类型的意义是差不多的。除了CURSOR外，还有TABLE、INDEX等等。
TYPE：类型
SHARABLE_MEM：所占用的内存
LOADS：对象被加载的次数
EXECUTIONS：对象被执行次数
LOCKS：正在锁定对象的会话数
PINS：正在Pin对象的会话数
KEPT：对象是否用DBMS_SHARED_POOL.KEEP保持在共享池中
CHILD_LATCH：对应的子闩
INVALIDATIONS：对象的无效次数
五、OLAP和OLTP的区别
我们上面所说的库缓存的调节适合于OLTP，但并不适合大部分的OLAP系统。什么是OLTP呢，它又叫联机事务处理。各种网站、BBS，或者银行的ATM机上的应用，银行前台电脑中的应用等等，这些都是OLTP型的应用。OLTP偏重于资料收集，但它不会对资料进行分析。OLAP，又叫联机应用程序，它主要指哪些根据以往资料进行分析、处理，查找规律或预测趋势的应用。像数据仓库和DSS（企业决策系统）或数据挖掘型的应用，都是OLAP型应用程序。例如，不知道我们听说过一个啤酒和尿裤的故事没有。（在此处补充此故事）在这个故事中，最后分析出啤酒和尿裤有关联的程序，就是一个OLAP应用。而沃尔玛超市的收银台中的应用，就是OLTP应用。OLTP收集资料，OLAP分析处理。
OLTP的并发会话数可能非常多，但都是执行短小的事务或查询，而且大多数语句都类似。因此，共享执行过的相似的语句，对OLTP是非常重要的。
而OLAP的并发会话可能很少，而且，以查询为主。因为OLAP的主要任务就是分析数据。但OLAP的查询往往需要执行很长时间。对于OLAP来说，共享语句的执行计划是没有必要的。因此，对于OLAP，共享池的大小可以尽量的小。
我们在讲到后面的内容时，会讲述更多OLTP和OLAP这二者的区别，和各种Oracle的特性分别是针对谁设计的。