RE: FUZZY column in V$DATAFILE_HEADER?
- From: "Tanel Poder" <tanel.poder.003@xxxxxxx>
- To: <gorbyx@xxxxxxxxx>, <Mark.Bobak@xxxxxxxxxxxxxxx>
- Date: Sat, 10 Jun 2006 12:41:59 +0800
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Alex Gorbachev
Sent: 10 June 2006 03:29
To: Mark.Bobak@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx>:
> Great note, clear explanation.
>
> Thanks Dimitre!
>
> -----Original Message-----
> From: Radoulov, Dimitre [mailto:cichomitiko@xxxxxxxxx]
> 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
