What happens when A Tablespace/database was Kept in Begin Backup Mode (Doc ID 469950.1)

Goal

This document explains in detail on what happens when a tablespace/datafile was kept in hot backup/begin backup mode.

Solution

To perform online/hot backup We had to put the tablespace in begin backup mode followed by copying the datafiles And then putting the tablespace to end backup.

In 8i, 9i we had to put each tablespace individually in Begin/end backup mode to perform the online backup. From 10g onwards the entire database can is put in Begin/end backup mode.

Make sure, the database is in Archivelog mode

Example:

Performing a single tablespace backup

+ sql>alter tablespace system begin backup;

+ Copy The corresponding datafiles using appropriate O/S commands.

+ sql>alter tablespace system end backup;

performing a full database backup (starting from 10g)

+ sql> ALTER DATABASE begin backup;

+ Copy all the datafiles using appropriate O/S commands.

+ sql> ALTER DATABASE end backup;

One danger in making online backups is the possibility of inconsistent data within a block. For example, assume this is backing up block of DataFile users.dbf. Also, assume, the copy utility reads the entire block while DBWR are in the middle of updating the block. The Copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. The result is called a fractured block, meaning that the data contained in this block are not consistent. At a given SCN.

Therefore Oracle internally manages the consistency as below:  

1.  the First Time a block is changed in a datafile-in-hot backup mode, the entire block was written to the redo log files, not J UST the changed bytes. Normally only the changed bytes (a redo vector) is written. In hot backup mode, the entire block is logged the first time. This was because you can get to a situation where the process copying the datafile and DBWR be working on the same block Simultaneously.

Lets say they is and the OS blocking read factor is 512bytes (the OS reads, bytes from disk at a time). The backup program goes to read a 8k Oracle block. The OS gives it 4k. Meanwhile--DBWR have asked to rewrite this block. The OS schedules the DBWR write to occur right now. The entire 8k block is rewritten. The backup program starts running again, multi-tasking OS here, and reads the last 4k of the block. The backup program have now gotten an fractured block-the head and tail is from the points in time.

We cannot deal with that during recovery. Hence, we log the entire block image so then during recovery, this block was totally rewritten from redo and is consistent With itself atleast. We can recover it from there.

2. The datafile headers which contain the SCN of the last completed checkpoint was not updated while a file was in hot BAC Kup mode. This lets the recovery process understand what archive redo log files might is needed to fully recover this file.

To limit the effect of this additional logging, you should ensure if you have place one tablepspace at a time in Backup mode And bring the tablespace out of backup mode as soon as, you had backed it up. This would reduce the number of blocks that May has the to is logged to the minimum possible.

Try to take the hot/online backups when there was less/no load on the database, so then less redo would be generated.

What happens when A Tablespace/database was Kept in Begin Backup Mode (Doc ID 469950.1)