当前位置:Gxlcms > mysql > 详解BufferHeader--DUMPbuffer结合X$BH视图各字段

详解BufferHeader--DUMPbuffer结合X$BH视图各字段

时间:2021-07-01 10:21:17 帮助过:34人阅读

Buffer Header结构图及简介 图1: buffer header:每一个数据块在被读入buffer cache时,都会先在buffer cache中构造一个buffer header,buffer header与数据块一一对应。buffer header包含的主要信息有: 1) 该数据块在buffer cache中实际的内存地址。就是

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值。
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(临时块)
第十一句:
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处于实例恢复模式
lru_flag
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'


人气教程排行