What happens when you place the tablespace/database in the begin backup mode ?

When you plan of having a using the User Managed Backup method to backup the tablespace, you do the following:

1. Place the tablespace in “begin backup” mode.
2. Use OS commands to copy the datafiles of the tablespace to the disk.
3. Finally remove the tablespace from the backup mode (“end backup”).
But what exactly happens internally at the database level is what makes us curious to know about. The first thing that happens is that a checkpoint occurs and then the datafile header of the tablespace that would be placed in backup mode would be frozen. This means that when the tablespace is in backup mode and when a checkpoint occurs, the checkpoint SCN information would not be updated to the datafile header of
this tablespace.

Being said that the datafile header would be frozen, it does not mean that the DBWn process has no work on the datafile. Oracle behaves in a normal way with DBWn process writing the dirty blocks to the datafile from the database buffer. Oracle does not update the header but increments the Backup Checkpoint SCN of the datafile that is in backup mode.

Most DBAs assume that since the header is frozen, the dirty blocks would not be written to the datafile instead recorded in the redo log buffer and onwards written to the log file due to which there is a huge redo log information generated. Also, many assume that these archives would be used to write the transactions to the datafile of the tablespace once the tablespace is removed from the backup mode. This assumption is false. DBWn as usual keeps writing the modified blocks to the datafile irrespective of tablespace being in backup mode. The reason for Oracle to freeze the datafile header is that the checkpoint SCN at which the header was frozen marks the SCN from which the
recovery needs to be peformed when the datafiles that were backed up (using OS copy) will be restored.

It is true that there would be a good amount of redo information generated when the tablespace is in backup mode but it is not due to the above said assumption. When you place the tablespace in backup mode, Oracle copies the modified block as a whole image in the Redo logs and not just as a change vector. There by leading to increase in the archivelog generation. When the tablespace is normal mode (no backup mode), Oracle only writes the changed bytes (as change vector) to the redo log files.

You might be aware that the OS block is smaller in size when compared to the database block. The reason for copying the entire block when the tablespace is in backup mode is because when you are using the OS copy command to copy the datafile, the datafile is copied by reading the OS blocks and there can be cases where the DBWr process might be writing the modified database block to the datafile (OS block) at the same time. There by the datafile copy might have OS blocks before the DBWn made changes and OS blocks after the DBWn made changes. This is called as fractured blocks. At the time of recovery, the fractured blocks would be resolved by replacing the full image of the block from the archivelogs.

Once the tablespace is removed from the backup mode, the datafile header is updated with the latest Checkpoint SCN.

Here we go !!

COPYRIGHT

© Shivananda Rao P, 2012 to 2018. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Shivananda Rao and http://www.shivanandarao-oracle.com with appropriate and specific direction to the original content.

DISCLAIMER

The views expressed here are my own and do not necessarily reflect the views of any other individual, business entity, or organization. The views expressed by visitors on this blog are theirs solely and may not reflect mine.