Buffer Header结构图及简介

图1: 


详解Buffer Header--DUMP buffer结合X$BH视图各字段_数据块



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)。


DUMP 指定的BUFFER BLOCK--含BH方法如下:   --数据库版本:11.2.0.4   

--补充下,如果是要DUMP整个BUFFER CACHE

BYS@ bys3>select dept.*,dbms_rowid.rowid_object(rowid) object#,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,dbms_rowid.rowid_row_number(rowid) row# from dept;


    DEPTNO DNAME          LOC              OBJECT#      FILE#     BLOCK#       ROW#


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


        10 ACCOUNTING     NEW YORK           22327          4        251          0


        20 RESEARCH       DALLAS             22327          4        251          1


        40 OPERATIONS     BOSTON             22327          4        251          2


        99 chedan         bj                 22327          4        251          3


BYS@ bys3>select dbms_utility.make_data_block_address(4,251) from dual;


DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(4,251)


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


                                   16777467


alter session set events 'immediate trace name set_tsn_p1 level 5';


alter session set events 'immediate trace name buffer level 16777467';


select value from v$diag_info where name like 'De%';



select * from x$bh where DBARFIL=4 and DBABLK=251; 用SYS用户从X$BH查看相应信息对照DUMP文件查看。


#########################################################


解读Buffer Header --结合X$BH


说明:DUMP BUFFER中一个块方法就是上一步的,可以先从多个会话对此块进行查询或DML之类,然后DUMP此块。下面的两段BH的内容是不是从同一个DUMP生成的文件中截取的已经记不清了。这里只是介绍了DUMP文件的BH中各个字段的意义,对已经知道的BH中各个字段与X$BH,V$BH中字段的对应也有写上。关于X$BH中字段,可以参考:

X$BH中各字段意义


而对于像:什么情况下 lru-flags: hot_buffer或lru-flags: moved_to_tail,什么情况下st: CR或 st: XCURRENT,暂不在本文讨论范围了!


后面尽量按照DUMP的BH中一句一句的顺序进行解读,但是因为ru-flags:  flags: obj-flags:这种并不在每一次DUMP中出现,所以这一块内容汇总在一起了--注意我下面的ru-flags:  flags: obj-flags:等在下面贴出来的两个BH中可能没出现,是从其它DUMP文件中贴过来的。


最后,这方面参考资料较少,难免有疏漏之处,欢迎补充、指错!!


######


Dump of buffer cache at level 10 for tsn=4 rdba=16777467


1.  BH (0x213e6ad0) file#: 4 rdba: 0x010000fb (4/251) class: 1 ba: 0x210b0000


2.    set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0


3.    dbwrid: 0 obj: 22327 objn: 22327 tsn: 4 afn: 4 hint: f


4.    hash: [0x2bbfddf4,0x213e7680] lru: [0x213e76b0,0x22ff07ec]


5.    lru-flags: moved_to_tail


6.    ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]


7.    st: CR md: NULL fpin: 'kdswh11: kdst_fetch' tch: 1


8.    cr: [scn: 0x0.3a9dcc],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.3a9dcc],[sfl: 0x0],[lc: 0x0.359e7e]


9.    flags: only_sequential_access


10.   buffer tsn: 4 rdba: 0x010000fb (4/251)


11.   scn: 0x0000.00359e7e seq: 0x01 flg: 0x04 tail: 0x9e7e0601


12.   frmt: 0x02 chkval: 0x8cd6 type: 0x06=trans data


Hex dump of block: st=0, typ_found=1


第二个


BH (0x21fe5dec) file#: 4 rdba: 0x010000fb (4/251) class: 1 ba: 0x21c92000


  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0


  dbwrid: 0 obj: 22327 objn: 22327 tsn: 4 afn: 4 hint: f


  hash: [0x213e7680,0x233f2418] lru: [0x233f76c8,0x233f2448]


  ckptq: [NULL] fileq: [NULL] objq: [0x233f76e0,0x240796ec] objaq: [0x233f76e8,0x240796e4]


  use: [NULL] wait: [NULL]


  st: XCURRENT md: NULL fpin: 'kdswh11: kdst_fetch'

tch: 2 txn: 0x293d0380


  flags: private


  LRBA: [0x0.0.0] LSCN: [0x0.3a9dcd] HSCN: [0x0.3a9dcd] HSUB: [65535]


  buffer tsn: 4 rdba: 0x010000fb (4/251)


  scn: 0x0000.00359e7e seq: 0x01 flg: 0x04 tail: 0x9e7e0601


  frmt: 0x02 chkval: 0x8cd6 type: 0x06=trans data


Hex dump of corrupt header 3 = CHKVAL


Dump of memory from 0x21C92000 to 0x21C92014


#############################################


解读Buffer Header,也是对X$BH中相应字段的更详解读


第一句:

BH (0x213e6ad0) file#: 4 rdba: 0x010000fb (4/251) class: 1 ba: 0x210b0000


BH (0x213e6ad0) ,这是BH的HASH值


file#: 4 ,对应X$BH.FILE#,此块在4号文件里,通过v$dbfile.FILE#可以查出来对应的数据文件


rdba: 0x010000fb (4/251),rdba就是rowid中的相对文件号rfile#+block#块号。通过DBMS_ROWID查出块的rfile#+block#,使用select dbms_utility.make_data_block_address(4,251) from dual;这种方法可以计算出来十进制的rdba。这里的10000fb用to_number函数转换为10进制就是前面计算出来的:16777467。。0x010000fb转成二进制时,由相对文件号10位 block号22位。


class: 1,对应X$BH.class --表示buffer header对应block的类型,1=data block。详见本段Buffer Header解析最后。


ba: 0x210b0000 对应X$BH.BA,这是BUFFER中block address,是块在内存中的物理地址。


第二句:

  set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0


  set: 3:对应X$BH.STATE,CR(3)=作为一致性读镜像的数据块,详见本段Buffer Header解析最后。


  bsz: 8192,块大小8192KB。这个可以在 dba_tablespaces.BLOCK_SIZE 查询出数据文件的块大小。


第三句:

dbwrid: 0 obj: 22327 objn: 22327 tsn: 4 afn: 4 hint: f


obj: 22327,对应X$BH.OBJ ,也就是块上数据在哪个对象里,这个查询渠道很多。


第四句:

hash: [0x2bbfddf4,0x213e7680] lru: [0x213e76b0,0x22ff07ec]


hash: [0x2bbfddf4,0x213e7680] 一一对应x$bh.nxt_hash x$bh.prv_hash这里用链表,指出下一个及前一个BH的HASH值。如果这个hash chain上只有一个bh,则这里的前一个及后一个BH的hash值都是此BH。


lru: [0x213e76b0,0x22ff07ec]  一一对应x$bh.nxt_repl x$bh.prv_repl这里用链表,指出下一个及前一个BH的在LRU链上HASH值。


第五句:

lru-flags: moved_to_tail  对应x$bh. LRU_FLAG 表示该数据块经历了依次全表扫描,它被移到LRU的冷端,随时都可能被age out。


lru-flags为0时,在DUMP BUFFER时可能不显示lru-flags:  这一行。


 lru-flags: on_auxiliary_list


可能出现的:


 obj-flags: object_ckpt_list   

  对应 x$bh.OBJ_FLAG,,文件队列的对应对应 x$bh.RFLAG


 flags: only_sequential_access   对应x$bh. FLAG


flags: buffer_dirty block_written_once redo_since_read     --在DML后可能会出现这种状态的  flags


  flags: buffer_dirty redo_since_read


第六句:

ckptq: [NULL] fileq: [NULL] objq: [0x22ff8054,0x24839390] objaq: [0x22ff805c,0x24839388]


ckptq: [NULL] 在检查点队列上的HASH值,这里为空


fileq: [NULL] 在文件队列上的HASH值


objq: [0x22ff8054,0x24839390] 对应x$bh.oq_nxt x$bh.oq_prv .对象队列HASH值


objaq: [0x22ff805c,0x24839388] 对应x$bh.aq_nxt x$bh.aq_prv.辅助对象队列HASH值



第七句

 st: CR md: NULL fpin: 'kdswh11: kdst_fetch' tch: 1


st: CR :对应x$bh.state CR, a consistent read (stale) block image 一致读。

详见本段Buffer Header解析最后。


tch: 1    对应X$BH.TCH,Touch的缩写,表示一个Buffer的访问次数--不过不是绝对,3秒内访问同一块,TCH不增加。与此相关的一个字段是:

X$BH.tim  --Touch Time



第八句

cr: [scn: 0x0.3a9dcc],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.3a9dcc],[sfl: 0x0],[lc: 0x0.359e7e]


[scn: 0x0.3a9dcc] 产生此CR块时的SCN



第九句:

buffer tsn: 4 rdba: 0x010000fb (4/251)


这个块的TSN 表空间号和RDBA


第十句:

scn: 0x0000.00359e7e seq: 0x01 flg: 0x04 tail: 0x9e7e0601


scn: 0x0000.00359e7e,SCN直接转换为用to_number函数转换为10进制就是数据库内查出的SCN了,是这个块的状态改变时的SCN。


seq: 0x01


flg: 0x04   flg:0x01 (新建块)0x2(数据块延迟清洗推进scn和seq) 0X04(设置校验和) 0x08(临时块) 0x00普通块


第十一句:

frmt: 0x02 chkval: 0x8cd6 type: 0x06=trans data


type:0x06(表/索引块)


frmt:  0x01(v7)  0x02(v8)


##############################


第二个块BH与不同的有:

LRBA: [0xe3.e8e5.0] LSCN: [0x0.3a9dcd] HSCN: [0x0.3a9dcd] HSUB: [65535]


LSCN: [0x0.3a9dcd] HSCN: [0x0.3a9dcd]    修改时的SCN--如记录有修改时的SCN,可以转换此十六进制为SCN进行对比


LRBA: [0xe3.e8e5.0] 应该是最低REDO BYTE ADDRES,[0xe3.e8e5.0]对应

日志号,块号,第几字节起。也可能会有HRBA ,recovery rba 。


use: [NULL] wait: [NULL]  对应BH中的     users list   ;   waiters list

################################################################


附:

flag中,每位代表如下含义:

bit bit


0 buffer_dirty 14 stale


1 notify_after_change 15 deferred_ping


2 mod_started 16 direct_access


3 block_has_been_logged 17 hash_chain_dump


4 temp_data 18 ignore_redo


5 being_written 19 only_sequential_access


6 waiting_for_write 20 prefetched_block


7 multiple_waiters 21 block_written_once


8 recovery_reading 22 logically_flushed


9 unlink_from_lock 23 resilvered_already


10 down_grade_lock 25 redo_since_read


11 clone_being_written 29 plugged_from_foreign_db


12 reading_as_CR 30 flush_after_writing


13 gotten_in_current_mode


class:表示buffer header对应block的类型:


            1=data block,                   9=2nd level bmb,     


            2=sort block,                   10=3rd level bmb,    


            3=save undo block,              11=bitmap block,     


            4=segment header,               12=bitmap index block,


            5=save undo header,             13=unused,           


            6=free list,                    14=undo header,      


            7=extent map,                   15=undo block  


state:

0, FREE, no valid block image


1, XCUR, a current mode block, exclusive to this instance 正在被当前的instance独占。


2, SCUR, a current mode block, shared with other instances正在被当前的instance共享


3, CR, a consistent read (stale) block image 一致读


4, READ, buffer is reserved for a block being read from disk 正在从磁盘上读取块


5, MREC, a block in media recovery mode  处于介质恢复模式


6, IREC, a block in instance (crash) recovery mode处于实例恢复模式



0,'free',1,'xcur',2,'scur',


3,'cr', 4,'read',5,'mrec',


6,'irec',7,'write',8,'pi', 9,'memory'


10,'mwrite',11,'donated', 12,'protected',  


13,'securefile', 14,'siop',15,'recckpt',


 16, 'flashfree',  17, 'flashcur', 18, 'flashna'

lru_flag

SYS@ bys3>select distinct(lru_flag) from x$bh;

  LRU_FLAG
----------
         6
         4
         8
         0


select  lru_flag,tch,BA,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi', 9,'memory',10,'mwrite',11,'donated', 12,'protected',  13,'securefile', 14,'siop',15,'recckpt', 16, 'flashfree',  17, 'flashcur', 18, 'flashna') status from x$bh where FILE#=4 and DBABLK=251;

select file#,block#,status from v$bh where objd=(select data_object_id from dba_objects where owner='bys' and object_name='TEST') and block#=341892 order by block#;