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

[20190124]bbed恢复数据遇到延迟块清除的问题.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.环境:

SCOTT@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.建立测试环境:

SCOTT@book> create table t as select rownum id,'test' name from dual connect by level<=2;

Table created.

SCOTT@book> select rowid,t.* from t;

ROWID                      ID NAME

------------------ ---------- --------------------

AAAWPYAAEAAAAILAAA          1 test

AAAWPYAAEAAAAILAAB          2 test

SCOTT@book> @ rowid AAAWPYAAEAAAAILAAA

    OBJECT       FILE      BLOCK        ROW ROWID_DBA            DBA                  TEXT

---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------

     91096          4        523          0  0x100020B           4,523                alter system dump datafile 4 block 523 ;

SCOTT@book> delete from t where id=1;

1 row deleted.

SCOTT@book> alter system flush buffer_cache;

System altered.

SCOTT@book> alter system flush buffer_cache;

System altered.

--//注:一定要确定对于数据块信息已经刷新到磁盘.IMU环境有时候奇怪,脏块有时候也不会写盘.

SYS@book> @ bh 4 523

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

---------------- ------- ------ ----- ---------- ----- --- ---------- ---------- ---------- ---------- ---------- ---------------- -----------

000000008538CA18       4    523     1 data block free    0          0          0          0          0          0 0000000073D1C000 T

000000008538CA18       4    523     1 data block free    0          0          0          0          0          0 0000000073D22000 T

SCOTT@book> commit ;

Commit complete.

3.使用bbed恢复看看:

BBED> set dba 4,523

        DBA             0x0100020b (16777739 4,523)

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       0x0013

      ub4 kxidsqn                           @72       0x00005816

   struct ktbituba, 8 bytes                 @76

      ub4 kubadba                           @76       0x00c0028e

      ub2 kubaseq                           @80       0x10d5

      ub1 kubarec                           @82       0x0f

   ub2 ktbitflg                             @84       0x0001 (NONE)

   union _ktbitun, 2 bytes                  @86

      sb2 _ktbitfsc                         @86       9

      ub2 _ktbitwrp                         @86       0x0009

   ub4 ktbitbas                             @88       0x00000000

--//可以发现ktbitflg=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 4, Block 523:

current = 0xdcbe, required = 0xdcbe

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

--//我以前测试提到过这样恢复,读取是没有问题,虽然verify时包如上的错误.

SCOTT@book> alter system flush buffer_cache;

System altered.

SCOTT@book> select rowid,t.* from t;

ROWID                      ID NAME

------------------ ---------- --------------------

AAAWPZAAEAAAAILAAA          1 Test

AAAWPZAAEAAAAILAAB          2 Test

SCOTT@book> alter system flush buffer_cache;

System altered.

BBED> x /rnc dba 4,523 *kdbr[0]

rowdata[11]                                 @8177

-----------

flag@8177: 0x2c (KDRHFL, KDRHFF, KDRHFH)

lock@8178: 0x00

cols@8179:    2

col    0[2] @8180: 1

col    1[4] @8183: Test

BBED> p dba 4,523 ktbbh.ktbbhitl[1]

struct ktbbhitl[1], 24 bytes                @68

   struct ktbitxid, 8 bytes                 @68

      ub2 kxidusn                           @68       0x000a

      ub2 kxidslt                           @70       0x0013

      ub4 kxidsqn                           @72       0x00005816

   struct ktbituba, 8 bytes                 @76

      ub4 kubadba                           @76       0x00c0028e

      ub2 kubaseq                           @80       0x10d5

      ub1 kubarec                           @82       0x0f

   ub2 ktbitflg                             @84       0xa000 (KTBFUPB, KTBFCOM)

   union _ktbitun, 2 bytes                  @86

      sb2 _ktbitfsc                         @86       3

      ub2 _ktbitwrp                         @86       0x0003

   ub4 ktbitbas                             @88       0x1774676a

--//OK,可以发现没有问题.即使现在还报错:

BBED> verify dba 4,523

DBVERIFY - Verification starting

FILE = /mnt/ramdisk/book/users01.dbf

BLOCK = 523

Block Checking: DBA = 16777739, Block Type = KTB-managed data block

data header at 0x13efe7c

kdbchk: the amount of space used is not equal to block size

        used=44 fsc=0 avsp=8029 dtl=8064

Block 523 failed with check code 6110

--//如果使用system表空间呢?下一篇测试看看.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/267265/viewspace-2564716/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/267265/viewspace-2564716/