共享池之五：Shared Pool子池与结果集缓存技术

SubPool技术及优势：

从Oracle 9i开始，Shared Pool可以被分割为多个子缓冲池（SubPool）进行管理，以提高并发性，减少竞争。
Shared Pool的每个SubPool可以被看作是一个Mini Shared Pool，拥有自己独立的Free List、内存结构以及LRU List、shared pool latch。同时Oracle提供多个Latch对各个子缓冲池进行管理，从而避免单个Latch的竞争（Shared Pool Reserved Area同样进行分割管理）。从10G开始，每个SubPool由4个SUB PARTITION组成。

SubPool的个数和大小

每四个CPU分配一个SubPool，最多可以有7个。Shared Pool Latch也就从原来的一个增加到现在的7个。
在Oracle 9i中，每个SubPool至少为128MB。
10G-10.2.0.3,每个SubPool至少为256MB
10.2.0.3之后，最少为512M。
_kghdsidx_count 隐含参数：ORACLE启动时，优化根据此参数设置SubPool数量。

SubPool缺点：

从ORACL 10G开始，ORACLE进程在某个SubPool中请求内存失败，会到下一个SubPool中请求---过小的SubPool碎片问题可能更严重--ORA-4031出现机率更大。
过多的SubPool还会带来更高的管理协调成本。
比如以下错误就是与SubPool相关：
ORA-04031: unable to allocate 4216 bytes of shared memory
("shared pool","unknown object","sga heap(2,0)","library cache")

共享池大小的判断

        LRU链表分两条：transient LRU(瞬时LRU)、 RECURRENT(周期LRU)。Chunk在第一次使用时，被放入瞬时LRU，第二次使用时，会被移至周期LRU。

        DSI中建议用如下SQL统计LRU和相关信息：
select KGHLUTRN transient,KGHLURCR recurrent ,KGHLUFSH Flush_chunk_number, KGHLUOPS Pin_or_release_operations from X$KGHLU;
--查询出的是自数据库启动以来的，执行ALTER SYSTEM FLUSH SHARED_POOL不会清零。
其中：
    TRANSIENT，瞬时LRU链长度。
    RECURRENT，周期LRU链长度。
    FLUSH_CHUNK_NUMBER，Flush Chunk数。
    PIN_OR_RELEASE_OPERATIONS，Pin或释放Chunk操作的次数。
        如果瞬时LRU链长度超过周期LRU链长度3倍，大量只用一次的Chunk堆积在LRU中，说明共享池太大了。
        如果Flush Chunk数和Pin、释放Chunk操作次数的比小于1：20，说明共享池太小了。这个比例，简单点说，Oracle认为每20次操作Chunk，只有一次Flush Chunk操作，还是可以接受的。如果再低，说明共享池有点小。

######Chunk数和Pin、释放Chunk操作次数的比小于1：20，说明共享池太小了。
这一句错了吧，应该是大于20分之1（每20次操作有一次需要FLUSH CHUNK）时，如十分之1（每十次操作需要一次需要FLUSH CHUNK），说明共享池太小。
共享池一般不超过10G，5、6G即可。过大共享池需要更大管理成本
#####################################################################

结果集缓存--RESULT CACHE

DB_BUFFER只能缓存访问过的BLOCK，部分解决了物理读的问题，查询仍然需要大量的逻辑读。
物化视图提供的是查询重写的功能，对于大部分的情况，只是简化了SQL的复杂度，即使是完全满足查询的条件，物化视图的扫描也是不可避免的。
而缓存结果集——RESULT CACHE则截然不同，它缓存的是查询的结果。不在需要大量的逻辑读，不在需要任何的复杂计算，而是直接将已经缓存的结果返回。---SQL的几乎全部开销都可以避免。这些开销包括，解析时间、逻辑读、物理读和任意的通常可能会遭遇的争用。

RESULT CACHE的结果对于所有的SESSION都是可见的。
RESULT CACHE是满足一致性读的，而且当缓存表数据发生变化的时候，Oracle会自动INVALIDATE缓存结果集：
是否使用RESULT_CACHE与Oracle的执行计划无关：
RESULT CACHE忽略SQL语句的执行计划，即使执行计划发生了变化，只有最终获取的结果是一样的，Oracle仍然会使用RESULT CACHE。
注意当执行计划不同导致结果不同时，Oracle使用RESULT CACHE可能会得到不正确的结果。

对于SQL中间结果使用RESULT CACHE必须使用RESULT_CACHE提示进行强制。
RESULT CACHE功能对于下列情况是无效的：系统表和临时表；序列的NEXTVAL和CURRVAL伪列；SYSDATE、SYSTIMESTAMP等函数；所有非确定性PL/SQL函数。

RESULT_CACHE和NO_RESULT_CACHE

Oracle新增了两个HINT，RESULT_CACHE和NO_RESULT_CACHE。通过这两个提示，可以明确的指出下面的语句是否进行RESULT CACHE。

Oracle还增加了几个初始化参数来管理RESULT CACHE功能，如：RESULT_CACHE_MODE、RESULT_CACHE_MAX_SIZE等。
RESULT_CACHE_MAX_SIZE指明SGA中RESULT CACHE功能可以使用的最大的内存容量。如果这个参数设置为0，则关闭RESULT CACHE功能。
RESULT_CACHE_MODE参数设置Oracle如何使用RESULT CACHE，有三个值：MANUAL、AUTO、FORCE。
当参数值设置为MANUAL时，只有通过HINT明确提示的SQL才会读取缓存结果集。如果不加提示，那么Oracle不会利用已经缓存的结果。
对于AUTO模式，Oracle如果发现缓冲结果集已经存在，那么就会使用。但是如果缓冲结果集不存在，Oracle并不会自动进行缓冲。只有使用HINT的情况下，Oracle才会将执行的结果集缓存。
对于FORCE参数，就是会对所有的SQL进行缓存，除非明确使用NO_RESULT_CACHE提示：
result_cache_max_result设置单个sql语句占用整个RESULT CACHE缓冲区的百分比，默认5%。
RESULT_CACHE_MAX_SIZE用来设置RESULT CACHE的总体大小--不超过过SHARED_POOL_SIZE的75%

在11.2.0.4中，默认是：MANUAL
BYS@ bys3>show parameter result_cache_mode
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
result_cache_mode                    string      MANUAL
Oracle提供了DBMS_RESULT_CACHE包来管理和维护RESULT CACHE。
Oracle还新增了几个关于RESULT CACHE的系统视图，用户可以看到和RESULT CACHE相关的各种信息，视图包括：V$RESULT_CACHE_DEPENDENCY、V$RESULT_CACHE_MEMORY、V$RESULT_CACHE_OBJECTS和V$RESULT_CACHE_STATISTICS等。
关于结果集缓存详见：
http://www.itpub.net/thread-846890-1-1.html
http://database.ctocio.com.cn/tips/365/8273865.shtml