9 Backing Up the Database

Purpose of RMAN Backups

The primary purpose of RMAN backups is to protect your data. If a media failure or disaster occurs, then you can restore your backups and recover lost changes.

You can also make backups to preserve data for long-time archival, as explained in "Making Database Backups for Long-Term Storage", and to transfer data, as explained in the chapters included in Part VII, "Transferring Data with RMAN".

Basic Concepts of RMAN Backups

As explained in Chapter 8, "RMAN Backup Concepts", you can back up all or part of your database with the BACKUP command from within the RMAN client. Many of the techniques described in this chapter are also used in the Oracle suggested backup strategy provided by Enterprise Manager and described in Oracle Database 2 Day DBA.

In many cases, after your database has been configured in accordance with your backup strategy, you can back up the database by entering the following command at the RMAN prompt:

RMAN> BACKUP DATABASE;

RMAN uses the configured settings, the records of previous backups, and the control file record of the database structure to determine an efficient set of steps for the backup. RMAN then performs these steps.

As explained in "RMAN File Management in a Data Guard Environment", you can run RMAN backups at any database in a Data Guard environment. Any backup of any database in the environment is usable for recovery of any other database if the backup is accessible. You can offload all backups of database files, including control file backups, to a physical standby database and thereby avoid consuming resources on the primary database.

Specifying the Device Type for an RMAN Backup

The BACKUP command takes a DEVICE TYPE clause that specifies whether to back up to disk or tape device. Example 9-1 illustrates a backup to disk.

BACKUP DATABASE 
  DEVICE TYPE DISK;

When you run BACKUP without a DEVICE TYPE clause, RMAN stores the backup on the configured default device (disk or SBT). You set the default device with the CONFIGURE DEFAULT DEVICE TYPE command described in "Configuring the Default Device for Backups: Disk or SBT".

Specifying Backup Set or Copy for an RMAN Backup to Disk

RMAN can create backups on disk as image copies or as backup sets. "Configuring the Default Type for Backups: Backup Sets or Copies" explains how to configure the default disk device. You can override this default with the AS COPY or AS BACKUPSET clauses. To back up to disk as image copies, use BACKUP AS COPY as shown in Example 9-2.

BACKUP AS COPY
  DEVICE TYPE DISK 
  DATABASE;

To back up your data into backup sets, use the AS BACKUPSET clause. You can allow backup sets to be created on the configured default device, or direct them specifically to disk or tape, as shownExample 9-3.

BACKUP AS BACKUPSET 
  DATABASE;

BACKUP AS BACKUPSET 
  DEVICE TYPE DISK 
  DATABASE;

BACKUP AS BACKUPSET 
  DEVICE TYPE SBT 
  DATABASE;

Specifying a Format for RMAN Backups

RMAN provides a range of options to name the files generated by the BACKUP command. RMAN uses the following set of rules to determine the format of the output files, which are listed in order of precedence:

1. If a FORMAT parameter is specified on the BACKUP command, then this setting controls the generated file name.

   For example, you can direct the output to a specific location, as shown in the following command:

   BACKUP DATABASE 
     FORMAT "/disk1/backup_%U";  # specifies a location on the file system
   

   In this case, backups are stored with generated unique file names with the prefix /disk1/backup_. The %U substitution variable, used to generate a unique string at this point in the file name, is required.

   You can also use the FORMAT parameter to name an ASM disk group as the backup destination, as shown in the following example:

   BACKUP DATABASE 
     FORMAT '+dgroup1';  # specifies an ASM disk group
   

   No %U is required in this case because Automatic Storage Management (ASM) generates unique file names as needed. However, you can specify %U if desired.

   Note:

   If you specify FORMAT when a fast recovery area is enabled, then RMAN obeys the FORMAT setting. If no location is specified in the FORMAT clause, then RMAN creates the backup in a platform-specific location.

2. If a FORMAT setting is configured for the specific channel used for the backup, then this setting controls the generated file name.

3. If a FORMAT setting is configured for the device type used for the backup, then this setting controls the generated file name.

4. If a fast recovery area is enabled during a disk backup, and if FORMAT is not specified, then RMAN creates the backup with an automatically generated name in the fast recovery area.

5. If none of the other conditions in this list apply, then the default location and file name format of the backup are platform-specific.

RUN
{ 
  ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
  ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
  ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
  BACKUP AS COPY DATABASE; 
} 

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;

Specifying Tags for an RMAN Backup

RMAN attaches a character string called a tag to every backup it creates, as a way of identifying the backup. You can either accept the default tag or specify your own with the TAG parameter of the BACKUP command.

BACKUP AS BACKUPSET
  COPIES 1 
  DATAFILE 7
  TAG mondaybkp; 

BACKUP AS COPY 
  TABLESPACE users, tools
  TAG mondaycpy;

BACKUP AS COPY
  COPY OF DATABASE
    FROM TAG full_cold_copy
  TAG new_full_cold_copy;

Making Compressed Backups

For any use of the BACKUP command that creates backup sets, you can take advantage of RMAN support for binary compression of backup sets. Specify the AS COMPRESSED BACKUPSET option to the BACKUP command.

RMAN compresses the backup set contents before writing them to disk. The details of which binary compression level is used are automatically recorded in the backup set. There is no need to explicitly mention the type of compression used or how to decompress the backup set in the recovery operation.

Example 9-7 backs up the entire database and archived logs to the configured default backup destination (disk or tape), producing compressed backup sets.

BACKUP 
  AS COMPRESSED BACKUPSET 
  DATABASE PLUS ARCHIVELOG;

Binary compression creates some performance overhead during backup and restore operations. Binary compression consumes CPU resources, so compressed backups should not be scheduled when CPU usage is high. However, the following circumstances may warrant paying the performance penalty:

• You are using disk-based backups when disk space in your fast recovery area or other disk-based backup destination is limited.

• You are performing your backups to some device over a network when reduced network bandwidth is more important than CPU usage.

• You are using some archival backup media such as CD or DVD, where reducing backup sizes saves on media costs and archival storage.

Backing Up a Whole Database with RMAN

You can perform a whole database backup with the database mounted or open. To perform a whole database backup, from the RMAN prompt, use the BACKUP DATABASE command.

You may want to exclude specified tablespaces from a whole database backup. As explained in "Configuring Tablespaces for Exclusion from Whole Database Backups", you can persistently skip tablespaces across RMAN sessions by executing the CONFIGURE EXCLUDE command for each tablespace that you always want to skip. You can override the configured setting with BACKUP ... NOEXCLUDE.

To back up the database:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. Ensure the database is mounted or open.

3. Issue the BACKUP DATABASE command at the RMAN prompt.

   The simplest form of the command requires no options or parameters:

   BACKUP DATABASE;
   

   For a list of what files are backed up (datafiles, control file, server parameter file) see the BACKUP command keyword DATABASE in Oracle Database Backup and Recovery Reference.

   The following example backs up the database, switches the online redo logs, and includes archived logs in the backup:

   BACKUP DATABASE PLUS ARCHIVELOG;
   

   By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. In this way, you guarantee that you can perform media recovery after restoring this backup.

Backing Up Tablespaces and Datafiles with RMAN

You can back up one or more tablespaces with the BACKUP TABLESPACE command or one or more datafiles with the BACKUP DATAFILE command. When you specify tablespaces, RMAN translates the tablespace name internally into a list of datafiles. The database can be mounted or open. Tablespaces can be read/write or read-only.

RMAN automatically backs up the control file and the server parameter file (if the instance was started with a server parameter file) when data file 1 is included in the backup. If control file autobackup is enabled, then RMAN writes the current control file and server parameter file to a separate autobackup piece. Otherwise, RMAN includes these files in the backup set that contains data file 1.

To back up tablespaces or datafiles:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. If the database instance is not started, then either mount or open the database.

3. Run the BACKUP TABLESPACE command or BACKUP DATAFILE command at the RMAN prompt.

   The following example backs up the users and tools tablespaces to tape:

   BACKUP
     DEVICE TYPE sbt
     TABLESPACE users, tools;
   

   The following example uses an SBT channel to back up data files 1 through 4 and a data file copy stored at /tmp/system01.dbf to tape:

   BACKUP 
     DEVICE TYPE sbt 
     DATAFILE 1,2,3,4 
     DATAFILECOPY '/tmp/system01.dbf';
   

Backing Up Control Files with RMAN

You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If the CONFIGURE CONTROLFILE AUTOBACKUP command is set to ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The control file autobackup contains metadata about the previous backup, which is crucial for disaster recovery.

If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:

• Run BACKUP CURRENT CONTROLFILE .

• Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command.

• Back up data file 1, because RMAN automatically includes the control file and server parameter file in backups of data file 1.

  Note:

  If the control file block size is not equal to the block size for data file 1, then the control file cannot be written into the same backup set as the data file. RMAN writes the control file into a backup set by itself if the block size is different. The V$CONTROLFILE.BLOCK_SIZE column indicates the control file block size, whereas the DB_BLOCK_SIZE initialization parameter indicates the block size of data file 1.

Backing Up Server Parameter Files with RMAN

As explained in "Backing Up Control Files with RMAN", RMAN automatically backs up the current server parameter file in certain cases. The BACKUP SPFILE command backs up the parameter file explicitly. The server parameter file that is backed up is the one currently in use by the instance.

To back up the server parameter file:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. Ensure the target database is mounted or open.

   The database must have been started with a server parameter file. If the instance is started with a client-side initialization parameter file, then RMAN issues an error if you execute BACKUP ... SPFILE.

3. Execute the BACKUP ... SPFILE command.

   The following example backs up the server parameter file to tape:

   BACKUP DEVICE TYPE sbt SPFILE;
   

Backing Up a Database in NOARCHIVELOG Mode

You can only backup a database in NOARCHIVELOG mode when the database is closed and in a consistent state. The script shown in Example 9-8 puts the database into the correct mode for a consistent, whole database backup and then backs up the database. The script assumes that control file autobackup is enabled for the database.

SHUTDOWN IMMEDIATE; 
# Start up the database in case it suffered instance failure or was 
# closed with SHUTDOWN ABORT before starting this script. 
STARTUP FORCE DBA; 
SHUTDOWN IMMEDIATE; 
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP 
  INCREMENTAL LEVEL 0
  MAXSETSIZE 10M
  DATABASE
  TAG 'BACKUP_1';
# Now that the backup is complete, open the database. 
ALTER DATABASE OPEN; 

You can skip tablespaces, such as read-only tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup is lost if the database has to be restored from a backup.

About Backups of Archived Redo Logs

Several features of RMAN backups are specific to archived redo logs. For example, you can use BACKUP ... DELETE to delete one or all copies of archived redo logs from disk after backing them up to backup sets.

BACKUP ARCHIVELOG
  FROM  SEQUENCE 121 
  UNTIL SEQUENCE 125;

Backing Up Archived Redo Log Files

To back up archived logs, use the BACKUP ARCHIVELOG command. If backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the specified device.

To back up archived redo log files:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. Ensure that the target database is mounted or open.

3. Execute the BACKUP ARCHIVELOG or BACKUP ... PLUS ARCHIVELOG command.

   The following example backs up the database and all archived redo logs:

   BACKUP DATABASE PLUS ARCHIVELOG;
   

   The following example uses a configured disk or SBT channel to back up one copy of each log sequence number for all archived redo logs:

   BACKUP ARCHIVELOG ALL;
   

   You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:

   BACKUP ARCHIVELOG 
     FROM TIME  'SYSDATE-30'
     UNTIL TIME 'SYSDATE-7';
   

Backing Up Only Archived Redo Logs That Need Backups

You can indicate that RMAN should automatically skip backups of archived redo logs in the following ways:

• Configure backup optimization.

  As explained in "Backup Optimization and the CONFIGURE command", if you enable backup optimization, then the BACKUP ARCHIVELOG command skips backing up files when an identical archived log has already been backed up to the specified device type. An archived log is considered identical to another when it has the same DBID, thread, sequence number, and RESETLOGS SCN and time.

• Configure an archived redo log deletion policy.

  As explained in "Configuring an Archived Redo Log Deletion Policy", if the deletion policy is configured with the BACKED UP integer TIMES clause, then a BACKUP ARCHIVELOG command copies the logs unless integer backups already exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG command skips the logs.

The BACKUP ... NOT BACKED UP integer TIMES command specifies that RMAN should back up only those archived log files that have not been backed up at least integer times to the specified device. To determine the number of backups for a file, RMAN only considers backups created on the same device type as the current backup.

The BACKED UP clause is a convenient way to back up archived logs to a specified device type. For example, you can specify that RMAN should keep two copies of each archived redo log on tape and skip additional backups.

To back up archived redo logs that need backups:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. Ensure that the target database is mounted or open.

3. Ensure that appropriate channels are configured for the backup.

4. Execute the BACKUP ARCHIVELOG command with the NOT BACKED UP clause.

   BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;
   

Deleting Archived Redo Logs After Backups

The BACKUP ARCHIVELOG ... DELETE INPUT command deletes archived log files after they are backed up. This command eliminates the separate step of manually deleting archived redo logs.

With DELETE INPUT, RMAN deletes only the specific copy of the archived log chosen for the backup set. With DELETE ALL INPUT, RMAN deletes each backed-up archived redo log file from all log archiving destinations.

As explained in "Configuring an Archived Redo Log Deletion Policy", the BACKUP ... DELETE INPUT and DELETE ARCHIVELOG commands obey the archived redo log deletion policy for logs in all archiving locations. For example, if you specify that logs should only be deleted when backed up at least twice to tape, then BACKUP ... DELETE honors this policy.

For the following procedure, assume that you archive to /arc_dest1, /arc_dest2, and the fast recovery area.

To delete archived redo logs after a backup:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. Ensure that the target database is mounted or open.

3. Run the BACKUP command with the DELETE INPUT clause.

   Assume that you run the following BACKUP command:

   BACKUP DEVICE TYPE sbt 
     ARCHIVELOG ALL 
       DELETE ALL INPUT;
   

   In this case, RMAN backs up only one copy of each log sequence number in these archiving locations. RMAN does not delete any logs from the fast recovery area, but it deletes all copies of any log that it backed up from the other archiving destinations. The logs in the fast recovery area that are eligible for deletion are automatically removed by the database when space is needed.

   If you had specified DELETE INPUT rather than DELETE ALL INPUT, then RMAN would have only deleted the specific archived redo log files that it backed up. For example, RMAN would delete the logs in /arc_dest1 if these files were used as the source of the backup, but leave the contents of the /arc_dest2 intact.

Purpose of Incremental Backups

The primary reasons for making incremental backups part of your strategy are:

• Faster daily backups if block change tracking is enabled (see "Using Block Change Tracking to Improve Incremental Backup Performance")

• Ability to roll forward data file image copies, thereby reducing recovery time and avoiding repeated full backups.

• Less bandwidth consumption when backing up over a network.

• Improved performance when the aggregate tape bandwidth for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os.

• Possibility of recovering changes to objects created with the NOLOGGING option.

  For example, direct load inserts do not create redo log entries, so their changes cannot be reproduced with media recovery. Direct load inserts do change data blocks, however, and these blocks are captured by incremental backups.

• Synchronize a physical standby database with the primary database. You can use the RMAN BACKUP INCREMENTAL FROM SCN command to create a backup on the primary database that starts at the current SCN of the standby database, which you can then use to roll forward the standby database. See Oracle Data Guard Concepts and Administration to learn how to apply incremental backups to a standby database.

Planning an Incremental Backup Strategy

Choose a backup strategy according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this strategy, you never have to apply more than a day of redo for complete recovery.

When deciding how often to take level 0 backups, a general rule is to take a new level 0 backup whenever 20% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 backup is appropriate. The following SQL query determines the number of blocks written to an incremental level 1 backup of each data file with at least 20% of its blocks backed up:

SELECT   FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, 
         BLOCKS, DATAFILE_BLOCKS 
FROM     V$BACKUP_DATAFILE 
WHERE    INCREMENTAL_LEVEL > 0 
AND      BLOCKS / DATAFILE_BLOCKS > .2
ORDER BY COMPLETION_TIME;

Compare the number of blocks in level 1 backups to a level 0 backup. For example, if you create only level 1 cumulative backups, then take a new level 0 backup when the most recent level 1 backup is about half of the size of the level 0 backup.

An effective way to conserve disk space is to make incremental backups to disk, and then offload the backups to tape with the BACKUP AS BACKUPSET command. Incremental backups are generally smaller than full backups, which limits the space required to store them until they are moved to tape. When the incremental backups on disk are backed up to tape, the tape is more likely to stream because all blocks of the incremental backup are copied to tape. There is no possibility of delay due to time required for RMAN to locate changed blocks in the datafiles.

Another strategy is to use incrementally updated backups as explained in "Incrementally Updating Backups". In this strategy, you create an image copy of each data file, then periodically roll forward this copy by making and then applying a level 1 incremental backup. In this way you avoid the overhead of making repeated full image copies of your data files, but enjoy all of the advantages.

In a Data Guard environment, you can offload incremental backups to a physical standby database. Incremental backups of a standby and primary database are interchangeable. Thus, you can apply an incremental backup of a standby database to a primary database, or apply an incremental backup of a primary database to a standby database.

Making Incremental Backups

After starting RMAN, run the BACKUP INCREMENTAL command at the RMAN prompt. By default incremental backups are differential.

To make an incremental backup:

1. Start RMAN and connect to a target database and a recovery catalog (if used).

2. Ensure that the target database is mounted or open.

3. Execute the BACKUP INCREMENTAL command with the desired options.

   Use the LEVEL parameter to indicate the incremental level. The following example makes a level 0 incremental database backup.

   BACKUP
     INCREMENTAL LEVEL 0
     DATABASE;
   

   The following example makes a differential incremental backup at level 1 of the SYSTEM and tools tablespaces. It only backs up those data blocks changed since the most recent level 1 or level 0 backup.

   BACKUP
     INCREMENTAL LEVEL 1
     TABLESPACE SYSTEM, tools;
   

   The following example makes a cumulative incremental backup at level 1 of the tablespace users, backing up all blocks changed since the most recent level 0 backup.

   BACKUP
     INCREMENTAL LEVEL 1 CUMULATIVE
     TABLESPACE users;
   

Incrementally Updating Backups

By incrementally updating backups, you can avoid the overhead of making full image copy backups of datafiles, while also minimizing time required for media recovery of your database. For example, if you run a daily backup script, then you never have more than 1 day of redo to apply for media recovery.

To incrementally update data file backups:

1. Create a full image copy backup of a data file with a specified tag.

2. At regular intervals (such as daily), make a level 1 differential incremental backup of the data file and use the same tag as the base data file copy.

3. Apply the incremental backup to the most recent backup with the same tag.

This technique rolls forward the backup to the time when the level 1 incremental backup was made. RMAN can restore this incrementally updated backup and apply changes from the redo log. The result is the same as restoring a data file backup taken at the SCN of the most recently applied incremental level 1 backup.

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update';
  BACKUP 
    INCREMENTAL LEVEL 1
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update' 
    UNTIL TIME 'SYSDATE - 7';
  BACKUP
    INCREMENTAL LEVEL 1 
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

Using Block Change Tracking to Improve Incremental Backup Performance

The block change tracking feature for incremental backups improves backup performance by recording changed blocks for each data file.

COL STATUS   FORMAT A8
COL FILENAME FORMAT A60
 
SELECT STATUS, FILENAME
FROM   V$BLOCK_CHANGE_TRACKING;

STATUS   FILENAME
-------- ------------------------------------------------------------
ENABLED  /disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg

Purpose of Archival Backups

You can use BACKUP ... KEEP to create a backup that is both all-inclusive and exempt from the backup retention policy. The backup is all-inclusive because every file needed to restore and recover the database is backed up to a single disk or tape location. The KEEP option also specifies that the backup should be exempt from the retention policy either forever or for a specified period of time. The general name for a backup created with BACKUP ... KEEP is an archival backup.

As explained in "Data Preservation", one purpose of a backup and recovery strategy is to preserve data. You can use BACKUP ... KEEP to retain a database backup for longer than the time dictated by the retention policy. For example, you can back up the database on the first day of every year to satisfy a regulatory requirement and store the media offsite. Years after you make the archival backup, you could restore and recover it to query the data as it appeared at the time of the backup.

Another purpose of an archival backup is to create a backup to restore for testing purposes and then delete. For example, you can back up the database, restore the database in a test environment, and then discard the archival backup after the test database is operational. A related purpose is to create a self-contained backup that you can delete after transferring it to another user or host. For example, another user might want a copy of the database for reporting or testing.

Basic Concepts of Archival Backups

You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command. You can also use the KEEP and NOKEEP options of the CHANGE command to change the status of an existing backup. Backups with KEEP attributes are valid backups that can be recovered like any other backups.

You can specify an end date for an archival backup with the KEEP UNTIL TIME clause, or specify that the backup should be kept FOREVER. If you specify UNTIL, then RMAN marks the backup as obsolete when the UNTIL time has passed, regardless of any configured retention policy. For example, if you specify KEEP UNTIL TIME '01-JAN-08', then the backup is obsolete one second after midnight on January 1. If you specify an UNTIL TIME of 9:00 p.m, then the backup is obsolete at 9:01 p.m.

When you specify KEEP on the BACKUP command, RMAN generates multiple backup sets. Note the following characteristics of the BACKUP ... KEEP command:

• It automatically backs up the data files, control file (even if the control file autobackup is disabled), and the server parameter file.

• It automatically generates an archived redo log backup to ensure that the database backup can be recovered to a consistent state.

• If the FORMAT, POOL, or TAG parameters are specified, then they are used for all backups. For this reason, the FORMAT string must allow for the creation of multiple backup pieces. Specifying the %U substitution variable is the easiest way to meet this requirement.

• It supports an optional RESTORE POINT clause that creates a normal restore point, which is a label for an SCN to which the backup must be recovered to be made consistent. The SCN is captured just after the data file backups complete. RMAN resynchronizes restore points with the recovery catalog and maintains the restore points as long as the backup exists. "Listing Restore Points" explains how to display restore points.

Making an Archival Backup for Long-Term Storage

Typically, you make an archival backup to tape. Because your data protection backups are most likely to be on a set of tapes that remain accessible and are recycled, it is advisable to earmark a set of tapes for the archival backup. You can write the archival backup to this special set of tapes and then place them in offsite storage.

You can vary the procedure for creating an archival backup by creating a stored script or shell script that updates dynamically. When you run the script, you can dynamically set the name of the restore point, backup format, and so on.

Making a Temporary Archival Backup

One purpose of an archival backup is for creating a test database. The technique for making a test database is essentially the same as the technique described in "Making an Archival Backup for Long-Term Storage". The difference is that you intend to delete the backup soon after creating it.

You can specify the temporary status of the backup with the BACKUP ... KEEP UNTIL parameter. Assume that you want to make a backup and then restore it to a new host the same day. In this case, you can specify KEEP UNTIL TIME SYSDATE+1 to indicate that RMAN should override the retention policy for this backup for only one day. After one day, the backup becomes obsolete, regardless of any configured backup retention policy.

The command in Example 9-11 makes an archival backup on a temporary disk with the tag TESTDB. The example creates a normal restore point, which is a label for the time to which the backup should be recovered. RMAN only backs up the archived redo logs if the database is open during the backup. Archived logs are not needed for offline backups and so are not backed up.

BACKUP DATABASE
  FORMAT '/disk1/oraclebck/%U' 
  TAG TESTDB 
  KEEP UNTIL TIME 'SYSDATE+1' 
  RESTORE POINT TESTDB06;

The recommended technique for restoring an archival backup is to use the DUPLICATE command. Refer to "Backup-Based Duplication Without a Target Connection: Example".

About Backups of Backups

You can use the BACKUP BACKUPSET command to back up backup sets produced by other backup jobs. You can also use BACKUP RECOVERY AREA to back up recovery files created in the current and all previous fast recovery area destinations. Recovery files are full and incremental backup sets, control file autobackups, data file copies, and archived redo logs. SBT and disk backups are supported for BACKUP RECOVERY AREA. For disk backups of the recovery files, you must use the TO DESTINATION option.

The preceding commands are especially useful in the following scenarios:

• Ensuring that all backups exist both on disk and on tape.

• Moving backups from disk to tape and then freeing space on disk. This task is especially important when the database uses a fast recovery area so that the space can be reused as needed.

You can also use the BACKUP COPY OF command to back up image copies of datafiles, control files, and archived redo logs. The output of this command can be either backup sets or image copies, so you can generate backup sets from image copies. This form of backup is used to back up a database backup created as image copies on disk to tape.

Backing Up Backup Sets with RMAN

This section explains how to use the BACKUP BACKUPSET command to copy backup sets from disk to tape. The procedure assumes that you have configured an SBT device as your default device.

To back up backup sets from disk to tape:

1. If you are backing up a subset of available backup sets, then execute the LIST BACKUPSET command to obtain their primary keys.

   The following example lists the backup sets in summary form:

   RMAN> LIST BACKUPSET SUMMARY;
   
   List of Backups
   ===============
   Key TY LV S Device Type Completion Time #Pieces #Copies Comp Tag
   --- -- -- - ----------- --------------- ------- ------- ---- ---
   1   B  F  A DISK        28-MAY-07       1       1       NO   TAG20070528T132432
   2   B  F  A DISK        29-MAY-07       1       1       NO   TAG20070529T132433
   3   B  F  A DISK        30-MAY-07       1       1       NO   TAG20070530T132434
   

   The following example lists details about backup set 3:

   RMAN> LIST BACKUPSET 3;
   
   List of Backup Sets
   ===================
   
   BS Key  Type LV Size       Device Type Elapsed Time Completion Time
   ------- ---- -- ---------- ----------- ------------ ---------------
   3       Full    8.33M      DISK        00:00:01     30-MAY-07
           BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20070530T132434
           Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02
     Control File Included: Ckp SCN: 397221       Ckp time: 30-MAY-07
     SPFILE Included: Modification time: 30-MAY-07
     SPFILE db_unique_name: PROD
   

2. Execute the BACKUP BACKUPSET command.

   The following example backs up all disk backup sets to tape and then deletes the input disk backups:

   BACKUP BACKUPSET ALL
     DELETE INPUT;
   

   The following example backs up only the backup sets with the primary key 1 and 2 to tape and then deletes the input disk backups:

   BACKUP BACKUPSET 1,2
     DELETE INPUT;
   

3. Optionally, execute the LIST command to see a listing of backup sets and pieces.

   The output lists all copies, including backup piece copies created by BACKUP BACKUPSET.

Backing Up Image Copy Backups with RMAN

This section explains how to use the BACKUP command to back up image copies to tape. It is assumed that you have configured an SBT device as your default device.

When backing up image copies that have multiple copies of the datafiles, specifying tags for the backups makes it easier to identify the input image copy. All image copies of datafiles have tags. The tag of an image copy is inherited by default when the image copy is backed up as a new image copy.

To back up image copies from disk to tape:

1. Issue the BACKUP ... COPY OF or BACKUP DATAFILECOPY command.

   The following example backs up data file copies that have the tag DBCopy:

   BACKUP DATAFILE COPY FROM TAG monDBCopy;
   

   The following example backs up the latest image copies of a database to tape, assigns the tag QUARTERLY_BACKUP, and deletes the input disk backups:

   BACKUP DEVICE TYPE sbt
     TAG "quarterly_backup"
     COPY OF DATABASE 
     DELETE INPUT;
   

2. Optionally, issue the LIST command to see a listing of backup sets. The output lists all copies, including backup piece copies created by the BACKUP BACKUPSET command.