The MAXSETSIZE parameter of the BACKUP command specifies a maximum size for a backup set in units of bytes (default), kilobytes, megabytes, or gigabytes.

For example, to limit a backup set to 305 MB, specify MAXSETSIZE 305M. RMAN attempts to limit all backup sets to this size.

You can use BACKUP ... MAXSETSIZE to limit the size of backup sets so that the database is divided among multiple backup sets. If the backup fails part way through, then you can use the restartable backup feature to back up only those files that were not backed up during the previous attempt.

In some cases the MAXSETSIZE value may be too small to contain the largest file that you are backing up. When determining whether MAXSETSIZE is too small, RMAN uses the size of the original data file rather than the file size after compression. 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/13 14:40:33
RMAN-06182: archive log larger than MAXSETSIZE: thread 1 seq 1
            /oracle/oradata/trgt/arch/archive1_1.dbf

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 MAXSETSIZE parameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command to limit the size of backup pieces.

1. Start RMAN and connect to a target database and recovery catalog (if used).

   See Also:

   Making Database Connections with RMAN

2. Execute the BACKUP command with the MAXSETSIZE parameter.

   The following example backs up archived logs to tape, limiting the size of each backup set to 100 MB:

   BACKUP DEVICE TYPE sbt
     MAXSETSIZE 100M
     ARCHIVELOG ALL;

If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN creates a backup set in which each backup piece contains the blocks from one file section.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. If necessary, configure channel parallelism so that RMAN can make the backup parallel.
3. Execute BACKUP with the SECTION SIZE parameter.

   For example, suppose that the users tablespace contains a single data file of 900 MB. Also assume that three SBT channels are configured, with the parallelism setting for the SBT device set to 3. You can break up the data file in this tablespace into file sections as shown in the following example:

   BACKUP
     SECTION SIZE 300M
     TABLESPACE users;

   In this example, each of the three SBT channels backs up a 300 MB file section of the users data file.

In Oracle Secure Backup, a media family is a named group of volumes with a set of shared, user-defined attributes. In this scenario, you back up logs that are not on tape to one media family, then back up the same logs to a second media family. Finally, you delete old logs.

# The following command backs up just the logs that are not on tape. The 
# first copies are saved to the tapes from the media family "log_family1".
RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt
    PARMS 'ENV=(OB_MEDIA_FAMILY=log_family1)';
  BACKUP ARCHIVELOG ALL;
}
# Make one more copy of the archived logs and save them to tapes from a 
# different media family
RUN
{
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt 
    PARMS 'ENV=(OB_MEDIA_FAMILY=log_family2)';
  BACKUP ARCHIVELOG
    NOT BACKED UP 2 TIMES;
}

CONFIGURE ARCHIVELOG DELETION POLICY 
  TO BACKED UP 2 TIMES TO DEVICE TYPE sbt;

The CONFIGURE...BACKUP COPIES command specifies the number of identical backup sets to create on the specified device type.

1. Configure the number of copies on the desired device type for data files and archived redo logs on the desired device types.

   By default, CONFIGURE...BACKUP COPIES is set to 1 for each device type. The following example configures duplexing for data files and archived logs on tape and also duplexing for data files (but not archived redo logs) on disk:

   CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
   CONFIGURE DEFAULT DEVICE TYPE TO sbt;
   CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/%U', '/disk2/%U';
   CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
   CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
   CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
   

2. Execute the BACKUP command.

   The following command backs up the database and archived logs to tape, making two copies of each data file and archived log:

   BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
   

   Because of the configured formats for the disk channel, the following command backs up the database to disk, placing one copy of the backup sets produced in the /disk1 directory and the other in the /disk2 directory:

   BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE;
   

   If the FORMAT clause were not configured on CONFIGURE CHANNNEL, then you specify FORMAT on the BACKUP command itself. For example, you issue the following command:

   BACKUP AS BACKUPSET DATABASE 
     FORMAT '/disk1/%U', 
            '/disk2/%U';
   

3. Issue a LIST BACKUP command to see a listing of backup sets and pieces.

   For example, enter the following command:

   LIST BACKUP SUMMARY;
   

   The #Copies column shows the number of backup sets, which may have been produced by duplexing or by multiple backup commands.

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

1. Specify the number of identical copies with the COPIES option of the BACKUP command. For example, run the following to make three copies of each backup set in the default DISK location:

   BACKUP AS BACKUPSET DEVICE TYPE DISK 
     COPIES 3 
     INCREMENTAL LEVEL 0 
     DATABASE;
   

   Because you specified COPIES in the BACKUP command, RMAN makes three backup sets of each data file regardless of the CONFIGURE DATAFILE COPIES setting.

2. Issue a LIST BACKUP command to see a listing of backup sets and pieces (the #Copies column shows the number of copies, which may have been produced through duplexing or through multiple invocations of the BACKUP command). For example, enter:

   LIST BACKUP SUMMARY;

Backup encryption is performed based on the specified encryption settings.

Encryption can be set with the following commands:

• CONFIGURE ENCRYPTION

  You can use this command to persistently configure transparent encryption. You cannot persistently configure dual mode or password mode encryption.

• SET ENCRYPTION

  You can use this command to configure dual mode or password mode encryption at the RMAN session level.

The database 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 clear text.

A single restore operation can process backups encrypted in different modes. For each backup piece that it restores, RMAN checks whether it is encrypted. Transparently encrypted backups need no intervention if the Oracle keystore is open and available.

If password encryption is detected, then RMAN searches for a matching key in the list of passwords entered in the SET DECRYPTION command. If RMAN finds a usable key, then the restore operation proceeds. Otherwise, RMAN searches for a key in the Oracle keystore. If RMAN finds a usable key, then the restore operation proceeds; otherwise, RMAN signals an error that the backup piece cannot be decrypted.

RMAN encryption is a CPU-intensive operation and can affect backup performance. The actual amount of CPU utilization during encryption depends on whether both input and output devices for disk and SBT produce and consume data faster than the CPU can encrypt it. Here are a few guidelines for managing and trying to maximize CPU performance:

• Because encrypted backups consume more CPU resources than unencrypted backups, you can improve performance of encrypted backups to disk by using more RMAN channels. A general rule is to use the same number of channels as the number of CPU cores in your system. For example, use two channels for a dual-core processor.

• If both the disk subsystem and SBT-subsystem are fast, you can expect very high CPU utilization. You may want to consider slowing the rate of the backup by setting the RMAN READRATE parameter. For example, you can set an upper limit for block reads so that RMAN does not consume excessive disk bandwidth and thereby degrade online performance.

You can set an encryption password in an RMAN session by executing the SET ENCRYPTION BY PASSWORD command. If transparent encryption is configured, then specify the ONLY keyword to indicate that the backups are protected with a password and not with the configured transparent encryption.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. Execute the SET ENCRYPTION ON IDENTIFIED BY password ONLY command.

   The following example sets the encryption password for all tablespaces (where password is a placeholder for the actual password that you enter) in the backup and specifies ONLY to indicate that the encryption is password-only:

   SET ENCRYPTION IDENTIFIED BY password ONLY ON FOR ALL TABLESPACES;
   

3. Back up the database.

   For example, enter the following command:

   BACKUP DATABASE PLUS ARCHIVELOG;

Use the SET ENCRYPTION BY PASSWORD command at the RMAN prompt to make password-protected backups. If transparent encryption is configured, then omit the ONLY keyword to indicate that the backups are protected with both a password and the configured transparent encryption.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. Execute the SET ENCRYPTION BY PASSWORD command, making sure to omit the ONLY keyword.

   The following example sets the encryption password for all tablespaces (where password is a placeholder for the actual password that you enter) in the backup and omits ONLY to indicate dual-mode encryption:

   SET ENCRYPTION IDENTIFIED BY password ON FOR ALL TABLESPACES;
   

3. Back up the database.

   For example, enter the following command:

   BACKUP DATABASE PLUS ARCHIVELOG;

The minimum unit of restartability is a data file. However, if a backup set contains one backup piece, and if this piece contains blocks from multiple data files, then the unit of restartability is the backup piece. The unit of restartability for image copies is a data file.

The benefit of restartable backups is that if the backup generates multiple backup sets, then the backup sets that completed successfully do not have to be rerun. However, if the entire database is written into one backup set, and if the backup fails halfway through, then the entire backup has to be restarted.

Any I/O errors that RMAN encounters when reading files or writing to the backup pieces or image copies cause RMAN to terminate the backup job in progress. For example, if RMAN tries to back up a data file but the data file is not on disk, then RMAN terminates the backup. If multiple channels are being used or redundant copies of backups are being created, however, then RMAN may be able to continue the backup without user intervention.

RMAN can back up only those files that have not been backed up since a specified date. Use this feature after a backup fails to back up the parts of the database missed by the failed backup.

You can restart a backup by specifying the SINCE TIME clause on the BACKUP command. If the SINCE TIME is later than the completion time, then RMAN backs up the file. If you use BACKUP DATABASE NOT BACKED UP without the SINCE TIME parameter, then RMAN only backs up files that have never been backed up.

Use the SINCE TIME parameter of the BACKUP command to specify a date after which a new backup is required.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. Execute the BACKUP ... NOT BACKED UP SINCE TIME command.

   Specify a valid date in the SINCE TIME parameter. The following example 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:

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

A backup window is a period of time during which a backup must complete. For example, you may want to restrict your database backups to a window of time when user activity on your system is low, such as between 2:00 a.m. and 6:00 a.m.

RMAN backs up the least recently backed up files first. By default, RMAN backs up the files at the maximum possible speed. Specifying a window does not mean that RMAN backs up data faster than normal to ensure that the backup completes before the window ends.

By default, if the backup is not complete within the DURATION time, then RMAN interrupts the backup and reports an error. If the BACKUP command is in a RUN command, then the RUN command terminates. Any completed backup sets are retained and can be used in restore operations, even if the entire backup is not complete. Thus, if you retry a job that was interrupted when the available duration expired, each successive attempt covers more of the files needing backup. Any incomplete backup sets are discarded.

Use the DURATION parameter of the BACKUP command to specify how long a given backup job is allowed to run.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. Execute the BACKUP DURATION command.

   For example, run the following command at 2:00 a.m. to specify that the backup runs until 6:00 a.m.:

   BACKUP 
     DURATION 4:00 
     TABLESPACE users;

When you specify PARTIAL, RMAN does not report an error when a backup is interrupted because of the end of the backup window. Instead, RMAN displays a message showing which files are not backed up.

1. Start RMAN and connect to a target database and recovery catalog (if used).
2. Execute the BACKUP DURATION command with the PARTIAL option.

   For example, you run the following command at 2:00 a.m. to specify that the backup runs until 6:00 a.m. and that each data file is in a separate backup set:

   BACKUP 
     DURATION 4:00 PARTIAL 
     TABLESPACE users 
     FILESPERSET 1;

When using DURATION you can run the backup with the maximum possible performance, or run as slowly as possible while still finishing within the allotted time, to minimize the performance impact of backup tasks.

BACKUP 
  DURATION 4:00 PARTIAL 
  MINIMIZE TIME 
  DATABASE 
  FILESPERSET 1;

BACKUP 
  DURATION 4:00 
  MINIMIZE LOAD 
  DATABASE 
  FILESPERSET 1;