bbed会产生cr块么?

联系:QQ(5163721)

标题:bbed会产生cr块么?

作者:Lunar©版权所有[文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.]

先说下结论,bbed不会产生cr块,具体请看测试结果:

这个结论我的测试不知道是不是科学或者完整,因此,有不同结论的测试,欢迎交流,O(∩_∩)O哈哈~

在没有flush buffer cache的情况下,我们看看:

Start dump data blocks tsn: 4 file#:4 minblk 131 maxblk 131
Block dump from cache:
Dump of buffer cache at level 4 for tsn=4 rdba=16777347
BH (0x64bfb2f8) file#: 4 rdba: 0x01000083 (4/131) class: 1 ba: 0x64bb6000
  set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 18222 objn: 18222 tsn: 4 afn: 4 hint: f
  hash: [0x617e2cf8,0x83e39ac0] lru: [0x64bfc480,0x77bee8d0]
  obj-flags: object_ckpt_list
  ckptq: [0x64fd9908,0x83f48650] fileq: [0x83f486d0,0x83f486d0] objq: [0x7c05dde8,0x7c05dde8] objaq: [0x7c05ddc8,0x64bfc4b8]
  st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 2
  flags: buffer_dirty redo_since_read
  LRBA: [0x5e.7af.0] LSCN: [0x0.af3be] HSCN: [0x0.af3c4] HSUB: [1]
BH (0x617e2c48) file#: 4 rdba: 0x01000083 (4/131) class: 1 ba: 0x61524000
  set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 18222 objn: 18222 tsn: 4 afn: 4 hint: f
  hash: [0x627d8588,0x64bfb3a8] lru: [0x83f44af8,0x763f2a20]
  lru-flags: moved_to_tail
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
  st: CR md: NULL fpin: 'kdswh01: kdstgr' tch: 2
  cr: [scn: 0x0.af3c3],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.af3c3],[sfl: 0x0],[lc: 0x0.af3be]
  flags: redo_since_read
BH (0x627d84d8) file#: 4 rdba: 0x01000083 (4/131) class: 1 ba: 0x6240a000
  set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 18222 objn: 18222 tsn: 4 afn: 4 hint: f
  hash: [0x83e39ac0,0x617e2cf8] lru: [0x613fa210,0x737e16a0]
  lru-flags: moved_to_tail on_auxiliary_list
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
  st: FREE md: NULL fpin: 'kdswh01: kdstgr' tch: 0 lfb: 33
  flags:

上面这段信息基本跟X$BH的内容对应。


这里,表示file 4 block 131是object_id为18222的对象的一个块(st: XCURRENT,即当前块),该块作为class 1 block被prefetch(class 1表示数据块,比如如果这是是class 8,就表示1st level bmb ,如果是3就表示3级位图块等等……)
这个块是脏块(buffer_dirty)。同时,在LRU链表的末端有一个该块的CR块,在辅助链表还有一个该块的副本(FREE状态,表示跟数据文件上该块的是一致的)。

其中LRU_FLAG的解释如下:
KCBBHLDF 0x01 8.1 LRU Dump Flag used in debug print routine
KCBBHLMT 0x02 8.1 moved to tail of lru (for extended stats)
KCBBHLAL 0x04 8.1 on auxiliary list
KCBBHLHB 0x08 8.1 hot buffer – not in cold portion of lru

可以通过如下语句查询lru_flah:
select ba,dbablk,lru_flag from x$bh where dbablk=131;
注意:
X$BH.lru_flag 为2:moved_to_tail
X$BH.lru_flag 为8:hot_buffer
X$BH.lru_flag 为4:on_auxiliary_list
X$BH.lru_flag 为6:moved_to_tail on_auxiliary_list


再比如,可以通过下面的语句查询出来该块hash链表的值,例如hash: [0x83e39ac0,0x617e2cf8],表示下一个BH的hash值是0x83e39ac0,而前面一个BH的hash值是0x617e2cf8:
select ba,dbablk,nxt_hash,prv_hash from x$bh where dbablk=131


如果我做了flush buffer cache,在使用bbed读取block,则所有块都在辅助链表,且没有XCURRENT了,都是FREE:

  
  Block dump from cache:
Dump of buffer cache at level 4 for tsn=4 rdba=16777347
BH (0x64bfb2f8) file#: 4 rdba: 0x01000083 (4/131) class: 1 ba: 0x64bb6000
  set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 18222 objn: 18222 tsn: 4 afn: 4 hint: f
  hash: [0x617e2cf8,0x83e39ac0] lru: [0x64fd9530,0x617e2d30]
  lru-flags: on_auxiliary_list
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
  st: FREE md: NULL fpin: 'kdswh01: kdstgr' tch: 0 lfb: 33
  flags:
BH (0x617e2c48) file#: 4 rdba: 0x01000083 (4/131) class: 1 ba: 0x61524000
  set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 18222 objn: 18222 tsn: 4 afn: 4 hint: f
  hash: [0x627d8588,0x64bfb3a8] lru: [0x64bfb3e0,0x64fda700]
  lru-flags: moved_to_tail on_auxiliary_list
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
  st: FREE md: NULL fpin: 'kdswh01: kdstgr' tch: 0 lfb: 33
  flags:
BH (0x627d84d8) file#: 4 rdba: 0x01000083 (4/131) class: 1 ba: 0x6240a000
  set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
  dbwrid: 0 obj: 18222 objn: 18222 tsn: 4 afn: 4 hint: f
  hash: [0x83e39ac0,0x617e2cf8] lru: [0x613fa210,0x737e16a0]
  lru-flags: moved_to_tail on_auxiliary_list
  ckptq: [NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]
  st: FREE md: NULL fpin: 'kdswh01: kdstgr' tch: 0 lfb: 33
  flags:

顺便多看一点:

  
Block dump from disk:
buffer tsn: 4 rdba: 0x01000083 (4/131)
scn: 0x0000.000af3c4 seq: 0x01 flg: 0x04 tail: 0xf3c40601
frmt: 0x02 chkval: 0x044f type: 0x06=trans data  
Hex dump of block: st=0, typ_found=1
.........

这部分内容中的type、frmt_kcbh等等和trace中的下面第一行对应(即块头的信息):

 
BBED> p kcbh  
struct kcbh, 20 bytes                       @0       
   ub1 type_kcbh                            @0        0x06
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x01000083
   ub4 bas_kcbh                             @8        0x000a5a05
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0x01
   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)
   ub2 chkval_kcbh                          @16       0x467e
   ub2 spare3_kcbh                          @18       0x0000

BBED> dump count 20   
 File: /stage/travel/users01.dbf (4)
 Block: 131              Offsets:    0 to   19           Dba:0x01000083
------------------------------------------------------------------------
 06a20000 83000001 055a0a00 00000104 7e460000 

 <32 bytes per line>

BBED> 

下面的dump是内存中的块的dump,这部分信息真好呀,你不用像以前那样为了看看OS系统上块长啥样子而去”dd|od -x” 了,O(∩_∩)O哈哈~

 
Dump of memory from 0x00007FFB32AFEA00 to 0x00007FFB32B00A00
7FFB32AFEA00 0000A206 01000083 000AF3C4 04010000  [................]     
这里A2就是type_kcbh,06就是type_kcbh,01000083就是rdba_kcbh,04就是flg_kcbh,01就是seq_kcbh.。。。。。。。。。后面的依此类推
7FFB32AFEA10 0000044F 00000001 0000472E 000A59FD  [O........G...Y..]     
7FFB32AFEA20 00000000 00320003 01000080 0000FFFF  [......2.........]
7FFB32AFEA30 00000000 00000000 00000000 00008000  [................]
7FFB32AFEA40 000A59FD 000D0001 000001EC 00C0025E  [.Y..........^...]
7FFB32AFEA50 0026004D 0013000A 00000000 00000000  [M.&.............]
7FFB32AFEA60 00000000 00000000 00000000 00000000  [................]
7FFB32AFEA70 00000000 00000000 00000000 00580100  [..............X.]
7FFB32AFEA80 00C2FFFF 037001C8 00000383 1F330058  [......p.....X.3.]
7FFB32AFEA90 039803E5 03491E4B 02AF02FC 02150262  [....K.I.....b...]
7FFB32AFEAA0 1C0D01C8 1B741BC0 1ACF1B1E 1A331A81  [......t.......3.]
7FFB32AFEAB0 199719E6 18FF194B 186118B0 17C81815  [....K.....a.....]
7FFB32AFEAC0 172D1779 168B16DA 15E81636 154C159A  [y.-.....6.....L.]
7FFB32AFEAD0 14AF14FE 140C1464 136C13BB 12CE131A  [....d.....l.....]
7FFB32AFEAE0 12331280 119811E6 10FD1149 105F10AF  [..3.....I....._.]
7FFB32AFEAF0 0FC61013 0F280F77 0E8A0ED9 0DED0E3C  [....w.(.....<...]
7FFB32AFEB00 0D400D91 0C9E0CF0 0BFD0C4C 0B5B0BAC  [..@.....L.....[.]
7FFB32AFEB10 0AC30B0F 0A230A76 097F09D2 08E0092C  [....v.#.....,...]
7FFB32AFEB20 083C0891 07A007EE 07060752 066A06B8  [..<.....R.....j.]
7FFB32AFEB30 05C8061A 05230576 048104CE 00000432  [....v.#.....2...]
7FFB32AFEB40 00000000 00000000 00000000 00000000  [................]
。。。。。。。。。。。。。。。。
7FFB32B00990 32302D33 3A38302D 303A3132 35323A30  [3-02-08:21:00:25]
7FFB32B009A0 4C415605 4E014449 4E014E01 2C05C102  [.VALID.N.N.N...,]
7FFB32B009B0 53030E02 4C055359 52414E55 15C102FF  [...SYS.LUNAR....]
7FFB32B009C0 0503C102 4C424154 71780745 01160802  [....TABLE.xq....]
7FFB32B009D0 7178071A 01160802 3032131A 302D3331  [..xq......2013-0]
7FFB32B009E0 38302D32 3A31323A 323A3030 41560535  [2-08:21:00:25.VA]
7FFB32B009F0 0144494C 014E014E 02C1024E F3C40601  [LID.N.N.N.......]

此条目发表在 Internal 分类目录。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注