DB_LOST_WRITE_PROTECT,DB_BLOCK_CHECKING,DB_BLOCK_CHECKSUM

Scope
This document is intended for Database Administrators wanting to learn how to prevent and detect from various data block corruptions. 
A corrupt block is a block that has been changed so that it differs from what Oracle Database expects to find. This note covers three data block corruption types:

• In a physical block corruption, which is also called a media corruption, the database does not recognize the block at all: the checksum is invalid, the block contains all zeros, the header and footer of the block do not match or one of the key data block data structure is incorrect such as the data block address (DBA).
• In a logical block corruption, the contents of the block are physically sound and pass the physical block checks; however the block can be logically inconsistent. Examples of logical corruption include corruption of a row piece or index entry.
• Block corruptions caused by stray writes, lost writes or misdirected writes can also cause havoc to your database availability. The data block may be physically or logically correct but in this case the block’s content is older or stale or in the wrong location.

Block corruptions can also be divided into interblock corruption and intrablock corruption:

• In intrablock corruption, the corruption occurs in the block itself and can be either a physical or a logical corruption.
• In an interblock corruption, the corruption occurs between blocks and can only be a logical corruption.

Details
Causes of corrupted blocks
Block corruptions can be caused by various failures including, but not limited to the following:

• Faulty disks and disk controllers
• Faulty memory
• Faulty network components
• Firmware, operating system, volume manager, NFS or third party software defects
• Oracle Database software defects

Block corruptions can be also be caused by operator errors such as copying backups over existing data files or restoring inconsistent database backups.

Configuration Details
Configure at Primary Database:

• DB_BLOCK_CHECKSUM=FULL
• DB_BLOCK_CHECKING=FULL or MEDIUM
• DB_LOST_WRITE_PROTECT=TYPICAL
• Enable Flashback Technologies for fast point-in-time recovery from human errors (e.g. drop table, inadvertent or malicious data changes) and for fast reinstatement of a primary database following failover.

Configure at Data Guard Standby Database:

• DB_BLOCK_CHECKSUM=FULL
• DB_BLOCK_CHECKING=FULL or MEDIUM
• DB_LOST_WRITE_PROTECT=TYPICAL
• Enable Flashback Technologies for fast point-in-time recovery from human errors (e.g. drop table, inadvertent or malicious data changes) and for fast reinstatement of a primary database following failover.
• Use Active Data Guard to enable Automatic Block Repair (Data Guard 11.2 onward).

Review the additional background on each of these settings provided in the sections below, especially if tests show that any of the above recommendations have a greater than acceptable impact on the performance of your application.