Labels

Tuesday, September 27, 2011

What happen during begin backup mode in oracle ?

          Below activity happen during begin backup mode.

  1.   DBWn checkpoints the tablespace (writes out all dirty blocks as of a given SCN)
  2. CKPT stops updating the Checkpoint SCN field in the datafile headers and begins updating the Hot Backup Checkpoint SCN field instead
  3. LGWR begins logging full images of changed blocks the first time a block is changed after being written by DBWn

Those three actions are all that is required to guarantee consistency once the file is restored and recovery is applied. By freezing the Checkpoint SCN, any subsequent recovery on that backup copy of the file will know that it must commence at that SCN. 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.
Note that during hot backup mode, checkpoints to datafiles are not suppressed. Only the main Checkpoint SCN flag is frozen, but CKPT continues to update a Hot Backup Checkpoint SCN in the file header.
There is a confusing side effect of having the Checkpoint SCN frozen at an SCN earlier than the true checkpointed SCN of the database. In the event of a system crash or a shutdown abort during hot backup of a tablespace, the automatic crash recovery routine during startup will look at the file headers, think that the files for that tablespace are out of date, and will suggest that you need to apply old archived redologs in order to bring them back into sync with the rest of the database. Fortunately, no media recovery is necessary. With the database started up in mount mode:
SQL> alter database end backup;
This action will bring the Checkpoint SCN in the file headers in sync with the Hot Backup Checkpoint SCN (which is a true representation of the last SCN to which the datafile is checkpointed). Once you do this, normal crash recovery can proceed during ‘alter database open;’.
By initially checkpointing the datafiles that comprise the tablespace and logging full block images to redo, Oracle guarantees that any blocks changed in the datafile while in hot backup mode will also be present in the archivelogs in case they are ever used for a recovery. Most of the Oracle user community knows that  Oracle generates a greater volume of redo during hot backup mode. This is the result of Oracle logging of full images of changed blocks in these tablespaces. Normally, Oracle writes a change vector to the redologs for every change, but it does not write the whole image of the database block. Full block image logging during backup eliminates the possibility that the backup will contain unresolvable split blocks. To understand this reasoning, you must first understand what a split block is.
Typically, Oracle database blocks are a multiple of O/S blocks. For example, most Unix filesystems have a default block size of 512 bytes, while Oracle’s default block size is 8k. This means that the filesystem stores data in 512 byte chunks, while Oracle performs reads and writes in 8k chunks or multiples thereof. While backing up a datafile, your backup script makes a copy of the datafile from the filesystem, using O/S utilities such as copy, dd, cpio, or OCOPY. As it is making this copy, your process is reading in O/S-block-sized increments. If DBWn happens to be writing a DB block into the datafile at the same moment that your script is reading that block’s constituent O/S blocks, your copy of the DB block could contain some O/S blocks from before the database performed the write, and some from after. This would be a split block. By logging the 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. Upon completion of a recovery, any blocks that got copied in a split state into the backup will have been resolved by overlaying them with the block images from the archivelogs.
All of these mechanisms exist for the benefit of the backup copy of the files and any future recovery. They have very little effect on the current datafiles and the database being backed up. Throughout the backup, server processes read datafiles DBWn writes them, just as when a backup is not taking place. The only difference in the open database files is the frozen Checkpoint SCN, and the active Hot Backup Checkopint SCN. To demonstrate the principle, we can formulate a simple proof:
Create a table and insert a row:
SQL> create table fruit (kind varchar2(32)) tablespace users;
Table created.

SQL> insert into fruit values ('orange');
1 row created.

SQL> commit;
Commit complete.
Force a checkpoint, to flush dirty blocks to the datafiles.
SQL> alter system checkpoint;
System altered.
Get  the file name and block number where the row resides:
SQL> select dbms_rowid.rowid_relative_fno(rowid) file_num,
            dbms_rowid.rowid_block_number(rowid) block_num,
            kind
     from fruit;
FILE_NUM BLOCK_NUM KIND
-------- --------- ------
       4       183 orange

SQL> select name from v$datafile where file# = 4;
NAME
-----------------------------
/u01/oradata/uw01/users01.dbf
Use the dd utility to skip to block 183 and extract the DB block containing the row:
unixhost% dd bs=8k skip=183 count=1 if=/u01/oradata/uw01/users01.dbf | strings
1+0 records in
16+0 records out
orange
Now we put the tablespace into hot backup mode:
SQL> alter tablespace users begin backup;
Tablespace altered.
Update the row, commit, and force a checkpoint on the database.
SQL> update fruit set kind = 'plum';
1 row updated

SQL> commit;
Commit complete.

SQL> alter system checkpoint;
System altered.
Extract the same block. It shows that the DB block has been written to disk during backup mode:
unixhost% dd bs=8k skip=183 count=1 if=/u01/oradata/uw01/users01.dbf | strings
1+0 records in
16+0 records out
plum
orange
Don’t forget to take the tablespace out of backup mode!
SQL> alter tablespace administrator end backup;
Tablespace altered.
It is quite clear from this demonstration that datafiles receive writes even during hot backup mode!

Reference:-

http://www.bluegecko.net/oracle/oracle-tablespace-hot-backup-mode-revisited/

3 comments:

  1. Excellent. But after the update only plum should be visible, where did the orange come from?

    Sayeed Salahuddin

    sayeed.shaikh@gmail.com

    ReplyDelete
    Replies
    1. It is quite clear from this demonstration that datafiles receive writes even during hot backup mode! Thats why both value will come.If we have extract the value after end backup, only plum should show.

      Delete