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

[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/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值