今天一大早例行数据库检查,在Rock的aler.log日志里发现以下问题:

Mon Sep 14 22:02:11 2009
Hex dump of (file 11, block 41091) in trace file /oracle/oraprod/proddb/10.2.0/admin/PROD_prod/udump/prod_ora_17341.trc
Corrupt block relative dba: 0x02c0a083 (file 11, block 41091)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x02c0a083
last change scn: 0x056d.2b6d3f2c seq: 0x8 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xe88b0601
check value in block header: 0x57af
computed block checksum: 0xd7ac
Reread of blocknum=41091, file=/oracle/oraprod/proddata/sysaux01.dbf. found valid data

检查备份,备份是正确完成的,没出错,查metalink找到一个相似的答案,应该match吧:

fact: Oracle Server - Enterprise Edition 8
fact: Oracle Server - Enterprise Edition 9
fact: Recovery Manager (RMAN)
symptom: Fractured block found during backup up datafile
symptom: Reread of blocknum found some corrupt data
symptom: Analyze table validate structure cascade returns no errors
change: NOTE ROLE:

The messages are of the form

Reread of blocknum=36256, file=/pdscdata/pdsclive/data1/dispatch_data_large2.
dbf. found same corrupt data
***
Corrupt block relative dba: 0xfc008dc0 (file 63, block 36288)
Fractured block found during backing up datafile
Data in bad block -
 type: 0 format: 0 rdba: 0x00000000
 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
 consistency value in tail: 0x53494e53
 check value in block header: 0x0, block checksum disabled
 spare1: 0x0, spare2: 0x0, spare3: 0x0
cause: RMAN backups of datafile are being performed while the datafile is
involved in heavy I/O.

RMAN reads Oracle blocks from disk. If it finds that the block is fractured, 
which means it is being actively used, it performs a reread of the block. If 
that fails again then the block is assumed to be corrupt.

By identifying the object that these blocks belong to by following
Handling Oracle Block Corruptions in Oracle7/8/8i and 
performing an analyze .. validate structure cascade on the object involved you 
can confirm that 
the object is not corrupt.



fix:

Run the backups when the tablespace has less I/O activity.

[@more@]