oracle判斷block corruption的依據是啥?

warehouse發表於2010-05-17
原文網址 : http://blog.itpub.net/19602/viewspace-1033653/
OracleBloC

oracle判斷block corruption的依據是啥也一直是困擾我的問題，今天看到一puber再次提到類似這樣的問題：

http://www.itpub.net/viewthread.php?tid=1303542&pid=15794986&page=1&extra=#pid15794986

搜了下老熊的文章


再次模擬了block corruption，不過由於對block結構瞭解的有些，所以要
準確的徹底搞清楚oracle判斷block corruption的依據目前還比較困難，下面記錄
一個大致的過程

[@more@]

--==========================
C:>sqlplus

SQL*Plus: Release 11.1.0.6.0 - Production on 星期一 5月 17 12:25:11 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.


連線到:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create tablespace test datafile 'G:APPOWNERORADATAORCLtest.dbf' size 1
m;

表空間已建立。

SQL> col file_name format a60
SQL> select file_id,file_name from dba_data_files;

FILE_ID FILE_NAME
---------- ------------------------------------------------------------
1 G:APPOWNERORADATAORCLSYSTEM01.DBF
2 G:APPOWNERORADATAORCLSYSAUX01.DBF
3 G:APPOWNERORADATAORCLUNDOTBS01.DBF
4 G:APPOWNERORADATAORCLUSERS01.DBF
5 G:APPOWNERORADATAORCLTEST.DBF

SQL> show user
USER 為 "TEST"
SQL> create table tt tablespace test as select * from dba_objects where object_i
d<=1000;

表已建立。

SQL> select min(rowid),max(rowid) from tt;

MIN(ROWID) MAX(ROWID)
------------------ ------------------
AAAD+GAAFAAAAAMAAA AAAD+GAAFAAAAAXABB

SQL> select dbms_rowid.rowid_relative_fno(min(rowid)) min_fno,dbms_rowid.rowid_b
lock_number(min(rowid)) min_bno , dbms_rowid.rowid_relative_fno(max(rowid)) max_
fno,dbms_rowid.rowid_block_number(max(rowid)) max_bno from tt;

MIN_FNO MIN_BNO MAX_FNO MAX_BNO
---------- ---------- ---------- ----------
5 12 5 23
SQL> alter system dump datafile 5 block min 12 block max 23;

系統已更改。

--==========================
BH (0x11FE921C) file#: 5 rdba: 0x0140000f (5/15) class: 1 ba: 0x11CCA000
set: 11 bsz: 8192 bsi: 0 sflg: 0 pwc: 121 lid: 0x00000000,0x00000000
dbwrid: 0 obj: 16262 objn: 16262 tsn: 5 afn: 5
hash: [0x2154769C,0x2154769C] lru: [0x11FE934C,0x11FE91AC]
ckptq: [NULL] fileq: [NULL] objq: [0x1F35ACA4,0x11FE920C]
st: XCURRENT md: NULL tch: 2
flags: only_sequential_access
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 5 rdba: 0x0140000f (5/15)
scn: 0x0000.002f650a seq: 0x02 flg: 0x04 tail: 0x650a0602
frmt: 0x02 chkval: 0xda1a type: 0x06=trans data
--==========================
--上面的dump資訊是block沒有損壞時的情況
SQL> shutdown immediate
ORA-01031: 許可權不足
SQL> connect as sysdba
已連線。
SQL> shutdown immediate
資料庫已經關閉。
已經解除安裝資料庫。
ORACLE 例程已經關閉。
SQL> startup mount
ORACLE 例程已經啟動。

Total System Global Area 313860096 bytes
Fixed Size 1332892 bytes
Variable Size 188746084 bytes
Database Buffers 117440512 bytes
Redo Buffers 6340608 bytes
資料庫裝載完畢。
SQL> select 15*8192 from dual;

15*8192
----------
122880
--尋找第15個block的位置並且透過ultraedit來修改第15個block的header，把
他們都該為a，修改之後自動變成了61：
SQL> alter database open;

資料庫已更改。

SQL> connect
已連線。
SQL> select count(*) from tt;
select count(*) from tt
*
第 1 行出現錯誤:
ORA-01578: ORACLE 資料塊損壞 (檔案號 5, 塊號 15)
ORA-01110: 資料檔案 5: 'G:APPOWNERORADATAORCLTEST.DBF'


SQL> hostname
SP2-0042: 未知命令 "hostname" - 其餘行忽略。
SQL> host
Microsoft Windows XP [版本 5.1.2600]
(C) 版權所有 1985-2001 Microsoft Corp.

C:>dbv file=G:APPOWNERORADATAORCLTEST.DBF

DBVERIFY: Release 11.1.0.6.0 - Production on 星期一 5月 17 13:04:54 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.

DBVERIFY - 開始驗證: FILE = G:APPOWNERORADATAORCLTEST.DBF
頁 15 標記為損壞
Corrupt block relative dba: 0x0140000f (file 5, block 15)
Bad header found during dbv:
Data in bad block:
type: 97 format: 1 rdba: 0x61616161
last change scn: 0x6161.61616161 seq: 0x61 flg: 0x61
spare1: 0x61 spare2: 0x61 spare3: 0x6161
consistency value in tail: 0x650a0602
check value in block header: 0x6161
block checksum disabled

DBVERIFY - 驗證完成

檢查的頁總數: 128
處理的頁總數 (資料): 11
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 11
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 105
標記為損壞的總頁數: 1
流入的頁總數: 0
加密的總頁數 : 0
最高塊 SCN : 3106062 (0.3106062)

C:>
--======================
Corrupt block relative dba: 0x0140000f (file 5, block 15)
Bad header found during buffer read
Data in bad block:
type: 97 format: 1 rdba: 0x61616161
last change scn: 0x6161.61616161 seq: 0x61 flg: 0x61
spare1: 0x61 spare2: 0x61 spare3: 0x6161
consistency value in tail: 0x650a0602
check value in block header: 0x6161
block checksum disabled
Reread of rdba: 0x0140000f (file 5, block 15) found same corrupted data
DDE rules only execution for: ORA 1110
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
----- DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
Successfully dispatched
----- (Action duration in csec: 0) -----
----- END DDE Actions Dump -----
Incident 16977 created, dump file: g:appownerdiagrdbmsorclorclincidentincdir_16977orcl_ora_5404_i16977.trc
ORA-01578: ORACLE 資料塊損壞 (檔案號 5, 塊號 15)
ORA-01110: 資料檔案 5: 'G:APPOWNERORADATAORCLTEST.DBF'

DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident)
ORA-01110: 資料檔案 5: 'G:APPOWNERORADATAORCLTEST.DBF'
Incident 16978 created, dump file: g:appownerdiagrdbmsorclorclincidentincdir_16978orcl_ora_5404_i16978.trc
ORA-01578: ORACLE 資料塊損壞 (檔案號 5, 塊號 15)
ORA-01110: 資料檔案 5: 'G:APPOWNERORADATAORCLTEST.DBF'


*** 2010-05-17 13:05:41.187
Start dump data blocks tsn: 5 file#:5 minblk 15 maxblk 15
Block dump from cache:
Dump of buffer cache at level 4 for tsn=5, rdba=20971535
Block dump from disk:
buffer tsn: 5 rdba: 0x61616161 (389/2187617)
scn: 0x6161.61616161 seq: 0x61 flg: 0x61 tail: 0x650a0602
frmt: 0x01 chkval: 0x6161 type: 0x61=unknown
--======================
目前我們看到的結果是block header獲得的資訊和tail的不一致，嘗試修改
tail使其和block header獲得資訊一致：
--嘗試修改tail的值：
修改前tail：02 06 0a 65
修改後tail：61 61 61 61
修改tail之後一致了都是61,重啟db之後再次查詢tt的資料驗證block 15：
SQL> select count(*) from tt;
select count(*) from tt
*
第 1 行出現錯誤:
ORA-01578: ORACLE 資料塊損壞 (檔案號 5, 塊號 15)
ORA-01110: 資料檔案 5: 'G:APPOWNERORADATAORCLTEST.DBF'


SQL> alter system dump datafile 5 block 15;

系統已更改。

SQL>
--=======================
Start dump data blocks tsn: 5 file#:5 minblk 15 maxblk 15
Block dump from cache:
Dump of buffer cache at level 4 for tsn=5, rdba=20971535
BH (0x14BF7A7C) file#: 5 rdba: 0x0140000f (5/15) class: 1 ba: 0x14B06000
set: 9 bsz: 8192 bsi: 0 sflg: 2 pwc: 3 lid: 0x00000000,0x00000000
dbwrid: 0 obj: 16262 objn: 16262 tsn: 5 afn: 5
hash: [0x2154769C,0x2154769C] lru: [0x215BF358,0x13BF974C]
lru-flags: moved_to_tail on_auxiliary_list
ckptq: [NULL] fileq: [NULL] objq: [NULL]
st: FREE md: NULL tch: 0
flags:
cr pin refcnt: 0 sh pin refcnt: 0
Buffer contents not dumped
Block dump from disk:
buffer tsn: 5 rdba: 0x61616161 (389/2187617)
scn: 0x6161.61616161 seq: 0x61 flg: 0x61 tail: 0x61616161
frmt: 0x01 chkval: 0x6161 type: 0x61=unknown
Hex dump of corrupt header 4 = CORRUPT
--========================
從block header獲得資訊和tail處獲得資訊看起來一致（當然僅僅是數值上一致），
oracle依然把這個block標記為corruption...
--=========================
根據老熊描述的再次模擬一下，這次直接修改block 16的seq_kcbh的值：
按照老熊的描述seq_kcbh偏移14位佔用1個位元組，所以找到這個位置
之後把原來的00改為ff，啟動db之後透過dbv檢查發現oracle確實標記了16號block為
corruption,看來seq_kcbh就是oracle的block corruption標記。
C:>dbv file=G:APPOWNERORADATAORCLTEST.DBF

DBVERIFY: Release 11.1.0.6.0 - Production on 星期一 5月 17 14:24:22 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.

DBVERIFY - 開始驗證: FILE = G:APPOWNERORADATAORCLTEST.DBF
頁 15 標記為損壞
Corrupt block relative dba: 0x0140000f (file 5, block 15)
Bad header found during dbv:
Data in bad block:
type: 170 format: 2 rdba: 0xaaaaaaaa
last change scn: 0xaaaa.aaaaaaaa seq: 0xaa flg: 0xaa
spare1: 0xaa spare2: 0xaa spare3: 0x6161
consistency value in tail: 0x61616161
check value in block header: 0x61a1
block checksum disabled

頁 16 標記為損壞
Corrupt block relative dba: 0x01400010 (file 5, block 16)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x01400010
last change scn: 0xff00.002f650a seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x650a0602
check value in block header: 0x889
computed block checksum: 0xff00

DBVERIFY - 驗證完成

檢查的頁總數: 128
處理的頁總數 (資料): 10
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 11
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 105
標記為損壞的總頁數: 2
流入的頁總數: 0
加密的總頁數 : 0
最高塊 SCN : 3106062 (0.3106062)

C:>
--=====================
再次把16號block的seq_kcbh改成原來的00之後用dbv檢查發現16號block好了
顯然seq_kcbh就是block corruption的標記，但是oracle標記block corruption的依據
我依然比較困惑...
C:>dbv file=G:APPOWNERORADATAORCLTEST.DBF

DBVERIFY: Release 11.1.0.6.0 - Production on 星期一 5月 17 14:40:41 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.

DBVERIFY - 開始驗證: FILE = G:APPOWNERORADATAORCLTEST.DBF
頁 15 標記為損壞
Corrupt block relative dba: 0x0140000f (file 5, block 15)
Bad header found during dbv:
Data in bad block:
type: 170 format: 2 rdba: 0xaaaaaaaa
last change scn: 0x00aa.aaaaaaaa seq: 0xaa flg: 0xaa
spare1: 0xaa spare2: 0xaa spare3: 0x6161
consistency value in tail: 0x61616161
check value in block header: 0x61a1
block checksum disabled

DBVERIFY - 驗證完成

檢查的頁總數: 128
處理的頁總數 (資料): 11
失敗的頁總數 (資料): 0
處理的頁總數 (索引): 0
失敗的頁總數 (索引): 0
處理的頁總數 (其它): 11
處理的總頁數 (段) : 0
失敗的總頁數 (段) : 0
空的頁總數: 105
標記為損壞的總頁數: 1
流入的頁總數: 0
加密的總頁數 : 0
最高塊 SCN : 3106062 (0.3106062)

C:>

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/19602/viewspace-1033653/，如需轉載，請註明出處，否則將追究法律責任。

相關文章