詳解Buffer Header--DUMP buffer結合X$BH檢視各欄位

Buffer Header結構圖及簡介

圖1： 


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中各欄位意義
而對於像：什麼情況下 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。詳見：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#;