[20190124]bbed恢复数据遇到延迟块清除的问题2.txt

来源：这里教程网时间：2026-03-03 12:54:24 作者：

[20190124]bbed恢复数据遇到延迟块清除的问题2.txt --//最近使用bbed做一个恢复测试,遇到一个问题.以前我的测试如果修改删除flag从0x3c=>0x2c,sum apply后,使用verify提示类似如下: BBED> verify DBVERIFY - Verification starting FILE = /mnt/ramdisk/book/users01.dbf BLOCK = 523 Block Checking: DBA = 16777739, Block Type = KTB-managed data block data header at 0x7fddbce4127c kdbchk: the amount of space used is not equal to block size used=44 fsc=9 avsp=8020 dtl=8064 Block 523 failed with check code 6110 --//如果偷懒,可以跳过这步.但是如果遇到提交时数据块不在缓存或者更新涉及的块太多,可能会出现许多块不做块清除,oracle执行的是 --//快速块清除操作.这样一些块在下一次touch时才修改对应ITL操以及对应记录的lock信息才会更新. --//对于这样的块,恢复时恢复会遇到什么问题呢?通过例子说明问题. --//前面测试在用户的表空间,测试读取是没有任何问题的,但是如果在系统表空间呢? 1.环境: SYSTEM@book> @ ver1 PORT_STRING VERSION BANNER ------------------------------ -------------- -------------------------------------------------------------------------------- x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production 2.建立测试环境: SYSTEM@book> create table t as select rownum id,'test' name from dual connect by level<=2; Table created. SYSTEM@book> select rowid,t.* from t; ROWID ID NAME ------------------ ---------- -------------------- AAAWPcAABAAAAnpAAA 1 test AAAWPcAABAAAAnpAAB 2 test SYSTEM@book> @ rowid AAAWPcAABAAAAnpAAA OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT ---------- ---------- ---------- ---------- -------------------- -------------------- ---------------------------------------- 91100 1 2537 0 0x4009E9 1,2537 alter system dump datafile 1 block 2537 --//建立在system表空间. SYSTEM@book> delete from t where id=1; 1 row deleted. SYSTEM@book> alter system flush buffer_cache; System altered. SYSTEM@book> alter system flush buffer_cache; System altered. SYSTEM@book> alter system flush buffer_cache; System altered. --//注:我的测试支持IMU,必须检查数据块不在缓存在提交. SYS@book> @ bh 1 2537 HLADDR DBARFIL DBABLK CLASS CLASS_TYPE STATE TCH CR_SCN_BAS CR_SCN_WRP CR_UBA_FIL CR_UBA_BLK CR_UBA_SEQ BA OBJECT_NAME ---------------- ---------- ---------- ---------- ------------------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- ----------- 0000000084DA5540 1 2537 1 data block xcur 1 0 0 0 0 0 0000000067F80000 T 0000000084DA5540 1 2537 1 data block free 0 0 0 0 0 0 0000000067F82000 T 0000000084DA5540 1 2537 1 data block free 0 0 0 0 0 0 0000000067C3C000 0000000084DA5540 1 2537 1 data block free 0 0 0 0 0 0 00000000683AA000 SYSTEM@book> commit ; Commit complete. --//这个时候对应数据块已经不在缓存了,做延迟块提交. SYSTEM@book> alter system flush buffer_cache; System altered. 3.使用bbed恢复看看: BBED> set dba 1,2537 DBA 0x004009e9 (4196841 1,2537) BBED> x /rnc *kdbr[0] rowdata[11] @8177 ----------- flag@8177: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH) lock@8178: 0x02 cols@8179: 0 --//使用ITL槽2.看看ITL槽2(从0开始)的情况: BBED> p ktbbh.ktbbhitl[1] struct ktbbhitl[1], 24 bytes @68 struct ktbitxid, 8 bytes @68 ub2 kxidusn @68 0x000a ub2 kxidslt @70 0x0007 ub4 kxidsqn @72 0x00005810 struct ktbituba, 8 bytes @76 ub4 kubadba @76 0x00c002c1 ub2 kubaseq @80 0x10d5 ub1 kubarec @82 0x19 ub2 ktbitflg @84 0x0002 (NONE) union _ktbitun, 2 bytes @86 sb2 _ktbitfsc @86 9 ub2 _ktbitwrp @86 0x0009 ub4 ktbitbas @88 0x00000000 --//可以发现ktbitflg=0x0002,表示没有提交.有点奇怪为什么是0x0002,应该是0x0001, --//ktbitbas=0x00000000,也就是没有scn相关信息写入. BBED> assign offset 8177=0x2c; Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y ub1 rowdata[0] @8177 0x2c BBED> x /rnc *kdbr[0] rowdata[11] @8177 ----------- flag@8177: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8178: 0x02 cols@8179: 2 col 0[2] @8180: 1 col 1[4] @8183: test BBED> sum apply Check value for File 1, Block 2537: current = 0xf770, required = 0xf770 BBED> verify DBVERIFY - Verification starting FILE = /mnt/ramdisk/book/system01.dbf BLOCK = 2537 Block Checking: DBA = 4196841, Block Type = KTB-managed data block data header at 0x7fc623819274 kdbchk: the amount of space used is not equal to block size used=44 fsc=9 avsp=8028 dtl=8072 Block 2537 failed with check code 6110 --//我以前测试提到过这样恢复,读取是没有问题,虽然verify时包如上的错误. SYSTEM@book> select rowid,t.* from t; select rowid,t.* from t * ERROR at line 1: ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [kdBlkCheckError], [1], [2537], [6110], [], [], [], [], [], [], [], [] --//注意错误号6110,与bbed的错误号一致. SYS@book> alter system flush buffer_cache; System altered. 4.继续使用bbed修复: BBED> set dba 1,2537 DBA 0x004009e9 (4196841 1,2537) BBED> assign ktbbh.ktbbhitl[1].ktbitflg=0x2002 ub2 ktbitflg @84 0x2002 (KTBFUPB) BBED> sum apply Check value for File 1, Block 2537: current = 0x68f3, required = 0x68f3 BBED> verify DBVERIFY - Verification starting FILE = /mnt/ramdisk/book/system01.dbf BLOCK = 2537 Block Checking: DBA = 4196841, Block Type = KTB-managed data block Found block already marked corrupted --//在执行alter system flush buffer_cache;后,块已经标识为坏块. BBED> assign kcbh.seq_kcbh=0x01 ub1 seq_kcbh @14 0x01 BBED> assign tailchk=0x00000601 ub4 tailchk @8188 0x00000601 BBED> sum apply Check value for File 1, Block 2537: current = 0x68f3, required = 0x68f3 BBED> verify DBVERIFY - Verification starting FILE = /mnt/ramdisk/book/system01.dbf BLOCK = 2537 Block Checking: DBA = 4196841, Block Type = KTB-managed data block data header at 0x1251074 kdbchk: the amount of space used is not equal to block size used=46 fsc=10 avsp=8026 dtl=8072 Block 2537 failed with check code 6110 --//现在还是出现一样的错误.继续测试. SYSTEM@book> select rowid,t.* from t; ROWID ID NAME ------------------ ---------- -------------------- AAAWPhAABAAAAnpAAA 1 test AAAWPhAABAAAAnpAAB 2 test --//也就是当提交时如果出现延迟块提交时,对于system表空间数据块,删除数据的恢复必须恢复提交标识加上U标识. --//这样下次提取时,oracle就认为数据已经提交了. --//换一句话讲,oracle对于system表空间检查更加严格,在修复数据块时对于系统表空间的数据文件特别要引起注意. --//还有一点疑问我仅仅删除1条为什么ktbbh.ktbbhitl[1].ktbitflg记录的是0x0002呢? SYSTEM@book> alter system dump datafile 1 block 2537; System altered. Block header dump: 0x004009e9 Object id on Block? Y seg/obj: 0x163e3 csc: 0x03.17747f26 itc: 3 flg: O typ: 1 - DATA fsl: 2 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0003.17747f26 0x02 0x000a.019.00005825 0x00c0018a.10d6.11 --U- 2 fsc 0x0009.00000000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000 bdba: 0x004009e9 data_block_dump,data header at 0x7f8c13c60274 =============== tsiz: 0x1f88 hsiz: 0x16 pbl: 0x7f8c13c60274 76543210 flag=-------- ntab=1 nrow=2 frre=-1 fsbo=0x16 fseo=0x1f72 avsp=0x1f5c tosp=0x1f67 0xe:pti[0] nrow=2 offs=0 0x12:pri[0] offs=0x1f7d 0x14:pri[1] offs=0x1f72 block_row_dump: tab 0, row 0, @0x1f7d tl: 11 fb: --H-FL-- lb: 0x2 cc: 2 col 0: [ 2] c1 02 col 1: [ 4] 54 65 73 74 tab 0, row 1, @0x1f72 tl: 11 fb: --H-FL-- lb: 0x0 cc: 2 col 0: [ 2] c1 03 col 1: [ 4] 54 65 73 74 end_of_block_dump End dump data blocks tsn: 0 file#: 1 minblk 2537 maxblk 2537