6 Making Backups with RMAN: Advanced Topics

Duplexing Backup Sets with CONFIGURE BACKUP COPIES

The CONFIGURE ... BACKUP COPIES command specifies the number of identical backup sets that you want to create on the specified device type. This setting applies to all backups except control file autobackups (because the autobackup of a control file always produces one copy) and backup sets when backed up with the BACKUP BACKUPSET command. You must have automatic channels configured.

To duplex a backup with CONFIGURE BACKUP COPIES:

Duplexing Backupsets with BACKUP... COPIES

The COPIES option of the BACKUP command overrides every other COPIES or DUPLEX setting to control duplexing of backupsets.

To duplex a backup with BACKUP COPIES:

BACKUP BACKUPSET and Backup Retention Policy

BACKUP BACKUPSET creates additional copies of backup pieces in a backup set by copying backup pieces from disk to tape. If you use the LIST BACKUPS command, the output contains the list of all copies (including copies created by BACKUP BACKUPSET command).

However, BACKUP BACKUPSET does not create a new backup set. In this way, BACKUP BACKUPSET is similar to using the DUPLEX or MAXCOPIES option of BACKUP. The extra copy of a backup set created by BACKUP BACKUPSET is not considered to be a new backup set, as the several copies of a backup set produced by these other forms of the BACKUP command are not separate backup sets.

For the purposes of a redundancy-based backup retention policy, a backup set is counted as one instance of backup, even if there are multiple copies of the backup pieces that make up backup set, such as when a backup set has been backed up from disk to tape. For the purposes of a recovery window retention policy, either all of the copies of a backup set are obsolete, or none of them are.

This is easier to understand if you look at the output of the LIST and REPORT commands. For example, perform the following backup:

RMAN> backup as backupset datafile 5 
RMAN> backup backupset <previous backupset>; 

Now, run the LIST command. The output contains the following:

Notice that the set_stamp and set_count values remain the same, but the copy# is incremented for the new backup. To see the effect of these copies under a redundancy-based backup retention policy, use the following command:

report obsolete redundancy 1;
 

None of the copies is reported as obsolete because both copies of the backup set have the same values for set_stamp & set_count.

To see the effect of these copies under a recovery window-based retention policy, use the following command:

report obsolete recovery window 1 day;
 

None of the copies of the backup set is reported as obsolete or based on the checkpoint_change# of this backupset, with respect to the current time and the availability of other backups.

RMAN Backup Encryption Modes

RMAN offers three encryption modes: transparent mode, password mode, and dual mode.

Using CONFIGURE and SET to Control RMAN Backup Encryption

The CONFIGURE command is used to make persistent settings controlling RMAN encryption of backups, including:

• Whether to encrypt backups of all database files.

• Whether to encrypt backups of specific tablespaces.

• Which algorithm to use for encrypting backups.

The SET ENCRYPTION command is used to:

• Override the encryption settings specified by the CONFIGURE ENCRYPTION command. For example, you can use SET ENCRYPTION OFF to create an unencrypted backup, even though your database is configured to create encrypted backups.

• Set a password for backup encryption, persisting until the RMAN client exits. Due to the sensitive nature of passwords, RMAN does not allow configuration of passwords that persist between RMAN sessions.

If you wish to modify your existing backup environment so that all RMAN backups are encrypted, perform the following steps:

• Set up the Oracle Encryption Wallet

• Issue the following RMAN command:

  RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON
  

After these steps, all RMAN backup sets created by this database will be encrypted, unless you explicitly override this behavior for an RMAN session with:

RMAN> SET ENCRYPTION ON

This remains in effect until you issue the SET ENCRYPTION OFF command during an RMAN session, or change the persistent setting again with:

RMAN> CONFIGURE ENCRYPTION FOR DATABASE OFF

Creating Encrypted Backups

The BACKUP command arguments do not change for creating encrypted backups. Encryption is performed based on the encryption settings specified with CONFIGURE ENCRYPTION or SET ENCRYPTION. Any backup to backup sets is encrypted with the specified settings.

Oracle uses a new encryption key for every encrypted backup. The backup encryption key is then encrypted with either the password, the database master key, or both, depending on the chosen encryption mode. Individual backup encryption keys or passwords are never stored in the clear.

Restoring Data from Encrypted Backups

RMAN automatically decrypts backup sets when their contents are restored. Transparently encrypted backups require no intervention to restore, as long as the Oracle Encryption Wallet is open and available. Password encrypted backups require the correct password to be entered before they can be restored.

You must enter the encryption password using the SET DECRYPTION command. Restore passwords cannot be persistently configured. If restoring from a set of backups that were created with different passwords, then specify all of the required passwords on the SET DECRYPTION command. RMAN will automatically use the correct password with each backup set.

Encryption of Archived Log Backups

There is no persistent configuration that controls whether archivelog backups as backupsets are encrypted. Backup sets containing archived logs are encrypted if any of the following are true:

• SET ENCRYPTION ON is in effect at the time that the archive log backup is being created.

• Encryption is configured for backups of the whole database or at least one tablespace.

This behavior ensures that the redo associated with any encrypted backup of a datafile is also encrypted.

Performance Impact of Encrypting RMAN Backups

Encryption can have a negative effect upon backup performance. Because encrypted backups will use more CPU resource than non-encrypted backups, you can improve performance of encrypted backups by using more RMAN channels.

Backing Up Files Using Backup Optimization

For backup optimization to be enabled, you must CONFIGURE BACKUP OPTIMIZATION to ON. Backup optimization is OFF by default.

To use backup optimization with a backup operation:

Restarting a Backup After It Partially Completes

Use the SINCE TIME parameter of the BACKUP command to specify a date after which a new backup is required. If you do not specify the SINCE parameter, then RMAN only backs up files that have never been backed up.

To only back up files that were not backed up after a specified date:

Specify a valid date in the SINCE TIME parameter. For example, this command uses the default configured channel to back up all database files and archived redo logs that have not been backed up in the last two weeks:

RMAN> BACKUP NOT BACKED UP SINCE TIME 'SYSDATE-14'
          DATABASE PLUS ARCHIVELOG;

Backups to CD, DVD and Other Disk Devices with Large Block Sizes

When backing up database files to DISK, the logical block size of the database file to be backed up must be an even multiple of the physical block size of the destination device. For example, a DISK device with a block size of 2K can only be used as a destination for backups of database files with logical block sizes of 2K, 4K, 6K and so on. In practice, most disk drives have physical block sizes of 512 bytes, so this limitation rarely affects backup to disk drives. However, you can encounter this limitation when using BACKUP ... DEVICE TYPE DISK to back your database up to a writeable CD or DVD, or some other device which has a larger physical block size.

Skipping Tablespaces when Backing Up a Database: Example

The following example assumes that the database is running in ARCHIVELOG mode and that you have an automatic sbt channel configured as follows:

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_DATA_VOLUME_POOL=BackupPool)';

To back up the database while skipping offline and read-only tablespaces, you can run the following command:

RMAN> BACKUP DATABASE
        SKIP READONLY
        SKIP OFFLINE;

You only need to back up a read-only tablespace once after it has been made read-only. You can use the SKIP READONLY option to skip read-only datafiles. If you use the SKIP OFFLINE option, then the BACKUP command does not attempt to access offline datafiles. Use this option if the offline datafiles are not available.

Another way to persistently skip tablespaces across RMAN sessions is to issue the CONFIGURE EXCLUDE command for each tablespace that you always want to skip. For example, you may always want to skip the example tablespace, which has been made read-only. You can then issue:

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE example;

Then, whenever you run BACKUP DATABASE, RMAN skips this tablespace. You do not have to specify a SKIP clause on the BACKUP command. You can override this behavior and include the example tablespace as follows:

RMAN> BACKUP DATABASE NOEXCLUDE;

Restarting a Backup: Example

Assume that you back up the database and archived logs every night to tape by running this command:

RMAN> BACKUP
  MAXSETSIZE 10G
  DATABASE PLUS ARCHIVELOG;

The preceding command sets an upper limit to the size of each backup set so that RMAN produces multiple backup sets. Assume that the media management device fails halfway through the backup and is then restarted. The next day you discover that only half the backup sets completed. In this case, you can run this command in the evening:

RMAN> BACKUP 
  # Note that the NOT BACKED UP SINCE clause should be placed immediately after the BACKUP
  # keyword or after each individual backupSpec clause
  NOT BACKED UP SINCE TIME 'SYSDATE-1'
  MAXSETSIZE 10M 
  DATABASE PLUS ARCHIVELOG;

With this form of the command, RMAN backs up only files that were not backed up during in the previous 24 hours. When RMAN finds out that a backup from the specified time window is already available, it displays output similar to the following:

RMAN-06501: skipping datafile 1; already backed up on NOV 02 2003 18:10:00
RMAN-06501: skipping datafile 2; already backed up on NOV 02 2003 18:09:45
RMAN-06501: skipping datafile 3; already backed up on NOV 02 2003 18:09:45

If the NOT BACKED UP SINCE clause is placed immediately after the backup command, it affects all objects to be backed up. It can also be placed after individual backupSpec clauses, to cause only backups for those objects described by the backupSpec to be subject to the limitation.

Spreading a Backup Across Multiple Disk Drives: Example

Typically, you do not need to specify a format when backing up to tape because the default %U variable generates a unique filename for tape backups. When backing up to disk, however, you can specify a format if you need to spread the backup across several drives for improved performance. In this case, allocate one DISK channel for each disk drive and specify the format string on the ALLOCATE CHANNEL command so that the filenames are on different disks. For example, issue:

RUN
{ 
  ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
  ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
  ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
  BACKUP AS COPY DATABASE; 
} 

You can distribute backups in this manner by default in the future, by configuring channels as follows:

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U';
CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U';
BACKUP AS COPY DATABASE;

If you specify a nonexistent directory, RMAN displays output such as the following:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/29/2001 
            14:36:04
ORA-19504: failed to create file "/nosuchdisk/0cd2momi_1_1"
ORA-27040: skgfrcre: create error, unable to create file
SVR4 Error: 2: No such file or directory

Specifying the Size of Backup Sets: Example

When making backups, RMAN divides the total number of files requiring backups by the number of allocated channels to calculate the number of files to place in each backup set. Use the MAXSETSIZE parameter to override this calculation and specify how many files should go in each backup set.

The MAXSETSIZE parameter specifies a maximum size for a backup set in units of bytes (default), kilobytes, megabytes, or gigabytes. Thus, to limit a backup set to 305 MB, specify MAXSETSIZE=305M. RMAN attempts to limit all sets to this size.

You can use MAXSETSIZE to limit the size of backup sets so that the database is divided among more than one backup set. If you configure MAXSETSIZE so that you generate multiple backup sets, however, then if the backup fails partway through, you can use the restartable backup feature to back up only those files that were not backed up during the previous attempt. See "Restartable Backups" for a conceptual overview of restartable backups.

The following example configures a tape device, then backs up archived redo logs to tape, limiting the size to 100 MB so that if the backup fails partway through, it can be restarted:

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RMAN> BACKUP MAXSETSIZE = 100M ARCHIVELOG ALL;

This example accomplishes the same result with CONFIGURE MAXSETSIZE:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RMAN> CONFIGURE MAXSETSIZE = 100M;
RMAN> BACKUP ARCHIVELOG ALL;

Note that if you specify a MAXSETSIZE value that is too small to contain the biggest file that you are backing up (either the actual size of that file, or if binary compression is specified, then the size of the tfile after compression), then RMAN displays an error stack such as the following:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 11/03/03 14:40:33
RMAN-06182: archive log larger than MAXSETSIZE: thread 1 seq 1
            /oracle/oradata/trgt/arch/archive1_1.dbf

Limiting the Size of Backup Pieces: Example

Backup piece size is an issue in those situations where it exceeds the maximum file size of the file system or media management software. Use the MAXPIECESIZE parameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command to limit the size of backup pieces.

For example, to always limit the backup piece size to 2GB or less, you can configure the automatic DISK channel as follows and then run BACKUP DATABASE:

# max file size for backup pieces is 2GB
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2GB;
RMAN> BACKUP DATABASE;

Note that in version 2.0 of the media management API, media management vendors can specify the maximum size of a backup piece that can be written to their media manager. RMAN will respect this limit regardless of the settings you configure for MAXPIECESIZE.

Backing Up Archived Redo Logs in a Failover Scenario: Example

Assume that you set your initialization parameters so that you archive to the following local destinations:

LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arch/'
LOG_ARCHIVE_DEST_2 = 'LOCATION=/disk2/arch/'
LOG_ARCHIVE_DEST_3 = 'LOCATION=/disk3/arch/'

Each directory contains the same set of logs, starting with log sequence 1 and ending at log sequence 400. Unknown to you, a user inadvertently deletes logs 300 through 400 from /disk1/arch and logs 350 through 400 from /disk2/arch. You run this backup command:

RMAN> BACKUP ARCHIVELOG 
  FROM SEQUENCE 288 UNTIL SEQUENCE 388
  THREAD 1 
  DELETE INPUT;

RMAN begins backing up logs starting with log sequence 288. If the copy of log 300 that was deleted from /disk1/arch is the one that RMAN attempts to back up, then RMAN checks the repository to determine whether other copies of this log sequence exist, and backs up the log in either /disk2/arch or /disk3/arch. Hence, because there is at least one intact copy of each log from sequence 288 through sequence 388, RMAN can back up all the specified logs.

Backing Up Archived Logs Needed to Recover an Online Backup: Example

Assume that you back up database trgt while it is open. You want to back up only those archived redo logs required to recover this online backup.

The recommended solution to this problem is to add the PLUS ARCHIVELOG clause to your database backup command, as shown here:

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

See Oracle Database Backup and Recovery Basics and Oracle Database Backup and Recovery Reference for details on using BACKUP... PLUS ARCHIVELOG.

You can also manually determine which archived logs are required and back them up, using the following procedure.

Backing Up and Deleting Multiple Copies of an Archived Redo Log: Example

In this scenario, you set initialization parameters so that you automatically archive redo logs to two directories: ?/oradata/trgt/arch/dest_1 and ?/oradata/trgt/arch/dest_2. Therefore, you have two identical copies of the archived redo log for each log sequence number. You decide to back up each copy of the archived redo logs and then delete the originals. (Note that the degree of backup duplexing configured or specified in the BACKUP command determines the number of output files, independent of the number of input files. See Duplexing Backup Sets for details.)

The easiest solution in this case is to use the DELETE ALL INPUT option means that RMAN deletes all logs that match the ARCHIVELOG criteria. Hence, it can remove all logs from both ?/oradata/trgt/arch/dest_1 and ?/oradata/trgt/arch/dest_2.

For example, run the following command to back up all logs that could be used to recover from a point 10 days ago, and then delete all logs within the specified time range from disk:

RMAN> BACKUP DEVICE TYPE sbt
  ARCHIVELOG ALL FROM TIME 'SYSDATE-10'
  DELETE ALL INPUT;

Determining How Channels Distribute a Backup Workload: Example

When you create multiple backup sets and allocate multiple channels, RMAN automatically writes multiple backup sets in parallel. The allocated server sessions share the work of backing up the specified datafiles, control files, and archived redo logs. Note that you cannot stripe a single backup set across multiple channels.

RMAN automatically assigns a backup set to a device. You can use the CHANNEL parameter so that RMAN writes all backup sets for a backupSpec to a specific channel.

For example, this example parallelizes the backup operation by specifying which channels RMAN should back up to disk and which to sbt:

RMAN> RUN
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT = '/backup/df/%U';
  ALLOCATE CHANNEL ch2 DEVICE TYPE DISK FORMAT = '/backup/cf/%U';
  ALLOCATE CHANNEL ch3 DEVICE TYPE sbt;
  BACKUP AS BACKUPSET # all output files are in backup sets
    # channel ch1 backs up datafiles to /backup/df directory
    DATAFILE 1,2,3,4 
    CHANNEL ch1
    # channel ch2 backs up control file copy to /backup/cf directory
    CONTROLFILECOPY '/tmp/control01.ctl'
    CHANNEL ch2;
  BACKUP AS BACKUPSET
    # channel ch3 backs up archived redo logs to tape
    ARCHIVELOG FROM TIME 'SYSDATE-14'
    CHANNEL ch3;
}

Backing Up in NOARCHIVELOG Mode: Example

This script puts the database into the correct mode for a consistent, whole database backup and then backs up the database. The script performs a shutdown, startup, shutdown, and then startup again before creating multiple copies of the backup:

# Shut down database cleanly with immediate option. This type of shutdown lets  
# current calls to the database complete, but prevents further logons or calls. 
# If the database is not up, you receive a message saying so but RMAN will not 
# treat this situation as an error.
SHUTDOWN IMMEDIATE; 
  
# Start up the database in case it suffered instance failure or was 
# closed with SHUTDOWN ABORT before starting this script. 
# The script performs instance recovery if 
# needed. Oracle uses the default init.ora file. Alternatively, use this form:
# STARTUP FORCE DBA pfile=filename. 
# Use the DBA option because you are going to shut down again
# and do not want to let users in during the short interval. Use the FORCE 
# option because it cannot hurt and might help in certain situations. 
STARTUP FORCE DBA; 
SHUTDOWN IMMEDIATE; 
  
# The database is cleanly closed and ready for a consistent backup. RMAN
# requires that the database be started and mounted to perform a backup.
RMAN> STARTUP MOUNT;

# this example uses automatic channels to make the backup
BACKUP 
  COPIES 2 
  INCREMENTAL LEVEL 0 
  MAXSETSIZE 10M 
  DATABASE 
  INCLUDE CURRENT CONTROLFILE
  TAG 'BACKUP_1'
;

# Now that the backup is complete, open the database. 
ALTER DATABASE OPEN; 

Note the inclusion of the current control file with the backup, and the use of the tag to identify the backup. To use this backup of the database, the control file must be restored from the same backup as the rest of the database. Adding INCLUDE CURRENT CONTROLFILE ensures that a usable backup of the control file is included with the backup and tagged in order to simplify restoring the control file with the rest of the database.

You can skip tablespaces, such as read-only tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup is lost if the database has to be restored from a backup.

Keeping a Long-Term Backup: Example

If you configure a retention policy, then you may want to exclude specified backups from this policy. For example, you may want to archive a consistent backup of the database once a year to serve as a historical record. This long-term backups does not function as a backup that you may perform recovery on, but an archived snapshot of data at a particular time.

To exempt a backup from the retention policy, specify the KEEP option on the BACKUP command. You can also specify LOGS or NOLOGS to indicate whether RMAN should save archived logs for possible recovery of this backup. If you specify NOLOGS, then the backup must be consistent.

This example keeps the backup of the database indefinitely and does not save archived logs needed to recover it:

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;  # put database in consistent state
RMAN> BACKUP DATABASE KEEP FOREVER NOLOGS 
              TAG 'db_archive_1'; # make long-term consistent backup

# mark backup as unavailable in the repository so that RMAN does not attempt to
# restore it unless explicitly specified on the RESTORE command
RMAN> CHANGE BACKUP TAG 'db_archive_1' UNAVAILABLE;
RMAN> SQL 'ALTER DATABASE OPEN';

Using Backup Optimization: Examples

Run the CONFIGURE BACKUP OPTIMIZATION command to enable backup optimization. When specific conditions are met (described in "Backup Optimization Algorithm"), RMAN skips backups of files that are identical to files that are already backed up.

Assume that you configure optimization and a retention policy as follows:

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;

BACKUP DATABASE;

BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;

# configure backup optimization
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;

# The following command backs up just the logs that are not on tape. The 
# first copies are saved to the tapes from the pool "archivelog_pool_1"
RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt
    PARMS='NSR_DATA_VOLUME_POOL=ARCHIVELOG_POOL_1';
  BACKUP ARCHIVELOG ALL;
}
# Make one more copy of the archived logs and save them to tapes from a 
# different pool 
RUN
{
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt 
    PARMS='NSR_DATA_VOLUME_POOL=ARCHIVELOG_POOL_2';
  BACKUP ARCHIVELOG
    FROM TIME 'SYSDATE-1'
    UNTIL TIME 'SYSDATE'; 
# specify UNTIL so RMAN does not archive current log
}
# Delete old logs - for example, delete logs created within the last week. 
DELETE ARCHIVELOG ALL COMPLETED AFTER 'SYSDATE-7';

# configure backup optimization
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE default DEVICE TYPE TO sbt;
# configure a default channel that sends backups to tape pool "first_copy"
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_DATA_VOLUME_POOL=first_copy);

BACKUP ARCHIVELOG ALL TAG first_copy;

RUN
{
  # manually allocate a channel, in order to specify that the backup run by this
  # channel should go to both pools "first_copy" and "second_copy"
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt
      PARMS='ENV=(NSR_DATA_VOLUME_POOL=second_copy)';
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt
      PARMS='ENV=(NSR_DATA_VOLUME_POOL=first_copy)';
  BACKUP CHANNEL C1 ARCHIVELOG UNTIL TIME 'SYSDATE' 
    NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape
    TAG SECOND_COPY; 
  BACKUP CHANNEL C2 ARCHIVELOG UNTIL TIME 'SYSDATE' 
    NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape
    TAG FIRST_COPY;
}

# now delete from disk all logs that have been backed up to tape at least twice
DELETE ARCHIVELOG ALL
  BACKED UP 2 TIMES TO DEVICE TYPE sbt;

CHANGE BACKUP OF ARCHIVELOG TAG SECOND_COPY UNAVAILABLE;

Handling Corruption During Backups: Example

By default a checksum is calculated for every block read from a datafile and stored in the backup or image copy. If you use the NOCHECKSUM option, then checksums are not calculated. If the block already contains a checksum, however, then the checksum is validated and stored in the backup. If the validation fails, then the block is marked corrupt in the backup.

The SET MAXCORRUPT FOR DATAFILE command sets how many corrupt blocks in a datafile that BACKUP will tolerate. If a datafile has more corrupt blocks than specified by the MAXCORRUPT parameter, the command terminates. If you specify the CHECK LOGICAL option, RMAN checks for logical and physical corruption.

By default, the BACKUP command terminates when it cannot access a datafile. You can specify parameters to prevent termination, as listed in the following table.

The following example uses an automatic channel to back up the database, and sets the corruption level for the datafile in the SYSTEM tablespace so that up to 10 errors will be accepted:

RMAN> RUN
{
  SET MAXCORRUPT FOR DATAFILE 1 TO 10;
  BACKUP DATABASE
    SKIP INACCESSIBLE
    SKIP READONLY
    SKIP OFFLINE; 
}