[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

[20190124]bbed恢復資料遇到延遲塊清除的問題2.txt

相關文章