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

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

[20190125]bbed恢复数据遇到延迟块清除的问题3.txt --//昨天分别做了2个测试,链接: http://blog.itpub.net/267265/viewspace-2564716/=>[20190124]bbed恢复数据遇到延迟块清除的问题.txt http://blog.itpub.net/267265/viewspace-2564717/=>[20190124]bbed恢复数据遇到延迟块清除的问题2.txt --//我测试完感觉,oracle对于system表空间检查更加严格,在修复数据块时对于系统表空间的数据文件特别要引起注意. --//仔细想想system表空间oracle使用mssm,一般用户的表空间是assm(多数用户应该选择这个模式),是否这两种模式导致的问题呢? --//自己还是测试看看. 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 CREATE TABLESPACE mssm DATAFILE '/mnt/ramdisk/book/mssm01.dbf' SIZE 40M AUTOEXTEND ON NEXT 16M MAXSIZE UNLIMITED LOGGING EXTENT MANAGEMENT LOCAL AUTOALLOCATE BLOCKSIZE 8K SEGMENT SPACE MANAGEMENT MANUAL FLASHBACK ON; --//使用SEGMENT SPACE MANAGEMENT MANUAL. 2.建立测试环境: SCOTT@book> create table t tablespace mssm as select rownum id,'test' name from dual connect by level<=5; Table created. SCOTT@book> select rowid,t.* from t; ROWID ID NAME ------------------ ---------- -------------------- AAAWP2AAHAAAACBAAA 1 test AAAWP2AAHAAAACBAAB 2 test AAAWP2AAHAAAACBAAC 3 test AAAWP2AAHAAAACBAAD 4 test AAAWP2AAHAAAACBAAE 5 test SCOTT@book> @ rowid AAAWP2AAHAAAACBAAA OBJECT FILE BLOCK ROW ROWID_DBA DBA TEXT ---------- ---------- ---------- ---------- -------------------- -------------------- ---------------------------------------- 91126 7 129 0 0x1C00081 7,129 alter system dump datafile 7 block 129 ; --//建立在mssm表空间,使用mssm模式. SCOTT@book> delete from t where id=2; 1 row deleted. SYS@book> alter system flush buffer_cache; System altered. SYS@book> @ bh 7 129 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 ---------------- ------- ------ ----- ---------- ----- --- ---------- ---------- ---------- ---------- ---------- ---------------- ----------- 0000000084D14E60 7 129 1 data block free 0 0 0 0 0 0 0000000069694000 T 0000000084D14E60 7 129 1 data block free 0 0 0 0 0 0 0000000069696000 T 0000000084D14E60 7 129 1 data block free 0 0 0 0 0 0 000000006D890000 0000000084D14E60 7 129 1 data block free 0 0 0 0 0 0 000000006D892000 0000000084D14E60 7 129 1 data block free 0 0 0 0 0 0 000000007068A000 --//注:我的测试支持IMU,必须检查数据块不在缓存在再提交. SCOTT@book> commit ; Commit complete. --//这个时候对应数据块已经不在缓存了,做延迟块提交. 3.使用bbed恢复看看: BBED> set dba 7,129 DBA 0x01c00081 (29360257 7,129) BBED> x /rnc *kdbr[1] rowdata[33] @8166 ----------- flag@8166: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH) lock@8167: 0x02 cols@8168: 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 0x0021 ub4 kxidsqn @72 0x00005305 struct ktbituba, 8 bytes @76 ub4 kubadba @76 0x00c01833 ub2 kubaseq @80 0x10dc ub1 kubarec @82 0x0d 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. --//注:我前面测试视乎mssm表空间会出现这样的情况. --//ktbitbas=0x00000000,也就是没有scn相关信息写入. BBED> assign offset 8166=0x2c; Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y ub1 rowdata[0] @8166 0x2c BBED> x /rnc *kdbr[1] rowdata[33] @8166 ----------- flag@8166: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8167: 0x02 cols@8168: 2 col 0[2] @8169: 2 col 1[4] @8172: test BBED> sum apply Check value for File 7, Block 129: current = 0xf398, required = 0xf398 BBED> verify DBVERIFY - Verification starting FILE = /mnt/ramdisk/book/mssm01.dbf BLOCK = 129 Block Checking: DBA = 29360257, Block Type = KTB-managed data block data header at 0x7f3667031274 kdbchk: the amount of space used is not equal to block size used=83 fsc=9 avsp=7989 dtl=8072 Block 129 failed with check code 6110 --//我以前测试提到过这样恢复,读取是没有问题,虽然verify时包如上的错误. SCOTT@book> select rowid,t.* from t; ROWID ID NAME ------------------ --- ----- AAAWP2AAHAAAACBAAA 1 test AAAWP2AAHAAAACBAAB 2 test AAAWP2AAHAAAACBAAC 3 test AAAWP2AAHAAAACBAAD 4 test AAAWP2AAHAAAACBAAE 5 test --//OK没有任何问题,也就是说明oracle对于system表空间检测更加严格. SYS@book> alter system flush buffer_cache; System altered. --//再次通过bbed观察: BBED> p ktbbh.ktbbhitl[1] struct ktbbhitl[1], 24 bytes @68 struct ktbitxid, 8 bytes @68 ub2 kxidusn @68 0x000a ub2 kxidslt @70 0x0021 ub4 kxidsqn @72 0x00005305 struct ktbituba, 8 bytes @76 ub4 kubadba @76 0x00c01833 ub2 kubaseq @80 0x10dc ub1 kubarec @82 0x0d ub2 ktbitflg @84 0x8000 (KTBFCOM) union _ktbitun, 2 bytes @86 sb2 _ktbitfsc @86 3 ub2 _ktbitwrp @86 0x0003 ub4 ktbitbas @88 0x17752c40 --//已经修改提交了. BBED> x /rnc *kdbr[1] rowdata[33] @8166 ----------- flag@8166: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8167: 0x00 cols@8168: 2 col 0[2] @8169: 2 col 1[4] @8172: test --//lock标识也清除了.