internal operation of hot backup

8/6/2019 Internal Operation of Hot Backup

http://slidepdf.com/reader/full/internal-operation-of-hot-backup 1/4

F R I D A Y , D E C E M B E R 1 8 , 2 0 0 9

INTERNAL OPERATION OF HOT BACKUP

What Happens When A Tablespace/Database Is Kept In Begin Backup Mode

This document explains in detail about what happens when a tablespace/datafile is kept in hot

backup/begin backup mode.

To perform online/hot backup we have 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 have to put each tablespace individually in begin/end backup mode to perform the

online backup. From 10g onwards the entire database can be put in begin/end backup mode.

Make sure that 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.

1

http://oracleinstance.blogspot.com/2009/12/internal-operation-of-hot-backup.html




+ sql> alter database end backup;

One danger in making online backups is the possibility of inconsistent data within a block. For

example, assume that you are backing up block 100 in datafile users.dbf. Also, assume that the

copy utility reads the entire block while DBWR is in the middle of updating the block. In this

case, 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 is 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 that is in hot backup mode, the entire block is

written to the redo log files, not just 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 is

because you can get into a situation where the process copying the datafile and DBWR are

working on the same block simultaneously.

Lets say they are and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk

at a time). The backup program goes to read an 8k Oracle block. The OS gives it 4k. Meanwhile

-- DBWR has 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 has now gotten an fractured

block -- the head and tail are from two points in time.

We cannot deal with that during recovery. Hence, we log the entire block image so that during

recovery, this block is 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 are not

updated while a file is in hot backup mode. This lets the recovery process understand what

2



archive redo log files might be needed to fully recover this file.

To limit the effect of this additional logging, you should ensure you only place one tablepspace

at a time in backup mode and bring the tablespace out of backup mode as soon as you have

backed it up. This will reduce the number of blocks that may have to be logged to the

minimum possible.

Try to take the hot/online backups when there is less / no load on the database, so that less

redo will be generated.

PO S TE D B Y R AJE S H KUMAR GO V I N DAR AJAN AT FR I DAY , DE C E MB E R 18 , 2 009

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Hi,Whenever a tablespace is in hot backup mode, Oracle logs the entire image of the block into theOnline redolog files.My question is does oracle logs the image before it is changed or after the block is changed ?...

and one more question is, when i add a new datafile to the Tablespace which is in hotbackup mode

is this datafile also in backup mode ?...what abt the blocks or extents which get allocated to this datafile ??

anbody has got any idea ?

Regards

sonia

Originally posted by SoniaHi,Whenever a tablespace is in hot backup mode, Oracle logs the entire image of the block into theOnline redolog files.

Not quite. When a datafile is in hot backup mode, Oracle logs the entire image of the changed blockinto the Online redolog files only the first time this block is changed since the beginning of the hotbackup mode. Any subsequent changes of that same block while the datafile is in backup mode willresult only in change vectors being written to the redo log files, exactly the same way as when the

datafile is not in backup mode.My question is does oracle logs the image before it is changed or after the block is changed ?...

Redo logs record only the after-the-change informations.and one more question is, when i add a new datafile to the Tablespace which is in hotbackup mode

is this datafile also in backup mode ?...No, the new datafile will not be in backup mode.

what abt the blocks or extents which get allocated to this datafile ??What about them??

Does Oracle write to data files in begin/hot backup mode?

Oracle will stop updating file headers, but will continue to write data to the database files even if atablespace is in backup mode.

3





In backup mode, Oracle will write out complete changed blocks to the redo log files. Normally onlydeltas (changes) are logged to the redo logs. This is done to enable reconstruction of a block if only

half of it was backed up (split blocks). Because of this, one should notice increased log activity andarchiving during on-line backup.

and on URL: http://orafaq.com/wiki/Hot_Backup's

What Happens during Hot Backup's???

When alter tablespace begin backup is issued, the datafiles which belongs to the tablespaces areflagged as hot-backup-in-progress.The command would checkpoint all data files that are in the hot backup mode. I.e DBWR is asked to

write dirty database block buffers to files, and LGWR or CKPT will update the file headers with thecurrent SCN number.An interesting point to pay attention to is the concept of "split blocks". For example let us say thatthe Oracle block size chosen is (DB_BLOCK_SIZE), by you is 8K and the OS (operating systems)

block size is 2K. OS always copies files as OS Blocks (not Oracle block size). When OS is copying thefirst 4K of the datafile (block), there are chances that the a block (database block buffers are Oracleblock size 8K in this case) may be updated in the buffers and may be written to the datafile byDBWR (basically overlaying the original 8K block in the datafile). Now when OS is copying the

second 4K of the datafile (block), the two portions of the blocks are "not" consistent. To avoid thisblunder this condition, Oracle tracks the blocks which are written to the files by DBWR. If a block

belonging to a datafile stays in the database block buffers for a long time, then the block is onlylogged once (in the online redolog files). But if DBWR flushes the database block buffer to the disk

and read it once again from the datafiles, there is a possibility that it may be got into the buffers forUpdates. In these situation the before image copy of the block is logged into the online redo log

files.Logging the before image of a data block to the redo log files before the first change, helps Oraclein reconstructing a fractured block (two portions of block not being consistent, because of variationbetween OS and Oracle block size). The undocumented parameter

_LOG_BLOCKS_DURING_BACKUP which by default is "TRUE" will make sure that the logging of before image happens.Due to the conditions discussed above excessive REDO LOG INFORMATION is generated during HOTBACKUPS.

4

internal operation of hot backup

Documents