Skip Headers
Oracle® Database Backup and Recovery User's Guide
11g Release 1 (11.1)

B28270-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 Configuring the RMAN Environment

This chapter explains the most basic tasks involved in configuring RMAN. This chapter includes the following topics:

See Also:

Chapter 6, "Configuring the RMAN Environment: Advanced Topics" to learn about configuration options not covered in this chapter, including backup compression and encryption

Configuring the Environment for RMAN Backups

For most parameters required for backups, RMAN provides sensible defaults that enable you to perform basic backup and recovery. When implementing an RMAN-based backup strategy, you can use RMAN more effectively if you understand the more common configurations.

To simplify ongoing use of RMAN, you can set a number of persistent configuration settings for each target database. These settings control many aspects of RMAN behavior. For example, you can configure the backup retention policy, default destinations for backups, default backup device type, and so on. You can use the SHOW and CONFIGURE commands to view and change RMAN configurations.

This section explains what an RMAN configuration is and how you can use the CONFIGURE command to change RMAN default behavior for your backup and recovery environment. This section also introduces the major settings available to you and their most common values.

Note:

If you plan to back up to tape, then refer to "Configuring RMAN to Make Backups to a Media Manager" to learn how to set up RMAN for use with a media manager.

This section includes the following topics:

See Also:

Oracle Database Backup and Recovery Reference for CONFIGURE syntax

Showing and Clearing Persistent RMAN Configurations

You can use the SHOW command to display the current value of RMAN configured settings for the target database. You can also view whether these commands are currently set to their default values.

To view or change your CONFIGURE command settings:

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

Run the RMAN SHOW command.

For example, run SHOW ALL as shown in Example 5-1 (sample output included). The output includes parameters you have changed and that are set to the default. The configuration is displayed as the series of RMAN commands required to re-create the configuration. You can save the output in a text file and use this command file to re-create the configuration on the same or a different database.

Example 5-1 SHOW ALL Command

SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default

You can also use the SHOW command with the name of a particular configuration. For example, you can view the retention policy and default device type as follows:

SHOW RETENTION POLICY;
SHOW DEFAULT DEVICE TYPE;

Optionally, use the CONFIGURE ... CLEAR command to return any configuration to its default value, as shown in the following examples:

CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;

Configuring the Default Device for Backups: Disk or SBT

Backups for which no destination device type is specified are directed to the configured default device. RMAN is preconfigured to use disk as the default device type. No additional configuration is necessary.

You may need to change the default device type from disk to tape, or change it back from tape to disk. Table 5-1 shows the commands that configure the default device.

Table 5-1 Commands to Configure the Default Device Type

Command Explanation

CONFIGURE DEFAULT DEVICE TYPE TO DISK

Specifies that backups should go to disk by default.

If a recovery area is enabled, then the backup location defaults to the flash recovery area. Otherwise, the backup location defaults to an operating system-specific directory on disk.

When backing up to disk, the logical block size of the database file must be an even multiple of the physical block size of the destination device. For example, a device of type DISK with a block size of 2 KB can only be used as a destination for backups of database files with logical block sizes of 2 KB, 4 KB, 6 KB, and so on. Most disk drives have physical block sizes of 512 bytes, so this limitation rarely affects backup to disk drives. Nevertheless, you can encounter this limitation when backing up to a writable DVD or a device that has a larger physical block size.

CONFIGURE DEFAULT DEVICE TYPE TO sbt

Specifies that backups should go to tape by default.

"Configuring RMAN to Make Backups to a Media Manager" explains how to set up RMAN for use with a media manager. After RMAN is able to communicate with the media manager, you can configure RMAN to make backups to tape and specify SBT as the default device type.


Note that you can always override the default device by using the DEVICE TYPE clause of the BACKUP command, as shown in the following examples:

BACKUP DEVICE TYPE sbt DATABASE;
BACKUP DEVICE TYPE DISK DATABASE;

To change the configured default device type:

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

Run the SHOW ALL command to show the currently configured default device.

Run the CONFIGURE DEFAULT DEVICE TYPE command, specifying either TO DISK or TO sbt.

See Also:

Oracle Database Backup and Recovery Reference for more details on using the BACKUP command with the DEVICE TYPE clause

Configuring the Default Type for Backups: Backup Sets or Copies

The BACKUP command can create either backup sets or image copies. For disk, you can configure RMAN to create either backup sets or image copies as its default backup type with the CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO command. The default backup type for disk is an uncompressed backup set.

Note:

Because RMAN can write an image copy only to disk, the backup type for tape can only be a backup set.

RMAN can create backup sets using binary compression. You can configure RMAN to use compressed backup sets by default on a device type by specifying the COMPRESSED option in the BACKUP TYPE TO ... BACKUPSET clause. To disable compression, use the CONFIGURE DEVICE TYPE command with arguments specifying your other desired settings, but omit the COMPRESSED keyword.

To configure the default type of backup:

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

    Configure backup sets or image copies as the default backup type.

    The following examples configure the backup type for disk backups to copies and backup sets:

    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed
    

    The following examples configure compression for backup sets:

    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
    CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
    

    See Also:

Configuring Channels

As explained in "RMAN Channels", an RMAN channel is a connection to a database server session. RMAN uses channels to perform almost all RMAN tasks.

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.

Note:

This section explains configuration of disk channels. To learn how to configure channels for tape, see "Configuring SBT Channels for Use with a Media Manager".

Note that 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 wish 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:

Example 5-2 Configuring a Nondefault Backup Location

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.

Note:

By configuring an explicit format for disk channels, RMAN does not create backups by default in the flash recovery area. In this case, you lose the disk space management capabilities of the flash recovery area.

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

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';

See Also:

"Backing Up Database Files with RMAN" to learn how to make backups

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 will read or write 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 will back up roughly half the total data.

Example 5-3 Configuring Parallelism for an SBT Device

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

Example 5-4 Configuring the Backup Type for an SBT Device

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

Note that 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.

See Also:

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.

See Also:

Configuring Control File and Server Parameter File Autobackups

As explained in "Control File and Server Parameter File Autobackups", you can configure RMAN to automatically back up the control file and server parameter file. The autobackup occurs whenever a backup record is added. If the database runs in ARCHIVELOG mode, then an autobackup is also taken whenever the database structure metadata in the control file changes. A control file autobackup enables RMAN to recover the database even if the current control file, recovery catalog, and server parameter file are lost.

Because the filename for the autobackup follows a well-known format, RMAN can search for it without access to a repository and then restore the server parameter file. After you have started the instance with the restored server parameter file, RMAN can restore the control file from an autobackup. After you mount the control file, the RMAN repository is available and RMAN can restore the datafiles and find the archived redo logs.

You can enable the autobackup feature by running the following command:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

You can disable the feature by running the following command:

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

See Also:

Oracle Database Backup and Recovery Reference for CONFIGURE syntax

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 hex 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 
  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 flash recovery area for the database, then you can direct control file autobackups to the flash 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:

SET CONTROLFILE AUTOBACKUP FORMAT (within a RUN block)

SET CONTROLFILE AUTOBACKUP FORMAT (at RMAN prompt)

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.

Configuring RMAN to Make Backups to a Media Manager

On most platforms, to back up to and restore from sequential media such as tape you must integrate a media manager with your Oracle database. You can use Oracle Secure Backup, which supports both database and file system backups to tape, as your media manager. You should refer to Oracle Secure Backup Administrator's Guide to learn how to set up RMAN for use specifically with Oracle Secure Backup.

If you do not use Oracle Secure Backup, then you can use a third-party media manager. This section describes the generic steps for configuring RMAN for use with a third-party media manager. The actual steps depend on the media management product that you install and the platform on which you are running the database. If you choose to use RMAN with a media manager other than Oracle Secure Backup, then you must obtain all product-specific information from the vendor.

Read the following sections in order when configuring the media manager:

Prerequisites for Using a Media Manager with RMAN

Determining the Location of the Media Management Library

Configuring Media Management Software for RMAN Backups

Testing Whether the Media Manager Library Is Integrated Correctly

Configuring SBT Channels for Use with a Media Manager

See Also:

"Media Management" for an overview of media management software and its implications for RMAN

Prerequisites for Using a Media Manager with RMAN

Before you can begin using RMAN with a third-party media manager, you must install it and make sure that RMAN can communicate with it. Refer to the media management vendor's software documentation for instructions.

In general, you should begin by installing and configuring the media management software on the target host or production network. Ensure that you can make non-RMAN backups of operating system files on the target database host. This step makes later troubleshooting much easier by confirming that the basic integration of the media manager with the target host has been successful. Refer to your media management documentation to learn how to back up files to the media manager without using RMAN.

Then, obtain and install the third-party media management module for integration with the database server. This module contains the media management library that the Oracle database loads and uses when accessing the media manager. It is generally a third-party product which must be purchased separately. Contact your media management vendor for details.

Determining the Location of the Media Management Library

Before attempting to use RMAN with a media manager, determine the location of the media management library. When allocating or configuring a channel for RMAN to use to communicate with a media manager, you must specify the SBT_LIBRARY parameter in an ALLOCATE CHANNEL or CONFIGURE CHANNEL command. The SBT_LIBRARY parameter specifies the path to the library.

The following example shows the channel syntax, where pathname is the absolute filename of the library:

CONFIGURE CHANNEL DEVICE TYPE sbt
  PARMS 'SBT_LIBRARY=pathname';

When RMAN allocates channels to communicate with a media manager, it attempts to load the library indicated by the SBT_LIBRARY parameter.

If you do not provide a value for the SBT_LIBRARY parameter in an allocated or preconfigured channel, then RMAN looks in a platform-specific default location. On Linux and UNIX, the default library filename is $ORACLE_HOME/lib/libobk.so, with the extension name varying according to platform: .so, .sl on HP-UX, .a on AIX, and so on. On Windows the default library location is %ORACLE_HOME%\bin\orasbt.dll.

Note:

The default media management library file is not part of the standard database installation. It is only present if you install third-party media management software.

See Also:

Your operating system-specific database documentation and the documentation supplied by your media vendor for instructions on how to achieve media manager integration on your platform

Configuring Media Management Software for RMAN Backups

After installing the media management software, perform whatever configuration that your vendor requires so that the software can accept RMAN backups. Depending on the type of media management software that you installed, you may have to define media pools, configure users and classes, and so on.

Consult your media management vendor documentation for the appropriate RMAN settings. The PARMS parameter sends instructions to the media manager. If PARMS values are needed for the ALLOCATE CHANNEL or the CONFIGURE CHANNEL command, or if a FORMAT string is recommended for the BACKUP or CONFIGURE command, then refer to the vendor documentation for this information.

Example 5-5 shows a PARMS setting for Oracle Secure Backup. This PARMS settings instructs the media manager to back up to a family of tapes called datafile_mf. The PARMS settings are always vendor-specific.

Example 5-5 PARMS Setting for Oracle Secure Backup

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE'
  PARMS 'ENV=(OB_MEDIA_FAMILY=datafile_mf)';

See Also:

Testing Whether the Media Manager Library Is Integrated Correctly

After you have confirmed that the database server can load the media management library, test to make sure that RMAN can back up to the media manager.

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:

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

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

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

See Also:

Oracle Database Administrator's Guide to learn how to use the Automatic Diagnostic Repository to monitor database operations

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

Example 5-6 Backing Up the Server Parameter File to Tape

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.

Example 5-7 Restoring the Server Parameter File from Tape

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

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.

Configuring SBT Channels for Use with a Media Manager

This section describes how to configure channels for use with a media manager. For an overview of configured channels and how they are used, refer to the section "Configuring Advanced Channel Options".

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. Note that the unique names generated by the %U substitution variable do not exceed 14 characters.

Note that 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.

See Also:

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:

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

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;

Make a test backup to tape.

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

BACKUP SPFILE;

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

LIST BACKUP OF SPFILE;

Configuring the Flash Recovery Area

As explained in "Flash Recovery Area", the flash recovery area feature enables you to set up a disk area where the database can create and manage a variety of files related to backup and recovery. Use of the flash recovery area is strongly recommended. Consider configuring a flash recovery area as one of the first steps in implementing a backup strategy.

This section outlines the functions of the flash recovery area, identifies the files stored there, explains the rules for file management, and introduces the most important configuration options. This section contains the following topics:

Overview of the Flash Recovery Area

The flash recovery area can contain control files, online redo logs, archived redo logs, flashback logs, and RMAN backups. Files in the recovery area are permanent or transient. Permanent files are active files used by the database instance. All files that are not permanent are transient. In general, Oracle Database eventually deletes transient files after they become obsolete under the backup retention policy or have been backed up to tape.

Table 5-2 describes the files in the recovery area, the classification of each file as permanent or temporary, and how database availability is affected.

Table 5-2 Files in the Flash Recovery Area

Files Type Database Behavior When Flash Recovery Area Is Inaccessible

Multiplexed copies of the current control file

Permanent

The instance fails if the database cannot write to a multiplexed copy of the control file stored in the flash recovery area. Failure occurs even if accessible multiplexed copies are located outside the recovery area.

See Also: "Configuring Control File Locations" to learn how to configure control files in the recovery area

Online redo log files

Permanent

Instance availability is not affected if a mirrored copy of the online redo log exists in an accessible location outside the flash recovery area. Otherwise, the instance fails.

See Also: "Configuring Online Redo Log Locations" to learn how to configure online redo logs in the recovery area

Archived redo log files

Transient

Instance availability is not affected if the log is archived to an accessible location outside the flash recovery area. Otherwise, the database eventually halts because it cannot archive the online redo logs.

See Also: "Configuring Archived Redo Log Locations" to learn how to configure archived redo logs in the recovery area

Foreign archived redo log files

Transient

Instance availability is not affected.

Note: Foreign archived redo logs are received by a logical standby database for a LogMiner session. Unlike a normal archived log, a foreign archived redo log has a different DBID. For this reason, it cannot be backed up or restored on a logical standby database.

Image copies of datafiles and control files

Transient

Instance availability is not affected.

Backup pieces

Transient

Instance availability is not affected.

Flashback logs

Transient

Instance availability is not affected if guaranteed restore points are not defined. In this case, the database automatically disables Flashback Database, writes a message to the alert log, and continues with database processing. If guaranteed restore points are configured, the instance fails because of interdependencies on the flashback logs.

The Oracle Flashback Database feature, which provides an convenient alternative to database point-in-time recovery (DBPITR), generates flashback logs. These logs are transient files and must be stored in the flash recovery area. Unlike other transient files, flashback logs cannot be backed up to other media. If the flash recovery area has insufficient space to store flashback logs and meet other backup retention requirements, then the recovery area may delete flashback logs.

See Also: "Enabling Flashback Database" to learn how to enable flashback logging


Note that if you are on a Windows platform, then you can use the Volume Shadow Copy Service (VSS) in conjunction with the Oracle VSS writer. In this case, the flash recovery area automates management of files that are already backed up in a VSS snapshot and deletes them as needed.

Oracle Managed Files and Automatic Storage Management

The flash recovery area can be used in conjunction with Oracle Managed Files (OMF) and Automatic Storage Management (ASM). The flash recovery area is built on top of OMF, so the flash 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 flash recovery area in ASM storage, you can still use Oracle Managed Files to manage your backup files in an ASM disk group. You will lose one of the major benefits of the flash 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 will still function.

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

How Oracle Manages Disk Space in the Flash Recovery Area

Space in the flash 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 flash 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 flash recovery area is full, Oracle Database automatically deletes eligible files to reclaim space in the recovery area as needed.

Enabling the Flash Recovery Area

To enable the recovery area, you must set the initialization parameters in Table 5-3 that are listed as required. Note that in an Oracle Real Application Clusters (Oracle RAC) database, all instances must have the same values for these initialization parameters. The location must be on a cluster file system, ASM, or a shared directory.

Table 5-3 Initialization Parameters for the Flash Recovery Area

Initialization Parameter Required Description

DB_RECOVERY_FILE_DEST_SIZE

Yes

Specifies the disk quota, which is maximum storage in bytes of data to be used by the recovery area for this database. You must set this parameter before DB_RECOVERY_FILE_DEST.

The DB_RECOVERY_FILE_DEST_SIZE setting does not include the following kinds of disk overhead:

  • Block 0 or the operating system block header of each Oracle file is not included.

    Allow an extra 10% for this data when computing the actual disk usage required for the flash recovery area.

  • DB_RECOVERY_FILE_DEST_SIZE does not indicate the real size occupied on disk when the underlying file system is mirrored, compressed, or affected by overhead not known to Oracle Database.

    For example, if the recovery area is on a two-way mirrored ASM disk group, each file of x bytes occupies 2x bytes on the ASM disk group. In this case, set DB_RECOVERY_FILE_DEST_SIZE to no more than half the size of the disks for the ASM disk group. Likewise, when using a three-way mirrored ASM disk group, DB_RECOVERY_FILE_DEST_SIZE must be no more than one third the size of the disks in the disk group, and so on.

DB_RECOVERY_FILE_DEST

Yes

Specifies the recovery area location, which can be a file system directory or ASM disk group, but not raw disk. The location must be large enough for the disk quota.

DB_FLASHBACK_RETENTION_TARGET

No

Specifies the upper limit (in minutes) on how far back in time the database may be flashed back. This parameter is required only for Flashback Database.

This parameter indirectly determines how much flashback log data is kept in the recovery area. The size of flashback logs generated by the database can vary considerably depending on the database workload. If more blocks are affected by database updates during a given interval, then more disk space is used by the flashback log data generated for that interval.


See Also:

Oracle Database SQL Language Reference for ALTER SYSTEM syntax, and Oracle Database Administrator's Guide for details on setting and changing database initialization parameters

Considerations When Setting the Size of the Flash Recovery Area

The larger the flash recovery area is, the more useful it becomes. Ideally, the flash 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 flash 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 flash 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 note that 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 will be 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 Flash Recovery Area

Place the flash 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 flash 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 Flash Recovery Area Location and Initial Size

Table 5-3 lists the initialization parameters that you must set to enable the flash 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 flash 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.

    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
      
  2. 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='*';
    
  3. Use the Database Configuration Assistant to set the size

    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'
      
  4. 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='*';
    
  5. 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.

    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.

    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.

    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 Locations for Control Files and Redo Logs

As explained in "Overview of the Flash Recovery Area", the only permanent files are multiplexed copies of the current control file and online redo logs. This section explains how to set locations for these files as well as the archived logs.

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 flash recovery area:

The default size of an online log created in the flash 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 flash 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 flash 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:

Enable archiving to the flash 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.

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

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

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

If you use the flash recovery area, then you cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters. If you do, then will not be able to start 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.

See Also:

Oracle Database Reference for details on the semantics of the LOG_ARCHIVE_DEST_n parameters

Configuring RMAN File Creation in the Flash Recovery Area

This section describes RMAN commands or implicit actions (such as control file autobackups) that can create files in the flash recovery area, and how to control whether a command creates files there or in another destination. The commands are:

  • BACKUP

    If you do not specify the FORMAT clause for disk backups, then RMAN creates backup pieces and image copies in the flash recovery area, with names in Oracle Managed Files name format. If a flash recovery area is enabled, and if you do specify FORMAT on BACKUP or a channel, then RMAN creates the backup in a platform-specific location rather than in the recovery area.

  • Control File Autobackup

    RMAN can create control file autobackups in the flash recovery area. Use the RMAN command CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR to clear any configured format option for the control file autobackup location on disk. RMAN creates control file autobackups in in the flash recovery area when no other destination is configured.

  • RESTORE ARCHIVELOG

    Explicitly or implicitly set one of the LOG_ARCHIVE_DEST_n parameters to LOCATION=USE_DB_RECOVERY_FILE_DEST. If you do not specify SET ARCHIVELOG DESTINATION to override this behavior, then RMAN restores archived redo log files to the flash recovery area.

  • RECOVER DATABASE or RECOVER TABLESPACE, RECOVER ... BLOCK, and FLASHBACK DATABASE

    These commands restore archived redo log files from backup for use during media recovery, as required by the command. RMAN restores any redo log files needed during these operations to the flash recovery area and deletes them after they are applied during media recovery.

    To direct the restored archived logs to the flash recovery area, set one of the LOG_ARCHIVE_DEST_n parameters to LOCATION = USE_DB_RECOVERY_FILE_DEST. Make sure you are not using SET ARCHIVELOG DESTINATION to direct restored logs to some other destination.

Configuring the Backup Retention Policy

As explained in "Backup Retention Policies", the backup retention policy specifies which backups must be retained to meet your data recovery requirements. This policy can be based on a recovery window or redundancy. Use the CONFIGURE RETENTION POLICY command to specify the retention policy.

See Also:

Oracle Database Backup and Recovery Reference for CONFIGURE syntax

Configuring a Redundancy-Based Retention Policy

The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many full or level 0 backups of each datafile and control file that RMAN should keep. In other words, if the number of full or level 0 backups for a specific datafile or control file exceeds the REDUNDANCY setting, then RMAN considers the extra backups as obsolete. The default retention policy is REDUNDANCY 1.

As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all archived logs and incremental backups that are needed to recover the nonobsolete backups.

Assume that you make a full backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four full backups of this datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup of datafile 7 becomes obsolete.

Assume a different case in which REDUNDANCY is 1. You run a level 0 database backup at noon Monday, a level 1 cumulative backup at noon on Tuesday and Wednesday, and a level 0 backup at noon on Thursday. Immediately after each daily backup you run a DELETE OBSOLETE. The Wednesday DELETE command does not remove the Tuesday level 1 backup because this backup is not redundant: the Tuesday level 1 backup could be used to recover the Monday level 0 backup to a time between noon on Tuesday and noon on Wednesday. However, the DELETE command on Thursday removes the previous level 0 and level 1 backups.

Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example:

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Configuring a Recovery Window-Based Retention Policy

The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window.

Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

RMAN does not automatically delete backups rendered obsolete by the recovery window. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.

Disabling the Retention Policy

When you disable the retention policy, RMAN does not consider any backup as obsolete. To disable the retention policy, run this command:

CONFIGURE RETENTION POLICY TO NONE;

Configuring the retention policy to NONE is not the same as clearing it. Clearing it returns it to its default setting of REDUNDANCY 1, whereas NONE disables it.

If you disable the retention policy and run REPORT OBSOLETE or DELETE OBSOLETE without passing a retention policy option to the command, then RMAN issues an error because no retention policy exists to determine which backups are obsolete.

Note:

If you are using a flash recovery area, then you should not run your database with the retention policy disabled. If files are never considered obsolete, then a file can only be deleted from the flash recovery area if it has been backed up to some other disk location or to a tertiary storage device such as tape. It is likely that all of the space in your recovery area will be used, which interferes with the normal operation of your database. See "How Oracle Manages Disk Space in the Flash Recovery Area".

Configuring Backup Optimization

Run the CONFIGURE command to enable and disable backup optimization. Backup optimization skips the backup of files in certain circumstances if the identical file or an identical version of the file has already been backed up.

Overview of Backup Optimization

If you enable backup optimization, then the BACKUP command skips backing up files when the identical file has already been backed up to the specified device type. Table 5-4 describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up.

Table 5-4 Criteria to Determine an Identical File

Type of File Criteria to Determine an Identical File

Datafile

The datafile must have the same DBID, checkpoint SCN, creation SCN, and RESETLOGS SCN and time as a datafile already in a backup. The datafile must be offline-normal, read-only, or closed normally.

Archived log

Same DBID, thread, sequence number, and RESETLOGS SCN and time.

Backup set

Same DBID, backup set record ID and stamp.


If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. RMAN must do further checking to determine whether to skip the file, however, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type.

RMAN uses backup optimization when the following conditions are true:

  • The CONFIGURE BACKUP OPTIMIZATION ON command has been run to enable backup optimization.

  • You run BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP BACKUPSET ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES, or BACKUP DATAFILECOPY.

  • Only one type of channel is allocated, that is, you do not mix disk and SBT channels in the same backup command.

Note:

In backup undo optimization, RMAN excludes undo that is not needed for recovery of a backup, that is, for transactions that have already been committed. You can enable and disable backup optimization, but backup undo optimization is built-in behavior.

For example, assume that you have configured backup optimization. These commands back up to tape the database, all archived logs, and all backup sets:


BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
BACKUP DEVICE TYPE sbt BACKUPSET ALL;

If none of the backed-up files has changed since the last backup, then RMAN does not back up the files again. RMAN also does not signal an error if it skips all files specified in the command because the files have already been backed up.

You can override optimization at any time by specifying the FORCE option on the BACKUP command. For example, you can run:

BACKUP DATABASE FORCE;
BACKUP ARCHIVELOG ALL FORCE;

See Also:

The CONFIGURE entry in Oracle Database Backup and Recovery Reference for a complete description of the backup optimization rules

Effect of Retention Policies on Backup Optimization for SBT Backups

Backup optimization is not always applied when backing up to SBT devices. The exceptions to normal backup optimization behavior for recovery window-based and redundancy-based retention policies are described in the following sections.

Note:

Use caution when enabling backup optimization if you use a media manager with its own internal expiration policy. Run the CROSSCHECK command periodically to synchronize the RMAN repository with the media manager. Otherwise, RMAN may skip backups due to optimization without recognizing that the media manager has discarded backups stored on tape.

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.

Table 5-5 Effect of Redundancy Setting on Backup Optimization

Day Action Result Redundant Backup

Monday

Take users offline normal.

   

Tuesday

BACKUP DATABASE

The users tablespace is backed up.

 

Wednesday

BACKUP DATABASE

The users tablespace is backed up.

 

Thursday

BACKUP DATABASE

The users tablespace is backed up.

Tuesday backup

Friday

BACKUP DATABASE

The users tablespace is not backed up.

Tuesday backup

Saturday

BACKUP DATABASE

The users tablespace is not backed up.

Tuesday backup

Sunday

DELETE OBSOLETE

The Tuesday backup is deleted.

 

Monday

BACKUP DATABASE

The users tablespace is backed up.

Wednesday backup


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. Note that 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.

Configuring Backup Optimization

By default, backup optimization is configured to OFF. You can use the SHOW BACKUP OPTIMIZATION command to view the current settings of backup optimization.

To configure backup optimization:

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

Run the SHOW BACKUP OPTIMIZATION command to determine whether optimization is currently enabled.

For example, enter the following command:

SHOW BACKUP OPTIMIZATION;

Sample output for SHOW BACKUP OPTIMIZATION follows:

RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE BACKUP OPTIMIZATION ON;

Enable backup optimization by running the following command:

CONFIGURE BACKUP OPTIMIZATION ON;

See Also:

"Using Backup Optimization to Skip Files" for examples of how to optimize RMAN backups

Configuring an Archived Redo Log Deletion Policy

You can use RMAN to create a persistent configuration that governs when archived redo logs are eligible for deletion from disk.

About Archived Redo Log Deletion Policies

You can use the CONFIGURE ARCHIVELOG DELETION POLICY command to specify when archived redo logs are eligible for deletion. This deletion policy applies to all archiving destinations, including the flash recovery area.

Archived redo logs can be deleted automatically by the database or as a result of user-initiated RMAN commands. Only logs in the flash recovery area can be deleted automatically by the database. For archived redo log files in the flash recovery area, the database retains them as long as possible and automatically deletes eligible logs when additional disk space is required. You can manually delete eligible logs from any location, whether inside or outside the flash recovery area, when you issue BACKUP ... DELETE INPUT or DELETE ARCHIVELOG.

When the Archived Redo Log Deletion Policy Is Disabled

The archived redo log deletion policy is configured to NONE by default. In this case, RMAN considers archived redo log files in the recovery area as eligible for deletion if they meet both of the following conditions:

  • The archived redo logs, whether in the flash recovery area or outside of it, have been transferred to the required remote destinations specified by LOG_ARCHIVE_DEST_n.

  • The archived redo logs 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'.

See Also:

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. Note that 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.

See Also:

Enabling an Archived Redo Log Deletion Policy

This section explains how to configure an archived redo log deletion policy. By default the policy is set to NONE.

To enable an archived redo log deletion policy:

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

Run the CONFIGURE ARCHIVELOG DELETION POLICY command with the desired options.

The following example specifies that archived redo logs are eligible to be deleted from the flash recovery area and all local archiving destinations when logs have been backed up at least twice tape:


CONFIGURE ARCHIVELOG DELETION POLICY
  TO BACKED UP 2 TIMES TO SBT;

See Also:

Configuring Oracle Flashback Database and Restore Points

This section describes how to plan and configure the environment for Oracle Flashback Database. This section also explains how to create restore points. This section contains the following topics:

About Restore Points and Flashback Database

Oracle Flashback Database and restore points are related data protection features. These features provide more efficient alternatives to point-in-time recovery for reversing unwanted database changes. Flashback Database enables you to rewind an entire database backward in time, reversing the effects of database changes within a time window. The effects are similar to database point-in-time recovery (DBPITR).

Restore points provide capabilities related to Flashback Database and other media recovery operations. In particular, a guaranteed restore point created at an SCN ensures that you can use Flashback Database to rewind the database to this SCN. You can use restore points and Flashback Database independently or together.

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 even return a database to its state in a previous incarnation, that is, 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 flash 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 flash 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. Note that in practice, redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery.

About the Flashback Database Window

The range of SCNs for which there is currently enough flashback log data to support the FLASHBACK DATABASE command is called the flashback database window. The flashback database window cannot extend further back than the earliest SCN in the available flashback logs.

Note:

Some database operations, such as dropping a tablespace or shrinking a datafile, cannot be reversed with Flashback Database. In these cases the flashback database window begins at the time immediately following that operation.

You cannot back up flashback logs to locations outside the flash recovery area. To increase the likelihood that enough flashback logs are retained to meet the flashback database window, you can increase the space in your flash recovery area (see "Setting the Flash Recovery Area Location and Initial Size").

If the flash recovery area is not large enough to hold the flashback logs and files such as archived redo logs and other backups needed for the retention policy, then the database may delete flashback logs from the earliest SCNs to make room for other files. Consequently, the flashback database window can be shorter than the flashback retention target, depending on the size of the flash recovery area, other backups that must be retained, and how much flashback logging data is needed. The flashback retention target is a target, not a guarantee that Flashback Database will be available.

If you cannot use FLASHBACK DATABASE because the flashback database window is not long enough, then you can use database point-in-time recovery (DBPITR) in most cases to achieve a similar result. Guaranteed restore points are the only way to ensure that you can use Flashback Database to return to a specific point in time or guarantee the size of the flashback window.

See Also:

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:

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.

See Also:

Oracle Database Advanced Application Developer's Guide to learn how to use Flashback Query

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.

Caution:

If flashback logging is disabled, then you cannot use FLASHBACK DATABASE to rewind the database to SCNs between the guaranteed restore points and the current time. In this case, your only option to return the database to an intermediate SCN is DBPITR.

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.

Note:

Limitations that apply to Flashback Database also apply to guaranteed restore points. For example, shrinking a datafile or dropping a tablespace can prevent flashing back the affected datafiles to the guaranteed restore point. See the FLASHBACK DATABASE entry in Oracle Database Backup and Recovery Reference for a complete list of command prerequisites and usage notes.
Guaranteed Restore Points and Storage Snapshots

In practice, guaranteed restore points provide a useful alternative to storage snapshots. Storage snapshots are often used to protect a database before risky operations such as large-scale database updates or application patches or upgrades. Rather than creating a snapshot or duplicate database to test the operation, you can create a guaranteed restore point on a primary or physical standby database. You can then perform the risky operation with the certainty that the required flashback logs are retained.

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

Guaranteed Restore Points and Flash Recovery Area Space Usage

The following rules govern creation, retention, overwriting and deletion of flashback logs in the flash recovery area:

  • If the flash recovery area has enough space, then a flashback log is created whenever necessary to satisfy the flashback retention target.

  • If a flashback log is old enough that it is no longer needed to satisfy the flashback retention target, then a flashback log is reused.

  • If the database needs to create a new flashback log and the flash recovery area is full or there is no disk space, then the oldest flashback log is reused instead.

    Note:

    Reusing the oldest flashback log shortens the flashback database window. If enough flashback logs are reused due to a lack of disk space, then the flashback retention target may not be satisfied.
  • If the flash recovery area is full, then an archived redo log that is not needed to satisfy the backup retention policy may be automatically deleted by the flash recovery area to make space for other files. In this case, any flashback logs that would require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.

  • No file in the flash recovery area is eligible for deletion if it is required to satisfy a guaranteed restore point. Thus, retention of flashback logs and other files required to satisfy the guaranteed restore point, in addition to files required to satisfy the backup retention policy, can cause the flash recovery area to fill completely. Consult "Responding to a Full Flash Recovery Area" if your flash recovery area becomes full.

When you create a guaranteed restore point, with or without enabling full flashback database logging, you must monitor the space available in your flash recovery area. "Managing Space For Flashback Logs in the Flash Recovery Area" explains how to monitor flash recovery area disk space usage.

Caution:

If no files are eligible for deletion from the flash recovery area because of the requirements imposed by your retention policy and the guaranteed restore point, then the database behaves as if it has encountered a disk full condition. In many circumstances, this causes your database to halt. See "Responding to a Full Flash Recovery Area".
Logging for Guaranteed Restore Points With Flashback Logging Disabled

Assume that you create a guaranteed restore point when logging for Flashback Database is disabled. In this case, the first time a datafile block is modified after the time of the guaranteed restore point, the database stores an image of the block before the modification in the flashback logs. Thus, the flashback logs preserve the contents of every changed data block at the time that the guaranteed restore point was created. Later modifications to the same block do not cause the contents to be logged again unless another guaranteed restore point was created after the block was last modified.

This method of logging has the following important consequences:

  • FLASHBACK DATABASE can re-create the datafile contents at the time of a guaranteed restore point by means of the block images.

  • For workloads that repeatedly modify the same data, disk space usage can be less than normal flashback logging. Less space is needed because each changed block is only logged once. Applications with low volume inserts may benefit from this disk space saving while this advantage is less likely for applications with high volume inserts or large batch inserts. The performance overhead of logging for a guaranteed restore point without flashback database logging enabled can also be lower.

Assume that your primary goal is the ability to return your database to the time at which the guaranteed restore point was created. In this case, it is usually more efficient to turn off flashback logging and use only guaranteed restore points. For example, suppose that you are performing an application upgrade on a database host over a weekend. You could create a guaranteed restore point at the start of the upgrade. If the upgrade fails, then reverse the changes with FLASHBACK DATABASE.

Logging for Flashback Database With Guaranteed Restore Points Defined

If you enable Flashback Database and define one or more guaranteed restore points, then the database performs normal flashback logging. In this case, the recovery area retains the flashback logs required to flash back to any arbitrary time between the present and the earliest currently defined guaranteed restore point. Flashback logs are not deleted in response to space pressure if they are required to satisfy the guarantee.

Flashback logging causes some performance overhead. Depending upon the pattern of activity on your database, it can also cause significant space pressure in the flash recovery area. Thus, you should monitor space used in the flash recovery area.

Prerequisites for Flashback Database and Guaranteed Restore Points

The prerequisites for enabling Flashback Database are the following:

  • Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation.

  • You must have a flash recovery area enabled, because flashback logs can only be stored in the flash recovery area.

  • For Real Application Clusters databases, the flash recovery area must be stored in a clustered file system or in ASM.

To support the use of guaranteed restore points, the database must satisfy the following prerequisites:

  • The COMPATIBLE initialization parameter must be set to 10.2 or greater.

  • The database must be running in ARCHIVELOG mode.

    To rewind your database to a guaranteed restore point, the FLASHBACK DATABASE command requires the use of archived redo logs starting from around the time of the restore point.

  • A flash recovery area must be configured, as described in "Configuring the Flash Recovery Area".

    Guaranteed restore points use a mechanism similar to flashback logging. As with flashback logging, Oracle Database must store the required logs in the flash recovery area.

  • If Flashback Database is not enabled, then the database must be mounted, not open, when creating the first guaranteed restore point (or if all previously created guaranteed restore points have been dropped).

Note:

No special requirements exist for using normal restore points.

Enabling Flashback Database

To enable logging for Flashback Database, set the DB_FLASHBACK_RETENTION_TARGET initialization parameter and issue the ALTER DATABASE FLASHBACK ON statement.

To enable flashback logging:

Start SQL*Plus and ensure that the database is mounted, but not open. For example:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Optionally, set the DB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes:

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days

By default DB_FLASHBACK_RETENTION_TARGET is set to one day (1440 minutes).

Enable the Flashback Database feature for the whole database:

ALTER DATABASE FLASHBACK ON;

Optionally, disable flashback logging for specific tablespaces.

By default, flashback logs are generated for all permanent tablespaces. If you wish, you can reduce overhead by disabling flashback logging for specific tablespaces as in the following example:

ALTER TABLESPACE tbs_3 FLASHBACK OFF;

You can re-enable flashback logging for a tablespace later with this command:

ALTER TABLESPACE tbs_3 FLASHBACK ON;

Note that if you disable Flashback Database for a tablespace, then you must take its datafiles offline before running FLASHBACK DATABASE.

You can disable flashback logging for the entire database with this command:

ALTER DATABASE FLASHBACK OFF;

Enabling Flashback Database on a physical standby database enables you to flash back a standby database. Flashback Database of standby databases has a number of applications in the Data Guard environment. See Oracle Data Guard Concepts and Administration for details.

Creating Normal and Guaranteed Restore Points

To create normal or guaranteed restore points, use the CREATE RESTORE POINT SQL statement, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default).

To create a restore point:

Connect SQL*Plus to a target database.

Ensure that the database is open or mounted. If the database is mounted, then it must have been shut down cleanly (unless it is a physical standby database).

Run the CREATE RESTORE POINT statement.

The following example shows how to create a normal restore point in SQL*Plus:

SQL> CREATE RESTORE POINT before_upgrade;

This example shows how to create a guaranteed restore point:

SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;

See Also:

Configuring the Environment for Optimal Flashback Database Performance

Maintaining flashback logs imposes comparatively limited overhead on an Oracle database instance. Changed blocks are written from memory to the flashback logs at relatively infrequent, regular intervals, to limit processing and I/O overhead.

To achieve good performance for large production databases with Flashback Database enabled, Oracle recommends the following:

  • Use a fast file system for your flash recovery area, preferably without operating system file caching.

    Files that the database creates in the flash recovery area, including flashback logs, are typically large. Operating system file caching is typically not effective for these files, and may actually add CPU overhead for reading from and writing to these files. Thus, it is recommended to use a file system that avoids operating system file caching, such as ASM.

  • Configure enough disk spindles for the file system that will hold the flash recovery area.

    For large production databases, multiple disk spindles may be needed to support the required disk throughput for the database to write the flashback logs effectively.

  • If the storage system used to hold the flash recovery area does not have nonvolatile RAM, then try to configure the file system on striped storage volumes.

    Use a relatively small stripe size such as 128 KB. This technique enables each write to the flashback logs to be spread across multiple spindles, improving performance.

  • For large databases, set the initialization parameter LOG_BUFFER to at least 8 MB.

    This setting ensures that the database allocates maximum memory (typically 16MB) for writing flashback database logs.

The overhead of logging for Flashback Database depends on the mixture of reads and writes in the database workload. The more write-intensive the workload, the higher the overhead caused by turning on logging for Flashback Database. Queries do not change data and thus do not contribute to logging activity for Flashback Database.

Configuring RMAN in a Data Guard Environment

If you use RMAN in a Data Guard environment, then you can use the CONFIGURE command to register and configure settings for the physical databases in this environment. RMAN uses the DB_UNIQUE_NAME initialization parameter to distinguish one database from another. Thus, it is critical that you maintain the uniqueness of the DB_UNIQUE_NAME in the Data Guard environment.

RMAN must be connected to a recovery catalog when you create or alter a configuration for a database in the Data Guard environment. If you use the SET DBID command to set the DBID in the RMAN session, then you can configure a standby database even when RMAN is not connected as TARGET to a database in the Data Guard environment. You can even create a configuration for a standby database that has not yet been created.

You can use the following forms of the CONFIGURE command:

  • CONFIGURE DB_UNIQUE_NAME defines a connection to a physical standby database and implicitly registers the new database.

    New standby databases are also automatically registered when RMAN connects as TARGET to a standby database for the first time.

  • CONFIGURE FOR DB_UNIQUE_NAME configures settings for a database in the Data Guard environment.

    For example, you can configure channels, default devices, and so on for a specified database or for all databases in the environment. You can use SHOW ALL FOR DB_UNIQUE_NAME to show the configuration for a specific standby database or SHOW ALL FOR DB_UNIQUE_NAME ALL to show configurations for all known databases.

A Data Guard environment involves many considerations that are only relevant for Data Guard. For example, you can configure an archived redo log deletion policy based on whether archived logs are transferred to or applied on a standby database.

See Also: