Block Corruption and how to identify corrupted blocks

Block corruption is while the data is being written to the data blocks, if the write to the block fails abruptly, which means there is a partial write in the block, may be because of power disruption or I/O problem, leaving no time for header to be updated, or row data to be populated, oracle leaves the block corrupt.In case of block corruption you can normally use the database unless you try to read that particular block, against which it shoots up the block corruption error.Generally block corruption occurs if write fails on the block, when the transaction is being committed. You can find detail information about block corruption in alert.log file

block corruption can happens at

1)Physical Level corruption (which means media corrupt)
2)Logical Level corruption (which means soft corrupt)

Physical corruption can be caused by defected memory boards, controllers or broken sectors on a hard disk;

Logical corruption can among other reasons be caused by an attempt to recover through a NOLOGGING action.

To Differentiate between both the corruption levels (logical and physical)

Logical corruption is header – footer – that is one of the checks, yes (it is looking for fractured blocks and when it hits one, it’ll re-read it, that is why there is no need for “alter tablespace begin backup” with rman)

Physical corruption is “we cannot read the block from disk, something is physically preventing us from doing so”

The methods to detect Block corruptions are

1) DBVerify utility

2) Block checking parameters (DB_BLOCK_CHCEKSUM) – In Oracle 10g db_block_checksum value TYPICAL which should be TRUE and db_block_checking value FULL should be TRUE.

3) ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE SQL statement

4) RMAN BACKUP command with THE VALIDATE option