bbed恢复数据遇到延迟块清除的问题
bbed恢复数据遇到延迟块清除的问题-/最近使用bbed做一个恢复测试,遇到一个问题.以前我的测试如果修改删除flag从0x3c=>0x2c,sum apply后,使用verify提示类似如下:BBED> verifyDBVERIFY - Verification startingFILE = /mnt/ramdisk/book/users01.dbfBLOCK = 523Block Checking: DBA = 16777739, Block Type = KTB-managed data blockdata header at 0x7fddbce4127ckdbchk: the amount of space used is not equal to block size used=44 fsc=9 avsp=8020 dtl=8064Block 523 failed with check code 6110-/如果偷懒,可以跳过这步.但是如果遇到提交时数据块不在缓存或者更新涉及的块太多,可能会出现许多块不做块清除,oracle执行的是-/快速块清除操作.这样一些块在下一次touch时才修改对应ITL操以及对应记录的lock信息才会更新.-/对于这样的块,恢复时恢复会遇到什么问题呢?通过例子说明问题.-/前面测试在用户的表空间,测试读取是没有任何问题的,但是如果在系统表空间呢?1.环境:SYSTEMbook> ver1PORT_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 Production2.建立测试环境:SYSTEMbook> create table t as select rownum id,'test' name from dual connect by level<=2;Table created.SYSTEMbook> select rowid,t.* from t;ROWID ID NAME- - -AAAWPcAABAAAAnpAAA 1 testAAAWPcAABAAAAnpAAB 2 testSYSTEMbook> 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表空间.www.gw638.cnSYSTEMbook> delete from t where id=1;1 row deleted.SYSTEMbook> alter system flush buffer_cache;System altered.SYSTEMbook> alter system flush buffer_cache;System altered.SYSTEMbook> alter system flush buffer_cache;System altered.-/注:我的测试支持IMU,必须检查数据块不在缓存在提交.SYSbook> bh 1 2537HLADDR 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 T0000000084DA5540 1 2537 1 data block free 0 0 0 0 0 0 0000000067F82000 T0000000084DA5540 1 2537 1 data block free 0 0 0 0 0 0 0000000067C3C0000000000084DA5540 1 2537 1 data block free 0 0 0 0 0 0 00000000683AA000SYSTEMbook> commit ;Commit complete.-/这个时候对应数据块已经不在缓存了,做延迟块提交.SYSTEMbook> alter system flush buffer_cache;System altered.3.使用bbed恢复看看:www.44226.netBBED> set dba 1,2537 DBA 0x004009e9 (4196841 1,2537)BBED> x /rnc *kdbr0rowdata11 8177-flag8177: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)lock8178: 0x02cols8179: 0-/使用ITL槽2.看看ITL槽2(从0开始)的情况:BBED> p ktbbh.ktbbhitl1struct ktbbhitl1, 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) yub1 rowdata0 8177 0x2cBBED> x /rnc *kdbr0rowdata11 8177-flag8177: 0x2c (KDRHFL, KDRHFF, KDRHFH)lock8178: 0x02cols8179: 2col 02 8180: 1col 14 8183: testBBED> sum applyCheck value for File 1, Block 2537:current = 0xf770, required = 0xf770BBED> verifyDBVERIFY - Verification startingFILE = /mnt
