BACKUP

Each backupSpec clause generates one or more backup sets (AS BACKUPSET) or image copies (AS COPY). For AS BACKUPSET, the backupSpec clause generates multiple backup sets if the number of datafiles specified in or implied by its list of objects exceeds the FILESPERSET limit.

1. Run an ALTER SYSTEM ARCHIVE LOG CURRENT statement.

2. Run the BACKUP ARCHIVELOG ALL command. If backup optimization is enabled, then RMAN only backs up logs that have not yet been backed up.

3. Back up the files specified in the BACKUP command.

4. Run an ALTER SYSTEM ARCHIVE LOG CURRENT statement.

5. Back up any remaining archived redo log files. If backup optimization is not enabled, then RMAN backs up the logs generated in step 1 plus all the logs generated during the backup.

You cannot specify PLUS ARCHIVELOG on the BACKUP ARCHIVELOG command or BACKUP AS COPY INCREMENTAL command (or BACKUP INCREMENTAL command when the default backup type is COPY). You cannot specify PLUS ARCHIVELOG when also specifying INCREMENTAL FROM SCN.

Unless the online redo log is archived after the backup, DUPLICATE is not possible with this backup.

See Also: backupTypeSpec for details

As shown in Example 2-23, you can use CHANNEL to specify which channels back up which files.

Note: You can also specify this parameter in the backupSpec clause.

Examples of logical corruption are corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert log and server session trace file. The SET MAXCORRUPT command specifies the total number of physical and logical corruptions permitted in a datafile.

By default, the BACKUP command computes a checksum for each block and stores it in the backup. If you specify the NOCHECKSUM option, then RMAN does not perform a checksum of the blocks when writing the backup.

If SET MAXCORRUPT and NOCHECKSUM are not set, then CHECK LOGICAL detects all types of corruption that are possible to detect during a backup.

You can use multiple format strings to specify different names and locations for the copies. Example 2-22 illustrates a duplexed backup to different locations on disk.

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.

You can specify duplexing in multiple commands. The order of precedence is as follows, with settings higher on the list overriding lower settings:

1. BACKUP COPIES

2. SET BACKUP COPIES

3. CONFIGURE ... BACKUP COPIES

Note: This option does not apply with AS COPY and results in an error message.

Note: Duplexing cannot be used when creating files in the fast recovery area.

Note: This option does not apply with AS COPY and results in an error message.

BACKUP DEVICE TYPE DISK DATABASE;

The DEVICE TYPE option is valid only for automatic channels and is not valid for manually allocated channels. You cannot use the DEVICE TYPE option for a device other than DISK if you have not run CONFIGURE DEVICE TYPE for this device.

Note: To specify a disk channel for the BACKUP RECOVERY AREA command, you must use the TO DESTINATION of the subclause toDestSpec.

See Also: deviceSpecifier

This parameter is only enabled when you are backing up datafiles or control files, and when the operating system can give RMAN disk contention and node affinity data. To manually disable this feature, set DISKRATIO to 0.

For example, assume that datafiles are distributed across 10 disks. If the disks supply data at 10 bytes/second, and if the tape drive requires 50 bytes/second to keep streaming, then set DISKRATIO to 5 to direct RMAN to include datafiles from at least 5 disks in each backup set.

If you set FILESPERSET but not DISKRATIO, then DISKRATIO defaults to the same value as FILESPERSET. If you specify neither parameter, then DISKRATIO defaults to 4. RMAN compares the DISKRATIO value to the actual number of devices involved in the backup and uses the lowest value. For example, if DISKRATIO is 4 and the datafiles are located on three disks, then RMAN attempts to include datafiles from three disks in each backup set.

The DISKRATIO parameter is easier for datafile backups when the datafiles are striped or reside on separate disk spindles and you either:

• Use a high-bandwidth tape drive that requires several datafiles to be multiplexed to keep the tape drive streaming.

• Make backups while the database is open and you must spread the I/O load across several disk spindles to leave bandwidth for online operations.

Note: Do not spread I/O over more than the minimum number of disks required to keep the tape streaming. Otherwise, you increase restore time for a file without increasing performance.

See Also: duration

See Also: fileNameConversionSpec for file renaming patterns

RMAN backs up the files in each backupSpec as one or more backup sets. When the number of files in each backupSpec exceeds the FILESPERSET setting, then RMAN splits the files into multiple backup sets accordingly. The default value for FILESPERSET is 64.

The RMAN behavior is illustrated by the following BACKUP commands:

BACKUP AS BACKUPSET (DATAFILE 3, 4, 5, 6, 7) (DATAFILE 8, 9);
BACKUP AS BACKUPSET DATAFILE 3, 4, 5, 6, 7, 8, 9;
BACKUP AS BACKUPSET DATAFILE 3, ... 72;

In the first command, RMAN places datafiles 3, 4, 5, 6, and 7 into one backup set and datafiles 8 and 9 into another backup set. In the second command, RMAN places all datafiles into one backup set. In the third command, the ellipses indicate datafiles 3 through 72. Because in this case RMAN is backing up 70 datafiles, RMAN places 64 files in one backup set and 6 in another.

By default, RMAN divides files among backup sets to make optimal use of channel resources. The number of files to be backed up is divided by the number of channels. If the result is less than 64, then this number is the FILESPERSET value. Otherwise, FILESPERSET defaults to 64.

Note: You cannot specify the number of backup pieces that are in a backup set.

Note: You can also specify this option in the backupSpecOperand clause.

You can use the BACKUP AUXILIARY FORMAT command to copy datafiles, archived logs, controlfile, and server parameter file (spfile) over the network between primary and standby databases. For example, if a datafile on a primary database was lost, you could CONNECT to the standby database as TARGET and the primary database as AUXILIARY, and copy an intact datafile from the standby host to the primary host.

See Also:Example 2-30, "Copying Archived Log From Operating System File to ASM"

See Also: formatSpec for valid substitution variables

The default location for disk backups depends on whether a fast recovery area is enabled and whether FORMAT is specified:

• If a fast recovery area is enabled, and if you do specify FORMAT, then RMAN names the output files according to the FORMAT setting. If no location is specified in FORMAT, then RMAN creates the backup in a platform-specific location—not in the recovery area.

• If a fast recovery area is enabled, and if you do not specify FORMAT, then RMAN creates the backup in the recovery area and uses the substitution variable %U to name the backup.

• If a fast recovery area is not enabled, and if you do not specify FORMAT, then RMAN creates the backup in a platform-specific location and uses %U to name the backup.

To create RMAN backups in the fast recovery area with names in Oracle Managed Files format, do not specify the FORMAT clause on the BACKUP command or channel.

Note: You cannot specify an Oracle Managed Files filename as the format for a backup. For example, if +DISK1/datafile/system.732.609791431 is an OMF filename, then you cannot specify this filename in the FORMAT parameter.

Backup pieces must have unique names. The maximum length of a backup piece filename is platform-specific. For backups to a media manager, the length is also limited by the limit in the supported version of the media management API. Vendors supporting SBT 1.1 must support filenames up to 14 characters. Some SBT 1.1 vendors may support longer filenames. Vendors supporting SBT 2.0 must support filenames up to 512 characters. Some SBT 2.0 vendors may support longer filenames.

You cannot specify multiple, identical FORMAT strings within a single backupSpec (for example, BACKUP DATAFILE 3 TO '/tmp/df3.f', DATAFILE 4 TO '/tmp/df4.f'). However, RMAN permits a single FORMAT string to exist in multiple backupSpec clauses.

Note: If you are making an archival backup with the KEEP option (see Example 2-26), then the format string must contain %U. The autobackup also uses this format string.

See Also: formatSpec for valid substitution variables

See Also: forRecoveryOfSpec

A full backup has no effect on subsequent incremental backups and is not considered a part of any incremental backup strategy. A full image copy backup can be incrementally updated, however, by applying incremental backups with the RECOVER command.

Note: Unused block compression, which is described in the entry for BACKUP AS BACKUPSET, causes some datafile blocks to be skipped during full backups.

See "Incremental Backups" for an explanation of incremental backups.

One use of this option is to refresh a standby database with changes from the primary database (see Example 2-24, and the chapter on RMAN backups in Oracle Data Guard Concepts and Administration). This backup contains all changed blocks since the standby database was created or last synchronized. At the standby database, you can use RECOVER with NOREDO to apply the incremental backup. All changed blocks captured in the incremental backup are applied at the standby database, bringing it current with the primary database.

If you are not making incremental backups based on Volume Shadow Copy Service (VSS) snapshots, then you should specify formatSpec when you specify INCREMENTAL FROM SCN. The FORMAT string should include substitution variables such as %U because RMAN generates a control file backup.

If you specify FROM SCN with the NOKEEP option, and if you do not specify formatSpec when you specify INCREMENTAL FROM SCN, then RMAN creates incremental backups in the fast recovery area so that you can create incremental backups based on VSS snapshots in a Windows environment. In this way, you can use incremental backup sets and VSS shadow copies in conjunction. Specify the checkpoint SCN value in the FROM SCN parameter identical to the BACKUP_CHECKPOINT value in the VSS backup metadata document. If block change tracking is enabled, then the backups use the change tracking mechanism, which significantly reduces the time taken to create incremental backups. RMAN can apply incremental backups from the fast recovery area during recovery transparently.

Note: You cannot use PLUS ARCHIVELOG when also specifying INCREMENTAL FROM SCN.

See Also: Oracle Database Platform Guide for Microsoft Windows to learn about making backups with VSS

You can use the KEEP syntax to generate archival database backups that satisfy business or legal requirements. The KEEP setting is an attribute of the backup set (not individual backup piece) or image copy.

Note: You cannot use KEEP with BACKUP BACKUPSET.

With the KEEP syntax, you can keep the backups so that they are considered obsolete after a specified time (KEEP UNTIL), or make them never obsolete (KEEP FOREVER). As shown in Example 2-27, you must be connected to a recovery catalog when you specify KEEP FOREVER.

Note: You can use CHANGE to alter the status of a backup generated with KEEP.

See Also: keepOption for more information about backups made with the KEEP option

It is possible for a backup set to span multiple tapes, so blocks from each datafile are written to multiple tapes. If one tape of a multivolume backup set fails, then you lose the data on all the tapes rather than just one. Because a backup set always include a whole file rather than part of a file, you can use MAXSETSIZE to specify that each backup set should fit on one tape.

Specify size in bytes (default), kilobytes (K), megabytes (M), or gigabytes (G). For example, to limit a backup set to 3 MB, specify MAXSETSIZE 3M. The default size is in bytes, rounded down from kilobytes. For example, MAXSETSIZE 3000 is rounded down to 2 KB (2048 bytes). The minimum value must be greater than or equal to the database block size.

The default number of files in each backup set is determined by FILESPERSET, which defaults to 64. When you specify MAXSETSIZE, RMAN attempts to limit the size in bytes of the backup sets according to the MAXSETSIZE parameter. The limit on the number of files in a backup set apply even if the total size of the resulting backup set is less than MAXSETSIZE.

Note: This option results in an error message if used with BACKUP AS COPY. If you run BACKUP AS COPY on a channel that has MAXSETSIZE set, then MAXSETSIZE is silently ignored.

See Also: notBackedUpSpec

A checksum is a number that is computed from the contents of a data block. DB_BLOCK_CHECKSUM is a database initialization parameter that controls the writing of checksums for the blocks in datafiles in the database (not backups). If DB_BLOCK_CHECKSUM is typical, then the database computes a checksum for each block during normal operations and stores it in the block before writing it to disk. When the database reads the block from disk later, it recomputes the checksum and compares it to the stored value. If they do not match, then the block is damaged.

Note: You cannot disable checksums for datafiles in the SYSTEM tablespace even if DB_BLOCK_CHECKSUM=false.

By default, the BACKUP command computes a checksum for each block and stores it in the backup. The BACKUP command ignores the values of DB_BLOCK_CHECKSUM because this initialization parameter applies to datafiles in the database, not backups. If you specify the NOCHECKSUM option, then RMAN does not perform a checksum of the blocks when writing the backup.

When restoring a backup datafile, RMAN honors the DB_BLOCK_CHECKSUM initialization parameter setting. RMAN clears the checksum if DB_BLOCK_CHECKSUM is set to false. If set to typical, then RMAN verifies the checksum when restoring from the backup and writing to the datafile.

Note: You can turn off checksum checking by specifying NOCHECKSUM, but other physical consistency checks, such as checks of the block headers and footers, cannot be disabled.

See Also: Oracle Database Reference for more information about the DB_BLOCK_CHECKSUM initialization parameter

Note: This option does not work with AS COPY and results in an error.

When you run BACKUP with the PROXY option, RMAN performs these steps:

1. Searches for a channel of the specified device type that is proxy-capable. If no such channel is found, then RMAN issues a warning and attempts a a conventional (that is, non-proxy) backup of the specified files.

2. If RMAN locates a proxy-capable channel, then it calls the media manager to check if it can proxy copy the files. If the media manager cannot proxy copy, then RMAN uses conventional backup sets to back up the files.

Note: If you specify PROXY, then the %p variable must be included in the FORMAT string either explicitly or implicitly within %U.

Note: This option does not work with AS COPY and results in an error.

By setting this parameter, RMAN can create a multisection backup. In a multisection backup, RMAN creates a backup piece that contains one file section, which is a contiguous range of blocks in a file. All sections of a multisection backup are the same size.

File sections enable RMAN to create multiple steps for the backup of a single large datafile. RMAN channels can process each step independently and in parallel, with each channel producing one section of a multisection backup set.

If you specify a section size that is larger than the size of the file, then RMAN does not use multisection backup for the file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections.

Depending on where you specify this parameter in the RMAN syntax, you can specify different section sizes for different files in the same backup job.

Note: You cannot use SECTION SIZE with MAXPIECESIZE.

See Also: skipSpec for details.

The tag name is not case-sensitive. The name must be 30 characters or less. The characters are limited to the characters that are valid in filenames on the target file system. For example, ASM does not support the use of the hyphen (-) character in the filenames it uses internally, so weekly-incremental is not a valid tag name for backups in ASM disk groups. Environment variables are not valid in the TAG parameter.

Typically, a tag name is a meaningful name such as MON_PM_BKUP or WEEKLY_FULL_BKUP. Tags are reusable, so that backup set 100 can have the tag MON_PM_BKUP one week while backup set 105 has the same tag the next week.

If you do not specify a tag name, then by default RMAN creates a tag for backups (except for control file autobackups). The default tag uses the format TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, HH is the hour (in 24-hour format), MM is the minutes, and SS is the seconds. For example, a backup of datafile 1 might receive the tag TAG20070208T133437. The date and time refer to when RMAN started the backup. If multiple backup sets are created by one BACKUP AS BACKUPSET command, then each backup piece is assigned the same default tag.

You can also specify the tag at the backupSpec level. If you specify the tag at:

• The command level, then all backup sets created by the command have the tag.

• The backupSpec level, then backup sets created with different backup specifications can have different tags.

• Both levels, then the tag in the backupSpec takes precedence.

Note: A tag is an attribute of each backup piece in a given copy of a backup set (for AS BACKUPSET) or each image copy (for AS COPY). For example, if you run BACKUP AS BACKUPSET COPIES 1 DATABASE TAG TUE_PM, then only one copy of the backup set exists and each backup piece has tag TUE_PM. Assume that this backup set has primary key 1234. If you then run BACKUP BACKUPSET 1234 TAG WED_PM, then the first copy of the backup set has tag TUE_PM and the second copy of the backup set has tag WED_PM.

RMAN creates no output files. This option is equivalent to using the VALIDATE command on the database files specified in the backup.

If you do not specify CHECK LOGICAL, then BACKUP VALIDATE checks for physical corruption only. If you specify CHECK LOGICAL, then BACKUP VALIDATE checks for both physical and logical corruption. RMAN populates the V$DATABASE_BLOCK_CORRUPTION view with any corruptions that it finds.

You can use the SET MAXCORRUPT command to set a limit for the number of corrupt blocks tolerated during the backup validation. The default is zero.

If you execute BACKUP INCREMENTAL with VALIDATE, then the behavior depends on whether block change tracking is enabled. If change tracking is enabled, then RMAN validates only changed blocks; otherwise, RMAN validates all blocks in the files included in the backup.

Note: You cannot validate backups of backup sets.

When backing up archived redo log files, RMAN can perform archived log failover automatically. RMAN backs up the log when at least one archived log corresponding to a given log sequence number and thread is available. Also, if the copy that RMAN is backing up contains corrupt blocks, then it searches for good copies of these blocks in other copies of the same archived redo log files.

RMAN does not signal an error if the command finds no logs to back up, since this situation probably exists because no new logs were generated after the previous BACKUP ARCHIVELOG ALL DELETE INPUT command. The only exception to this behavior is when the SEQUENCE number clause is specified. In this scenario, RMAN signals the RMAN-06004 error if an archived redo log file of the specified sequence is not found.

If you specify BACKUP ARCHIVELOG ALL, then RMAN backs up exactly one copy of each distinct log sequence number. For example, if you archive to multiple destinations, RMAN backs up one copy of each log sequence number—not each copy of each log sequence number. For other commands, such as DELETE ALL does refer to every log, even duplicate log sequences.

If the database is open when you run BACKUP ARCHIVELOG, and if the UNTIL clause or SEQUENCE parameter is not specified, then RMAN runs ALTER SYSTEM ARCHIVE LOG CURRENT.

Note: If you run BACKUP ARCHIVELOG ALL, or if the specified log range includes logs from prior incarnations, then RMAN backs up logs from prior incarnations to ensure availability of all logs that may be required for recovery through an OPEN RESETLOGS.

See Also: archivelogRecordSpecifier for syntax, and Oracle Database Backup and Recovery User's Guide explanations of backup failover for logs and automatic log switching

If you specify the DELETE INPUT option on the BACKUP BACKUPSET command, then RMAN deletes all copies of the backup set that exist on disk. For example, if you duplexed a backup to 4 locations, then RMAN deletes all 4 backup sets. The ALL option does not add any functionality.

RMAN performs backup set failover when backing up backup sets. RMAN searches for all available backup copies when the copy that it is trying to back up is corrupted or missing. This behavior is similar to RMAN's behavior when backing up archived redo log files that exist in multiple archiving destinations.

If backup optimization is enabled when you back up a backup set, and if the identical backup set has been backed up to the same device type, then RMAN skips the backup of this backup set.

Note: You can duplex backups of backup sets with BACKUP COPIES and SET BACKUP COPIES.

Note: When you use BACKUP BACKUPSET command with encrypted backup sets, the backup sets are backed up in their encrypted form. Because BACKUP BACKUPSET just copies an already-encrypted backup set to disk or tape, no decryption key is needed during a BACKUP BACKUPSET operation. The data is never decrypted during any part of the operation. The BACKUP BACKUPSET command can neither encrypt nor decrypt backup sets.

See Also: completedTimeSpec

A control file copy can be created with the BACKUP AS COPY CURRENT CONTROLFILE command or the SQL statement ALTER DATABASE BACKUP CONTROLFILE TO '...'.

Note: A control file autobackup is not a control file copy.

See Also: copyOfSpec

If the backupSpec includes datafile 1, and if CONFIGURE CONTROLFILE AUTOBACKUP is OFF, then RMAN automatically includes the control file in the backup. If the instance is started with a server parameter file, then RMAN also includes this parameter file in the backup.

If the backupSpec includes datafile 1, and if CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN does not automatically include the control file in the output. Instead, RMAN generates a separate control file autobackup piece. If the instance is started with a server parameter file, then RMAN includes this parameter file in the autobackup piece.

Full database backups should usually be either image copies or compressed backup sets. Image copies are more flexible than backup sets for some purposes (such as use in an incrementally updated backups strategy), and compressed backup sets make more efficient use of storage space, if the CPU overhead involved in creating them is tolerable.

Note: To force RMAN to include the current control file in the backup when CONTROLFILE AUTOBACKUP is ON, specify the INCLUDE CURRENT CONTROLFILE clause.

See Also: The TABLESPACE description to learn about backup behavior when the database includes bigfile tablespaces

See Also: datafileCopySpec for details

See Also: datafileSpec

Recovery files are full and incremental backup sets, control file autobackups, datafile copies, and archived redo log files. If an archived redo log file is missing or corrupted, then RMAN looks outside of the recovery area for a good copy of the log that it can use for the backup. Flashback logs, the current control file, and online redo log files are not backed up.

By default, backup optimization is enabled for this command even if the CONFIGURE BACKUP OPTIMIZATION setting is OFF. You can disable backup optimization for BACKUP RECOVERY AREA by specifying FORCE.

Note: If the fast recovery area is not enabled but has been enabled before, then files created in the previous fast recovery area location are backed up.

Recovery files include full and incremental backup sets, control file autobackups, archived redo log files, and datafile copies.

By default, backup optimization is enabled for this command even if the CONFIGURE BACKUP OPTIMIZATION setting is OFF. You can disable backup optimization for RECOVERY FILES by specifying FORCE.

RMAN backs up the server parameter file currently in use by the target database. RMAN cannot back up the server parameter file when the instance was started with an initialization parameter file. RMAN cannot make incremental backups of the SPFILE.

You cannot back up locally-managed temporary tablespaces, although you can back up dictionary-managed tablespaces.

If the following conditions are met, then RMAN can back up transportable tablespaces that have not been made read/write after being transported:

• The COMPATIBLE initialization parameter is set to 11.0.0 or higher.

• You are using an Oracle Database 11g RMAN client.

If any of the preceding conditions is not met, then RMAN automatically skips transportable tablespaces that have not yet been made read/write. Note that if you specify a transportable tablespace explicitly when any of the conditions is not met, then RMAN issues an error saying that the tablespace does not exist.

Note: If you rename a tablespace, then RMAN detects that the tablespace has changed its name and updates the recovery catalog on the next resynchronization.

Specify this option only when backing up archived redo log files, datafile copies (COPY OF or DATAFILECOPY), or backup sets. The BACKUP ARCHIVELOG command only backs up one copy of each distinct log sequence number, so if the DELETE INPUT option is used without the ALL keyword, RMAN only deletes the copy of the file that it backs up.

Specifying the DELETE INPUT option is equivalent to issuing the DELETE command for the input files. When backing up archived redo log files, RMAN uses the configured settings to determine whether an archived redo log can be deleted (CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP).

The ALL option applies only to archived redo log files. If you run DELETE ALL INPUT, then the command deletes all copies of corresponding archived redo log files or datafile copies that match the selection criteria in the BACKUP command (as shown in Example 2-19). For example, if you specify the SEQUENCE n clause, then RMAN deletes all archived redo log files with same sequence number n.

Note: The database retains archived redo log files in the fast recovery area as long as possible and deletes them automatically when disk space is required. You can use the BACKUP DELETE INPUT, DELETE ARCHIVELOG, and DELETE OBSOLETE commands to delete log files manually from inside or outside the recovery area. You do not need to specify BACKUP DELETE INPUT when backing up the recovery area because the database automatically deletes log files based on the archived redo log deletion policy and other fast recovery area rules.

Note: This option does not apply with AS COPY and results in an error message.

AS BACKUPSET is the only possibility when backing up to tape, and for creating level 1 incremental backups to any destination. Backup sets are RMAN-specific logical structures. The backup set is the smallest unit of a backup.

The FILESPERSET parameter of the BACKUP command determines the maximum number of files in each backup set. Archived redo log files and datafiles are never combined into a single backup set.

When using encrypted backups (see "Encryption of Backup Sets"), datafiles from tablespaces with different encryption settings are never written into the same backup set.

RMAN cannot back up files with different block sizes into the same backup set. RMAN can back up tablespaces with different block sizes, but puts each differently sized datafile into its own backup set.

When unused block compression is applied, RMAN reads only the blocks that are currently allocated to a table. RMAN still checks each of the blocks to see whether the header has marked the block as unused. If a block has been unused, it is not written to the backup.

Unused block compression is turned on automatically when all of the following five conditions are true:

1. The COMPATIBLE initialization parameter is set to 10.2 or higher.

   Note: If COMPATIBLE is set to 10.2, then only tablespaces created with 10.2 compatibility are optimized to exclude blocks that do not currently contain data. If COMPATIBLE is set to 11.0.0 or higher, however, then the first backup that produces backup sets after COMPATIBLE is set to 11.0.0 or higher updates the headers of all locally managed datafiles so that all locally managed datafiles can be optimized.

2. There are currently no guaranteed restore points defined for the database.

3. The datafile is locally managed

4. The datafile is being backed up to a backup set as part of a full backup or a level 0 incremental backup

5. The backup set is created on disk or Oracle Secure Backup is the media manager.

   Note: When backing up to a media manager that is not Oracle Secure Backup, RMAN copies all the blocks regardless of whether they contain data or not.

Note: A corrupt unused block is not harmful. This is because when a block is corrupt and RMAN does not read it because of unused block compression, RMAN does not detect the corruption.

See Also: Oracle Backup and Recovery User's Guide for a discussion of null block compression and unused block compression.

Each backup set contains at least one backup piece, which is an RMAN-specific physical file containing the backed up data. You can also use the BACKUP command to generate a proxy copy, which is a backup in which the entire data transfer is conducted by a media manager.

RMAN only records complete backup sets in the RMAN repository. There are no partial backup sets. When a BACKUP command creates backup pieces but does not produce a complete backup set, the backup pieces are discarded.

Note: You cannot stripe a single backup set across multiple channels. You also cannot stripe a single input file across multiple backup sets.

RMAN compresses the data written into the backup set to reduce the overall size of the backup set. All backups that create backup sets can create compressed backup sets. Restoring compressed backup sets is no different from restoring uncompressed backup sets.

RMAN applies a binary compression algorithm as it writes data to backup sets. This compression is similar to the compression provided by many media manager vendors. When backing up to a locally attached tape device, compression provided by the media management vendor is usually preferable to the binary compression provided by BACKUP AS COMPRESSED BACKUPSET. Therefore, use uncompressed backup sets and turn on the compression provided by the media management vendor when backing up to locally attached tape devices. You should not use RMAN binary compression and media manager compression together.

Some CPU overhead is associated with compressing backup sets. If the target database is running at or near its maximum load, then you may find the overhead unacceptable. In most other circumstances, compressing backup sets saves enough disk space to be worth the CPU overhead.

An image copy is a byte-for-byte identical copy of the original file. You can create image copy backups of datafiles, datafile copies, and archived redo log files. Image copy files can only exist on disk. When using incrementally updated backups, the level 0 incremental must be an image copy backup.

By default, BACKUP generates backup sets. You can change the default backup type for disk backups to image copies using the CONFIGURE DEVICE TYPE ... BACKUP TYPE TO COPY command.

RMAN chooses a location for the copy according to the following rules, listed in order of precedence:

1. FORMAT specified on BACKUP command for the object being backed up

2. FORMAT specified for the BACKUP command

3. fileNameConversionSpec setting for BACKUP command

4. CONFIGURE CHANNEL integer ... FORMAT

5. CONFIGURE CHANNEL DEVICE TYPE ... FORMAT

6. Platform-specific default FORMAT (which includes a %U for generating a unique filename)

You can create and restore image copy backups with RMAN or use a native operating system command for copying files. When you use RMAN, copies are recorded in the RMAN repository and are more easily available for use in restore and recovery. Otherwise, you must use the CATALOG command to add the user-managed copies to the RMAN repository so that RMAN can use them.

You cannot make a copy of a backup set, although you can make an image copy of an image copy. To back up a backup set, use BACKUP BACKUPSET.

Note: The output of this command can be image copies or backup sets.

Note: It is not necessary for the image copies that you are backing up to have been created by a single BACKUP command.

Note: The output of this command can be image copies or backup sets.

See Also: datafileSpec

Specify the tablespaces in the list by tablespace name (for example, users) or specify a particular copy by tag name (for example, 0403_CPY_OF_USERS). If you do not specify TAG, then RMAN backs up the most recent datafile copy for each datafile in the tablespace.

Note: The output of this command can be image copies or backup sets.

Without the PARTIAL option, the backup command is considered to have failed if it does not complete in the specified duration, and RMAN reports an error. If the backup command is part of a RUN block, then subsequent commands in the RUN block do not execute.

If you specify TIME, then file most recently backed up is given the lowest priority to back up. This scheduling mechanism provides for the eventual complete backup of the database during successive backup windows, as different datafiles are backed up in round-robin fashion.

Without the PARTIAL option, the backup command is considered to have failed if it does not complete in the specified duration, and RMAN reports an error. If the backup command is part of a RUN block, then subsequent commands in the RUN block do not execute.

Whether PARTIAL is used or not, all backup sets completed before the backup is interrupted are retained and can be used in RESTORE and RECOVER operations.

You should use the WITH TAG clause to separate this incremental backup strategy from the rest of your backup strategies. If you do not specify WITH TAG, then RMAN uses the most recent datafile copy as the basis for the incremental backup.

A BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY command can create image copies or backup sets. RMAN creates level 0 image copies if no such copies exist, but otherwise creates backup sets.

See Also: Oracle Database Backup and Recovery User's Guide to learn how to make incrementally updated backups

By using the BACKUP INCREMENTAL ... WITH TAG syntax, you can create level 1 incremental backups suitable for rolling forward a level 0 image copy. You can then use RECOVER COPY OF ... WITH TAG to apply level 1 backups to this copy. In this way, the strategy continues to roll forward the datafile copy so that media recovery does not need to apply as many changes. This technique is the basis for the Enterprise Manager strategy for disk backups.

When WITH TAG is specified, RMAN automatically assigns all new incremental backups in the strategy the same tag as the level 0 datafile copy. RMAN decides which blocks to include in the level 1 backup based on the available incremental backups that have this tag.

Note: If the BACKUP command has both the TAG and WITH TAG options, then RMAN issues a warning stating that the TAG option will be ignored and that incremental backups will receive the tag specified by WITH TAG.

If no level 0 backup with the tag specified in the WITH TAG parameter exists in either the current or parent database incarnation, then FOR RECOVER OF COPY option creates a level 0 datafile copy tagged with the value specified in the WITH TAG parameter.

If you add a datafile to the database, then you do not need to change the backup script because RMAN automatically creates the level 0 datafile copy required by the incrementally updated backup strategy for the newly created file.

For example, the BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF TAG wholedb ARCHIVELOG ALL command backs up all archived redo log files needed to recover the level 0 incremental backup tagged wholedb.

This subclause is a convenient way to back up new datafiles after adding them to the database. Note that RMAN does not examine datafile checkpoints, but backs up any datafile that is not already backed up. You can also specify NOT BACKED UP when backing up backup sets.

Using BACKUP with this clause does manually what an archived redo log deletion policy can do automatically. If you specify the CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP integer TIMES command, then a BACKUP ARCHIVELOG ALL command copies all logs unless integer backups exist on the specified device type. If integer backups of the logs exist, then the BACKUP 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 command.

Note: This clause overrides backup optimization (CONFIGURE BACKUP OPTIMIZATION) and archived redo log file deletion policies (CONFIGURE ARCHIVELOG DELETION POLICY).

Note: You can only specify NOT BACKED UP integer TIMES when backing up archived redo log files into backup sets.

To determine the number of backups for a file, RMAN only considers backups created on the same device type as the current backup.

This option is a convenient way to back up archived redo log files on a specified media. For example, you want to keep at least three copies of each log on tape.

The date_string is either a date in the current NLS_DATE_FORMAT or a SQL date expression such as 'SYSDATE-1'. When calculating the number of backups for a file, RMAN only considers backups created on the same device type as the current backup.

This option is a convenient way to back up datafiles that were not backed up during a previous failed backup. For example, you back up the database, but the instance fails halfway through. You can restart the backup with the NOT BACKED UP SINCE TIME clause and avoid backing up those files that you already backed up. If AS BACKUPSET is specified, then this feature is only useful if RMAN generates multiple backup sets during the backup.

When determining whether a file has been backed up, the SINCE date is compared with the completion time of the most recent backup. For BACKUP AS BACKUPSET, the completion time for a file in a backup set is the completion time of the entire backup set. In other words, all files in the same backup set have the same completion time.

Note: You can also specify this option in the backupSpec clause.

A datafile is only considered inaccessible if it cannot be read. Some offline datafiles can still be read because they still exist on disk. Others have been deleted or moved and so cannot be read, making them inaccessible.