"Translated from MoS article" V$backup_datafile shows file#=0 damaged

From:
V$backup_datafile shows corruptions for File #0 (document ID 399113.1)

Suitable for:
Oracle database-enterprise edition-version 9.2.0.1 to 11.1.0.6 [Release 9.2 to 11.1]
Information in this document applies to any platform.

Symptoms:
When querying v$backup_datafile, it is found that for file#=0 rows, their marked_corrupt, media_corrupt, or logically_corrupt columns have non-0 values, such as:

Sql> SELECT marked_corrupt, Media_corrupt, logically_corrupt from      v$backup_datafile WHERE file#=0; Marked_corrupt media_corrupt logically_corrupt--------------------------------------------              0             0                 0           2006           823                 1

There are no corrupted entries in alert, and the DBV tool has not found any damage on datafile.

Reason:
File#=0 is the control file

A value other than 0 does not indicate corruption in the control file, but instead: instead it is a result of the underlying fields being used by RMAN for timestamp and sequence Informati On for autobackups, ie. This is intended behaviour.

The issue was promoted to bug5520904 and was not identified as a bug when the issue was closed

Ideally, the definition of the V$backup_datafile view should exclude file#=0, or Rman should use some other field to store the Timestamp/sequence information--which might be implemented in the future.

Solution:

It is safe to ignore the non-0 value of file#=0 when seen in V$backup_datafile.

Reference:
Bug:5520904-rman with Autobackup on resuls in controlfilebackup MARKED corrupt

"Translated from MoS article" V$backup_datafile shows file#=0 damaged