Tuesday, July 5, 2011

Hot/Online backup

Hot/Online backup

Hot or On-line Backups - If the database is available and in ARCHIVELOG mode,
set the tablespaces into backup mode and backup their files.
Also remember to backup the control files and archived redo log files.

Basic procedure for a hot backup
The following pseudo code(!) demonstrates how a hot backup is taken on Oracle.
for ts in tablespaces
  alter tablespace $ts begin backup
  for df in datafiles of $ts
    cp $df $SAVE/$df
    alter database datafile '$df' end backup
  alter tablespace end backup
alter system switch logfile
alter database backup controlfile to trace

when you place a tablespace in hot backup mode, oracle
 will log extra information for a block the
first time it is modified whilst the tablespace it
belongs to is in hot backup mode.

Say tablespace X containing file 55 is put into hot
backup mode.

You modify block 123 in file 55 -- this generates redo. 
Oracle will log the ENTIRE block image
instead of just changed bytes.

You commit.

Someone else modifies blocks 123 and 124 in file 55.
Oracle will log just changed bytes for block 123 but
a full block image copy for 124.

in hot backup mode only 2 things are different:

o the first time a block is changed in a datafile that
is in hot backup mode, the ENTIRE BLOCK is written to
the redo log files, not just the changed bytes.  
Normally only the changed bytes (a redo vector)
is written. In hot backup mode, the entire block is
logged the FIRST TIME.  This is because you can get
into a situation where the process copying the datafile
 and DBWR are working on the same block simultaneously. 
 Lets say they are and the OS blocking read factor is 512bytes
 (the OS reads 512 bytes from disk at a time).
 The backup program goes to read an 8k Oracle block.  
The OS gives it 4k.  Meanwhile --
DBWR has asked to rewrite this block.  
the OS schedules the DBWR write to occur right now.  
The entire 8k block is rewritten. 
 The backup program starts running again
(multi-tasking OS here) and reads the last 4k of
the block.  The backup program has now gotten an
impossible block -- the head and tail are from two
points in time.  We cannot deal with that during
recovery.  Hence, we log the entire block image so
that during recovery, this block is totally rewritten
from redo and is consistent with itself at
least.  We can recover it from there.

o the datafile headers which contain the SCN of the
last completed checkpoint are NOT updated while a file
 is in hot backup mode.  This lets the recovery process
 understand what archive redo log files might be needed
 to fully recover this file.

1 comment: