Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2) Part Number B14192-03 |
|
|
View PDF |
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.
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
As in the disk-only scenarios, the backup scripts in this section are categorized based on database workload.
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.
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.
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 |
|
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 |
|
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 |
|
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. |
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.
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.
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;
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.
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.
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.
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_copy"; # 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;
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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. |
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.
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;
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 |
|
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 |
|
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 |
|
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. |