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 default limit of 4 datafiles or 16 archived logs in each backup set.

1. Runs an ALTER SYSTEM ARCHIVE LOG CURRENT statement.

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

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

4. Runs an ALTER SYSTEM ARCHIVE LOG CURRENT statement.

5. Backs up any remaining archived redo logs.

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

If the sum of physical and logical corruptions detected for a file is no more than its MAXCORRUPT setting, then the backup command completes, and V$DATABASE_BLOCK_CORRUPTION is populated with any corrupt block ranges. If there are more thanMAXCORRUPT corrupt blocks, then the command terminates without updating the view and no output file is created for the backup.

If the initialization parameter DB_BLOCK_CHECKSUM=TRUE, and if MAXCORRUPT and NOCHECKSUM are not set, then specifying CHECK LOGICAL detects all types of corruption that are possible to detect.

Note: The MAXCORRUPT setting specifies the total number of physical and logical corruptions permitted on a file.

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

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

BACKUP DEVICE TYPE DISK DATABASE;

See Also: "deviceSpecifier"

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 = 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 in order to keep the tape drive streaming

• Make backups while the database is open and you need to 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 "fileNameConversionSpec" for details about file renaming patterns.

By default, RMAN divides files among backupsets in order 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 it is the number of files placed in each backupset. Otherwise, 64 files will be placed in each backupset.

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

See Also: "formatSpec" for legal substitution variables

RMAN makes full backups by default if neither FULL nor INCREMENTAL is specified.

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

Note:Backup Unused Space Compression, described in "Unused Block Compression Of Datafile Backups to Backup Sets", causes some datafile blocks to be skipped during full backups of datafiles as backup sets.

Incremental backups at level 0 can be either backup sets or image copies. Incremental backups at level 1 can only be backup sets.

A level 0 backup must exist as the base backup for an incremental strategy. An incremental backup at level 0 is identical in content to a full backup, but unlike a full backup the level 0 backup is considered a part of the incremental strategy. If no level 0 backup exists when you run a level 1 backup, then RMAN makes a level 0 backup automatically.

The database performs checks when attempting to create a level 1 incremental backup, to ensure that the incremental backup is usable by a subsequent RECOVER command. Among the checks performed are:

• A level 0 backup must exist for each datafile in the BACKUP command. These backups must not have status UNAVAILABLE. If no level 0 backup exists, then RMAN makes one.

• Sufficient incremental backups taken since the level 0 must exist and be available such that the incremental backup to be created is usable.

If you specify INCREMENTAL, then in the backupSpec clause you must set one of the following parameters: DATAFILE, DATAFILECOPY, TABLESPACE, or DATABASE. RMAN does not support incremental backups of control files, archived redo logs, or backup sets.

Note: You cannot make inconsistent incremental backups when the database is in NOARCHIVELOG mode. Hence, you cannot generate incremental backups when a NOARCHIVELOG database is open and in use.

Note: When creating an incremental backup, RMAN considers backups from parent incarnations as valid. For example, assume you make a level 0 backup and then OPEN RESETLOGS. If you make a level 1 incremental backup, then RMAN backs up all blocks changed since the pre-RESETLOGS level 0 backup.

See Also: "CHANGE"

The expected use of this feature is in refreshing a standby database with changes from a primary database. See Oracle Database Backup and Recovery Advanced User's Guide for details.

Note:

• The default location of the incremental is the dbs subdirectory under the Oracle home.

• The incremental backup created by BACKUP INCREMENTAL FROM SCN is not part of any incremental strategy at the primary database. It can only be used to refresh a standby with the changes at the primary. In the RMAN repository, this backup is not marked with an incremental level when it is recorded in the RMAN repository. The algorithms that control which backups RMAN selects for use in a restore and recovery do not select incremental backups created using FROM SCN.

See Also: "keepOption"

Specify size in bytes (default), kilobytes (K), megabytes (M), or gigabytes (G). Thus, 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 4 for datafiles and 16 for archived logs. When you specify MAsXSETSIZE, 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 will apply even if the total size of the resulting backup set is less than MAXSETSIZEs.

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

By default, the database also computes a checksum for each block and stores it in the backup. The checksum is verified when restoring from the backup and written to the datafile when restored.

If the database is already maintaining block checksums, then this flag has no effect. The checksum is always verified and stored in the backup in this case.

If you wish to prevent the use of block checksums in your backup, use the NOCHECKSUM option.

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

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

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

If you do not want RMAN to try a conventional copy when a proxy copy fails, use the ONLY option.

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 cannot be used with BACKUP AS COPY and results in an error message.

If you do not specify a tag name, then by default RMAN creates a tag for backups (except for control file autobackups) in 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 can receive the tag TAG20020208T133437. 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.

A tag applies to 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 piece in the backup set 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.

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

Tags must be 30 characters or less. The characters used in a tag must be limited to the characters that are legal in filenames on the target filesystem. For example, ASM does not support the use of the - character in the filenames it uses interally, so a tag including a - (for example, weekly-incremental) is not a legal tag name if you are storing backups in ASM disk groups.

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 as a result of different backup specifications can have different tags.

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

Note: You cannot validate backups of backup sets.

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 default limit of 4 datafiles or 16 archived logs in each backup set.

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 Advanced User's Guide explanations of backup failover for logs and automatic log switching

Note if you specify the DELETE INPUT option, 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 is redundant, that is, it 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 logs that exist in multiple archiving destinations.

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

See Also: "completedTimeSpec"

• 'filename' specifies a control file copy by filename

• ALL specifies that all control file copies should be backed up

• LIKE 'pattern' specifies a filename pattern. The percent sign (%) as a wildcard meaning 0 o r more characters; an underscore (_) is a wildcard meaning 1 character.

The control file copy can be:

• A copy of a normal control file (that is, not a standby control file) created with the BACKUP AS COPY CURRENT CONTROLFILE command or the SQL statement ALTER DATABASE BACKUP CONTROLFILE TO '...'

• A standby control file copy created with the BACKUP AS COPY STANDBY CONTROLFILE command or the SQL statement ALTER DATABASE CREATE STANDBY CONTROLFILE

RMAN inspects the header of the control file copy to determine whether it is a standby or nonstandby control file.

If you specify FOR STANDBY, then RMAN generates a backup of the control file that is usable during creation of a standby database. The backup contains only the standby control file.

Note: You cannot assign a tag to a backup of the current control file.

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

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: "datafileSpec"

RECOVERY AREA and DB_RECOVERY_FILE_DEST are synonyms.

Backup optimization is always ON for this option. The backup must go to sbt, so RMAN issues an error if no sbt channels are allocated or configured.

Note: If the flash recovery area is not enabled but has been enabled in the past, then files that were created in the previous flash recovery area location are backed up.

The TABLESPACE keyword is merely a convenience; tablespace names are translated internally into a list of datafiles. If you rename a tablespace (for example, from users to customers), then RMAN detects that the tablespace has changed its name and updates the recovery catalog on the next resynchronization.

The ALL option applies only to archived logs. If you run DELETE ALL INPUT, then the command deletes all copies of corresponding archived redo logs or datafile copies that match the selection criteria. For example, if you specify the SEQUENCE n clause, then RMAN deletes all archive logs with same sequence number n, including duplicate archived logs (that is, logs with same log sequence number and thread).

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

See Also: "CONNECT" for information on the effect of recovery catalog compatibility on this command

If you specify FOR STANDBY, then RMAN creates a backup of the control file usable for creation of a standby database. The backup set includes the standby control file and the object backed up.

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.

When backing up datafiles into backup sets, RMAN only backs up blocks that are currently in use.

With the COMPRESSED option, binary compression is used. The data written into the backup set is compressed 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.

Note:

• There is some CPU overhead associated with compressing backup sets. If the database being backed up is running at or near its maximum load, you may find the overhead from using AS COMPRESSED BACKUPSET unacceptable. In most other circumstances, compressing backupsets saves enough disk space to be worth the CPU overhead.

• 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. In any case, you should not use both forms of compression together.

• When using incrementally updated backups, the level 0 incremental must be an image copy backup.

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

Note:

When using BACKUP AS COPY, if you do not specify the destination for the image copies, RMAN will choose a location according to the following rules:

• If the channel used for output has a default CONFIGURE... FORMAT setting, that setting is used to generate output file names

• If a flash recovery area is configured, the backups are placed in the flash recovery area

• Otherwise a platform-specific default FORMAT (which includes a %U for generating a unique filename) is used.

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

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.

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"

}

• 'filename' specifies an image copy by filename

• ALL specifies that all datafile image copies should be backed up

• LIKE 'pattern' specifies a filename pattern. The percent sign (%) is a wildcard that means zero or more characters; an underscore (_) is a wildcard that means one character.

• FROM TAG 'tag_name' specifies a list of one or more datafile copies, identified by the tag tag_name. If multiple datafile copies with this tag exist, then RMAN backs up only the most current datafile copy of any particular datafile. Tags are not case sensitive.

[PARTIAL][MINIMIZE (TIME|LOAD)]

With the PARTIAL option, the command is considered to have completed successfully and no error is reported by RMAN even if the whole backup is not completed in the specified duration.

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, subsequent commands in the RUN block do not execute.

Whether PARTIAL is used or not, all backupsets completed before the backup is interrupted are retained and can be used in restore and recover operations.

With disk backups, you can use MINIMIZE TIME run the backup at maximum speed (default) , or MINIMIZE LOAD to slow the rate of backup to lessen the load on the system. With MINIMIZE LOAD the backup will take the full specified duration.

When DURATION is used with MINIMIZE TIME, the 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.

This option is a convenient way to back up files 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 set, 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.

This option is a convenient way to back up archived logs on a specified media (for example, you want to keep at least three copies of each log on tape).

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.