Oracle Backup and Recovery

Description of Begin backup/End Franck Pachot

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.

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.

All tests and documentation that helped building this document were related to 10gR2 Oracle version.
All comments are welcome at contact@pachot.net