The "Vimal Mohan" Blog

Oracle, Unix basics & tricks for all those interested in discovering…

Misconception around hot backup

Posted by Vimal Mohan on December 14, 2010

A lot of DBA’s around here might be having a lot of different concepts about how Oracle deals its datafiles during a hot backup process. Well, end of the day we all need to understand and agree with one of them ie: the real Oracle way. I thought its appropriate to explain here on how Oracle deals itself during a hot backup scenario.

Lets see what these different DBA concepts or misconceptions are, before we get the Oracle way of doing things.

Wrong Concept 1: Oracle datafiles are “frozen” during backup mode.
Wrong Concept 2: While the datafiles are “frozen”, changes to the data within these datafiles are written somewhere else, like SGA, UNDO, REDO etc.. and moved to the datafiles after the completion of backup.
Wrong Concept 3: Few of them even have an argument supporting the above wrong concept 2, that the excess amount of redo generated during the hot backup are all changes during the backup and will be moved to the datafile after the hot backup.

Stop right here, no more Wrong Concepts…

Let me now get on to how Oracle works its way through this misconceptions. There are three milestones during for a datafile during its hot backup phase –

  • The corresponding tablespace is checkpointed by DBWn.
  • The Checkpoint SCN marker in the datafile headers cease to increment with checkpoints, but the Hot Backup checkpoint SCN field instead will get updated.
  • LGWR begins logging full images of changed database blocks to the redologs.

By freezing the Checkpoint SCN, any subsequent recovery on that backup copy of the file will know that it must commence at that SCN. And thus, having an old SCN in the file header tells recovery that the file is an old one, and that it should look for the archivelog containing that SCN, and apply recovery starting there. And please note that the datafile “header” is not completely frozen, ie: the Checkpoint SCN is not allowed to make any changes to its state, but the Hot Backup checkpoint SCN field will gets its updates from the CKPT. The same way, the data section of datafile will also receive its update from DBWn as it does during a normal write operation (while not in hot backup mode). Thus please make it crystal clear that the DBWn doesn’t stop writing to datafiles during a hot backup mode, rather it actually continues as before.

By checkpointing the datafile as the first step during a hot backup phase and performing a full block redo write of the first change in a block, Oracle ensures that all changes to the datafile after the start of hot backup will also be available in the redolog for recovery. This is the reason why the redo is more during a hot backup phase of a database. Normally for every change, Oracle writes a change vector to the redologs. But during a hot backup mode, Oracle will write the complete block (not just the change vector) to the redolog. But it should be noted that Oracle doesn’t write the complete block redo everytime a block is changed during this backup mode, it does this just for the first change to the block after the datafile was set to hot backup mode. All the remaining changes to that particular block will be logged just like any other redo change ie: as change vector.

Why does Oracle write a complete first block image? To understand that, we need to know what is a “split block”. As you know, Oracle writes and read in-terms of Oracle blocks, ie: 8k or multiples, which in-turn are multiples of OS blocks. While DBWn does a write on one oracle block within a hot backup mode datafile, our backup process might be in stage which does a copy of the same block to another disk/tape. Since the copy will be done using OS-based block sizes, we might get to a stage where some OS blocks within that backed-up Oracle block might have data before the database write and some after. This situation is called “split block”. By logging the first full block image of the changed block to the redologs, Oracle guarantees that in the event of a recovery, any split blocks that might be in the backup copy of the datafile will be resolved by overlaying them with the full legitimate image of the block from the archivelogs.

RMAN backups don’t suffer from split blocks. RMAN first reads the blocks into its input buffers and while writing the data from inout buffers to output buffers, it checks for split blocks. If it encounters a split block, RMAN will reread that oracle block.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: