Understand the DBV output

Below is a DBV output of a totally corrupted block:
Page 104503 is marked corrupt
Corrupt block relative dba: 0x04019837 (file 16, block 104503)
Bad header found during dbv:
Data in bad block:
type: 201 format: 0 rdba: 0x6bf21791
last change scn: 0x2cd7.f5a66aae seq: 0x7 flg: 0x0e
spare1: 0x63 spare2: 0x81 spare3: 0x8c0e
consistency value in tail: 0x910ff227
check value in block header: 0x4fb6
computed block checksum: 0xe10f


1.type: 201
No this type of block. Mostly we see 6 here, which means : Table/cluster/index segment data block. 

2.format: 0
No this format of  block, below are some possible format.
8i~9i:  all : 0x02
10g  :  2k : 0x62
            4k : 0x82
            8k : 0xa2
          16k : 0xc2
logfile   all : 0x22

3.rdba: 0x6bf21791
rdba(rfile#+block) infor in block header is wrong, it should be the same with below part:
relative dba: 0x04019837 (file 16, block 104503)

4.last change scn: 0x2cd7.f5a66aae seq: 0x7 flg: 0x0e
consistency value in tail: 0x910ff227
facture tail is wrong, should be 0x6aae0e07 (Red part)

5. flg: 0x0e
Wrong. Blow are some posible block flg:
#define KCBHFNEW 0x01 /* new block - zeroed data area */
#define KCBHFDLC 0x02 /* Delayed Logging Change advance SCN/seq */
#define KCBHFCKV 0x04 /* ChecK Value saved-block xor's to zero */
#define KCBHFTMP 0x08 /* Temporary block */
We often see 0x06 in an formated block which means 02+04.

6. spare1: 0x63 spare2: 0x81 spare3: 0x8c0e
Wrong, wrong, wrong, all spare should be 0x0 in any formated block.

7.check value in block header: 0x4fb6
checksum value recorded on block is wrong, should be the same with below part:
computed block checksum: 0xe10f

Gernerally speaking, this data block is totally corruput. It looks like an un-formated block.
Even though there were some data, now are already gone.
More......