In fact, it is not within the capacity of the Database Administrator to prevent Block Corruption from occurring, but they can detect these corrupt blocks and perhaps mitigate the effects of these corrupt blocks.

Database users must have a good strategy for backup copies that the Database Administrator can utilize to address the issue of corrupt blocks.

Of course, Block Corruption can occur at the level of the Online Redo Log File, Archive Redo Log File, or Control File, but what concerns us here is only the Block Corruption that occurs at the Data File level. This is because the Database Administrator can avoid the problem of corrupt blocks at the Control File, Archive Redo Log File, and Online Redo Log File through Multiplexing.

Generally, there are two types of Block Corruption: the first type is Media Corruption, which refers to a problem that occurs in a block, causing the contents of this block to be inconsistent with the Oracle format. This means that this block is of no use.

The second type is Logical Corruption, also known as Software Corruption. In this type, the block conforms to the Oracle format, and the Header Area is correct, as well as the Data Area, but the contents of this block are internally inconsistent. However, even Software Corruption is often related to Hardware, but in rare conditions, it can occur due to the creation of an Oracle block that is inconsistent.

Overall, there are more variables in the variable file of the database that are related to the topic of Block Corruption, including the variable DB_BLOCK_CHECKSUM, which takes the value TRUE as a default value. This variable helps you detect the damages that occurred due to storage on the disk. At the moment of the DBWn process, which writes the block to the disk, this variable performs a check on the blocks and incorporates that into the header.

When the Server Process attempts to read that block, the Checksum performs a comparison, meaning that any issue that occurred between DBWn and the attempt to read that block will be discovered. Therefore, Oracle recommends that the variable DB_BLOCK_CHECKSUM maintain the default value of TRUE, so any problem that occurs as long as the block is on the disk, or during writing or reading that block, will be detected.

However, generally, even if this variable takes the value FALSE, it will still be active during the System Tablespace.

Also, the variable DB_BLOCK_CHECKING, which takes the value FALSE as a default value, helps you detect damages that occurred due to a problem in memory. If the value TRUE is assigned to this variable, it will affect performance. Therefore, Oracle recommends that this variable take the default value FALSE as long as there are no specific issues related to problems that occurred in memory.