|
Whenever you back up datafiles, you have to do one of two things. You
can shut down the database and then back up the datafiles. This option of
a cold backup is a safe option because the datafiles will not be
modified while you are backing them up. The second option is a hot
backup. With a hot backup, it is likely that the datafile will be
modified in the middle of backing it up. When this happens, the
datafile is said to be "inconsistent." You need a mechanism to resolve
that inconsistency. Prior to RMAN, this mechanism was to put the
tablespaces in BACKUP mode. The database froze the SCN (System Change
Number) in the datafile header. Each block of data also has a SCN
noting when that block's contents last changed. On restore, if a
block's SCN is higher than the header's SCN, then the database needs to
resolve any inconsistencies using the archived redo logs. The system
will go through the archived redo logs and ensure all blocks are
consistent with a point in time.
RMAN is not that much different. It uses SCNs on the block level and
the archived redo logs to resolve any inconsistencies in the datafiles
from a hot backup. What RMAN does not require is to put the tablespace
in BACKUP mode, thus freezing the SCN in the header. Rather, RMAN keeps
this information in either your control files or in the RMAN
repository (i.e., Recovery Catalog).
|
