深入浅出Oracle学习笔记（5）-CSDN博客

第5章 Buffer Cache与Shared Pool原理

LRU与Dirty List

在Buffer Cache中，Oracle通过几个链表进行内存管理。

LRU list用于维护内存中的Buffer，按照LRU算法进行管理。数据库初始化时，所有的Buffer都被Hash到LRU list上管理。当需要从数据文件上读取数据时，首先要在LRU List上寻找Free的Buffer，然后读取数据到Buffer Cache中；当数据被修改之后，状态变为Dirty，就可以被移动至Dirty List，Dirty List上的都是候选的可以被DBWR写出到数据文件的Buffer，一个Buffer要么在LRU List上，要么在Dirty List上存在，不能同时存在于多个list。

Buffer Cache的原理及使用：

当一个Server进程需要读数据到Buffer Cache中时，首先必须判断该数据在Buffer中是否存在，如果存在且可用，则获取该数据，根据LRU算法在LRU List上移动该Block；如果Buffer中不存在数据，则需要从数据文件上读取。

在读取数据之前，Server进程需要扫描LRU List寻找Free的Buffer，扫描过程中Server进程会把发现的所有已经被修改过的Buffer移动到Checkpoint Queue上，这些Dirty Buffer随后可以被写出到数据文件。

如果Checkpoint Queue超过了阈值，Server进程就会通知DBWn去写出脏数据；这也是触发DBWn写的一个条件，这个阈值曾经提到是25%，也就是当检查点队列超过25%满就会触发DBWn的写操作：

SQL> Select kvittag,kvitval,kvitdsc from x$kvit where kvittag='kcbldq';

KVITTAG KVITVAL KVITDSC

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

kcbldq 25 large dirty queue if kcbclw reaches this

如果Server进程扫描LRU超过一个阈值仍然不能找到足够的Free Buffer，将停止寻找，转而通知DBWn去写出脏数据，释放内存空间。这个数字是40%，也就是说当Server进程扫描LRU超过40% 还没能找到足够的Free Buffer就会停止搜索，通知DBWn执行写出，这时进程会处于free buffer wait等待：

SQL> Select kvittag,kvitval,kvitdsc from x$kvit where kvittag='kcbfsp';

KVITTAG KVITVAL KVITDSC

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

kcbfsp 40 Max percentage of LRU list foreground can scan for free

同时由于增量检查点的引入，DBWn也会主动扫描LRU List，将发现的Dirty Buffer移至Checkpoint Queue，这个扫描也受到一个内部约束，在Oracle 9iR2中这个比例是25%：

SQL> Select kvittag,kvitval,kvitdsc from x$kvit where kvittag='kcbdsp';

KVITTAG KVITVAL KVITDSC

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

kcbdsp 25 Max percentage of LRU list dbwriter can scan for dirty

找到足够的Buffer之后，Server进程就可以将Buffer从数据文件读入Buffer Cache。

如果读取的Block不满足读一致性要求，则Server进程需要通过当前Block版本和回滚段构造前镜像返回给用户。

从Oracle 8i开始，LRU List和Dirty List又分别增加了辅助List（Auxiliary list），用于提高管理效率。引入了辅助List之后，当数据库初始化时，Buffer首先存放在LRU的辅助List上（Auxiliary rpl_lst），当被使用后移动到LRU的主List上（Main rpl_lst），这样当用户进程搜索Free Buffer时，就可以从LRU-AUX List开始，而DBWR搜索Dirty Buffer时，则可以从LRU-MAIN List开始，从而提高了搜索效率和数据库性能。

可以通过如下命令转储Buffer Cache的内容，从而清晰地看到以上描述得数据结构：

Alter session set events ‘immediate trace name buffers level 4’;

不同Level转储内容的详细程度不同，此命令的可用级别主要有1~10级，其中各级别的含义如下：

Level 1：仅包含Buffer Headers信息；

Level 2：包含Buffer Headers和Buffer概要信息转储；

Level 3：包含Buffer Headers和完整Buffer内容转储；

Level 4：Level 1+Latch转储+LRU队列；

Level 5：Level 4+Buffer概要信息转储；

Level 6和Level 7：Level 4+完整的Buffer内容转储；

Level 8：Level 4 +显示users/waiters信息；

Level 9：Level 5 +显示users/waiters信息；

Level 10：Level 6 +显示users/waiters信息。

Cache Buffers Lru Chain闩锁竞争与解决

当进程需要读数据到Buffer Cache时，或Cache Buffer根据LRU算法进行管理时，就不可避免地要扫描LRU List获取可用Buffer 或更改Buffer状态。Oracle的Buffer Cache是共享内存，可以为众多并发进程并发访问，所以在搜索过程中必须获取Latch（Latch是Oracle的一种串行锁机制，用于保护共享内存结构），锁定内存结构，防止并发访问损坏内存中的数据。

这个用于锁定LRU的Latch就是经常见到的Cache Buffers Lru Chain：

SQL> select addr,latch#,name,gets,misses,immediate_gets,immediate_misses

2 from v$latch where name='cache buffers lru chain';

ADDR LATCH# NAME GETS MISSES

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

IMMEDIATE_GETS IMMEDIATE_MISSES

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

01FED330 92 cache buffers lru chain 12409 3

5849 0

Cache Buffers Lru Chain Latch存在多个子Latch，其数量受隐含参数_db_block_lru_latches控制。可以从v$latch_children视图查看当前各子Latch使用情况：

SQL> select addr,child#,name,gets,misses,immediate_gets,immediate_misses

2 from v$latch_children where name='cache buffers lru chain';

ADDR CHILD# NAME GETS MISSES

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

IMMEDIATE_GETS IMMEDIATE_MISSES

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

67EA55E8 8 cache buffers lru chain 22 0

0 0

67EA511C 7 cache buffers lru chain 22 0

0 0

67EA4C50 6 cache buffers lru chain 22 0

0 0

67EA4784 5 cache buffers lru chain 22 0

0 0

67EA42B8 4 cache buffers lru chain 22 0

0 0

67EA3DEC 3 cache buffers lru chain 12553 3

6137 0

67EA3920 2 cache buffers lru chain 22 0

0 0

67EA3454 1 cache buffers lru chain 22 0

0 0

如果该Latch竞争激烈，通常有如下方法可以采用：

适当增大Buffer Cache，这样可以减少读数据到Buffer Cache的机会，减少扫描LRU List的竞争；

可以适当增加LRU Latch数量，修改_db_block_lru_latches参数，该方法不推荐使用；

通过多缓冲池技术，可以减少不希望的数据老化和全表扫描等操作对Default池的冲击，从而可以减少竞争。

Cache Buffer Chain闩锁竞争与解决

在LRU和Dirty List 这两个内存结构之外，Buffer Cache的管理还存在另外两个重要的数据结构：Hash Bucket和Cache Buffer Chain。

可以想象如果所有的Buffer Cache中的所有Buffer都通过同一个结构管理，当需要确定某个Block在Buffer中是否存在时，将需要遍历整个结构，性能会相当低下。

为了提高效率，Oracle引入了Bucket的数据结构，Oracle把管理的所有Buffer通过一个内部的Hash算法运算后，存放到不同的Hash Bucket中，这样通过Hash Bucket分割之后，众多的Buffer被分布到一定数量的Bucket之中，当用户需要在Buffer中定位数据是否存在时，只需要通过同样的算法获得Hash值，然后到相应得Bucket中查找少量的Buffer即可确定。

Bucket内部通过Cache Buffer Chain（Cache Buffer Chain是一个双向链表）将所有的Buffer通过Buffer Header信息联系起来。Buffer Header存放的是对应数据块的概要信息，包括数据块的文件号、块地址、状态等。要判断数据块在Buffer中是否存在，检查Buffer Header即可确定。

对应每个Bucket，只存在一个Chain，当用户试图搜索Cache Buffer Chain时，必须首先获得Cache Buffer Chain Latch。

总结：

从Oracle 8i开始，Bucket的数量比以前大大增加；通过增加的Bucket的“稀释”使得每个Bucket上的Buffer数量大大减少。

在Oracle 8i之前，_db_block_hash_latches的数量和Bucket的数量是一致的，每个Latch管理一个Bucket；从Oracle 8i开始每个Latch需要管理多个Bucket，由于每个Bucket上的Buffer数量大大降低，所以Latch的性能反而得到提高。

每个Bucket存在一条Cache Buffer Chain。

Buffer Header上存在指向具体Buffer的指针。

X$BH与Buffer Header

Buffer Header数据可以从数据库的字典表中查询得到，这张字典表是X$BH。每个Buffer在X$BH中都存在一条记录。

X$BH中有一个重要字段TCH，TCH为Touch的缩写，表示一个Buffer的访问次数，Buffer 被访问的次数越多，说明该Buffer越“抢手”，也就可能存在热点块竞争的问题。

SQL> select *

2 from (select addr,ts#,file#,dbarfil,dbablk,tch

3 from x$bh order by tch desc)

4 where rownum<11;

ADDR TS# FILE# DBARFIL DBABLK TCH

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

0430A6E8 0 1 1 1498 652

0430C9FC 0 1 1 7882 142

0430A5A4 0 1 1 7938 142

0430C9FC 0 1 1 8202 142

0430C9FC 0 1 1 7873 107

0430C9FC 0 1 1 7889 107

0430C9FC 0 1 1 8233 107

0430C9FC 5 5 5 18444 106

0430C9FC 5 5 5 18516 106

0430C9FC 0 1 1 9017 106

再结合dba_extents中的信息，可以查询到这些热点Buffer都来自哪些对象：

SQL> select e.owner,e.segment_name,e.segment_type

2 from dba_extents e,

3 (select *

4 from (select addr,ts#,file#,dbarfil,dbablk,tch

5 from x$bh order by tch desc)

6 where rownum<11) b

7 where e.relative_fno=b.dbarfil

8 and e.block_id<=b.dbablk

9 and e.block_id+e.blocks>b.dbablk;

OWNER SEGMENT_NAME SEGMENT_TYPE

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

SYS I_JOB_NEXT INDEX

SYS I_FILE#_BLOCK# INDEX

SYS C_FILE#_BLOCK# CLUSTER

SYS I_FILE#_BLOCK# INDEX

SYS C_USER# CLUSTER

SYS I_OBJ1 INDEX

SYS OBJ$ TABLE

SYS C_FILE#_BLOCK# CLUSTER

SYS C_TS# CLUSTER

转储Buffer内容获取跟踪文件：

Alter session set events ‘immediate trace name buffers level 10’;

Shared Pool的基本原理

Oracle通过Shared Pool来实现SQL共享、减少代码硬解析等，从而提高数据库的性能。

通过如下命令转储Shared Pool共享内存的内容：

Alter session set events ‘immediate trace name heapdump level 2’;

Shared Pool通过Free Lists管理Free内存块（Chunk），Free的内存块（Chunk）按不同size被划分到不同的部分（Bucket）进行管理。

初始时，数据库启动以后，Shared Pool多数是连续内存块，但是当空间分配使用以后，内存块开始被分割，碎片开始出现，Bucket列表开始变长。Oracle请求Shared Pool空间时，首先进入相应的Bucket进行查找。如果找不到，则转向下一个非空的Bucket，获取第一个Chunk。如果找不到，则转向下一个非空的Bucket，获取第一个Chunk。分割这个Chunk，剩余部分会进入相应的Bucket，进一步增加碎片。

最终的结果是，由于不停分割，每个Bucket上的内存块会越来越多，越来越碎小。碎片过多会导致搜索Free List的时间过长，而Free Lists的管理和搜索都需要获得和持有一个非常重要的Latch，就是Shared Pool Latch。Latch是Oracle数据库内部提供的一种低级锁，通过串行机制保护共享内存不被并发更新/修改所损坏。Latch的持有通常都非常短暂，但是对于一个繁忙的数据库，这个串行机制往往会成为极大的性能瓶颈。