Specifies the net service name for the physical standby database specified by DB_UNIQUE_NAME. The CONNECT IDENTIFIER string must not include the database user name and password.

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 uses 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 SYSDBA or SYSBACKUP 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.

CLEAR

Returns a parameter to its default setting. See the Usage Notes.

delalConf

Configures an archived redo log deletion policy.

Configures the auxiliary file name for the specified target data file to 'filename' (see Example 2-54). Specify CLEAR to unspecify the auxiliary file name.

If you are performing TSPITR or using DUPLICATE, then you can set AUXNAME to preconfigure the file names for use on the auxiliary database without manually specifying the auxiliary file names 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 data files are on raw disk and you must restore auxiliary data files to raw disk for performance reasons. Typically, you set the AUXNAME parameter in TSPITR for the data files 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 data file 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 file name 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

backupConf

Configures default backup options such as duplexing, optimization, excluding tablespaces, backup set sizes, and retention policies.

cfauConf

Configures control file autobackup settings.

Specifies the algorithm that RMAN uses to create compressed backup sets.

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

If, however, you have enabled the 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 about which level is best must factor in on how balanced your system is regarding bandwidth into the CPU and 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 data set 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.

OPTIMIZE FOR LOAD

{TRUE|FALSE}

Specifies whether Oracle Database performs pre-compression block processing when compressed backups have been requested. TRUE is the default and FALSE enables pre-compression processing. The default behavior is not to perform pre-compression block processing. Such processing can consume extra CPU resources, and is not needed for blocks that contain all originally loaded data, and have never been the subject of single-row inserts and deletes. Specifying FALSE uses additional CPU resources to perform pre-compression block processing which consists of internal block cleanups and defragmentation that can result in improved levels of binary compression.

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

AS OF RELEASE

'version'

Specifies the release version. The version number uses the release number format and may use as many as 5 numbers to fully qualify the release. For example, 10.2.0.3.0 and 11.2 are acceptable values. This option ensures compression algorithm stability across future releases.

deviceConf

Configures default backup settings for devices, such as the default backup device, channel configurations for devices, default backup types for each device, and parallelism.

ENCRYPTION

Specifies transparent-mode encryption settings for the database or tablespaces.

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 Guide to learn about transparent data encryption

Specifies the default algorithm to use for encryption when writing backup sets. Possible values are listed in V$RMAN_ENCRYPTION_ALGORITHMS. The CLEAR option resets the database to the default value.

Specifies whether to enable transparent encryption for the entire database. The options are as follows:

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

Specifies whether to enable transparent encryption for one or more tablespaces. Configured settings for a tablespace always override configuration set at the database level. The options are as follows:

• 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 name of the tablespace in a CDB. Multiple databases can have tablespaces with the same name. A qualifier before the name uniquely identifies the tablespace. pdb-name is the name of a PDB.

See the previous description of FOR TABLESPACE.

RMAN OUTPUT TO KEEP FOR integer DAYS

Configures RMAN output logging to the number of days specified by integer. Information regarding the output of RMAN commands is stored in two views, RC_RMAN_OUTPUT and V$RMAN_OUTPUT. When you configure output logging to integer days, any logging entry that is older than integer days is deleted from both the RC_RMAN_OUTPUT and V$RMAN_OUTPUT views.

For example, assume that the existing output logging configuration is set to 20 days. You use the CONFIGURE command to change output logging to 10 days. Any logging entries that are older than 10 days are deleted from RC_RMAN_OUTPUT and V$_RMAN_OUTPUT.

To disable RMAN output logging, set integer to zero, as shown in the following example.

CONFIGURE RMAN OUTPUT TO KEEP FOR 0 DAYS; 

When you disable output logging, no logging information is stored in the RC_RMAN_OUTPUT and V$RMAN_OUTPUT views. Existing logging entries in RC_RMAN_OUTPUT are deleted.

CLEAR

Clears the existing RMAN output logging configuration and resets it to 7 days, which is the default.

RMAN stores output logging information in the RC_RMAN_OUTPUT and V$RMAN_OUTPUT views. When you clear the output logging configuration, any logging entry that is older than 7 days (the default value) is deleted from the RC_RMAN_OUTPUT view. Entries older than 7 days in the V$RMAN_RMAN_OUTPUT view are not deleted immediately. They are deleted only when the maximum number of rows permitted for this view is exceeded.

Configures the snapshot control file name and location to 'filename'. If you run CONFIGURE SNAPSHOT CONTROLFILE NAME CLEAR, then RMAN sets the snapshot control file name to its default.

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 is 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

forDbUniqueNameOption

Creates an RMAN configuration in the recovery catalog for the database in a Data Guard environment specified by DB_UNIQUE_NAME. You can specify a single database with db_unique_name or use ALL for all databases in the recovery catalog that share the DBID of the target database (or DBID specified by the SET DBID command).

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

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.

ARCHIVELOG DELETION POLICY

Determines when archived redo log files are eligible for deletion.

The archived log deletion policy applies to all log archiving destinations, including the fast recovery area. 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 if 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 that are reclaimable according to the fast recovery area rules.

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.

Archived redo log files are eligible for deletion if both of the following conditions are met:

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

When valid standby remote databases exist, this policy is applicable to primary databases, standby databases, and FAR SYNC standby databases.

For primary databases, the archived redo log files are eligible for deletion after they are applied on the standby. If no valid standby database exists, then RMAN uses TO NONE as the policy. For standby databases, the archived redo log files are eligible for deletion after they are applied on the standby database and on any cascading standby databases.

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

Archived redo log files are eligible for deletion if both of the following conditions are met:

• 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 the TO SHIPPED TO policy is not 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 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

   TO NONE

Disables the archived log deletion policy. This is the default setting.

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 remote destinations are configured for the target database, archived redo log files, whether in the fast recovery area or outside of it, are eligible for deletion if have been transferred to the required remote destinations specified by LOG_ARCHIVE_DEST_n.

• When no remote destinations are configured, archived redo log files in the fast recovery area are eligible for deletion if they have been backed up at least once to disk or SBT or the logs are obsolete according to the backup retention policy.

  The backup retention policy considers logs obsolete only if the logs are not needed by a guaranteed restore point and the logs are not needed by 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.

Archived redo log files are eligible for deletion if both of the following conditions are met:

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

When valid standby remote databases exist, this policy is applicable to primary databases, standby databases, and FAR SYNC standby databases.

• For primary databases:

  • If valid standby configurations exist, then the archived redo log files are eligible for deletion after they are shipped to the standby.

  • If no valid standby database exists, then RMAN uses TO NONE as the default policy.

• For standby databases:

  • If valid cascading standby configurations exist, then the archived redo log files are eligible for deletion after they are shipped to the cascading standby database.

  • If no valid cascading standby configurations exist, then RMAN uses TO NONE as the default policy.

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

Data file

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

If a recovery window-based retention policy is enabled, then whether RMAN skips a data file depends on the backup media.

For backups to tape, if the most recent backup is older than the recovery window, then RMAN takes another backup of a data file even if a backup of an identical data file exists. In this way, tapes can be recycled after they expire.

For backups to disk, RMAN skips the backup if an identical data file is available on disk, even if that backup is older than the beginning of the recovery window. The window-based retention policy causes RMAN to retain the old backup if it is needed.

If a retention policy is enabled with CONFIGURE RETENTION POLICY TO REDUNDANCY r, then RMAN skips backups only if at least n backups of an identical file exist on the specified device, where n=r+1.

If no retention policy is enabled, then RMAN skips a backup only if at least n backups of an identical file exist on the specified device. RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):

1. BACKUP ... COPIES n

2. SET BACKUP COPIES n

3. CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE ... TO n

4. n=1

Archived redo log

The archived redo log must have the same thread, sequence number, and RESETLOGS SCN and time as an archived log already in a backup.

RMAN skips a backup only if at least n backups of an identical file exist on the specified device. RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):

1. BACKUP ... COPIES n

2. SET BACKUP COPIES n

3. CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE ... TO n

4. n=1

Backup set

The backup set must have the same record ID and stamp as an existing backup set.

RMAN skips a backup only if at least n backups of an identical file exist on the specified device. By default, n=1. RMAN searches for other values of n in this order of precedence (that is, values higher on the list override values lower on the list):

1. BACKUP ... COPIES n

2. SET BACKUP COPIES n

3. n=1

Specifies the number of copies of each backup set for DATAFILE (both data files and control files) or ARCHIVELOG files on the specified device type (see Example 2-51). You can create from 1 (default) to 4 copies.

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.

Toggles backup optimization ON or OFF (default). Specify CLEAR to return optimization to its default value of OFF.

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. The backup retention policy affects which files backup optimization skips.

For two files to be identical, their content must meet the requirements described in Table 2-3. 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

Excludes the specified tablespace from BACKUP DATABASE and RESTORE DATABASE commands (see Example 2-53). You cannot exclude the SYSTEM tablespace.

The BACKUP command default does not exclude tablespaces. You must declare the option to use it. The exclusion is stored as an attribute of the tablespace and not to the individual data files. In this manner, the exclusion applies not only to the present set of data files but also 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. Similarly, you can restore an excluded tablespace by specifying it in the RESTORE TABLESPACE command.

The name of the tablespace in a PDB. Multiple PDBs can have tablespaces with the same name. A qualifier before the name uniquely identifies the tablespace. pdb-name is the name of a PDB.

See the previous description of EXCLUDE FOR TABLESPACE.

MAXSETSIZE

Specifies the maximum size of each backup set created on a channel. Use the CLEAR option to return MAXSETSIZE to the default value of UNLIMITED.

Note: This option is ignored by BACKUP AS COPY.

   TO sizeSpec

Specifies the maximum size of each backup set as integer gigabytes, kilobytes, or megabytes.

   TO UNLIMITED

Specifies no size limit for backup sets.

RETENTION POLICY

Specifies a persistent, ongoing policy for backup sets and copies that RMAN marks as obsolete, that is, not needed and eligible for deletion.

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.

   TO NONE

Disables the retention policy feature. RMAN does not consider any backup sets or copies as obsolete.

Specifies a time window in which RMAN can recover the database.

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. Use this setting to restore or recover dropped tablespaces or data files.

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

   TO REDUNDANCY integer

Retains integer full or level 0 backups of each data file and control file. The default retention policy setting is REDUNDANCY 1. This setting considers only the current set of data files.

If more than integer full or level 0 backups of a data file 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 data file 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.

CONTROLFILE AUTOBACKUP

Controls the control file autobackup feature.

By default, control file autobackup is turned on for CDBs and standalone databases with the COMPATIBLE initialization parameter set to 12.2 or higher.

Note: Oracle recommends that you enable the control file autobackup feature.

   ON

Performs a control file autobackup in the following circumstances:

• 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 data file (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 file name 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 backs up the control file to the specified FORMAT location and then executes 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.

   OFF

Disables the autobackup feature.

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

   CLEAR

Returns this configuration to its default setting of ON.

Configures the default location and file name format for the control file autobackup on the specified device type (see Example 2-55).

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

Specifies the standard or AUXILIARY channel that you are configuring or clearing, and the device type of the channel.

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-53 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

   allocOperandList

Specifies control options for the configured channel.

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 cross-check these backups.

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

   CLEAR

Clears the specified channel. For example, CONFIGURE CHANNEL 1 DEVICE TYPE DISK CLEAR returns only channel 1 to its default, whereas CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR returns the generic disk channel to its default. You cannot specify any other channel options (for example, PARMS) when you specify CLEAR.

Specifies the default device type for automatic channels. By default, DISK is the default device type. CLEAR returns the default device type to DISK.

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

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.

Specifies the device type (disk or sbt) to which to apply the settings specified in this CONFIGURE command. The CLEAR option resets backup type and parallelism settings for this device to their defaults.

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

Configures the default backup type for disk or tape backups. For SBT devices the COPY option is not supported. The default for disk is BACKUPSET.

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 file names is %U.

   PARALLELISM integer

Configures the number of automatic channels of the specified device type allocated for RMAN jobs. By default, PARALLELISM is set to 1.

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

If the SPARSE setting is set to ON, then the BACKUP command creates sparse backups and the RESTORE command performs restore operations from sparse backups. If the SPARSE setting for the device is set to OFF, then RMAN continues to perform database backup and restore operations as before.

If COMPATIBLE is set to 12.2 or higher for the database, then ON is the default setting. This setting overrides the default sparseness mode of the database.

See Oracle Database Backup and Recovery User’s Guide for more information on sparse databases