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.
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;
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 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.
Table A–6 (Cont.) Backup Timeline for Scenario When Moderate Number of Blocks
Day Script Action
Contents of Flash Recovery Area and Tape After Script
Backing Up to the Flash Recovery Area and to Tape: Basic Scenarios
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.
archived redo log
A copy of one of the filled members of an online redo log group made when the database is in ARCHIVELOG mode. After the LGWR process fills each online redo log with redo records, the archiver process copies the log to one or more redo log archiving destinations. This copy is the archived redo log. Note that RMAN does not distinguish between an original archived redo log and an image copy of an archived redo log; both are considered image copies.
ARCHIVELOG mode
The mode of the database in which Oracle copies filled online redo logs to disk.
Specify the mode at database creation or with the ALTER DATABASE ARCHIVELOG statement.
See Also: archived redo log, NOARCHIVELOG mode
archiving
The operation in which a filled online redo log file is copied to an offline log archiving destination. An offline copy of an online redo logs is called an archived redo log. You must run the database in ARCHIVELOG mode to archive redo logs.
automatic channel allocation
The ability of RMAN to perform backup and restore tasks without requiring the use of the ALLOCATE CHANNNEL command. You can use the CONFIGURE command to specify disk and tape channels. Then, you can issue commands such as BACKUP and RESTORE at the RMAN command prompt without manually allocating channels.
RMAN uses whatever configured channels that it needs in order to execute the commands.
automatic undo management mode
A mode of the database in which undo data is stored in a dedicated undo tablespace.
The only undo management that you must perform is the creation of the undo tablespace. All other undo management is performed automatically.
auxiliary database
(1) A database created from target database backups with the RMAN DUPLICATE command.
(2) A temporary database that is restored to a new location and then started up with a new instance name during tablespace point-in-time recovery (TSPITR). A TSPITR auxiliary database contains the recovery set and auxiliary set.
See Also: recovery set, auxiliary set, tablespace point-in-time recovery (TSPITR)
auxiliary set
In TSPITR, the set of files that is not in the recovery set but which must be restored in the auxiliary database for the TSPITR operation to be successful.
See Also: auxiliary database, recovery set
backup
(1) A backup copy of data, that is, a database, tablespace, table, datafile, control file, or archived redo log. Backups can be physical (at the database file level) or logical (at the database object level). Physical backups can be created by using RMAN to back up one or more datafiles, control files or archived redo log files. Logical backups can be created using one of the Oracle export utilities (Data Pump Export or Original Export).
(2) An RMAN command that creates a backup set, proxy copy, or disk-based image copy.
See Also: copy, backup set, multiplexing, RMAN
backup, whole database See whole database backup
backup and recovery
The set of concepts, procedures, and strategies involved in protecting the database against data loss due to media failure or users errors.
backup control file
A backup of the control file. You can back up the control file with the RMAN backup command or with the SQL statement ALTER DATABASE BACKUP CONTROLFILE TO 'filename'.
backup mode
The database mode (also called hot backup mode) initiated when you issue the ALTER TABLESPACE ... BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP command before taking an online backup. You take a tablespace out of backup mode when you issue the ALTER TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP command.
You must use this command when you make a user-managed backup of datafiles in an online tablespace. RMAN does not require you to put the database in backup mode. In backup mode, updates to the database create more than the usual amount of redo.
Each time a block in the buffer cache becomes dirty, Oracle must write an image of the changed block to the redo log file, in addition to recording the changes to the data.
See Also: corrupt block, online backup
backup piece
The physical file format used to store RMAN backup sets.
See Also: backup, backup set, RMAN
backup retention policy See retention policy
backup set
A backup of one or more datafiles, control files, SPFILEs and archived redo log files.
Each backup set consists of one or more binary files called backup pieces. Backup