Explanation/Reference:
Explanation:
V$DATABASE_BLOCK_CORRUPTION displays information about database blocks that were corrupted after the last backup.
------------------------------------------------------------------------------- BACKUP...VALIDATE Scans the specified files and verifies their contents, testing whether this file can be backed up and whether the data blocks are corrupt. RMAN creates no output files.
This option is equivalent to using the VALIDATE command on the database files specified in the backup. If you do not specify CHECK LOGICAL, then BACKUP..VALIDATE checks for physical corruption only. If you specify CHECK LOGICAL, then BACKUP VALIDATE checks for both physical and logical corruption.
RMAN populates the V$DATABASE_BLOCK_CORRUPTION view with any corruptions that it finds.
You can use the SET MAXCORRUPT command to set a limit for the number of corrupt blocks tolerated during the backup validation. The default is zero.
If you execute BACKUP INCREMENTAL with VALIDATE, then the behavior depends on whether block change tracking is enabled. If change tracking is enabled, then RMAN validates only changed blocks; otherwise, RMAN validates all blocks in the files included in the backup.
Note: You cannot validate backups of backup sets.
------------------------------------------------------------------------------- The following prerequisites apply to RECOVER BLOCK: (link) The target database must run in ARCHIVELOG mode and be open or mounted with a current control

file.
RMAN can only recover blocks marked media corrupt. The V$DATABASE_BLOCK_CORRUPTION

view indicates which blocks in a file were marked corrupt since the most recent BACKUP or BACKUP
... VALIDATE command was run against the file.
The backups of the data files containing the corrupt blocks must be full backups and not proxy

backups. If only proxy backups exist, then you can restore them to a nondefault location on disk, in which case RMAN considers them data file copies. You can then use the data file copies for block media recovery. RMAN can use only archived redo log files for recovery. Block media recovery cannot survive a missing or inaccessible log, although it can sometimes survive missing or inaccessible records (see Oracle Database Backup and Recovery User's Guide).
For RMAN to be able to search the flashback logs for good copies of corrupt blocks, Flashback

Database must be enabled on the target database. For RMAN to be able to search a standby database for good copies of corrupt blocks, the target database must be associated with a physical standby database in a Data Guard environment. In addition, the physical standby database must be open read- only in managed recovery.