CONFIGURE

RMAN must also be connected to the primary database as TARGET. RMAN must be connected to a recovery catalog.

When you run the RESYNC CATALOG FROM DB_UNIQUE_NAME command, databases in a Data Guard environment use the net service name to connect with the db_unique_name database. For example, assume that a standby database has the unique name standby1 and the net service name sby1. You connect RMAN as TARGET to the primary database and execute CONFIGURE DB_UNIQUE_NAME 'standby1' CONNECT IDENTIFIER 'sby1'. Every primary and standby database in the environment will use the net service name sby1 when it needs to make an Oracle Net connection to standby1.

Note: When the target database needs to connect to other standby or primary databases, it connects as the SYS user by using the existing Data Guard authentication mechanisms.

Suppose that you recently connected RMAN as TARGET to the primary database and used CONFIGURE ... FOR DB_UNIQUE_NAME standby_new to configure backup settings for standby database standby_new. However, you have not yet connected RMAN as TARGET to standby_new. In this case, you can execute RESYNC CATALOG FROM DB_UNIQUE_NAME standby_new. The primary database uses the connect identifier to make an Oracle Net connection to the standby database. When you later connect RMAN to the standby database, RMAN pushes the configuration from the recovery catalog to the mounted control file.

Note: If the database specified by CONFIGURE DB_UNIQUE_NAME is not registered in the recovery catalog, then RMAN implicitly registers it.

If you are performing TSPITR or using DUPLICATE, then you can set AUXNAME to preconfigure the filenames for use on the auxiliary database without manually specifying the auxiliary filenames during the procedure. You cannot use CONFIGURE AUXNAME for recovery set, you must use SET NEWNAME.

For example, use this command during TSPITR if the datafiles are on raw disk and you must restore auxiliary datafiles to raw disk for performance reasons. Typically, you set the AUXNAME parameter in TSPITR for the datafiles of the SYSTEM and SYSAUX tablespaces and the tablespaces containing rollback or undo segments. Do not overlay files which are in use by the production database and can be discarded after TSPITR completes. In essence, the AUXNAME of a datafile is the location where TSPITR can create a temporary copy of it.

When renaming files with the DUPLICATE command, CONFIGURE AUXNAME is an alternative to SET NEWNAME. The difference is that after you set the AUXNAME the first time, you do not need to reset the filename when you issue another DUPLICATE command: the AUXNAME setting remains in effect until you issue CONFIGURE AUXNAME ... CLEAR. In contrast, you must reissue the SET NEWNAME command every time you execute the DUPLICATE command.

See Also: Oracle Database Backup and Recovery User's Guide to learn how to perform RMAN TSPITR, and Oracle Database Backup and Recovery User's Guide to learn how to duplicate a database with RMAN

The default compression algorithm setting is BASIC and does not require the Advanced Compression Option.

If, however, you have enabled the Oracle Database 11g Release 2 Advanced Compression Option, you can choose from the following compression levels:

• HIGH - Best suited for backups over slower networks where the limiting factor is network speed

• MEDIUM -Recommended for most environments. Good combination of compression ratios and speed

• LOW - Least impact on backup throughput and suited for environments where CPU resources are the limiting factor.

Note: The compression ratio generally increases from LOW to HIGH, with a trade-off of potentially consuming more CPU resources.

Since the performance of the various compression levels depends on the nature of the data in the database, network configuration, system resources and the type of computer system and its capabilities, Oracle cannot document universally applicable performance statistics. The decision as to which level is best must factor in on how balanced your system is regarding bandwidth into the CPU as well as the actual speed of the CPU. It is highly recommended that you run tests with the different compression levels on the data in your environment. Choosing a compression level based on your environment, network traffic characteristics (workload) and dataset is the only way to ensure that the backup set compression level can satisfy your organization's performance requirements and any applicable service level agreements.

Note: The V$RMAN_COMPRESSION_ALGORITHM view describes the supported algorithms.

See Also: Oracle Database Reference entry for V$RMAN_COMPRESSION_ALGORITHM.

{TRUE|FALSE}

See Also: Oracle Database Backup and Recovery User's Guide to learn more about this option.

'version'

This configuration applies unless overridden with the SET ENCRYPTION command. Options specified for an individual tablespace take precedence over options specified for the whole database.

See Also: "Encryption of Backup Sets" to learn about the different modes of backup encryption, and Oracle Database Advanced Security Administrator's Guide to learn about transparent data encryption

• ON enables encryption for all database files.

• OFF turns off encryption for all database files.

• CLEAR restores the default setting of OFF.

Note: You must use the SET ENCRYPTION IDENTIFIED BY command to enable password encryption.

• ON enables encryption for the specified tablespace unless SET ENCRYPTION OFF FOR ALL TABLESPACES is used.

• OFF disables encryption for the specified tablespace unless SET ENCRYPTION ON FOR ALL TABLESPACES is used.

• CLEAR means that encryption for the specified tablespace is determined by the current default for the whole database.

Note: You must use the SET ENCRYPTION IDENTIFIED BY command to enable password encryption.

The default value for the snapshot control file name is platform-specific and dependent on Oracle home. For example, the default on some UNIX systems is ?/dbs/snapcf_@.f. If you clear the control file name, and if you change Oracle home, then the default location of the snapshot control file changes as well.

The snapshot control file name is valid for this database only. Assume that you configure the snapshot control file name to a nondefault value on the primary database. If you use DUPLICATE to create a standby database, then the snapshot control file location on the standby database will be set to the default value. If desired, you can then configure the snapshot location on the standby database to a nondefault value.

See Also: Oracle Database Backup and Recovery User's Guide for more information about snapshot control files

A recovery catalog is required when performing operations in a Data Guard environment. RMAN must be connected as TARGET to a mounted or open database (which can be a primary or standby database), or you must identify the target database with the SET DBID command. Thus, you can use this clause to create a persistent configuration for a standby database without connecting as TARGET to the standby or primary database. For example, you can create a configuration for a standby database before its creation so that the configuration applies after the database is created (see Example 2-46).

When you specify FOR DB_UNIQUE_NAME, RMAN directly updates the configuration metadata in the recovery catalog. When RMAN connects as TARGET to a database whose configurations were changed with FOR DB_UNIQUE_NAME, RMAN updates the mounted control file with the configuration metadata from the recovery catalog.

Note: It is possible to run CONFIGURE locally on a standby database and then run CONFIGURE FOR DB_UNIQUE_NAME for the same database while RMAN is not connected to this database as TARGET. In this case, the configuration in the recovery catalog overrides the configuration in the control file for the specific database.

The archived log deletion policy applies to all log archiving destinations, including the fast recovery area. Note that the policy does not apply to archived redo log files in backup sets.

Only archived redo log files in the fast recovery area are automatically deleted by the database. You can execute the BACKUP ... DELETE INPUT, DELETE ARCHIVELOG, or DELETE OBSOLETE commands to delete logs manually from log archiving destinations, including the recovery area. If FORCE is not specified on the deletion commands, then these deletion commands obey the archived log deletion policy. If FORCE is specified, then the deletion commands ignore the archived log deletion policy.

In the recovery area, the database retains logs eligible for deletion as long as possible. The database deletes the oldest logs first when disk space is required. When the recovery area is under disk pressure, the database may delete archived redo log files needed by Oracle Streams.

Note: The deletion policy does not apply to foreign archived redo log files, which are logs received by a logical standby database for a LogMiner session. These logs are transferred from a primary database, but unlike ordinary archived redo log files they have a different DBID. Foreign archived redo log files cannot be backed up or restored on a logical standby database.

• The archived redo log files have been applied to the required standby databases.

• The logs are not needed by the BACKED UP ... TIMES TO DEVICE TYPE deletion policy. If the BACKED UP policy is not set, then this condition is always met.

Which remote destinations are considered depends on the following criteria:

• If you do not specify ALL, then archived redo log files are eligible for deletion after being applied to all mandatory remote destinations.

• If you specify ALL, then archived redo log files are eligible after being applied or consumed on all remote destinations, whether mandatory or not.

  For example, standby database sby1 may be the only remote destination receiving logs, but other remote destinations may apply logs by referring to the same location on sby1. With ALL, sby1 marks the log on the primary database as consumed as soon as it is not required at sby1, but does not permit deletion of this log until it is applied or consumed by all other dependent remote destinations referring to the same location.

Note: It is invalid to specify the TO APPLIED clause in combination with either NONE or the TO SHIPPED clause.

See Also: Oracle Data Guard Concepts and Administration for details

• The specified number of archived log backups exist on the specified device type.

• The logs are not needed by the TO SHIPPED TO ... STANDBY or TO APPLIED ON ... STANDBY deletion policy. If neither standby deletion policy is set, then this condition is always met.

If you configure the deletion policy with this clause, then a BACKUP ARCHIVELOG command copies the logs unless integer backups already exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG command skips the logs. In this way, the archived log deletion policy functions as a default NOT BACKED UP integer TIMES clause on the BACKUP ARCHIVELOG command. You can override this deletion policy by specifying FORCE option on the BACKUP command.

See Also: deviceSpecifier

Archived redo log files can be located inside or outside of the fast recovery area. Logs in any location can be deleted by manual commands. Only logs in the fast recovery area can be deleted automatically by the database.

When the deletion policy is set to NONE, RMAN considers archived redo log files as eligible for deletion if they meet both of the following conditions:

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

• The archived redo log files in the fast recovery area 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 Flashback Database. Archived redo log files are needed by Flashback Database if the logs were created later than SYSDATE-'DB_FLASHBACK_RETENTION_TARGET'.

For example, suppose that archived redo log files have been transferred to required remote destinations. The logs are obsolete according to the recovery window retention policy, but have not been backed up. In this case, the logs are eligible for deletion. Alternatively, suppose that the logs are obsolete and have been backed up to SBT, but have not been transferred to required remote destinations. In this case, the logs are not eligible for deletion.

If the deletion policy is set to NONE, and if you execute a deletion command for archived redo log files outside the fast recovery area, then RMAN obeys only the conditions specified on the deletion command.

• The archived redo log files have been transferred to the required remote destinations.

• The logs are not needed by the BACKED UP ... TIMES TO DEVICE TYPE deletion policy. If the BACKED UP deletion policy is not set, then this condition is always met.

Which remote destinations are considered depends on the following criteria:

• If you do not specify ALL, then the archived redo log files are eligible for deletion after transfer to mandatory remote destinations only.

• If you specify ALL, then the logs are eligible for deletion after transfer to all remote destinations, whether mandatory or not.

Note: It is invalid to specify the TO SHIPPED clause in combination with NONE or the TO APPLIED clause.

See Also: Oracle Data Guard Concepts and Administration for details

RMAN can duplex backups to either disk or tape, but cannot duplex backups to tape and disk simultaneously. When backing up to tape, ensure that the number of copies does not exceed the number of available tape devices. Also, if COPIES is greater than 1, then the BACKUP_TAPE_IO_SLAVES initialization parameter must be enabled on the target database.

Control file autobackups are never duplexed. Also, duplexing is not permitted in the fast recovery area.

If duplexing is specified in the BACKUP command or in a SET BACKUP COPIES command, then the CONFIGURE setting is overridden.

Backup optimization is enabled when all of the following conditions are met:

• The CONFIGURE BACKUP OPTIMIZATION ON command has been run.

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

• The RMAN job uses a channel of only one device type.

Optimization prevents RMAN from backing up a file to a device type if the identical file is already backed up on the device type. RMAN does not signal an error if backup optimization causes all files to be skipped during a backup. Note that the backup retention policy has an effect on which files backup optimization skips.

For two files to be identical, their content must be exactly the same, as described in Table 2-3. Note that when you create backup pieces on disk or on media managed by Oracle Secure Backup, optimization excludes undo data from the backup when the data does not belong to an active transaction.

Note: BACKUP ... DELETE INPUT deletes all specified archived redo log whether or not optimization would skip these files during a backup.

Note: You can override backup optimization with the FORCE option of the BACKUP command.

See Also: Oracle Database Backup and Recovery User's Guide for a description of how RMAN determines that it can skip the backup of a file

By default, each tablespace is not excluded, that is, the exclude functionality is disabled. The exclusion is stored as an attribute of the tablespace, not the individual datafiles, so the exclusion applies to any files that are added to this tablespace in the future. If you run CONFIGURE ... CLEAR on a tablespace after excluding it, then it returns to the default configuration of nonexclusion.

You can still back up an excluded tablespace by explicitly specifying it in a BACKUP command or by specifying the NOEXCLUDE option on a BACKUP DATABASE command.

Note: This option is ignored by BACKUP AS COPY.

As time passes, RMAN marks backup sets and copies as obsolete according to the criteria specified in the retention policy. RMAN automatically deletes obsolete backup sets and copies in the fast recovery area when space is needed. RMAN does not automatically delete obsolete files outside the fast recovery area: you must manually execute DELETE OBSOLETE to remove them.

For backups, the basic unit of the retention policy is a backup set (not a backup piece) or image copy. For example, BACKUP AS BACKUPSET COPIES 4 TABLESPACE users creates a single backup set that is duplexed into four identical backup pieces. The retention policy considers this as one backup, not four separate backups.

Note: Use the CLEAR option to return RETENTION POLICY to its default of REDUNDANCY 1.

The window stretches from the current time (SYSDATE) to the point of recoverability, which is the earliest date to which you want to recover. The point of recoverability is SYSDATE - integer days in the past.

Note: The REDUNDANCY and RECOVERY WINDOW options are mutually exclusive. Only one type of retention policy can be in effect at any time.

If more than integer full or level 0 backups of a datafile or control file exist, then RMAN marks these extra files as obsolete. RMAN then determines the oldest of the retained backups and marks all archived redo log files and log backups older than this backup as obsolete. The DELETE OBSOLETE command removes obsolete datafile backups (full or incremental), control file backups, and archived log backups or image copies.

The following scenario illustrates how redundancy works in an incremental backup strategy. Assume that the redundancy level 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.

Note: The REDUNDANCY and RECOVERY WINDOW options are mutually exclusive. Only one type of retention policy can be in effect at any time.

Note: You should enable control file autobackup feature when using RMAN without a recovery catalog.

• After every BACKUP or CREATE CATALOG command issued at the RMAN prompt.

• Whenever a BACKUP command within a RUN block is followed by a command that is not BACKUP.

• At the end of every RUN block if the last command in the block was BACKUP.

• After structural changes for databases in ARCHIVELOG mode. The autobackup after structural changes does not occur for databases in NOARCHIVELOG mode.

  Structural changes include adding tablespaces, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, enabling or disabling Flashback Database, and so on. This type of autobackup, unlike autobackups that occur in the preceding circumstances, is only to disk. You can run CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set a nondefault disk location.

  Starting with Oracle 11g Release 2, RMAN creates a single autobackup file encompassing all of the structural changes that have occurred within a few minutes of each other rather than creating a new backup of the controlfile on each structural change to the database.

The first channel allocated during the backup or copy job creates the autobackup and places it into its own backup set; for post-structural autobackups, the default disk channel makes the backup. RMAN writes the control file and server parameter file to the same backup piece. After the control file autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log.

The default location for the autobackup on disk is the fast recovery area (if configured) or a platform-specific location (if not configured). RMAN automatically backs up the current control file using the default format of %F. You can change the location and filename format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT and SET CONTROLFILE AUTOBACKUP FORMAT commands.

You cannot configure RMAN to write the autobackup to multiple locations. To create multiple control file backups, you can make the last command in your backup job a BACKUP CURRENT CONTROLFILE FORMAT command, which will back up the control file to the specified FORMAT location and then execute an autobackup.

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

1. SET within a RUN block

2. SET at RMAN prompt

3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

You can configure the autobackup format even when CONFIGURE CONTROLFILE AUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, you must set CONFIGURE CONTROLFILE AUTOBACKUP to ON.

Any BACKUP command that includes datafile 1 automatically includes the current control file and server parameter file in the backup set. Otherwise, RMAN does not include these files.

By default, the format is %F for all devices. Any default format string specified with CONFIGURE must include the %F substitution variable. Use of any other substitution variable is an error. Specify CLEAR to return the format to the default %F.

If a fast recovery area is enabled, and if the format is the default '%F', then RMAN creates the autobackup in the recovery area in a directory named autobackup. Otherwise, the default autobackup location is an operating system-specific location (?/dbs on UNIX, Linux, and Windows).

The string # default in the output of the SHOW command indicates when RMAN is using the default format. If you manually configure the disk format to '%F', then RMAN creates the autobackups in the operating system-specific default location even though the recovery area is enabled. To change the format back to its default so that RMAN creates the autobackups in the recovery area, run CONFIGURE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR.

The formatSpec can specify an Automatic Storage Management disk group. The following example configures a channel for an ASM disk group:

CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1';

See Also: formatSpec for the semantics of the %F substitution variable

Note: Channels allocated with ALLOCATE CHANNEL within a RUN command override configured automatic channels.

Either configure a generic channel or specify a channel number, where integer is less than 255. See Example 2-43 for an illustration of numbered channels.

If AUXILIARY is specified, then this configuration is used only for channels allocated at the auxiliary instance. Specify configuration information for auxiliary channels if they require different parameters from the channels allocated at the target instance. If no auxiliary device configuration is specified, then RMAN configures any auxiliary channels using the target database device configuration.

You must specify at least one channel option. For example, you cannot issue a command such as CONFIGURE CHANNEL 2 DEVICE TYPE DISK, but you can issue a command such as CONFIGURE CHANNEL 2 DEVICE TYPE DISK MAXPIECESIZE 2500K.

For generic channels of a specified device type, a new command erases previous settings for this device type. Assume that you run these commands:

CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 1G;
CONFIGURE CHANNEL DEVICE TYPE sbt FORMAT 'bkup_%U';

The second command erases the MAXPIECESIZE setting of the first command.

Note: RMAN does not simultaneously allocate automatic channels for multiple device types in the BACKUP command.

See Also: Oracle Database Backup and Recovery User's Guide to learn how configure automatic channels specified by channel number

If you configure channels by using the nondefault CONNECT or PARMS options to create backups or copies, then you must either use the same configured channels or manually allocate channels with the same options to restore or crosscheck these backups.

Note that the FORMAT parameter can specify an Automatic Storage Management disk group. The following example configures a channel for an ASM disk group:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';

See Also: allocOperandList

By default, the BACKUP command only allocates channels of the default device type. For example, if you configure automatic channels for DISK and sbt and set the default device type to sbt, then RMAN only allocates tape channels when you run the BACKUP DATABASE command. You can override this behavior either by manually allocating channels in a RUN command, or by specifying DEVICE TYPE on the BACKUP command itself (see Example 2-41).

The RESTORE command allocates automatic channels of all configured device types, regardless of the default device type. The RESTORE command obeys the PARALLELISM setting for each configured device type.

If you run the CONFIGURE DEVICE TYPE command to configure default settings for a device type and do not run CONFIGURE CHANNEL for this device type, then RMAN allocates all channels without other channel control options. Assume that you configure the sbt device and run a backup as follows:

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
BACKUP DEVICE TYPE sbt DATABASE;

In effect, RMAN does the following when executing this backup:

RUN 
{
  ALLOCATE CHANNEL ORA_SBT_TAPE_1 DEVICE TYPE sbt;
  BACKUP DATABASE;
}

If BACKUP TYPE is set to BACKUPSET, then the BACKUP command always produces backup sets regardless of which media the backup is created on. With the COMPRESSED option, the backup sets produced use binary compression.

The default location for disk backups is the fast recovery area, if one is configured; otherwise, RMAN stores backups in a platform-specific location. The default format for backup filenames is %U.

Note: The CONFIGURE ... PARALLELISM parameter specifies channel parallelism, that is, the number of channels that RMAN allocates during backup and restore operations. The RECOVERY_PARALLELISM initialization parameter specifies the number of processes used in instance recovery.

Suppose you set PARALLELISM for disk backups to 2 (see Example 2-42). If you set the default device type as disk, then RMAN allocates two disk channels when you run BACKUP DATABASE at the RMAN prompt. RMAN always allocates the number of channels set by PARALLELISM, although it may use only a subset of these channels.

Note: If you configure n manually numbered channels, then the PARALLELISM setting can be greater than or less than n. For example, you can manually number 10 automatic channels and configure PARALLELISM to 2 or 12.

To change the parallelism for a device type to n, run a new CONFIGURE DEVICE TYPE ... PARALLELISM n command. For example, you can change configure PARALLELISM to 3 for sbt and then change it to 2 as follows:

CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;