[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
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/267265/viewspace-2564717/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/267265/viewspace-2564717/