《bbed恢复数据遇到延迟块清除的问题》由会员分享，可在线阅读，更多相关《bbed恢复数据遇到延迟块清除的问题（16页珍藏版）》请在金锄头文库上搜索。
1、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
2、 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
3、.环境: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 select rowid,t.* from t;ROWID ID NAME- - -AAAWPcAAB
4、AAAAnpAAA 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表空间SYSTEMbook delete from t where id=1;1 row deleted.SYSTEMbook alter system flush buffe
5、r_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_N
6、AME- - - - - - - - - - - - - -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 00
7、000000683AA000SYSTEMbook commit ;Commit complete.-/这个时候对应数据块已经不在缓存了,做延迟块提交.SYSTEMbook alter system flush buffer_cache;System altered.3.使用bbed恢复看看:BBED set dba 1,2537 DBA 0x004009e9 (4196841 1,2537)BBED x /rnc *kdbr0rowdata11 8177-flag8177: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH)lock8178: 0x02cols8179:
8、 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 (N
9、ONE) 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
