RE: FUZZY column in V$DATAFILE_HEADER?

FUZZY bit in datafile header means that there may have been writes into a datafile after the last checkpoint. E.g. there may be changes written to datafile with higher SCN than checkpoint_change# stored in datafile header (seen from v$datafile_header.checkpoint_change#).

So any online read-write datafile is essentially a fuzzy one as writes could have happened there. That's the primary thing which is checked when opening up datafiles, if file is fuzzy, then we go to checkpoint_change# and see from which SCN we need to start applying redo.

Btw, with incremental checkpointing it has been optimized a bit - if having a current controlfile, then the checkpoint progress records are read from controlfile and recovery can start from whatever is stated there - reducing recovery time. The point with checkpoint progress records is to avoid full checkpoints to often (which mean updating *every* datablock header - as opposed to updating few controlfile blocks every three seconds).

But if you lose your controlfiles, then you still have to resort to checkpoint_change# in datafile headers and recover from more distant past. Control files are not required for any recovery. All that's needed is available in datafile headers, as long as you know where your files are. Controlfiles just can make recovery easier for us.

Btw, have you ever have been wondering, how Oracle can have predictable results from recovery given the huge complexity of redo records and room for error (e.g. when restoring a year old backup and applying all archivelogs will eventually result in 100% identical database with current one)?

The key is that Oracle actually uses exactly the same kernel functions for recovery and making changes to data blocks. E.g. if we do DML, we are just going to prepare redo records in either PGA or public redo strands in shared pool and then the recovery function will apply the redo records do buffers in buffer cache, making whatever changes are needed, just as with normal recovery.

This means that watch out when having different binaries / patch levels for your standby databases..

Tanel.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Alex Gorbachev
Sent: 10 June 2006 03:29
To: Mark.Bobak_at_il.proquest.com
Cc: Radoulov, Dimitre; Oracle Discussion List Subject: Re: FUZZY column in V$DATAFILE_HEADER?

Well, than it's still not clear what FUZZY means? That datafile is "live" and "prone" to chages?

2006/6/6, Bobak, Mark <Mark.Bobak_at_il.proquest.com>:
> Great note, clear explanation.
>
> Thanks Dimitre!
>
> -----Original Message-----
> From: Radoulov, Dimitre [mailto:cichomitiko_at_gmail.com]
> Sent: Tuesday, June 06, 2006 4:20 PM
> To: Bobak, Mark
> Cc: Oracle Discussion List
> Subject: Re: FUZZY column in V$DATAFILE_HEADER?
>
> > Ok, but my database's tablespaces are NOT in backup mode. So,
> > what's this actually telling me?
>
> MetaLink Note:353606.1 After A Tablespace Hot Backup Ended Fuzzy Value
> Not Set To Null

--
Best regards,
Alex Gorbachev

http://oracloid.blogspot.com
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l