Sie sind auf Seite 1von 8

Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

Ceci est le cache Google de http://knol.google.com/k/franck-pachot/oracle-begin-backupend-backup


/17uabcrki6uux/3. Il s'agit d'un instantané de la page telle qu'elle était affichée le 31 jan 2009 08:57:58 GMT.
La page actuelle peut avoir changé depuis cette date. En savoir plus

Les termes de recherche suivants sont mis en surbrillance : backup cold begin Ces Version en texte seul
termes apparaissent uniquement dans les liens pointant sur cette page : backup

How-to contestNew! | Help


Knol: a unit of knowledge
Search Toolkit

Manage
Revisions
Edit
View

Oracle: Begin backup/End backup


Description of Begin backup/End backup behaviour

What happens when tablespace is in hot backup mode.


Contents

Introduction
Description
Frequent questions
References

Print Print Favorite Favorite

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 ?

1 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

Why use OS backups instead of RMAN ?


Why BEGIN BACKUP takes a long time ?

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)

2 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

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.

3 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

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.

4 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

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,

5 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

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

6 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

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.

Why BEGIN BACKUP takes a long time ?


BEGIN BACKUP has to checkpoint the dirty buffers related with the tablespace, so that the backup
datafiles and the folowing redo log are sufficient to recover.
This is the same reason why an offline backup is done after a normal shutdown (that do a checkpoint) and
not a shutdown abort, but here it is at tablespace level only.
The duration of that checkpoint is proportional to the buffer cache size and the number of datafiles.
The performance of BEGIN BACKUP checkpoint has been improved in 10g.

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."

That document has already been posted on : http://www.dba-village.com

Share what you know


Write a Knol
Franck Pachot
Oracle DBA
Sophia-Antipolis, France
Article rating:
Your rating:

Activity for this knol

This week:

92pageviews

Totals:

2397pageviews
Moderated collaboration
Creative Commons Attribution 3.0 License
Version: 4
Last edited: Jul 24, 2008 2:42 AM.

Reviews

7 sur 8 02/02/2009 10:40


Oracle: Begin backup/End backup - a knol by Franck Pachot http://74.125.77.132/search?q=cache:jwwrEh5d6hUJ:knol.google.com/k...

There are no reviews for this knol.

Review This Knol

Similar Content on the Web

wordpress.com 90%
scribd.com 90%

Franck Pachot also wrote

Oracle: workarea maxium size


Oracle: Recover a deleted datafile from unix/linux when database is still up
Franck Pachot
Oracle: passing a list as bind variable

Related Knols

Cloning Database
Cloning Database
by ashic ash
Clone an Oracle Dat...
Clone an Oracle Dat...
by Parikshit Paul
Oracle's Health Mon...
Oracle's Health Mon...
by alexander bubernak
Initialization Para...
Initialization Para...
by Koushikinath misra
Oracle Applications...
Oracle Applications...
by Sharad Srivastava

Flag inappropriate content

Comments

Home | Terms of Service | Privacy Policy | Content Policy | Help


©2008 Google

8 sur 8 02/02/2009 10:40

Das könnte Ihnen auch gefallen