5 Configuring the RMAN Environment

About Channel Configuration

Use the CONFIGURE CHANNEL command to configure options for disk or SBT channels. CONFIGURE CHANNEL takes the same options used to specify one-time options with the ALLOCATE CHANNEL command. You can configure generic channel settings for a device type, that is, a template that is used for any channels created based on configured settings for that device.

If you use CONFIGURE CHANNEL to specify generic channel settings for a device, any previous settings are discarded, even if the settings are not in conflict. For example, after the second CONFIGURE CHANNEL command, which specifies only the FORMAT for configured disk channels, the MAXPIECESIZE for the disk channel is returned to its default value:

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /tmp/%U;

Configuring Channels for Disk

By default, RMAN allocates one disk channel for all operations. You may want to specify different options for this channel, for example, a new default location for backups. Example 5-2 configures RMAN to write disk backups to the /disk1 directory and specifies a nondefault format for the relative filename:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/ora_df%t_s%s_s%p';

In Example 5-2, RMAN automatically replaces the format specifier %t with a four byte time stamp, %s with the backup set number, and %p with the backup piece number.

You can also specify an ASM disk location, as shown in the following example:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';

Configuring Channel Parallelism for Disk and SBT Devices

The number of channels available for a device type when you run a command determines whether RMAN reads or writes in parallel. As a rule, the number of channels used in executing a command should match the number of devices accessed. Thus, for tape backups, allocate one channel for each tape drive. For disk backups, allocate one channel for each physical disk, unless you can optimize the backup for your disk subsystem architecture with multiple channels. Failing to allocate the right number of channels adversely affects RMAN performance during I/O operations.

You can configure channel parallelism settings, binary compression for backup sets, and other options for an SBT device with CONFIGURE DEVICE TYPE sbt. You set the configuration for the device type independently of the channel configuration.

Example 5-3 changes the parallelism for the SBT device (sample output included) so that RMAN can back up to a media manager using two tape drives in parallel. Each configured SBT channel backs up roughly half the total data.

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters are successfully stored

Example 5-4 changes the default backup type for the SBT device to an uncompressed backup set (sample output included).

RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;
 
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2;
new RMAN configuration parameters are successfully stored

The CONFIGURE DEVICE TYPE commands used in this example to set parallelism and backup type do not affect the values of settings not specified. In Example 5-3, the default backup type of compressed backup set was not changed by changing the parallelism. In Example 5-4, the parallelism was not changed by changing the default backup type.

Manually Overriding Configured Channels

If you manually allocate a channel during a job, then RMAN disregards any configured channel settings. For example, assume that the default device type is SBT, and you execute the following command:

RUN 
{
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  BACKUP TABLESPACE users;
}

In this case, RMAN uses only the disk channel that you manually allocated within the RUN command, overriding any defaults set by using CONFIGURE DEVICE TYPE, CONFIGURE DEFAULT DEVICE, or CONFIGURE CHANNEL settings.

Configuring the Control File Autobackup Format

By default, the format of the autobackup file for all configured devices is the substitution variable %F in the FORMAT clause. This variable format translates into c-IIIIIIIIII-YYYYMMDD-QQ, with the placeholders defined as follows:

• IIIIIIIIII stands for the DBID.

• YYYYMMDD is a time stamp of the day the backup is generated.

• QQ is the hexadecimal sequence that starts with 00 and has a maximum of FF.

You can change the default format by using the following command, where deviceSpecifier is any valid device type, and 'string' must contain the substitution variable %F (and no other substitution variables) and is a valid handle for the specified device:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 
  FOR DEVICE TYPE deviceSpecifier TO 'string';

For example, you can run the following command to specify a nondefault filename for the control file autobackup. In the filename, ? stands for ORACLE_HOME.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 
  FOR DEVICE TYPE DISK TO '?/oradata/cf_%F';

The following example configures the autobackup to write to an Automatic Storage Management disk group:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 
  FOR DEVICE TYPE DISK TO '+dgroup1/%F';

To clear control file autobackup formats for a device, use the following commands:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR;

If you have set up a fast recovery area for the database, then you can direct control file autobackups to the fast recovery area by clearing the control file autobackup format for disk.

Overriding the Configured Control File Autobackup Format

The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN command or at the RMAN prompt, overrides the configured autobackup format in the current session only. The order of precedence is:

1. SET CONTROLFILE AUTOBACKUP FORMAT (within a RUN block)

2. SET CONTROLFILE AUTOBACKUP FORMAT (at RMAN prompt)

3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

The following example shows how the two forms of SET CONTROLFILE AUTOBACKUP FORMAT interact:

SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%F';
BACKUP AS COPY DATABASE;
RUN
{ 
  SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck'; 
  BACKUP AS BACKUPSET 
    DEVICE TYPE DISK 
    DATABASE;
}

The first SET CONTROLFILE AUTOBACKUP FORMAT controls the name of the control file autobackup until the RMAN client exits, overriding any configured control file autobackup format. The SET CONTROFILE AUTOBACKUP FORMAT in the RUN block overrides the SET CONTROLFILE AUTOBACKUP FORMAT outside the RUN block for the duration of the RUN block.

Testing ALLOCATE CHANNEL on the Media Manager

The following steps use the ALLOCATE CHANNEL command to perform a basic test that RMAN is able to communicate with the media manager.

To test channel allocation on the media manager:

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

2. Run the ALLOCATE CHANNEL command with the PARMS required by your media management software.

   The following RUN command shows sample vendor-specific PARMS settings:

   RUN
   {
     ALLOCATE CHANNEL c1 DEVICE TYPE sbt
       PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
       ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
   }
   

3. Examine the RMAN output.

   If you do not receive an error message, then the database successfully loaded the media management library. If you receive the ORA-27211 error, the media management library could not be loaded:

   RMAN-00571: ===========================================================
   RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
   RMAN-00571: ===========================================================
   RMAN-03009: failure of allocate command on c1 channel at 11/30/2007 13:57:18
   ORA-19554: error allocating device, device type: SBT_TAPE, device name: 
   ORA-27211: Failed to load Media Management Library
   Additional information: 25
   

   In this case, you must check the media management installation to make sure that the library is correctly installed, and re-check the value for the SBT_LIBRARY parameter as described in "Determining the Location of the Media Management Library".

   If the database is unable to locate a media management library in the location specified by the SBT_LIBRARY parameter or the default location, then RMAN issues an ORA-27211 error and exits.

Whenever channel allocation fails, the database writes a trace file to the trace subdirectory in the Automatic Diagnostic Repository (ADR) home directory. The following shows sample output:

SKGFQ OSD: Error in function sbtinit on line 2278
SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log
SBT Initialize failed for /oracle/lib/libobk.so

Testing Backup and Restore Operations on the Media Manager

After testing a channel allocation on the media manager, create and restore a test backup. For example, you can use the command in Example 5-6 (substituting the channel settings required by your media management vendor) to test whether a backup can be created on the media manager. If your database does not use a server parameter file, then back up the current control file instead.

RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt
    PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
    ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
  BACKUP SPFILE;
  # If your database does not use a server parameter file, use:
  # BACKUP CURRENT CONTROLFILE;
}

If the backup succeeds, then attempt to restore the server parameter file as an initialization parameter file. Example 5-7 restores the backup created in Example 5-6 to a temporary directory.

RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt
    PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so,
    ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)';
  RESTORE SPFILE TO PFILE '/tmp/test_restore.f';
  # If your database does not use a server parameter file, use:
  # RESTORE CURRENT CONTROLFILE TO '/tmp/test_restore.f';
}

If the backup and restore operations succeed, then you are ready to use the media manager with RMAN. Possible failures include the following cases:

• The backup hangs.

  A hanging backup usually indicates that the media manager is waiting to mount a tape. Check if there are any media manager jobs in tape mount request mode and fix the problem. Ensure that the steps in "Configuring RMAN to Make Backups to a Media Manager" are correctly done.

• The backup fails with ORA-27211: Failed to load Media Management Library.

  This error indicates that the media management software is not correctly configured. Ensure that the steps in "Configuring RMAN to Make Backups to a Media Manager" are correctly done. Also, ensure that you have the correct PARMS and FORMAT strings required by your media management software.

About Media Manager Backup Piece Names

A backup piece name is determined by the FORMAT string specified in the BACKUP command, CONFIGURE CHANNEL command, or ALLOCATE CHANNEL command. The media manager considers the backup piece name as the name of the backup file, so every backup piece must have a unique name in the media management catalog.

You can use the substitution variables in a FORMAT parameter to generate unique backup piece names. For example, %d specifies the name of the database, whereas %t specifies the backup timestamp. For most purposes, you can use %U, in which case RMAN automatically generates a unique filename. The backup piece name 12i1nk47_1_1 is an example. If you do not specify the FORMAT parameter, then RMAN automatically generates a unique filename with the %U substitution variable.

Your media manager may impose restrictions on file names and sizes. In this case, you may need more fine-grained control over the naming of backup pieces so that they obey media manager restrictions. For example, some media managers only support a 14-character backup piece name, and some require special FORMAT strings. The unique names generated by the %U substitution variable do not exceed 14 characters.

Some media managers may have limits on the maximum size of files that they can back up or restore. You must ensure that RMAN does not produce backup sets larger than those limits. To limit backup piece sizes, use the parameter MAXPIECESIZE, which you can set in the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands.

Configuring Automatic SBT Channels

The easiest technique for backing up to a media manager is to configure automatic SBT channels. As explained in "Configuring the Default Device for Backups: Disk or SBT", you can use a tape device as your default backup destination.

To configure channels for use with a media manager:

1. Configure a generic SBT channel.

   In the configuration enter all parameters that you tested in the section "Testing Backup and Restore Operations on the Media Manager". The following example configures vendor-specific channel parameters and sets the default device:

   CONFIGURE CHANNEL DEVICE TYPE sbt 
     PARMS 'ENV=(OB_RESOURCE_WAIT_TIME=1minute,OB_DEVICE=tape1)';
   

2. Configure the default device type to SBT, as shown in the following command:

   CONFIGURE DEFAULT DEVICE TYPE TO sbt;
   

   If you use more than one tape device, then you must specify the channel parallelism as described in "Configuring Channel Parallelism for Disk and SBT Devices". The following configuration enables you to back up to two tape drives in parallel:

   CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
   

   Optionally, check your channel configuration by running the following command:

   SHOW CHANNEL FOR DEVICE TYPE sbt;
   

3. Make a test backup to tape.

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

   BACKUP SPFILE;
   

4. List your backups to make sure that the test backup went to the media manager:

   LIST BACKUP OF SPFILE;
   

Oracle Managed Files and Automatic Storage Management

The fast recovery area can be used in conjunction with Oracle Managed Files (OMF) and Automatic Storage Management (ASM). The fast recovery area is built on top of OMF, so the fast recovery area can be stored anywhere Oracle Managed Files can. You can also use the recovery area with ASM.

Even if you choose not to set up the fast recovery area in ASM storage, you can still use Oracle Managed Files to manage your backup files in an ASM disk group. Although you lose one of the major benefits of the fast recovery area: the automatic deletion of files no longer needed to meet your recoverability goals as space is needed for more recent backups. Nevertheless, the other automatic features of OMF still function.

When storing backups, using OMF on top of ASM without using a fast recovery area is supported but discouraged. It is awkward to directly manipulate files under ASM.

How Oracle Manages Disk Space in the Fast Recovery Area

Space in the fast recovery area is balanced among backups and archived logs that must be kept according to the retention policy, and other files which may be subject to deletion. Oracle Database does not delete eligible files from the fast recovery area until the space must be reclaimed for some other purpose. Thus, files recently moved to tape are often still available on disk for use in recovery. The recovery area can thus serve as a cache for tape. When the fast recovery area is full, Oracle Database automatically deletes eligible files to reclaim space in the recovery area as needed.

Considerations When Setting the Size of the Fast Recovery Area

The larger the fast recovery area is, the more useful it becomes. Ideally, the fast recovery area should be large enough to contain the files listed in Table 5-2. The recovery area should be able to contain a copy of all datafiles in the database and the incremental backups used by your chosen backup strategy.

If providing this much space is impractical, then it is best to create an area large enough to keep a backup of the most important tablespaces and all the archived logs not yet on tape. At an absolute minimum, the fast recovery area must be large enough to contain the archived redo logs not yet on tape. If the recovery area has insufficient space to store flashback logs and meet other backup retention requirements, then the recovery area may delete flashback logs to make room.

Formulas for estimating a useful fast recovery area size depend on whether:

• Your database has a small or large number of data blocks that change frequently

• You store backups only on disk, or on disk and tape

• You use a redundancy-based backup retention policy, or a recovery window-based retention policy

• You plan to use Flashback Database or a guaranteed restore point as alternatives to point-in-time recovery in response to logical errors

If you plan to enable flashback logging, then the volume of flashback log generation is approximately the same order of magnitude as redo log generation. For example, if you intend to set DB_FLASHBACK_RETENTION_TARGET to 24 hours, and if the database generates 20 GB of redo in a day, then a rule of thumb is to allow 20 GB to 30 GB disk space for the flashback logs. The same rule applies to guaranteed restore points when flashback logging is enabled. For example, if the database generates 20 GB redo every day, and if the guaranteed restore point is kept for a day, then plan to allocate 20 to 30 GB.

Suppose that you want to determine the size of a flash recovery when the backup retention policy is set to REDUNDANCY 1 and you intend to follow the Oracle Suggested Strategy of using an incrementally updated backup. In this example, you use the following formula to estimate the disk quota, where n is the interval in days between incremental updates and y is the delay in applying the foreign archived redo logs on a logical standby database:

Disk Quota =
Size of a copy of database +
Size of an incremental backup +
Size of (n+1) days of archived redo logs +
Size of (y+1) days of foreign archived redo logs (for logical standby) +
Size of control file +
Size of an online redo log member * number of log groups +
Size of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value)

Considerations When Setting the Location of the Fast Recovery Area

Place the fast recovery area on a separate disk from the database area, where the database maintains active database files such as datafiles, control files, and online redo logs. Keeping the fast recovery area on the same disk as the database area exposes you to loss of both your live database files and backups if a media failure occurs.

Oracle recommends that DB_RECOVERY_FILE_DEST be set to a different value from DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_DEST_n initialization parameters. The database writes a warning to the alert log if DB_RECOVERY_FILE_DEST is the same as these parameters.

Multiple databases can have the same value for DB_RECOVERY_FILE_DEST, but one of the following must be true:

• No two databases for which the DB_UNIQUE_NAME initialization parameters are specified have the same value for DB_UNIQUE_NAME.

• For those databases where no DB_UNIQUE_NAME is provided, no two databases have the same value for DB_NAME.

When databases share a single recovery area in this way, the location should be large enough to hold the files for all databases. Add the values for DB_RECOVERY_FILE_DEST_SIZE for the databases, then allow for overhead such as mirroring or compression.

Setting the Fast Recovery Area Location and Initial Size

Table 5-3 lists the initialization parameters that you must set to enable the fast recovery area. This section explains how to specify a location for the recovery area and set its initial size.

To determine the optimum size for the fast recovery area:

1. If you plan to use flashback logging or guaranteed restore points, then query V$ARCHIVED_LOG to determine how much redo the database generates in the time to which you intend to set DB_FLASHBACK_RETENTION_TARGET.

2. Set the recovery area size.

   If you plan to use flashback logging or guaranteed restore points, then ensure that the size value obtained from step 1 is incorporated into the setting. Set the DB_RECOVERY_FILE_DEST_SIZE initialization parameter by any of the following means:

   • Shut down the database and set the DB_RECOVERY_FILE_DEST_SIZE parameter in the initialization parameter file of the database, as shown in the following example:

     DB_RECOVERY_FILE_DEST_SIZE = 10G
     

   • Specify them with the SQL statement ALTER SYSTEM SET when the database is open, as shown in the following examples:

     ALTER SYSTEM SET 
       DB_RECOVERY_FILE_DEST_SIZE = 10G 
       SCOPE=BOTH SID='*';
     

   • Use the Database Configuration Assistant to set the size

3. Set the recovery area location.

   Set the initialization parameters by any of the following means:

   • Set DB_RECOVERY_FILE_DEST in the initialization parameter file of the database, as shown in the following example:

     DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area'
     

   • Specify DB_RECOVERY_FILE_DEST with the SQL statement ALTER SYSTEM SET when the database is open, as shown in the following example:

     ALTER SYSTEM SET
       DB_RECOVERY_FILE_DEST = '+disk1' 
       SCOPE=BOTH SID='*';
     

   • Use the Database Configuration Assistant to set the location

   If you do not plan to use flashback logging, then open the database (if it is closed) and do not complete the rest of the steps in this procedure.

4. If flashback logging is enabled, then run the database under a normal workload for the time period specified by DB_FLASHBACK_RETENTION_TARGET.

   In this way, the database can generate a representative sample of flashback logs.

5. Query the V$FLASHBACK_DATABASE_LOG view as follows:

   SELECT ESTIMATED_FLASHBACK_SIZE 
   FROM   V$FLASHBACK_DATABASE_LOG;
   

   The result is an estimate of the disk space needed to meet the current flashback retention target, based on the database workload since Flashback Database was enabled.

6. If necessary, adjust the flashback log space requirement based on the actual size of flashback logs generated during the time period specified by DB_FLASHBACK_RETENTION_TARGET.

Configuring Online Redo Log Locations

The initialization parameters that determine where online redo log files are created are DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST. Details of the effect of combinations of these parameters on online redo log creation can be found in Oracle Database SQL Language Reference in the description of the LOGFILE clause of the CREATE DATABASE statement.

The following SQL statements can create online redo logs in the fast recovery area:

• CREATE DATABASE

• ALTER DATABASE ADD LOGFILE

• ALTER DATABASE ADD STANDBY LOGFILE

• ALTER DATABASE OPEN RESETLOGS

The default size of an online log created in the fast recovery area is 100 MB. The log member filenames are automatically generated by the database.

Configuring Control File Locations

The initialization parameters CONTROL_FILES, DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST all interact to determine the location where the database control files are created. For a full description of how these parameters interact, see the "Semantics" section of the description of CREATE CONTROLFILE in Oracle Database SQL Language Reference.

If the database creates an Oracle managed control file, and if the database uses a server parameter file, then the database sets the CONTROL_FILES initialization parameter in the server parameter file. If the database uses a client-side initialization parameter file, then you must set the CONTROL_FILES initialization parameter manually in the initialization parameter file.

Configuring Archived Redo Log Locations

It is recommended that you the use fast recovery area as an archiving location because the archived logs are automatically managed by the database. The generated filenames for the archived logs in the fast recovery area are for Oracle Managed files and are not determined by LOG_ARCHIVE_FORMAT. Whatever archiving scheme you choose, it is always advisable to create multiple copies of archived redo logs.

You have the following basic options for archiving redo logs, listed from most to least recommended:

1. Enable archiving to the fast recovery area only and use disk mirroring to create the redundancy needed to protect the archived redo logs.

   If DB_RECOVERY_FILE_DEST is specified and no LOG_ARCHIVE_DEST_n is specified, then LOG_ARCHIVE_DEST_10 is implicitly set to the recovery area. You can override this behavior by setting LOG_ARCHIVE_DEST_10 to an empty string.

2. Enable archiving to the fast recovery area and set other LOG_ARCHIVE_DEST_n initialization parameter to locations outside the fast recovery area.

   If a fast recovery area is configured, then you can add the fast recovery area as an archiving destination by setting any LOG_ARCHIVE_DEST_n parameter to LOCATION=USE_DB_RECOVERY_FILE_DEST.

3. Set LOG_ARCHIVE_DEST_n initialization parameters to archive only to non-fast recovery area locations.

If you use the fast recovery area, then you cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters. Using either of these parameters prevents you from starting the instance. Instead, set the LOG_ARCHIVE_DEST_n parameters. After your database is using LOG_ARCHIVE_DEST_n, you can configure a recovery area.

Note also that if you enable archiving but do not set any value for LOG_ARCHIVE_DEST, LOG_ARCHIVE_DEST_n, or DB_RECOVERY_FILE_DEST, then the redo logs are archived to a default location that is platform-specific. For example, on Solaris the default is ?/dbs.

Backup Optimization for SBT Backups with Recovery Window Retention Policy

Suppose that backup optimization is enabled, and a recovery window backup retention policy is in effect. In this case, when performing SBT backups RMAN always backs up datafiles whose most recent backup is older than the recovery window. For example, assume the following scenario:

• Today is February 21.

• The recovery window is 7 days.

• The most recent backup of tablespace tools to tape is January 3.

• Tablespace tools is read-only.

On February 21, when you issue a command to back up tablespace tools to tape, RMAN backs it up even though it did not change after the January 3 backup (because it is read-only). RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window.

This behavior enables the media manager to expire old tapes. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools indefinitely. By making a more recent backup of tablespace tools on February 21, RMAN enables the media manager to expire the tape containing the January 3 backup.

Backup Optimization for SBT Backups With Redundancy Retention Policy

Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only datafiles to SBT when there are r + 1 backups of the files, where r is set in CONFIGURE RETENTION POLICY TO REDUNDANCY r.

For example, assume that you enable backup optimization and set the following retention policy:

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

With these settings, RMAN only skips backups when three identical files are already backed up. Also assume that you have never backed up the users tablespace, which is read/write, and that you perform the actions described in Table 5-5 over the course of the week.

The backups on Tuesday, Wednesday, and Thursday back up the offline users tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). The Friday and Saturday backups do not back up the users tablespace because of backup optimization. The Tuesday backup of users is obsolete beginning on Thursday.

On Sunday, you delete all obsolete backups, which removes the Tuesday backup of users. The Tuesday backup is obsolete because of the retention policy setting. The whole database backup on Monday then backs up the users tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). In this way, you can recycle your tapes over time.

When the Archived Redo Log Deletion Policy Is Disabled

By default, there is no archived redo log deletion policy and this is why the archive redo log policy is set to the NONE clause. In this particular case, the fast recovery area considers archived redo log files in the recovery area as eligible for deletion if they have been backed up at least once to disk or SBT or the logs are obsolete according to the backup retention policy. The backup retention policy considers logs obsolete only if the logs are not needed by a guaranteed restore point and the logs are not needed by Oracle Flashback Database. Archived redo logs are needed by Flashback Database if the logs were created later than SYSDATE-'DB_FLASHBACK_RETENTION_TARGET'.

When the Archived Redo Log Deletion Policy Is Enabled

You can use the CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPE command to enable an archived log deletion policy. This configuration specifies that archived logs are eligible for deletion only when the specified number of archived log backups exist on the specified device type.

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. In this way, the archived log deletion policy functions as a default NOT BACKED UP integer TIMES clause on the BACKUP ARCHIVELOG command. You can override the deletion policy by specifying the FORCE option on the BACKUP command.

The archived log deletion policy also has options specific to a Data Guard environment. For example, if you specify the APPLIED ON STANDBY clause, then RMAN can delete logs after they have been applied at all mandatory remote destinations. If you specify SHIPPED TO STANDBY, for example, then RMAN can delete logs when they have been transferred to all mandatory standby destinations.

Flashback Database

Oracle Flashback Database is accessible through the RMAN command FLASHBACK DATABASE or through the SQL statement FLASHBACK DATABASE. You can use either command to quickly recover the database from logical data corruptions or user errors.

Flashback Database is similar to conventional point-in-time recovery in its effects, enabling you to return a database to its state at a time in the recent past. Flashback Database is much faster than point-in-time recovery, however, because it does not require restoring datafiles from backup and requires applying fewer changes from the archived redo logs.

You can use Flashback Database to reverse most unwanted changes to a database as long as the datafiles are intact. You can return a database to its state in a previous incarnation, and undo the effects of an ALTER DATABASE OPEN RESETLOGS statement. "Rewinding a Database with Flashback Database" explains how to use the FLASHBACK DATABASE command to reverse database changes.

Flashback Database uses its own logging mechanism, creating flashback logs and storing them in the fast recovery area. You can only use Flashback Database if flashback logs are available. Thus, to take advantage of this feature you must set up your database in advance to create flashback logs.

To enable Flashback Database, you configure a fast recovery area and set a flashback retention target. This retention target specifies how far back you can rewind a database with Flashback Database. From the target time onwards, the database regularly copies images of every changed block in the datafiles to the flashback logs.

When you use Flashback Database to rewind a database to a past target time, the command determines which blocks changed after the target time and restores them from the flashback logs. The database restores the version of each block that is most immediately prior to the target time. The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs.

Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example, if the flashback retention target is one week, then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. In practice, redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery.

Normal Restore Points

A normal restore point assigns a restore point name to an SCN or specific point in time. Thus, a restore point functions as a bookmark or alias for this SCN. Before performing any operation that you may have to reverse, you can create a normal restore point. The control file stores the name of the restore point and the SCN.

If you need to use flashback features or point-in-time recovery, then you can use the name of the restore point instead of a time or SCN. The following commands support this use of restore points:

• The RECOVER DATABASE and FLASHBACK DATABASE commands in RMAN

• The FLASHBACK TABLE statement in SQL

A normal restore point eliminates the need to manually record an SCN in advance or determine the correct SCN after the fact by using features such as Flashback Query.

Normal restore points are lightweight. The control file can maintain a record of thousands of normal restore points with no significant impact on database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.

Guaranteed Restore Points

Like a normal restore point, a guaranteed restore point serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore points never age out of the control file and must be explicitly dropped. In general, you can use a guaranteed restore point as an alias for an SCN with any command that works with a normal restore point. Except as noted, the information about where and how to use normal restore points applies to guaranteed restore points as well.

A guaranteed restore point ensures that you can use Flashback Database to rewind a database to its state at the restore point SCN, even if the generation of flashback logs is disabled. If flashback logging is enabled, then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point. Thus, if flashback logging is enabled, you can rewind the database to any SCN in the continuum rather than to a single SCN only.

If the recovery area has enough disk space to store the needed logs, then you can use a guaranteed restore point to rewind a whole database to a known good state days or weeks ago. As with Flashback Database, even the effects of NOLOGGING operations like direct load inserts can be reversed with guaranteed restore points.

Logging for Flashback Database and Guaranteed Restore Points

Logging for Flashback Database and guaranteed restore points involves capturing images of datafile blocks before changes are applied. The FLASHBACK DATABASE command can use these images to return the datafiles to their previous state.

The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be deleted in response to space pressure in the fast recovery area. These differences affect space usage for logs and database performance.

Your recoverability goals partially determine whether to enable logging for flashback database, use guaranteed restore points, or both. The implications in performance and in space usage for these features, separately and when used together, should also factor into your decision.