This is not really a corruption. This is what data blocks look like just after they have been formatted during tablespace creation (or datafile addition, or extension). All you can conclude from this is that these block have never held any data, although they may have been allocated to a segment above its high water mark.

I was scanning (refreshing my knowledge) through a datafile block dump when I came across some interesting corruption related errors. I have read the information on your site regarding Block Headers, when trying to decode the block dump information. I noticed after the "end of block dump" line for the first block that there is a "corrupt header" entry. The block dump is listed below.

Start dump data blocks tsn: 6 file#: 7 minblk 3 maxblk 5120
buffer tsn: 6 rdba: 0x01c00003 (7/3)
scn: 0x0000.0000a32e seq: 0x01 flg: 0x02 tail: 0xa32e0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump:  0x01c00003
.
.
.
end_of_block_dump
buffer tsn: 6 rdba: 0x00000004 (0/4)
scn: 0x0000.00000000 seq: 0x01 flg: 0x01 tail: 0x00000001
frmt: 0x02 chkval: 0x0000 type: 0x00=unknown
Hex dump of corrupt header 4 = CORRUPT
Dump of memory from 0x173EE60 to 0x173EE74
173EE60 00020000 00000004 00000000 00000101  [................]
173EE70 00000000                             [....]
Dump of memory from 0x173EE74 to 0x173FE5C
173EE70          00000000 00000000 00000000      [............]
173EE80 00000000 00000000 00000000 00000000  [................]
        Repeat 252 times
173FE50 00000000 00000000 00000000           [............]

The same corruption messages occur throughout the entire block dump for the datafile. There are no corruption errors in the alert log as I would have expected. Could you please advise as to whether this is significant and to any possible remedies. The entire block dump is attached (380KB compressed).