bbed恢复数据遇到延迟块清除的问题--//最近使用bbed做一个恢复测试,遇到一个问题.以前我的测试如果修改删除flag从0x3c=>0x
2c,sumapply后,使用verify提示类似如下:BBED>verifyDBVERIFY-Verification
startingFILE=/mnt/ramdisk/book/users01.dbfBLOCK=523BlockChec
king:DBA=16777739,BlockType=KTB-manageddatablockdatahea
derat0x7fddbce4127ckdbchk:theamountofspaceusedisnotequa
ltoblocksizeused=44fsc=9avsp=8020dtl=8064Block523failed
withcheckcode6110--//如果偷懒,可以跳过这步.但是如果遇到提交时数据块不在缓存或者更新涉及的块太多,可能
会出现许多块不做块清除,oracle执行的是--//快速块清除操作.这样一些块在下一次touch时才修改对应ITL操以及对应记录的
lock信息才会更新.--//对于这样的块,恢复时恢复会遇到什么问题呢?通过例子说明问题.--//前面测试在用户的表空间,测试读取
是没有任何问题的,但是如果在系统表空间呢?1.环境:SYSTEM@book>@ver1PORT_STRING????
??????VERSION????BANNER--------------------------------
----------------------------------------------------------------
----------------------------x86_64/Linux2.4.xx??????11.2.0
.4.0??OracleDatabase11gEnterpriseEditionRelease11.2.0.4.
0-64bitProduction2.建立测试环境:SYSTEM@book>createtabletasselec
trownumid,''test''namefromdualconnectbylevel<=2;Tablecreat
ed.SYSTEM@book>selectrowid,t.fromt;ROWID??????????
?IDNAME------------------------------------------------AAAWPc
AABAAAAnpAAA?????1testAAAWPcAABAAAAnpAAB?????2testSYS
TEM@book>@rowidAAAWPcAABAAAAnpAAAOBJECT???FILE???BLOCK
????ROWROWID_DBA??????DBA?????????TEXT-------
------------------------------------------------------------
-----------------------------------------------------?91100??
???1???2537?????0?0x4009E9?????1,2537????
???altersystemdumpdatafile1block2537--//建立在system表空间.www
.gw638.cnSYSTEM@book>deletefromtwhereid=1;1rowdeleted.SYST
EM@book>altersystemflushbuffer_cache;Systemaltered.SYSTEM@bo
ok>altersystemflushbuffer_cache;Systemaltered.SYSTEM@book>a
ltersystemflushbuffer_cache;Systemaltered.--//注:我的测试支持IMU,必须检
查数据块不在缓存在提交.SYS@book>@bh12537HLADDR???????DBARFIL??
DBABLK???CLASSCLASS_TYPE????STATE??????TCHCR_SCN
_BASCR_SCN_WRPCR_UBA_FILCR_UBA_BLKCR_UBA_SEQBA???????
OBJECT_NAME-------------------------------------------------
------------------------------------------------------------
----------------------------------------------------000000008
4DA5540?????1???2537?????1datablock????xcur
????????1?????0?????0?????0?????0??
???00000000067F80000T0000000084DA5540?????1???2537?
????1datablock????free????????0?????0??
???0?????0?????0?????00000000067F82000T000000
0084DA5540?????1???2537?????1datablock????fr
ee????????0?????0?????0?????0?????0?
????00000000067C3C0000000000084DA5540?????1???2537
?????1datablock????free????????0?????0?
????0?????0?????0?????000000000683AA000SYSTEM@
book>commit;Commitcomplete.--//这个时候对应数据块已经不在缓存了,做延迟块提交.SYSTEM@
book>altersystemflushbuffer_cache;Systemaltered.3.使用bbed恢复看看
:www.44226.netBBED>setdba1,2537DBA??????0x004009e9(41
968411,2537)BBED>x/rnc?kdbr[0]rowdata[11]?????????
???????@8177-----------flag@8177:0x3c(KDRHFL,KDRHFF,KD
RHFD,KDRHFH)lock@8178:0x02cols@8179:??0--//使用ITL槽2.看看ITL槽2(从0
开始)的情况:BBED>p?ktbbh.ktbbhitl[1]structktbbhitl[1],24bytes??
??????@68?structktbitxid,8bytes????????@68ub2
kxidusn?????????????@68???0x000aub2kxidslt?
????????????@70???0x0007ub4kxidsqn??????
???????@72???0x00005810?structktbituba,8bytes???
?????@76ub4kubadba?????????????@76???0x
00c002c1ub2kubaseq?????????????@80???0x10d5u
b1kubarec?????????????@82???0x19?ub2ktbitflg
??????????????@84???0x0002(NONE)?union_ktbitu
n,2bytes?????????@86sb2_ktbitfsc??????????
??@86???9ub2_ktbitwrp????????????@86???
0x0009?ub4ktbitbas??????????????@88???0x00000
000--//可以发现ktbitflg=0x0002,表示没有提交.有点奇怪为什么是0x0002,应该是0x0001,--//kt
bitbas=0x00000000,也就是没有scn相关信息写入.BBED>assignoffset8177=0x2c;Wa
rning:contentsofpreviousBIFILEwillbelost.Proceed?(Y/N)y
ub1rowdata[0]???????????????@8177??0x2cBBED>x
/rnckdbr[0]rowdata[11]????????????????@8177--
---------flag@8177:0x2c(KDRHFL,KDRHFF,KDRHFH)lock@8178:0x02c
ols@8179:??2col??0[2]@8180:1col??1[4]@8183:testBBED>su
mapplyCheckvalueforFile1,Block2537:current=0xf770,requi
red=0xf770BBED>verifyDBVERIFY-VerificationstartingFILE=/m
nt/ramdisk/book/system01.dbfBLOCK=2537BlockChecking:DBA=419
6841,BlockType=KTB-manageddatablockdataheaderat0x7fc6238
19274kdbchk:theamountofspaceusedisnotequaltoblocksize
used=44fsc=9avsp=8028dtl=8072Block2537failedwithcheckcode
6110--//我以前测试提到过这样恢复,读取是没有问题,虽然verify时包如上的错误.SYSTEM@book>select
rowid,t.fromt;selectrowid,t.fromtERRORatline1:ORA-00
607:Internalerroroccurredwhilemakingachangetoadatabloc
kORA-00600:internalerrorcode,arguments:[kdBlkCheckError],[1
],[2537],[6110],[],[],[],[],[],[],[],[]--//注意错误号6110,与b
bed的错误号一致.SYS@book>altersystemflushbuffer_cache;Systemaltere
d.4.继续使用bbed修复:www.f-1.ccBBED>setdba1,2537DBA??????0x0
04009e9(41968411,2537)BBED>assignktbbh.ktbbhitl[1].ktbitflg=0
x2002ub2ktbitflg????????????????@84???0x2002
(KTBFUPB)BBED>sumapplyCheckvalueforFile1,Block2537:curre
nt=0x68f3,required=0x68f3BBED>verifyDBVERIFY-Verification
startingFILE=/mnt/ramdisk/book/system01.dbfBLOCK=2537BlockC
hecking:DBA=4196841,BlockType=KTB-manageddatablockFound
blockalreadymarkedcorrupted--//在执行altersystemflushbuffer_ca
che;后,块已经标识为坏块.BBED>assignkcbh.seq_kcbh=0x01ub1seq_kcbh???
?????????????@14???0x01BBED>assigntailchk=0x000
00601ub4tailchk????????????????@8188??0x0000
0601BBED>sumapplyCheckvalueforFile1,Block2537:current=0
x68f3,required=0x68f3BBED>verifyDBVERIFY-Verificationstart
ingFILE=/mnt/ramdisk/book/system01.dbfBLOCK=2537BlockCheckin
g:DBA=4196841,BlockType=KTB-manageddatablockdataheader
at0x1251074kdbchk:theamountofspaceusedisnotequaltobloc
ksizeused=46fsc=10avsp=8026dtl=8072Block2537failedwithch
eckcode6110--//现在还是出现一样的错误.继续测试.SYSTEM@book>selectrowid,t.f
romt;ROWID???????????IDNAME------------------------
------------------------AAAWPhAABAAAAnpAAA?????1testAAAWPh
AABAAAAnpAAB?????2test--//也就是当提交时如果出现延迟块提交时,对于system表空间数据块,
删除数据的恢复必须恢复提交标识加上U标识.--//这样下次提取时,oracle就认为数据已经提交了.--//换一句话讲,oracl
e对于system表空间检查更加严格,在修复数据块时对于系统表空间的数据文件特别要引起注意.--//还有一点疑问我仅仅删除1条为什
么ktbbh.ktbbhitl[1].ktbitflg记录的是0x0002呢?SYSTEM@book>altersystem
dumpdatafile1block2537;Systemaltered.Blockheaderdump:?0x0
04009e9?ObjectidonBlock?Y?seg/obj:0x163e3?csc:0x03.17747f2
6?itc:3?flg:O?typ:1-DATA?fsl:2?fnx:0x0ver:0x01?Itl?
????Xid?????????Uba????Flag?Lck????Scn/Fs
c0x01?0xffff.000.00000000?0x00000000.0000.00?C---??0?scn0
x0003.17747f260x02?0x000a.019.00005825?0x00c0018a.10d6.11?--U
-??2?fsc0x0009.00000000~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~0x03?0x0000.000.000000
00?0x00000000.0000.00?----??0?fsc0x0000.00000000bdba:0x004
009e9data_block_dump,dataheaderat0x7f8c13c60274===============tsiz:0x1f88hsiz:0x16pbl:0x7f8c13c60274?76543210flag=--------ntab=1nrow=2frre=-1fsbo=0x16fseo=0x1f72avsp=0x1f5ctosp=0x1f670xe:pti[0]?nrow=2?offs=00x12:pri[0]offs=0x1f7d0x14:pri[1]offs=0x1f72block_row_dump:tab0,row0,@0x1f7dtl:11fb:--H-FL--lb:0x2?cc:2col?0:[2]?c102col?1:[4]?54657374tab0,row1,@0x1f72tl:11fb:--H-FL--lb:0x0?cc:2col?0:[2]?c103col?1:[4]?54657374end_of_block_dumpEnddumpdatablockstsn:0file#:1minblk2537maxblk2537 |
|
