Inside a Hot Backup

What happens during a hot backup is widely misunderstood. Many people believe
that while a tablespace is in backup mode, the datafiles within that tablespace
are not written to. They believe that all changes to these files are kept in the
redologs until the tablespace is taken out of backup mode, at which point all
changes are applied to the datafiles just as they are during a media recovery.
Although this explanation is easier to understand (and swallow) than how things
really work, it is absolutely not how hot backups work in Oracle. A common react
ion
to this statement is a very loud "What?" followed by crossed arms and a really s
tern look.
(I reacted the same way the first time I heard it.) "How could I safely back up
these
files if they are changing as I'm backing them up?" Don't worry -- Oracle has it
all
under control. Remember that every Oracle datafile has an SCN that is changed ev
ery
time an update is made to the file. Also remember that every time Oracle makes a
change
to a datafile, it records the vector of that change in the redolog. Both of thes
e
behaviors change during hot backups. When a tablespace is put into backup mode,
the following three things happen:
1. Oracle checkpoints the tablespace, flushing all changes from shared memory to
disk.
2. The SCN markers for each datafile in that tablespace are "frozen" at their
current values. Even though further updates will be sent to the datafiles, the
SCN markers will not be updated until the tablespace is taken out of backup mode
.
3. Oracle switches to logging full images of changed database blocks to the redo
logs.
Instead of recording how it changed a particular block (the change vector), it w
ill
log the entire image of the block after the change. This is why the redologs gro
w
at a much faster rate while hot backups are going on.
After this happens, your backup program works happily through this datafile,
backing it up block by block. Since the file is being updated as you are reading
it, it may read blocks just before they're changed, after they're changed, or ev
en
while they're changing. Suppose that your filesystem block size is 4 KB, and
Oracle's block size is 8 KB. Your backup program will be reading in increments
of 4 KB. It could back up the first 4 KB of an 8-KB Oracle data block before a
change is made to that block, then back up the last 4 KB of that file after a
change has been made. This results in what Oracle calls a "split block". However
,
when your backup program reaches the point of the datafile that contains the SCN
,
it will back up that block the way it looked when the backup began, since that
block is frozen. Once you take the tablespace out of backup mode, the SCN marker
is advanced to the current value, and Oracle switches back to logging change
vectors instead of full images of changed blocks. How does Oracle straighten
this out during media recovery? It's actually very simple. You use your backup
program to restore the datafile. When you attempt to start the instance, Oracle
looks at the datafile and sees an old SCN value. Actually, it sees the value
that the SCN marker had before the hot backup began. When you enter recover
datafile, it begins to apply redo against this datafile. Since the redologs
contain a complete image of every block that changed during your backup, it
can rebuild this file to a consistent state, regardless of when you backed
up a particular block of data. Let's create a table called tapes in the
tablespace test, insert the value "DLT" into it, and force a checkpoint:
SQL> create table tapes (name varchar2(32)) tablespace test;
Table created.
SQL> insert into tapes values ('DLT');
1 row created
SQL> commit;
Commit complete.
SQL> alter system checkpoint;
System altered.