Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> FUZZY column in V$DATAFILE_HEADER?
What does the FUZZY column in V$DATAFILE_HEADER really mean?
I thought I knew, but now I'm not so sure.....I assumed it meant one of
two things:
1.) datafile is in backup mode.
2.) datafile was restored from a conventional (non-RMAN) backup that
was taken while the datafile was NOT in backup mode. (If this were the
case, it would not be possible to do any type of recovery, complete or
incomplete, due to ORA-1547 and ORA-1194 (Recover succeeded but open
resetlogs will get error below, file needs more recovery to be
consistent.))
However, I have a database, 9.2.0.6 Enterprise edition, 2-node RAC
cluster, where I see the following:
SQL> select status,count(*) from v$backup group by status;
STATUS COUNT(*)
------------------ ----------
NOT ACTIVE 346
SQL> select fuzzy,count(*) from v$datafile_header group by fuzzy;
FUZ COUNT(*)
--- ----------
YES 346
So, what does that mean?? Specifically, what does FUZZY='YES' really
mean?
Clearly, no datafiles are in backup mode, the database is open and up, and has been for several weeks, so these files are by no means in need of recovery, and yet they all say FUZZY='YES'....?
Oracle's Backup and Recovery Concepts Manual defines "fuzzy file" as "A datafile that contains at least one block with an SCN more recent than the checkpoint SCN in its header. For example, this situation occurs when Oracle updates a datafile that is in backup mode <http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96519/glo ssary.htm#432100> . A fuzzy file that is restored always requires recovery. "
Ok, but my database's tablespaces are NOT in backup mode. So, what's this actually telling me?
-Mark
--
Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning
For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. --Richard P. Feynman, 1918-1988
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jun 06 2006 - 14:17:37 CDT