oracle buffer cache的基本原理

Buffer cache 的原理

一、

1·）当一个服务器进程需要读数据到buffer cache中时，首先必须判断该数据在buffer 中是否存在，如果存在且可用，则获取该数据，根据lru算法在lru list上移动该block；如果buffer中不存在该数据，则需要从数据文件上获取

2）在读取数据之前，server进程需要扫描lru list 寻找free的buffer，扫描过程中server进程会把发现的所有已经被修改过的buffer移动到checkpoint queue上，这些dirty buffer随后可以被写出到数据文件。

3）如果checkpoint queue超过了阈值，server进程会通知dbwn去写出脏数据；这也是出发dbwr写的一个条件。

Select   kvittag,kvitval,kbvitdsc  from x$kvit  where  kvittag=’kcbldq’;

如果server进程扫描lru超过一个阈值仍然不能找到足够的free buffer ，将停止寻找，转而通知dbwn去写出脏数据，释放空间。

Select   kvittag,kvitval,kbvitdsc  from x$kvit  where  kvittag=’kcbfsp’;

同时由于增量检查点的引入，dbwn进程也会主动扫描lru list，将发现的dirty buffer 移动至checkpoint queue，这个扫描也受到一个内部 约束，

Select   kvittag,kvitval,kbvitdsc  from x$kvit  where  kvittag=’kcbdsp’;

4)找到足够的buffer之后，server进程就可以将buffer从数据文件读入buffer cache

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

从oracle 8i开始lru list 和dirty list 引入了辅助的list，用于提高管理效率，当数据库初始化时，buffer首先存放在lru的辅助list上，当被使用后移动到lru 的主list上，这样当用户进程搜索free buffer时，首先从辅助list上搜索，当dbwr搜索dirty buffer时 会首先从lru 的主list上进行搜索，提高了搜索效率和数据库性能。

二、转储buffer cache 的内容（1-10级）

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

Level  1:仅包含buffer headers 的信息。

Level  2：包含buffer headers和buffer概要信息转储

Level 3：包含buffer headers和完整buffer内容转储。

三、cache buffer  lru chain 闩锁竞争与解决

当用户进程需要读数据到buffer cache时，或cache buffer根据lru算法进行管理时，就不可避免地要扫描lru list 获取可用buffer或更改buffer状态。在搜索的过程中必须获取latch，锁定lru的latch就是常见到的cache buffers  lru chain

解决该latch竞争的方法：

1）适当的增加buffer cache，这样既可以减少读数据到buffer cache的机会，减少扫描lru list 的竞争

。

2）可以适当增加lru latch 的数量，修改_db_block_lru_latches 参数可以实现，

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

四、cache  buffer  chain 闩锁竞争与解决

1、在lru和checkpoint queue这两个内存结构之外，buffer cache的管理还存在另外两个重要的数据结构：hash bucket 和 cache buffer chain

2、为了提高oracle 确定某个block在buffer中的位置，oracle引入了bucket的数据结构，oracle把管理的所有buffer通过一个内部的hash算法运算之后，存放到不同hash  bucket中，这样通过hash bucket进行分割之后，众多的buffer 被分布到一定数量的bucket之中，当用户需要在buffer中定位数据是否存在时，只需要通过同样的算法获得hash值，然后到相应的bucket中查找少量的buffer即可确定。每个buffer存放的bucket由buffer的数据块地址运算决定。

Bucket 内部，通过cache buffer chain （一个双向链表）将所有的buffer通过buffer header信息联系起来。

Buffer header 存放的是对应数据块的概要信息，包括数据文件号、块地址、状态等。要判断数据块在buffer中是否存在，通过检查buffer header即可确定。

3、bucket的数量受一个隐含参数的影响：

Db_block_hash_budkets

1)       从oracle 8i开始，bucket的数量比以前大大增加，通过增加的bucket的稀释使得每个bucket上的buffer数量大大减少。

2)       oracle 8i之前，_db_block_hash_laches的数量和bucket的数量是一致的，每个latch管理一个bucket；从oracle 8i开始每个latch管理多个bucket，由于每个bucket上的buffer数量大大降低，所以latch的性能反而得到了提高。

3)       每个bucket存在一条cache buffer chain

4)       Buffer header 上存在指向具体buffer的指针。

5)       了解了以上算法后，可以想象，如果大量进程对相同的block进程进行操作，那么必然引发cache buffer chain的竞争，也就是通常所说的热快竞争。

五、x$bh和 buffer header

每个buffer在x$BH中都存在一条记录。

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

查询当前数据库最繁忙的buffer

Select *

From (select addr,ts#,file#,dbarfil,dbablk,tch

From x$bh

Order by tch desc)

Where rownum<11;

结合dba_extents中的信息，可以查询到这些热点buffer都来自那些对象。

Select   e.owner,e.segmet_name,e.segment_type

From dba_extents e,

（Select *

From (select addr,ts#,file#,dbarfil,dbablk,tch

From x$bh

Order by tch desc)

Where rownum<11）

Where  e.relative_fno=b.dbarfl

And e.block_id<=b.dbablk

And e.block_id+e.blocks>dbablk;

如果需要确定热点块对象，可以从v$latch_children中查询具体的子latch信息。

X$BH中还存在另外一个关键字段hladdr 即hash chain latch address，这个字段可以和v$latch_child.addr进行关联，这样就可以把具体的latch竞争和数据块关联起来。再结合dba_extents视图再结合v$sqlarea或者v$sqltext找到频繁操作这些对象的sql，然后对其进行优化，即可缓解或解决热点竞争的问题。