The ALLOCATE CHANNEL command is used to perform a basic test of RMAN communication with 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, check the media management installation to ensure that the library is correctly installed, and recheck the value for the SBT_LIBRARY parameter as described in Determining the Location of the Media Management Library.

   If the database cannot 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.

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

After testing a channel allocation on the media manager, create and restore a test backup.

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;
}

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';
}

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 time stamp. For most purposes, you can use %U, in which case RMAN automatically generates a unique file name. The backup piece name 12i1nk47_1_1 is an example. If you do not specify the FORMAT parameter, then RMAN automatically generates a unique file name with the %U substitution variable.

Your media manager may impose restrictions on file names and sizes. In this case, you may need more 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 andALLOCATE CHANNEL commands.

The easiest technique for backing up to a media manager is to configure automatic SBT channels

1. Configure a generic SBT channel.

   In the configuration, enter all parameters that you tested in "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 multiple tape devices, then you must specify the channel parallelism as described in "Configuring Parallel Channels 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 ensure that the test backup went to the media manager:

   LIST BACKUP OF SPFILE;

The fast recovery area can be used with Oracle Managed Files (OMF) and Automatic Storage Management (ASM)

Because the fast recovery area is built on top of OMF, it can be stored anywhere that 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. However, you lose a major benefit 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 your store 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.

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 that 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. However, starting with Oracle Database Release 19c, flashback logs that are beyond the configured retention period are automatically deleted. 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.

The larger the fast recovery area is, the more useful it becomes. Ideally, the fast recovery area is large enough to contain the control files, online redo logs, archived redo logs, and flashback logs. It should be able to contain a copy of all data files 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 new flashback logs and meet other backup retention requirements, then to make room, the recovery area may delete older flashback logs.

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 gigabytes of redo in a day, then a general rule of thumb is to allow 20 GB to 30 GB of 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 of 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 fast recovery area when the backup retention policy is set to REDUNDANCY 1 and you intend to follow Oracle's suggested strategy of using an incremental forever. 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)

Place the fast recovery area on a separate disk from the database area, where the database maintains active database files such as data files, 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 equals 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.

Use database initialization parameters to set the location and size of 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 the parameter 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='*';
     

     Note:

     The DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST settings must be persistent across database startup and shutdown. If a server parameter file is used, then setting SCOPE=BOTH results in the settings being persistent. However, if a server parameter file is not used, then the changes made by the ALTER SYSTEM command are not persistent. You must also add these parameters to the initialization parameter file.

   • 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 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.

     The following example sets the fast recovery area to an Automatic Storage Management (ASM) disk group named disk1:

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

     The following example sets the fast recovery area to the file system directory /disk1/fast_recovery_area:

     ALTER SYSTEM SET 
       DB_RECOVERY_FILE_DEST = '/disk1/fast_recovery_area'
       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.

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 data files 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 is 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.

Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only data files 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 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.

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'.

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 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, then RMAN can delete logs when they have been transferred to all mandatory standby destinations.