What happens during a hot backup

What happens during 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 reaction to this statement is a very loud "What?" followed by crossed arms and a really stern 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 every 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 these 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 redologs. Instead of recording how it changed a particular block the change vector), it will log the entire image of the block after he change. This is why the redologs grow 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 even 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.