Comment below.
HJR
--
----------------------------------------------
Resources for Oracle: http://www.hjrdba.com
===============================
"Svend Jensen" <Master_at_OracleCare.Com> wrote in message
news:3C3F469B.50303_at_OracleCare.Com...
> Howard J. Rogers wrote:
>
>
> I would like to clearify a few things here. Seems some confusion on how
> hot BU are made and work.
> Old fassion alter tblsp X begin backup, freeses the SCN number in all
> datafiles belonging to tblsp X. When U then copy the datafiles, the copy
> util might make 'fuzzy' copies of datablocks, ie. the util takes a chunk
> of data and copies it, this chunk can end in the middle of a datablock,
> and while the copy process is busy, the database writer updates the very
> same 'divided' block, thus the util will make a copy of a datablock
> where the two halves are from different 'timezones' ie. internaly
> inconsistent. Thats why the hole datablock is copied to redolog the
> first time it is changed, if the tablespace is in begin backup mode, and
> thus generating a lot more redo while in backup mode. Having a sound
> consistent copy of the block in the redolog, makes it possible to
> recover from fuzzy copies. When the tblsp is set back in normal mode,
> the SCN in datafile headers are updated to 'current' SCN.
> The 'frozen' SCN in the datafile headers tell the recovery process when
> to start to apply redo's - ending up with a (hopefuly) consistent file.
That last bit is not actually true. Setting the tablespace back into normal
mode does NOT cause the headers to be updated to the current SCN. Only the
next checkpoint does that (which is why the standard documentation advises
that you issue a checkpoint the moment you take a tablespace out of hot
backup mode.
>
> RMAN uses the same mechanism as a users shadow processes, it makes
> consistent reads of (hole) datablocks, with latching, locking and all
> the stuff and then there is no need to make extra block copies to redolog.
>
That's not quite true, either. RMAN guarantees consistent data blocks
because it knows when a block is undergoing change, and simply re-reads the
block as often as necessary until a stable image is obtained.
> I dont know what mechanism Veritas BU exec uses.
>
>
> /svend jensen
>
>
Received on Sat Jan 12 2002 - 04:39:06 CST
