Know more about V$BACKUP_CORRUPTION

The V$backup_corruption view shows corrupted blocks discovered during an RMAN backup. But once the corruption on this blocks has been fixed this view is not updated. It can be said that this view stores the blocks that have been corrupted in past.
There is another view to identify the corrupted blocks: V$DATABASE_BLOCK_CORRUPTION. This view will reflect the blocks that were found to be corrupted after the last RMAN backup and is updated after each RMAN backup or backup validate command.
The corrupted blocks found in a backup must be checked in V$DATABASE_BLOCK_CORRUPTION.

In 10.2.0.4, the v$database_block_corruption view is based on v$copy_corruption and v$backup_corruption.The rows for dropped datafile doesn't go away until the datafile# is reused by database and a backup of that file# is taken.This issue was fixed in 11g. To workaround the problem in 10.2.0.4, you will have to clear the v$backup_corruption and v$copy_corruption view on target database.
SQL> execute dbms_backup_restore.resetCfileSection(17); /** clear v$backup_corruption
SQL> execute dbms_backup_restore.resetCfileSection(18); /**clear v$copy_corruption
dbms_backup_restore.resetCfileSection(section_id),    How to get section_id?  In 11g Release 2, if you query the v$controlfile_record_section use the following sql:

SQL> select rownum-1, type from v$controlfile_record_section;

The V$BACKUP_CORRUPTION & V$COPY_CORRUPTION views list corrupt blocks in the backups, not the database itself.
The V$DATABASE_BLOCK_CORRUPTION lists corrupt blocks in the database detected during a variety of RMAN operations. Recovered blocks will still be listed until the next backup is performed.
RMAN keeps corruption information in the control file (v$database_block_corruption, v$backup_corruption). DBV does not.
In addition to the above method used to clear the v$backup_coruption record, you can also use   recreate control file or set control_file_record_keep_time=0 and wait auto clear;
Note Although dbms_backup_restore.resetCfileSection can clean up the records in the control file, But do not do that!, at least  do not execute on the production database before the test, because there are other cases that might make the database crash  .

rman>run{
set MAXCORRUPT for datafile 4 to 10;
backup database; -- or backup datafile 4
}

The SET MAXCORRUPT command specifies the total number of physical and logical corruptions permitted in a datafile during a backup job.The default limit is zero, If the sum of physical and logical corruptions detected for a datafile is no more than its MAXCORRUPT setting, then the BACKUP command completes. If more than MAXCORRUPT corrupt blocks exist, then RMAN terminates without creating output files. when set MAXCORRUPT  and   detect corrupted block then will generate record in v$backup_corruption, the case is meaning that RMAN tolerates datafile 4# detected 10 corrupt blocks .