Bug 8339404 - ORA-1578 - Blocks can be misplaced in ASM during a REBALANCE

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 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  
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