Oracle Backup and RecoveryDescription of Begin backup/

End backupversion 1.0

Franck Pachotcontact@pachot.net

Introduction

This document tries to explain exactly what happens when usingALTER TABLESPACE ... BEGIN BACKUP and ALTER TABLESPACE ... END BACKUP,and why it is mandatory to use it when the online backup is done with a tool that is externalto Oracle ( such as OS backups using cp, tar, BCV, etc. )

It also gives an answer to those frequent questions:

• Does Oracle write to data files while in hot backup mode ?• What about ALTER DATABASE BEGIN BACKUP ?• Why it is not used with RMAN backups• What if you do an online backup without setting tablespaces in backup mode ?• What if the instance crashes while the tablespaces is in backup mode ?• How to check which datafiles are in backup mode• What are the minimal archive logs to keep with the hot backup ?• Why use OS backups instead of RMAN ?

Description

Offline backup (Cold backup)

A cold OS backup is simple: the database has been cleanly shut down (not crashed, notshutdown abort) so that:

• all datafiles are consistent (same SCN) and no redo is needed in case of restore• the datafiles are closed: they will not be updated during the copy operation

Thus, it can be restored entirely and the database can be opened without the need to

recover.

Online backup (Hot backup)

An hot backup does the copy while the database is running. That means that the copy isinconsistent and will need redo applied to be usable.Recovery is the process of applying redo log information in order to roll-forward filemodifications as they were done in the original files.

When the copy is done with Oracle (RMAN), Oracle copies the datafile blocks to backupsetso that it will be able to restore them and recover them.

When the copy is done from the OS (i.e with a tool that is not aware of the Oracle filestructure), several issues come up:

• Header inconsistency: Nothing guaranties the order in which the files are copied,thus the header of the file may reflect its state at the beginning or at the end of thecopy.

• Fractured blocks: Nothing guaranties that an Oracle block is read in one single i/o sothat two halves of a block may reflect its state at two different points in time.

• Backup consistency:As the copy is running while the datafile is updated, it readsblocks at different point in time. The recovery is able to roll forward blocks from thepast, but cannot deal with blocks from the future, thus the recovery of the copymust be recovered at least up to the SCN that was at the end of the copy.

So it is all about consistency in the copy: consistency between datafiles, consistency withindatafiles and consistency within data blocks, and keep this consistency in the current files(obviously) as well as in the copy (as it will be needed for a restore/recovery)

Backup mode

The goal of ALTER TABLESPACE ... BEGIN BACKUP and ALTER TABLESPACE ... END BACKUPis to set special actions in the current database files in order to make their copy usable,without affecting the current operations.

Nothing needs to be changed in the current datafiles, but, as the copy is done by anexternal tool, the only way to have something set in the copy is to do it in the currentdatafiles before the copy, and revert it back at the end.

This is all about having a copy that can be recovered, with no control on theprogram that does the copy, and with the minimal impact on the current database.

In order to deal with the 3 previous issues, the instance that will do the recovery of therestored datafiles has to know:

• that the files need recovery• from which SCN, and up to which SCN it has to be recovered at least

• enough information to fix fractured blocks

During backup mode, for each datafile in the tablespace, here is what happens:

1- When BEGIN BACKUP is issued:

• The hot backup flag in the datafile headers is set, so that the copy is identified to bea hot backup copy.This is to manage the backup consistency issue when the copy will be used for arecovery.

• A checkpoint is done for the tablespace, so that in case of recovery, no redogenerated before that point will be applied.Begin backup command completes only when checkpoint is done.

2- During backup mode:

• The datafile header is frozen so that whenever it is copied, it reflects the checkpointSCN that was at the beginning of the backup.Then, when the copy will be restored, Oracle knows that it needs to start recoveryat that SCN to apply the archived redo logs.This is to avoid the header inconsistency issue.That means that any further checkpoints do not update the datafile header SCN (butthey do update a 'backup' SCN)

• Each first modification to a block in buffer cache will write the full block into the redothread (in addition to the default behaviour that writes only the change vector).This is to avoid the fractured block issue. There may be a fractured block in thecopy, but it will be overwritten during the recovery with the full block image.

That means that everything goes as normal except for two operations:- at checkpoint the datafile header SCN is not updated- when updating a block, the first time it is updated since it came in the buffer cache,

the whole before image of the block is recorded in redo- direct path writes do not go through the buffer cache, but they always write full

blocks and then full block is written to redo log (if not in nologging)

3- When END BACKUP is issued:• A record that marks the end of backup is written to the redo thread so that if the

copy is restored and recovered, it cannot be recovered earlier than that point. Thisis to avoid the backup consistency issue.

• The hot backup flag in the datafile headers is unset.• The header SCN is written with the current one.

Remarks:1. the fractured block is not frequent as it happens only if the i/o for the copy is done

at the same time on the same block as the i/o for the update. But the only mean toavoid the problem is to do that full logging of block for each block, just in case.

2. if the OS i/o size is multiple of the Oracle block size (e.g backup done with ddbs=1M), that supplemental logging is not useful as fractured blocks cannot happen.

3. the begin backup checkpoint is mandatory to manage the fractured block issue: asOracle writes the whole before image of the block, it needs to ensure that it does

not overwrite a change done previously. With the checkpoint at the beginning, it issure that no change vector preceding the begin backup has to be applied be applied.

4. The supplemental logging occurs when accessing the block for the first time in thebuffer cache. If the same block is reloaded again in the buffer cache, supplementallogging will occur again. I haven't seen that point documented, but a testcase doinga 'flush buffer_cache' proves that.

Consequence on the copy (the backup)

When the copy has been done between begin backup and end backup, the copy is fullyavailable to be restored and recovered using the archive log files that where generatedsince the begin backup.After the files have been restored, Oracle sees that the SCN is older than the current oneand says that the database needs recovery.

The recovery must be done up to a point in time ulterior to the end backup point in time sothat we are sure that there is no blocks in the datafile that comes from the future.

Consequence on the current database

All operations can be done during the backup mode.However, as more logging is written, it should be done during a low activity period. And forthe same reason, it is better to do the tablespaces one after one instead of putting all thedatabase tablespaces in backup mode.

In addition, it is not possible to shutdown the database while a tablespace is in hot backup.This is because, as the datafile header is frozen with a non current SCN, the datafile wouldbe seen as if it requires recovery.

However that cannot be avoided if the instance crashes (or shutdown abort), and then thestartup of the database will raise:

ORA-1113: file ... needs media recoveryThis is the only case I know where instance recovery is not automatic, you need to issue'alter database... end backup;' before opening the database.

Frequent questions

Does Oracle write to data files while in hot backup mode ?

Yes of course, it would not be called 'online' backup if it were not the case.

What about ALTER DATABASE BEGIN BACKUP ?

That command put all database tablespaces in backup mode at the same time.As seen previously, it is a bad idea to put all tablespaces in backup mode, as it is better todo it one by one in order to minimize the supplemental redo logging overhead.

Oracle introduces this 'shortcut' for one reason only: when doing backup with a mirror split(BCV, Flashcopy, etc), the copy gets all the datafiles at the same time, and the copy lastsonly few seconds. In that case, it is easier to use that command to put all tablespaces inbackup mode during the operation.

Why it is not used with RMAN backups

RMAN is an Oracle tool, that is totally aware of the datafile structure, and the way they arewritten.Then, it knows how it can read the datafiles in a way the copy is consistent: write the goodversion of datafile header, read the blocks with an i/o size that is multiple of the Oracleblock size so that there is no fractured blocks, and check head and tail of the block to see ifblock is fractured (in that case, it re-reads the block to get a consistent image).

That is one advantage among many others of using RMAN for backups.

What if you do an online backup without setting tablespaces inbackup mode ?

If you don't put the tablespace in backup mode, we can't be sure that the copy isrecoverable. It may be fine, but it may have inconsistencies.

We can suppose that the copy is consistent if we make the copy with the followingconditions

• Header inconsistency: If the file copy is done from beginning to end, then thedatafile header should reflect the right SCN

• Fractured blocks: If the copy does i/o with a size that is multiple of the Oracle blocksize, then you should not have fractured blocks

• Backup consistency:If you take care to recover later than the point in time of theend of the copy, you should not have inconsistency

But there may be other internal mechanisms that are not documented so that we can't besure that this list of issues is exhaustive.And, as it is not supported, we cannot rely on a backup done like that. Note that you willhave no message

What if the instance crashes while the tablespaces is in backupmode ?

When you start the database after that, Oracle will say that it requires recovery. This isbecause the SCN was frozen and it is the expected behaviour because if you restore the

copied file, it has to be recovered. (and the only way Oracle has to set its value in the copyis to set it in the current file while it is copied)

In that case you can can issue:ALTER DATABASE END BACKUP;ALTER DATABASE OPEN;

to open the database.

But your backup is not usable, you have to do it again.

How to check which datafiles are in backup mode

The V$BACKUP view shows the datafiles that are currently in backup mode (status ACTIVE).

Some old documentation says to check V$DATAFILE_HEADER column FUZZY.This is because in previous versions (<9i) the begin backup unsets the online fuzzy bit inthe datafile header, and set it back at when end backup is issued.Since 9i, the online fuzzy bit is unset only when datafile is offline or read-only, not forbackup mode.

What are the minimal archive logs to keep with the hot backup?

The backup done online is unusable if there is not at least the possibility to restore archivelogs- from the archive log that was the current redo log when the backup started,- up to the archive log that was archived just after the backup (of the whole database)

ended.

That is sufficient to do an incomplete media recovery up to the point of 'end backup'.Subsequent archive logs will be needed to recover up to the point of failure.

Why use OS backups instead of RMAN

The best way to do online backups is using RMAN as it has a tons of features that youcannot have with OS backups.

Yet, the OS backup are still used when using OS tools that can copy an entire database inseconds, using mirror split (BCV, Flashcopy, etc), for very large databases.

References

• Misconception: Hot backup mode stops writing to the datafiles (Jeremiah Wilton)• METALINK Note:1050932.6 'Why Are Datafiles Being Written To During Hot

Backup?'• AskTom "Backup and Recovery -- why extra redo is generated."

All tests and documentation that helped building this document were related to 10gR2 Oracleversion.

All comments are welcome at contact@pachot.net