Database blocks can be misplaced if there is a pending IO (not submitted to the
storage yet) while the ASM extent is being relocated by an ASM REBALANCE operation.
Soon after the ASM extent is relocated, the previous pending write I/O is
submitted to the storage causing the corruption.

Subsequent SQL operations in the database may fail with error ORA-1578
while trying read the block from the affected segment.

DBVERIFY shows "Bad header found during dbv" with a misplaced block:

Example:

file 27, block 8195 (dba: 0x06c02003) is identified as corrupt
because the content of that block belongs to a different block
rdba: 0x06c01a03(file 27, block 6659)

DBVERIFY - Verification starting : FILE = +GROUP1/data_1.269.586785881
Page 8195 is marked corrupt
Corrupt block relative dba: 0x06c02003 (file 27, block 8195)
Bad header found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x06c01a03 <-- Content is for a different block last change scn: 0x08e4.371d0fa4 seq: 0x2 flg: 0x04 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x0fa40602 check value in block header: 0x7965 computed block checksum: 0x0 <--- Checksum is ok The SCN in the content for the misplaced block can be used to convert it to timestamp (last change scn: 0x08e4.371d0fa4) using function scn_to_timestamp or v$archived_log and check the ASM alert log to identify if there was a rebalance around that time for ASM group GROUP1 as cited by the above example. The patch for this bug needs to applied to both ASM and DB instances. Workaround 1. Apply RMAN Blockrecover or datafile recover. or 2. If this is a table, recreate the table skipping the corrupt block