The process of recovering corrupted blocks is one of the features of RMAN. If a database administrator performs a backup using User-Managed Backup, the recovery process will be at the Data File level because User-Managed Restore cannot perform Block Recovery. If an issue occurs in one block within a Data File, it is necessary to restore the entire Data File, and the steps will be as follows:

1. Place the Data File in Offline mode.
2. Restore the Data File from the backup taken before the problem occurred.
3. Recover the Data File.
4. Bring the Data File back Online.

However, if the database administrator uses RMAN, it can identify corrupted blocks during backup operations. Naturally, if User-Managed Backup is used, it can only identify hardware corruption issues because the operating system can detect problems when reading the file during the backup process, but it cannot detect software corruption since the file remains readable by the operating system.

On the other hand, RMAN verifies the contents of the blocks during backup operations, so if a corrupted block is found, the backup process will stop unless you specify otherwise. However, you can continue the backup even if corrupted blocks are found by logging the addresses of the corrupted blocks in the Repository.

Here is the following example that illustrates this:

RMAN>run{

Set maxcorrupt for datafile 5 to 50;

Backup datafile 5;

} 

In this example, the database administrator performed a backup for Data File number 5, even if the number of corrupted blocks reached fifty. The addresses of the corrupted blocks will be stored in the Repository. However, if the number of corrupted blocks exceeds fifty, the backup process will fail.

We can benefit from this feature to continue backup operations even if the backup contains some corrupted blocks. Generally, as a database administrator, you can monitor the corrupted blocks via V$DATABASE_BLOCK_CORRUPTION, which contains the addresses of the blocks that caused the problem, including the file number and block number. The address of the block in the backup will be recorded in V$BACKUP_CORRUPTION if the backup type is a BACKUP SET or V$COPY_CORRUPTION if the backup type is an IMAGE COPY.

In a normal situation, the SET MAXCORRUPT option is not used, which results in the backup failing if it encounters the first block corruption. As a database administrator, you can bypass the block testing during the backup by using certain options. For example, if you want to ignore the integrity of the blocks from physical corruption issues, you can use the command NOCHECKSUM during the backup.

You can also ensure the integrity of the blocks against logical corruption problems by using the command CHECK LOGICAL.

If the database administrator performs backup tasks using User-Managed Backup, they may face some issues when recovering corrupted blocks. If a single block becomes corrupted in one of the Data File files, the entire file must be restored because User-Managed Backup does not support Block Media Recovery.

On the other hand, if the database administrator uses RMAN, they can recover only the corrupted blocks, reducing the time spent in recovery. During the recovery, the database remains open, and the Data File also stays open, allowing users to continue their work, including sessions that need access to the blocks being recovered.

At the moment of recovering corrupted blocks using RMAN, RMAN is provided with a list of blocks that need to be recovered, and it searches for these blocks in the backup files, whether the backup type is Backup Set or Image Copy, and it restores them to the file, then applies the appropriate archive files to implement the changes that occurred.

Typically, a complete recovery is performed, but users may continue to receive error messages 01578-ORA as long as they attempt to access the corrupted blocks before the recovery is completed.

The corrupted blocks are recovered via RMAN using the command BLOCKRECOVER.

RMAN> blockrecover datafile 5 block 5,7;