Oracle Study之案例--Buffer Header结构图及简介

秒速五厘米 2022-08-07 10:38 2阅读 0赞

### Buffer Header结构图及简介   ###

![SouthEast][]  
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，可以参考：http://blog.csdn.net/haibusuanyun/article/details/17439845

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中各字段意义][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. rmt: 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。详见：http://blog.csdn.net/haibusuanyun/article/details/17029517  
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#;

[SouthEast]: /images/20220805/64e8a657a2e849fb968f06cbbdb9ce46.png
[X_BH]: http://blog.csdn.net/haibusuanyun/article/details/17528441