[Translated from mos] file # = 0 is damaged in V $ BACKUP_DATAFILE,

[Translated from mos] file # = 0 is damaged in V $ BACKUP_DATAFILE,

Source:
V $ BACKUP_DATAFILE Shows before uptions for File #0 (Document ID 399113.1)

Applicable:
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, you find that the marked_0000upt, media_0000upt, or logically_0000upt columns of the row with file # = 0 have non-zero values, for example:

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 corrupt entries in alert, and dbv tool does not find any corruption on datafile.

Cause:
File # = 0 is the control file

A non-zero value does not indicate damage to the control file, but is: instead it is a result of the underlying fields being used by RMAN for timestamp and sequence information for autobackups, ie. this is intended behaviour.

This problem is promoted to bug5520904. when the problem is disabled, it is regarded as not a bug.

Ideally, the definition of the v $ backup_datafile view should exclude file # = 0, or rman should use some other fields to store timestamp/sequence information-which may be implemented in the future.

Solution:

When the non-zero value of file # = 0 is damaged in v $ backup_datafile, it can be safely ignored.

Refer:
BUG: 5520904-rman with autobackup on resuls in controlfilebackup marked upt