BUFFER CACHE之五：多缓冲池技术

---

一、 各个子缓冲池的参数及其大小查看（动态，彼此独立，latche自动分配，对象分流）：

– DB_CACHE_SIZE

– DB_KEEP_CACHE_SIZE

–DB_RECYCLE_CACHE_SIZE

SQL> SELECT NAME, BLOCK_SIZE, CURRENT_SIZE        

  2  FROM V$BUFFER_POOL;

NAME                 BLOCK_SIZE CURRENT_SIZE

-------------------- ---------- ------------

KEEP                       8192           52

RECYCLE                    8192            8

DEFAULT                    8192           32

# 查看各个子缓冲池大小

---

二、 多缓冲池调优意义：

1. 限制使用keep池的表的数量，继而 增加在cache里的数据块。

2. 避免各个子缓冲池对块的竞争，在storage子句为表指定keep池，否则进入default。

3. 设置latch的个数（由实例设置，无需DBA插手）。

---

三、 多缓冲池使用（对象：表，索引，簇）：

CREATE INDEX cust_idx …

STORAGE (BUFFER_POOL KEEP …);

ALTER TABLE customer

STORAGE (BUFFER_POOL RECYCLE);

ALTER INDEX cust_name_idx

STORAGE (BUFFER_POOL KEEP);

NOTE:

当对象的缺省缓冲池被ALTER语句改变时, 所有固定的(cached)数据块仍会在其当前的缓冲块(buffers)中. 换句话说, alter语句对固定的数据块不起作用, 只有能由正常的cache管理活动清理. 从磁盘读取的数据块按段(segment)放入新指定的缓冲池, 缓冲池是按段为单位来分配的, 这样具有多个段的对象其数据库可放在多个缓冲池中， 比如索引组织表(IOT, index-organized table) 的索引和其他的段放在不同的池里面.

常见问题: random access to large segments

访问非常大的segment时（对大的或未绑定索引扫描），LRU算法会出现问题：任何单一的segment若占非连续物理读（non-sequential physical reads）大小的10%以上，可视为非常大的segment。对大的segment的随机读取会导致含其他segment数据的buffer被淘汰；大的segment最终消耗大量的cache，却不会从后者收益。

经常被访问的segment，足够热，不受大的segement读取（large segment reads）的影响，不会被淘汰；偶尔访问的segment，比较热，受LSR的影响，时刻面临被淘汰的危险，解决方案如下：

1. 访问对象如果是索引，查看该索引是否被筛选（selective），否则，调优SQL语句，使用更具筛选性的（more selective）索引

2. 如果该SQL语句已调优，可将大的segment移到recycle池（小于default池，较之重复使用buffer更快）里。

3. 或者，将次热segment移到keep池（大的segment根本不用），keep池要提高保障 高命中率，减少请求响应时间。

Default：Keep：Recycle=非常热（上流社会）：次热（中产阶级）；不热（社会底层）

尺寸： keep：default：recycle=大：中：小

Segment：Pool = 一对多，一个segment（里面数据块）只能放到一个pool里面

一个表只有一个segment，放在一个池里。表有多个segment（partition表）根据不同segment放在不同的pool里面。

---

四、 keep池调优方法：

目标：在内存中保存经常被访问的objects（存放小于default池的10%尺寸大小的segment）,减少I/O操作；

大小：足以存放所有段（segment）的块（block）；

视图：dba_tables，dba_tab_partitions，dba_indexes，获得总块数；

工具：dbms_stats.gather_table_stats

通常可以大量减小keep池，同时不影响命中率；

DBA需监控那些逐渐增大的keep池里面的对象，当一个对象过大时，他们的块将被冲出keep池为其他的块让位。

SQL> EXECUTE dbms_stats.gather_table_stats -

>    ('HR','DEPARTMENTS');

SQL> SELECT  table_name, blocks

2  FROM  dba_tables

3  WHERE wner = 'HR' 

4  AND table_name = 'DEPARTMENTS';

TABLE_NAME     BLOCKS

---------- ----------

DEPARTMENTS         1

（对象没有load到内存使用的方法，否则见六）

---

五、 recycle池调优方法（用v$cache看，这个视图通过catclust.sql脚本创建，很类似v$bh，本池基于trasaction，下次transaction就不用了，，非常适合批处理）：

大小：物理读的统计数据或计算块的大小

跟踪物理读：Oracle Trace Manager，SQL*Plus Autotrace，SQL（TKPROF）

SQL> SELECT  owner#, name, count(*) blocks

2  FROM  v$cache

3  GROUP BY owner#, name;

OWNER# NAME           BLOCKS

------ ---------- ----------

5 CUSTOMER          147

v$sess_io：某个连接的用户自己的I/O。

SQL> SELECT s.username, io.block_gets,

2         io.consistent_gets, io.physical_reads

3  FROM   v$sess_io io, v$session s

4  WHERE  io.sid  = s.sid ;

USERNAME  BLOCK_GETS CONSISTENT_GETS PHYSICAL_READS

-------- ---------- --------------- --------------

HR       21874            2327           1344

---

六、 计算各个池的命中率：

SQL> SELECT name, 1 - (physical_reads /

2  (db_block_gets + consistent_gets)) "HIT_RATIO" 

3  FROM v$buffer_pool_statistics

4  WHERE db_block_gets + consistent_gets > 0;

NAME HIT_RATIO

------------------ ----------

KEEP .983520845

RECYCLE .503866235 （我们也希望这个命中率低）

DEFAULT .790350047

Keep池的命中率最高，块的重用率高，其大小设置大于该池所有segement的总大小，只有很少量的buffer被age out。Segement的大小小于default池的10%；

Recycle池的命中率最低，块的重用率低，基于transaction ，其大小设置小于该池所有segement的总大小。

Trade-Off：内存里的每个对象都会产生trade-off，尽管要在Cache中保存常用块，也要保存那些占用较少空间的非常用块。 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24463783/viewspace-675347/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24463783/viewspace-675347/