+++++buffer cache 深度解析( 三 ) _链表

我们可以看到第一个BH ()的hash: [,]和第二个BH ()的hash：[,] 。这里记录的就是指向前一个和后一个的指针。这里，我们看到第一个BH所指向的后一个的指针是，而第二个BH所指向的前一个的指针也是，说明这两个是在同一个hash chain上。同样的，我们还可以看到类似结构的lru、ckptq、fileq，这些都是管理的一些链表结构。
然后，我们来看我们创建的表所对应的。首先，我们看到class，表示该所对应的数据块的类型，具体的值与含义的对应为：
1=data block；
2=sort block；
3=save undo block；
4= ；
5=save undo ；
6=free list；
7= map；
8=1st level bmb；
9=2nd level bmb；
10=3rd level bmb；
11= block；
12= index block；
13=；
14=undo ；
15=undo block 。
我们可以看到与表相关有两个：一个是4（），另一个是1（data block）。
然后，我们看到rdba，这表示所对应的数据块在磁盘数据文件上的地址。我们可以看到class为1的的rdba为 (6/45066) 。十六进制数。说明该数据块的位置是6号文件的45066号block里。018表示数据文件号乘以4，而b00a表示数据块的号。
上面一句算法是错的，正确的算法是这样的：
这个RDBA由,rfile# + block#组成的
相对文件号10位 block号22位
解码以后就是:
0 0 0000 1010前10位代表rfile#
也就是
0110 = 6
00 0 0000 1010 = 45066
SQL> select to_number('018','xxx')/4 as file#,to_number('b00a','xxxx') as block# from dual;FILE#BLOCK#---------- ----------645066
我们看到，该指向的就是6号文件里的45066号数据块。我们可以再来看看表
里的rowid所告诉我们的文件号以及数据块号，从下面可以看到，结果是一样的。
SQL> select id,dbms_rowid.rowid_relative_fno(rowid) as file#,2dbms_rowid.rowid_block_number(rowid) as block# from cost.buffer_test;IDFILE#BLOCK#---------- ---------- ----------1645066
关于ROWID 和 rdba 参考：
我们可以来看一下st，这表示 cache所指向的数据块的状态。一共有六种状态：
FREE(0)=可以被重用的数据块；
(1)=实例以排他方式获取的当前模式数据块；
(2)=可以与其他实例共享的当前模式数据块；
CR(3)=作为一致性读镜像的数据块，永远不会被写入磁盘；
(4)=正在从磁盘读出的数据块；
(5)=正在进行介质恢复的数据块；
(6)=正在进行实例恢复的数据块。
从状态说明中我们可以看到，现在表的数据块都是当前模式的数据块。我们可以来构造一个CR状态的数据块。
1、分别建立两个，在一个中，执行：
SQL> update buffer_test set id=2 where id=1;
2、不要提交，然后在另外一个中，执行：
SQL> select * from buffer_test;ID----------1
3、然后我们转储后，到跟踪文件中找到obj为7087的记录，可以看到类似如下的内容。可以看到该的状态就是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，就是表示该数据块被扫描的次数。以上这些是转储出来的内容。还提供了视图来显示的内容，这就是X$BH 。这个视图就是把转储到平面文件以后所看到的诸如hash、st、tch等的值以列的方式呈现出来。这里就不做过多的介绍了，有兴趣的话，可以将该视图取出的结果与转储出来的文件进行比较，就可以知道每一列的含义。
3. cache的内部管理机制