buffer cache深度分析之内部管理机制

• 机制
• buffer
• 数据
• header
• hash
• 我们
• 可以

本文首先详细介绍了oracle中buffer cache的概念以及所包含的内存结构。然后结合各个后台进程（包括DBWRn、CKPT、LGWR等）深入介绍了oracle对于buffer cache的管理机制，并详细解释了oracle为什么会采用现在的管理机制，是为了解决什么问题。比如为何会引入touch次数、为何会引入增量检查点等等。最后全面介绍了有关buffer cache监控以及调优的实用方法。

1. buffer cache的概念
  用最简单的语言来描述oracle数据库的本质，其实就是能够用磁盘上的一堆文件来存储数据，并提供了各种各样的手段对这些数据进行管理。作为管理数据的最基本要求就是能够保存和读取磁盘上的文件中的数据。众所周知，读取磁盘的速度相对来说是非常慢的，而内存相对速度则要快的多。因此为了能够加快处理数据的速度，oracle必须将读取过的数据缓存在内存里。而oracle对这些缓存在内存里的数据起了个名字：数据高速缓存区（db buffer cache），通常就叫做buffer cache。按照oracle官方的说法，buffer cache就是一块含有许多数据块的内存区域，而这些数据块主要都是数据文件里的数据块内容的拷贝。通过初始化参数：buffer_cache_size来指定buffer cache的大小。oracle实例一旦启动，该区域大小就被分配好了。

buffer cache所能提供的功能主要包括：
1） 通过缓存数据块，从而减少I/O。
2） 通过构造CR块，从而提供读一致性功能。
3） 通过提供各种lock、latch机制，从而提供多个进程并发访问同一个数据块的功能。
2.buffer cache的内存结构

2.1 buffer cache概述
oracle内部在实现其管理的过程中，有两个非常有名的名词：链表和hash算法。
链表是一种数据结构，通过将对象串连在一起，从而构成链表结构。这样，如果要修改、删除、查找某个对象的话，都可以先到链表中去查找，而不必实际的访问物理介质。oracle中最有名的链表大概就是LRU链表了，我们后面会介绍它。

  而hash算法则是为了能够进行快速查找定位所使用一种技术。所谓hash算法，就是根据要查找的值，对该值进行一定的hash算法后得出该值所在的索引号，然后进入到该值应该存在的一列数值列表（可以理解为一个二维数组）里，通过该索引号去找它应该属于哪一个列表。然后再进入所确定的列表里，对其中所含有的值，进行一个一个的比较，从而找到该值。这样就避免了对整个数值列表进行扫描才能找到该值，这种全扫描的方式显然要比hash查找方式低效很多。其中，每个索引号对应的数值列在oracle里都叫做一个hash bucket。 中国_网管联盟bitsCN.com

  我们来列举一个最简单的hash算法。假设我们的数值列表最多可以有10个元素，也就是有10个hash buckets，每个元素最多可以包含20个数值。则对应的二维数组就是t[10][20]。我们可以定义hash算法为n MOD 10。通过这种算法，可以将所有进入的数据均匀放在10个hash bucket里面，hash bucket编号从0到9。比如，我们把1到100都通过这个hash函数均匀放到这10个hash bucket里，当查找32在哪里时，只要将32 MOD 10等于2，这样就知道可以到2号hash bucket里去找，也就是到t[2][20]里去找，2号hash bucket里有10个数值，逐个比较2号hash bucket里是否存在32就可以了。

  buffer cache就是使用多个hash bucket来管理的，其hash算法当然比我们前面列举的要复杂多了。
我们先来看下面这个图一。这副图从逻辑上说明了整个buffer cache的结构是怎么样的。这副图的右
上角列出了三个名词：hash bucket、buffer header和hash chain。

  这里的hash bucket就是我们前面说明hash算法中提到的二维数组的第一维。它是通过对buffer header
 里记录的数据块地址和数据块类型运用hash算法以后，得到的组号。
这里的hash chain就是属于同一个hash bucket的所有buffer header所串起来的链表。实际上，hash
bucket只是一个逻辑上的概念。每个hash bucket都是通过不同的hash chain而体现出来的。每个hash chain都会由一个cache buffers chains latch来管理其并发操作。

  而对于buffer header来说，每一个数据块在被读入buffer cache时，都会先在buffer cache中构造一个buffer header，buffer header与数据块一一对应。buffer header包含的主要信息有：
1） 该数据块在buffer cache中实际的内存地址。就是上图中的虚线箭头所表示的意思。
2） 该数据块的类型，包括data、segment header、undo header、undo block等等。
3） 该buffer header所在的hash chain，是通过在buffer header里保存指向前一个buffer header的指针和指向后一个buffer header的指针的方式实现的。
4） 该buffer header所在的LRU、LRUW、CKPTQ等链表（这些链表我们后面都会详细说明）。也是通过记录前后buffer header指针的方式实现。
5） 当前该buffer header所对应的数据块的状态以及标记。
6） 该buffer header被访问（touch）的次数。
7） 正在等待该buffer header的进程列表（waiter list）和正在使用该buffer header的进程列表（user list）。 
    
   buffer cache中，缺省的hash bucket的数量或者说缺省有多少条hash chain链表，是由一个隐藏参数：
_db_block_hash_buckets决定的。置于该参数的取值，在我的测试中，8i下，该参数缺省为db_block_buffers×2；但是到了9i以后，该参数似乎取的是小于且最接近于db_block_buffers×2的素数。

2.2 转储buffer cache
就象实例中的其他内存结构一样，oracle提供了可以将buffer cache转储到跟踪文件的方法。方法如下：

ALTER SESSION SET EVENTS 'immediate trace name buffers level level';
   这里的level有很多值，分别可以转储buffer cache中的不同的内容。level的可选值包括：
1 只转储buffer header
2 在level 1的基础上再转储数据块头
3 在level 2的基础上再转储数据块内容
4 转储buffer header和hash chain
5 在level 1的基础上再转储数据块头和hash chain
6 在level 2的基础上再转储数据块内容和hash chain
8 转储buffer header和hash chain以及users/waiters链表
9 在level 1的基础上再转储数据块头、hash chain以及users/waiters链表
10 在level 2的基础上再转储数据块内容、hash chain以及users/waiters链表

我们创建一个简单的测试表，然后看看转储出来的buffer header是什么样子的。

SQL> create table buffer_test(id number);
SQL> select object_id from dba_objects where object_name='BUFFER_TEST';
 OBJECT_ID
----------
      7087
SQL> insert into buffer_test values(1);
SQL> commit;

这时我们知道buffer_test表的object_id是7987，同时，该表中只有2个block具有数据。1个是segment header，另一个就是实际存放了1这个值的数据块。接着我们把buffer header转储出来：

SQL> ALTER SESSION SET EVENTS 'immediate trace name buffers level 1';

到user_dump_dest所定义的目录下，找到跟踪文件并打开，可以看到类似下面的信息，这里我们列出前两个buffer header以及我们建立的object_id为7087的buffer_test表所对应的buffer header的内容：

bitsCN~com

BH (0x637F0720) file#: 1 rdba: 0x004011ed (1/4589) class 1 ba: 0x63570000
…………………………………
  hash: [64be8000,65a5eab4] lru: [637f06ac,637f0824]
  LRU flags: moved_to_tail
  ckptq: [NULL] fileq: [NULL]
…………………………………
BH (0x64BE8000) file#: 0 rdba: 0x00000000 (0/0) class 0 ba: 0x64800000
…………………………………
  hash: [65a5eab4,637f0720] lru: [64be8104,65aa3f0c]
…………………………………
BH (0x63BEC0A0) file#: 6 rdba: 0x0180b00a (6/45066) class 1 ba: 0x638B0000
  set: 3 dbwrid: 0 obj: 7087 objn: 7087
  hash: [65a9ccd4,65a9ccd4] lru: [63bec1a4,63bec02c]
  ckptq: [65abceb4,63bec66c] fileq: [65abcfbc,63becd10]
  st: XCURRENT md: NULL rsop: 0x00000000 tch: 1
  flags: buffer_dirty gotten_in_current_mode redo_since_read
  LRBA: [0xe9.229.0] HSCN: [0x0000.00122967] HSUB: [1] RRBA: [0x0.0.0]
BH (0x63BECAE8) file#: 6 rdba: 0x0180b009 (6/45065) class 4 ba: 0x638CC000
  set: 3 dbwrid: 0 obj: 7087 objn: 7087
  hash: [65a9cbcc,65a9cbcc] lru: [63becbec,63beca74]
  ckptq: [637fc250,63becdc4] fileq: [65ab8ad0,63becdcc]
  st: XCURRENT md: NULL rsop: 0x00000000 tch: 2
  flags: buffer_dirty gotten_in_current_mode redo_since_read
  LRBA: [0xe9.21b.0] HSCN: [0x0000.00122965] HSUB: [1] RRBA: [0x0.0.0]
…………………………………

    我们可以看到第一个BH (0x637F0720)的hash: [64be8000,65a5eab4]和第二个BH (0x64BE8000)的hash：[65a5eab4,637f0720]。这里记录的就是指向前一个buffer header和后一个buffer header的指针。这里，我们看到第一个BH所指向的后一个buffer header的指针是65a5eab4，而第二个BH所指向的前一个buffer header的指针也是65a5eab4，说明这两个buffer header是在同一个hash chain上。同样的，我们还可以看到类似结构的lru、ckptq、fileq，这些都是管理buffer header的一些链表结构。

  然后，我们来看我们创建的buffer_test表所对应的buffer header。  首先，我们看到class，表示该buffer header所对应的数据块的类型，具体的值与含义的对应为：1=data block；2=sort block；3=save undo block；4=segment header；5=save undo header；6=free list；7=extent map；8=1st level bmb；9=2nd level bmb；10=3rd level bmb；11=bitmap block；12=bitmap index block；13=unused；14=undo header；15=undo block。我们可以看到与buffer_test表相关buffer header有两个：一个是4（segment header），另一个是1（data block）。
 
  然后，我们看到rdba，这表示buffer header所对应的数据块的地址。我们可以看到class为1的buffer header的rdba为0x0180b00a (6/45066)。说明该数据块的位置是6号文件的45066号block里。018表示数据文件号乘以4，而b00a表示数据块的号。

SQL> select to_number('018','xxx')/4 as file#,to_number('b00a','xxxx')   as block# from dual;
     FILE#     BLOCK#
---------- ----------
         6      45066

我们看到，该buffer header指向的就是6号文件里的45066号数据块。我们可以再来看看表buffer_test
里的rowid所告诉我们的文件号以及数据块号，从下面可以看到，结果是一样的。

SQL> select id,dbms_rowid.rowid_relative_fno(rowid) as file#,
  2  dbms_rowid.rowid_block_number(rowid) as block# from cost.buffer_test;
        ID      FILE#     BLOCK#
---------- ---------- ----------
         1          6      45066

  我们可以来看一下st，这表示buffer cache所指向的数据块的状态。一共有六种状态：FREE(0)=可以被重用的数据块；XCURRENT(1)=实例以排他方式获取的当前模式数据块；SCURRENT(2)=可以与其他实例共享的当前模式数据块；CR(3)=作为一致性读镜像的数据块，永远不会被写入磁盘；READING(4)=正在从磁盘读出的数据块；MRECOVERY(5)=正在进行介质恢复的数据块；IRECOVERY(6)=正在进行实例恢复的数据块。从状态说明中我们可以看到，现在表buffer_test的数据块都是当前模式的数据块。我们可以来构造一个CR状态的数据块。
分别建立两个session，在一个session中，执行：

SQL> update buffer_test set id=2 where id=1;

不要提交，然后在另外一个session中，执行：

SQL> select * from buffer_test;
        ID
----------
         1

  然后我们转储buffer header后，到跟踪文件中找到obj为7087的记录，可以看到类似如下的内容。可以看到该buffer header的状态就是CR。

…………………………………
BH (0x63FFBBC8) file#: 6 rdba: 0x0180b00a (6/45066) class 1 ba: 0x63F5C000
…………………………………
  ckptq: [NULL] fileq: [NULL]
  st: CR md: NULL rsop: 0x00000000 tch: 0
…………………………………

  另外，我们还可以看到tch，就是表示该数据块被扫描的次数。 以上这些是转储出来的内容。Oracle还提供了视图来显示buffer header的内容，这就是X$BH。这个视图就是把转储到平面文件以后所看到的诸如hash、st、tch等的值以列的方式呈现出来。这里就不做过多的介绍了，有兴趣的话，可以将该视图取出的结果与转储出来的文件进行比较，就可以知道每一列的含义。