一套AIX上的10.2.0.3系统，在rman备份期间告警日志出现如下记录:
======================= alert log record ============================
Hex dump of (file 35, block 1087687) in trace file /oracle/product/10.2.0/admin/MS/udump/ms_ora_103548.trc
Corrupt block relative dba: 0x08d098c7 (file 35, block 1087687)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x08d098c7
last change scn: 0x0006.44443e06 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x6d910601
check value in block header: 0xc0b0
computed block checksum: 0x4286
Reread of blocknum=1087687, file=/dev/vx/rdsk/oradgMS/lv_ms_DB31. found valid data
=========== trace information for process 103548 ========================
Corrupt block relative dba: 0x08d098c7 (file 35, block 1087687)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x08d098c7
last change scn: 0x0006.44443e06 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x6d910601
check value in block header: 0xc0b0
computed block checksum: 0x4286
Reread of blocknum=1087687, file=/dev/vx/rdsk/oradgMS/lv_ms_DB31. found valid data
可以看到该块的type为6，下面列出了Oracle 9.2中已经存在的各种块类型:
| Type |
Description |
| 1 |
KTU UNDO HEADER |
| 2 |
KTU UNDO BLOCK |
| 3 |
KTT SAVE UNDO HEADER |
| 4 |
KTT SAVE UNDO BLOCK |
| 5 |
DATA SEGMENT HEADER |
| 6 |
trans data |
| 7 |
Unknown |
| 8 |
Unknown |
| 9 |
Unknown |
| 10 |
DATA SEGMENT FREE LIST BLOCK |
| 11 |
Unknown |
| 12 |
DATA SEGMENT HEADER WITH FREE LIST BLOCKS |
| 13 |
Compatibility segment |
| 14 |
KTU UNDO HEADER W/UNLIMITED EXTENTS |
| 15 |
KTT SAVE UNDO HEADER W/UNLIMITED EXTENTS |
| 16 |
DATA SEGMENT HEADER - UNLIMITED |
| 17 |
DATA SEGMENT HEADER WITH FREE LIST BLKS - UNLIMITED |
| 18 |
EXTENT MAP BLOCK |
| 19 |
Unknown |
| 20 |
Unknown |
| 21 |
Unknown |
| 22 |
DATA SEGMENT FREE LIST BLOCK WITH FREE BLOCK COUNT |
| 23 |
BITMAPPED DATA SEGMENT HEADER |
| 24 |
BITMAPPED DATA SEGMENT FREELIST |
| 25 |
BITMAP INDEX BLOCK |
| 26 |
BITMAP BLOCK |
| 27 |
LOB BLOCK |
| 28 |
KTU BITMAP UNDO HEADER - LIMITED EXTENTS |
| 29 |
KTFB Bitmapped File Space Header |
| 30 |
KTFB Bitmapped File Space Bitmap |
| 31 |
TEMP INDEX BLOCK |
| 32 |
FIRST LEVEL BITMAP BLOCK |
| 33 |
SECOND LEVEL BITMAP BLOCK |
| 34 |
THIRD LEVEL BITMAP BLOCK |
| 35 |
PAGETABLE SEGMENT HEADER |
| 36 |
PAGETABLE EXTENT MAP BLOCK |
| 37 |
EXTENT MAP BLOCK OF SYSTEM MANAGED UNDO SEGMENT |
| 38 |
KTU SMU HEADER BLOCK |
| 39 |
Unknown |
| 40 |
PAGETABLE MANAGED LOB BLOCK |
| 41 |
Unknown |
| 42 |
Unknown |
| 43 |
Unknown |
| 44 |
Unknown |
| 45 |
Unknown |
| 46 |
Unknown |
| 47 |
Unknown |
表和索引的块均可能为type 6的trans data；也就是说rman在备份期间读取到该数据块，并在初次读取时发现该块断裂了(Fractured)，但Fractured并不代表块就真的corrupted了；从告警日志看rman在初次读取发现该块Fractured后，又再次读取时发现数据块已经恢复正常(found valid data)。所以上述告警日志并代表所列出的数据块存在讹误，很有可能是该数据块所在数据文件在备份期间发生了剧烈的IO操作，当rman读取到该数据块时可能存储正在对其进行写的操作，所以rman在第一次读取时认为该快断裂了(Fractured)；之后rman对该块进行reread发现"断裂"现象已不存在，而"Corrupt block"仅仅是一种假象；针对上述问题可以对表或索引进行进一步的analyze..validate操作以确保不存在坏块。
同时上述"Corrupt block误报"现象极有可能是因为在Rman备份期间个别数据文件的IO过于活跃所致(如频繁的dml操作)，建议在磁盘活跃度低的时间段运行rman备份工作。
参考文档:
Fractured Block Messages in Alert.log During RMAN Backup of Datafile
* 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.
