Oracle Backup and Recovery

Description of Begin backup/ Franck Pachot

End backup contact@pachot.net
version 1.0

Introduction

This document tries to explain exactly what happens when using

ALTER 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 external
to 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, not
shutdown 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 is
inconsistent and will need redo applied to be usable.
Recovery is the process of applying redo log information in order to roll-forward file
modifications as they were done in the original files.

When the copy is done with Oracle (RMAN), Oracle copies the datafile blocks to backupset
so 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 file
structure), 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 the
copy.
• Fractured blocks: Nothing guaranties that an Oracle block is read in one single i/o so
that 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 reads
blocks at different point in time. The recovery is able to roll forward blocks from the
past, but cannot deal with blocks from the future, thus the recovery of the copy
must 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 within
datafiles 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 BACKUP
is 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 an
external tool, the only way to have something set in the copy is to do it in the current
datafiles 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 the
program 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 the
restored 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 be
a hot backup copy.
This is to manage the backup consistency issue when the copy will be used for a
recovery.
• A checkpoint is done for the tablespace, so that in case of recovery, no redo
generated 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 checkpoint
SCN that was at the beginning of the backup.
Then, when the copy will be restored, Oracle knows that it needs to start recovery
at 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 (but
they do update a 'backup' SCN)
• Each first modification to a block in buffer cache will write the full block into the redo
thread (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 the
copy, 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. This
is 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 to
avoid 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 dd
bs=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: as
Oracle 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 is
sure 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 the
buffer cache. If the same block is reloaded again in the buffer cache, supplemental
logging will occur again. I haven't seen that point documented, but a testcase doing
a '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 fully
available to be restored and recovered using the archive log files that where generated
since the begin backup.
After the files have been restored, Oracle sees that the SCN is older than the current one
and 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 so
that 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 for
the same reason, it is better to do the tablespaces one after one instead of putting all the
database 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 would
be seen as if it requires recovery.

However that cannot be avoided if the instance crashes (or shutdown abort), and then the
startup of the database will raise:
ORA-1113: file ... needs media recovery
This 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 to
do 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 lasts
only few seconds. In that case, it is easier to use that command to put all tablespaces in
backup 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 are
written.
Then, it knows how it can read the datafiles in a way the copy is consistent: write the good
version of datafile header, read the blocks with an i/o size that is multiple of the Oracle
block size so that there is no fractured blocks, and check head and tail of the block to see if
block 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 in

backup mode ?

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

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

• Header inconsistency: If the file copy is done from beginning to end, then the
datafile header should reflect the right SCN
• Fractured blocks: If the copy does i/o with a size that is multiple of the Oracle block
size, then you should not have fractured blocks
• Backup consistency:If you take care to recover later than the point in time of the
end of the copy, you should not have inconsistency

But there may be other internal mechanisms that are not documented so that we can't be
sure 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 will
have no message

What if the instance crashes while the tablespaces is in backup

mode ?

When you start the database after that, Oracle will say that it requires recovery. This is
because 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 copy
is 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 in
the 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 for
backup 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 archive
logs
- 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 you
cannot have with OS backups.

Yet, the OS backup are still used when using OS tools that can copy an entire database in
seconds, 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 Oracle
version.
All comments are welcome at contact@pachot.net