oracle判断block corruption的依据是啥?

oracle判断block corruption的依据是啥也一直是困扰我的问题，今天看到一puber再次提到类似这样的问题：

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

搜了下老熊的文章

http://www.laoxiong.net/how_to_mark_corruption_block_and_recovery.html
再次模拟了block corruption，不过由于对block结构了解的有些，所以要
准确的彻底搞清楚oracle判断block corruption的依据目前还比较困难，下面记录
一个大致的过程

[@more@]

--==========================
C:>sqlplus test/test@orcl

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 sys/system@orcl 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 test/test@orcl
已连接。
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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/19602/viewspace-1033653/