共享池之五: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

你可能感兴趣的:(共享池之五:Shared Pool子池与结果集缓存技术)