Skip Headers
Oracle® Database Backup and Recovery Basics
10g Release 2 (10.2)

Part Number B14192-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

A.2 Backing Up to the Flash Recovery Area and to Tape: Basic Scenarios

This scenario describes how to use RMAN to make backups to the flash recovery area and then later move them to tape.

The scripts in this section use the flash recovery area as the log archiving destination and the destination for all disk backups. Therefore, whenever there is no space to create archived logs or backups in the flash recovery area, Oracle automatically deletes archived logs and backups that are obsolete or that have been moved to tape.

By moving backup files and archived redo logs to tape, more space becomes available in the flash recovery area for new files. The formulas for the flash recovery area disk quota are suggested minimums, and depend upon the availability of space on tape to satisfy the retention policy. You can, however, increase your on-disk recovery window and reduce the need to restore archived redo logs and backups from tape during a database restore-and-recovery scenario, by allocating a larger flash recovery area disk quota than these formulas specify.

A.2.1 Configuring the RMAN Environment for Disk and Tape Backups

Use RMAN to configure the retention policy, backup optimization, and the control file autobackup. For example:

CONNECT TARGET SYS/orace@trgt;
# Recovery window of 15 days ensures that the database is recoverable within 7
# days using backups on disk and tape
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
# Because you do not use a recovery catalog, enable the autobackup feature
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE sbt PARMS='...' PARALLELISM 1; # PARMS are vendor-specific

A.2.2 Writing Backup Scripts for Disk and Tape Scenarios

As in the disk-only scenarios, the backup scripts in this section are categorized based on database workload.

A.2.2.1 Backup Scripts When Few Data Blocks Change

In this scenario, relatively few data blocks change frequently, so daily level 1 incremental backups will typically be small. The goal is to keep one level 0 incremental backup on disk, incrementally updated each day using a level 1 incremental backup, and then move all other files onto tape. This keeps flash recovery area usage to a minimum.

A.2.2.1.1 Initial Setup

The only required setup is to create a flash recovery area with the required disk quota, and set the flash recovery area as a redo log archiving destination.

The formula for determining your disk quota depends upon the backup retenion policy. It is the same, however, whether your retention policy is based on redundancy or recovery window. Use the following formula:

Disk Quota = Size of 1 copy of the database 
             + size of 1 day's level 1 incremental backup
             + size of (Y+1) days of archived logs

where Y is the number of days that elapse between execution of BACKUP RECOVERY AREA in your backup scripts.

For this example, there is one backup script, executed every day, which creates a new incremental level 1 backup with that day's changes, rolls forward the level 0 backup using the level 1 backup from the previous day, and backs up all flash recovery area files to tape. Since the script backs up the flash recovery area to tape daily, the flash recovery area must be large enough to hold a copy of the database, the daily level 1 incremental backup, and two days' worth of archived redo logs.

The on-disk recovery window is one day. To recover to a point farther back than one day, RMAN must restore backups from tape.

A.2.2.1.2 Daily Script

After the initial setup, a typical daily RMAN backup script would look like the following:

# Execute each day of the week
# Roll forward the copy to most recent incremental backup SCN, which will
# be yesterday's incremental level 1 backup
RECOVER COPY OF DATABASE WITH TAG "daily_backup";
# Take incremental backups to flash recovery area (using default disk channel)
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "daily_backup" DATABASE;
# Back up flash recovery area to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;

The following table describes how the contents of the flash recovery area and tape change as this script is run each day. The script rolls forward the level 0 database copy tagged as daily_backup to the SCN of the preceding day's incremental level 1 backup, then creates a new level 1 incremental backup with the previous day's changes. For example, when you run the script on Thursday, RMAN rolls forward the level 0 backup to the SCN of the incremental backup on Wednesday.

Table A-5 Backup Timeline for Scenario When Few Blocks Change

Day Action Contents of Flash Recovery Area and SBT

Sun Feb 1

  1. Attempt roll-forward of level 0 backup; fail because there is no level 0 backup yet.

  2. Create level 0 incremental backup to be rolled forward on future days.

Level 0 incremental backup.

Any other flash recovery area files such as archived redo logs are copied to tape and may be deleted from flash recovery area when space is needed.

Mon Feb 2

  1. Attempt roll-forward of level 0 backup; fail because there is no level 1 backup yet.

  2. Create level 1 incremental backup, containing changes during Feb 2.

  3. Back up flash recovery area to sbt.

Level 0 backup from Feb 1, level 1 incremental backup containing changes from Feb 2.

Any other flash recovery area files such as archived redo logs are copied to tape and may be deleted from flash recovery area when space is needed.

Any obsolete files stored on tape are deleted.

All future days

  1. Roll forward incremental level 0 backup to SCN of previous level 1 incremental backup.

  2. Create level 1 incremental backup containing changes from previous day.

  3. Back up flash recovery area to sbt.

Level 0 backup rolled forward to previous day, level 1 incremental backup containing changes from this day

Any other flash recovery area files such as archived redo logs are copied to tape and may be deleted from flash recovery area when space is needed.

Any obsolete files stored on tape are deleted.


A.2.2.2 Backup Scripts When Many Blocks Change

In this scenario, many or most of the data blocks are updated over the course of a week, as in a CRM environment. A strategy using daily incremental backups would not be recommended because the size of the incremental backups could be quite large and is hard to predict.

A better strategy in this case is to back up the database to tape weekly and the archived logs to tape every day, and to use a recovery window-based retention policy.

The elements of the strategy are as follows:

  • Redo log files are archived in the flash recovery area.

  • A full backup of the database is taken to the flash recovery area once each week.

  • Once each day, any backup files (including archived redo logs) in the flash recovery area that is not currently stored on tape is backed up to tape using the BACKUP RECOVERY AREA command, and any obsolete backups on tape are deleted.

If you use a recovery window-based retention policy, all backups required to perform point-in-time recovery within the window are retained as long as they are needed. This provides the necessary protection for your data, even with limited use of disk space.

A.2.2.2.1 Initial Setup

Create your flash recovery area with the required disk quota and set up the flash recovery area as a redo log archiving destination. The formula for determining your disk quota depends upon the frequency of backups of the flash recovery area to tape, as follows:

Disk Quota = Size of 1 copies of the database 
           + size of (Y+1) days of archived logs

where Y is the number of days that elapse between execution of BACKUP RECOVERY AREA in your backup scripts.

For this example, assume that you take a full database backup once each week, and back up the flash recovery area to tape on all seven days of the week.

There are two scripts in this strategy. Use the first script at the beginning of each week (say, on Sunday) to create a full database backup, and the other script on the remaining days of the week (Monday through Saturday) to back up the flash recovery area contents (the archived redo logs for the day) to tape.

Note that both of the scripts in this strategy include the BACKUP RECOVERY AREA command, so that command is executed every day. For this example, Y=1, so the disk quota is the size of one copy of the database plus two days of archived redo logs.

A.2.2.2.2 Weekly Scripts

This RMAN backup script is executed once each week, on Sunday:

# Execute only once a week
# Take copy of database to flash recovery area
BACKUP AS COPY DATABASE;
# Take backup of flash recovery area to tape
BACKUP RECOVERY AREA;
# Delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;
EXIT;

A.2.2.2.3 Daily Script

The RMAN script to be executed each day (Monday through Saturday) would look like the following:

# Execute 6 days/wk
# Take backup of flash recovery area to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TPE sbt;

Because the entire flash recovery area is backed up to tape every day, the database may delete backups and archived redo log files from the flash recovery area whenever space is needed for new files. Between backups it may be difficult to predict exactly which files will still be in the flash recovery area, because files are deleted whenever space is needed.

A.2.2.3 Backup Scripts When Blocks Change Moderately

The following strategy is based on full database backups taken at regular intervals. It is useful when about half of the data blocks change during the interval between full database backups, or when the number of changed data blocks varies widely between full database backups.

The strategy is based on an incrementally updated backups-based full backup of the database, rolled forward once each week. This requires a level 0 disk copy incremental backup of the database, and a level 1 incremental created each Sunday with the previous seven days of datafile changes. After the roll-forward, the contents of the flash recovery area are backed up to tape, so the incremental level 0 copy of the database and the level 1 weekly incremental backup are available both on disk and tape.

Each day, archived redo log files accumulate in the flash recovery area. Each time the daily script runs, those redo log files are backed up to tape. After that, they may be deleted from disk if space is needed in the flash recovery area.

A.2.2.3.1 Initial Setup

The minimum flash recovery area disk quota for this scenario is calculated with the following formula:

Disk Quota = Size of 1 copy of the database 
           + Size of 1 level 1 incremental backup with Y days of changes 
           + Size of (Y+1) days of archived redo logs

where Y is the number of days between backing up the flash recovery area to tape.

For this example, Y=7, so the disk quota must be at least the size of one copy of the database, one seven-day level 1 incremental backup, and eight days' worth of archived redo logs.

A.2.2.3.2 Weekly Script

The script that implement the Sunday backup for this strategy weekly parts of the backup is as follows:

# Execute once a week
# Roll forward the whole copy of the database to last incremental backup SCN
RECOVER COPY OF DATABASE WITH TAG "whole_db_cpy";
# Make an incremental backup of the database to the flash recovery area.
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 
       FOR RECOVER OF COPY WITH TAG "whole_db_copy" 
       DATABASE;
# Back up flash recovery area to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;

A.2.2.3.3 Daily Script

The daily script for this strategy is shown here:

# Execute 6 days/wk
# Back up flash recovery area to tape
BACKUP RECOVERY AREA;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;

The following table llustrates how the scripts maintain the recovery window. Assume for the purposes of this example that the week begins on Sunday.

Table A-6 Backup Timeline for Scenario When Moderate Number of Blocks Change

Day Script Action Contents of Flash Recovery Area and Tape After Script

Week 1, Sunday

Weekly

  1. Attempt RECOVER COPY OF DATABASE command. This command has no effect, because there is no level 0 backup of the database yet.

  2. Create level 0 backup as result of the BACKUP... FOR RECOVER OF COPY command.

  3. Back up all files in the flash recovery area to tape.

  4. Delete obsolete backups from tape.

Flash recovery area contains the level 0 incremental backup of the database, to be rolled forward each week.

Tape contains a backup of the level 0 incremental backup of the database.

Week 1, Monday- Saturday

Daily

  1. Back up flash recovery area to tape.

  2. Delete obsolete backups from tape.

Flash recovery area contains archived redo logs for the previous day, and the incremental level 0 database backup.

Tape contains a backup of the level 0 incremental backup, and all redo logs for all days since Sunday of week 1.

No backups are obsolete.

Week 2, Sunday

Weekly

  1. Attempt RECOVER COPY OF DATABASE level 0 to most recent incremental SCN. This command has no effect, because there is no level 1 incremental backup to use in roll-forward.

  2. Perform level 1 incremental backup. A level 1 incremental backup is created, including changes from week 1.

  3. Back up flash recovery area to tape.

  4. Delete obsolete backups from tape.

Flash recovery area contains incremental level 0 database backup at SCN of Sunday of week 1, level 1 incremental backup with changes from week 1.

Tape contains level 0 incremental backup from Sunday of week 1, level 1 incremental backup with all changes from week 1, archived redo logs from week 1.

No backups are obsolete.

Week 2, Monday- Saturday

Daily

  1. Back up flash recovery area to tape.

  2. Delete obsolete backups from tape.

Flash recovery area contains archived redo logs for the previous day, and the incremental level 0 database backup. May also contain other archived redo logs.

Tape contains a backup of the level 0 incremental backup, and all redo logs for all days since Sunday of week 1.

Week 3, Sunday

Weekly

  1. Perform RECOVER COPY OF DATABASE level 0 to most recent incremental SCN. The level 0 incremental backup is rolled forward to the beginning of week 2.

  2. Perform level 1 incremental backup. A level 1 incremental backup is created including changes from week 2.

  3. Back up flash recovery area to tape.

  4. Delete obsolete backups from tape.

Flash recovery area contains incremental level 0 database backup at SCN of Sunday from week 2, level 1 incremental backup with changes from week 2.

Tape contains level 0 incremental backup rolled forward to SCN of Sunday of week 2, level 1 incremental backup with all changes from week 2, archived redo logs from week 2.

Obsolete backups deleted from tape include archived redo logs from week 1, tape backup of level 0 incremental database backup from week 1.


A.2.2.4 Backup Scripts When Not Enough Disk Space for a Database Backup

If the disk quota is not sufficient to keep a copy of database, then the flash recovery area should be used only as an archived log destination. The disk quota rules will automatically delete these logs from the flash recovery area when they are no longer needed (because they are obsolete or because they have been backed up to tape). Back up the archived logs to tape daily, to ensure that they can be deleted from the flash recovery area when space is needed there for other files.

For this strategy, the flash recovery area should be sized large enough to hold at least two days' worth of archived redo logs, plus one day's worth of incremental backup.

This strategy is based on level 0 and level 1 incremental backups (though it does not use incrementally updated backups). This strategy uses two scripts: one to be executed once a week (for example, on Sunday), and the other to be executed every day except for the day that the first script is executed (Monday through Saturday).

The script that runs once each week creates a level 0 incremental backup on tape, containing the full contents of the database.

The script that runs each day except the first day creates level 1 incremental backups containing the changes to the database each day.

A.2.2.4.1 Weekly Script

Here is the script to run once at the beginning of each week

# Execute only once a week
# backup database to tape
BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE;
# delete obsolete backups on tape
DELETE OBSOLETE DEVICE TYPE sbt;
# backup recovery file destination to tape
BACKUP RECOVERY AREA;

A.2.2.4.2 Daily Script

This script executes each day of the week except for the first day, for example, Monday through Saturday:

# backup recovery file destination to tape
BACKUP RECOVERY AREA;
# Take incremental backups to flash recovery area
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 DATABASE;

The following table illustrates how the scripts maintain the RMAN retention policy recovery window and how the disk quota is maintained. The recovery files that exist after the execution of the script each day also exist on tape, so Oracle can delete files from the flash recovery area as needed.

Table A-7 Backup Timeline for Limited Disk Space Scenario

Day Script Action Contents of Tape After Script

Sun Feb 1

Once-a-week

  1. Back up level 0 to tape.

  2. Delete obsolete from tape.

  3. Back up flash recovery area to tape.

Tape contains a level 0 backup of the whole database from February 1, and any archived redo logs.

Mon Feb 2 - Sat Feb 7

Daily

  1. Back up flash recovery area to tape.

  2. Back up level 1 to disk.

Tape contains a level 0 backup of the whole database from February 1, incremental level 1 backups for each day from Monday through the present day, and any archived redo logs for the whole week.

Sun Feb 8

Once-a-week

  1. Back up level 0 to tape.

  2. Delete obsolete from tape.

  3. Back up flash recovery area to tape.

Tape contains a level 0 backup of the whole database from February 1, incremental level 1 backups for each day from Monday through the present day, and any archived redo logs for the whole week.