2 RMAN Backups Concepts

This chapter describes the basic concepts involved in backing up the database with the Recovery Manager (RMAN) utility.

This chapter contains these topics:

About RMAN Channels

An RMAN channel represents one stream of data to a device type, and corresponds to one server session. Most backup and recovery commands in RMAN are executed by server sessions. As illustrated in Figure 2-1, each channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance. The server session performs the backup, restore, and recovery.

Figure 2-1 Channel Allocation

Description of Figure 2-1 follows
Description of "Figure 2-1 Channel Allocation"

You can use the CONFIGURE CHANNEL command to configure channels for use with disk or tape in all RMAN sessions using automatic channel allocation, or allocate channels manually within a RUN block. RMAN comes preconfigured with one DISK channel that you can use for backups to disk.

When you run a command that requires a channel without allocating a channel explicitly, then RMAN automatically allocates the channels with the options specified in the CONFIGURE command. For the BACKUP command, RMAN allocates only a single type of channel, such as DISK. For the RESTORE command and maintenance commands (for example, DELETE), RMAN allocates all necessary channels for the device types required to execute the command.

To specify the device type to use for an operation explicitly, use the ALLOCATE CHANNEL command, which must be used within a RUN block, or ALLOCATE CHANNEL FOR MAINTENANCE, which must be executed at the RMAN prompt.

In a Real Application Clusters configuration, there are special considerations regarding channel allocation and backups. See Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more details.

How and when the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands cause the media manager to allocate resources is vendor-specific. Some media managers allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.

See Also:

Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL syntax and Oracle Database Backup and Recovery Reference on ALLOCATE CHANNEL FOR MAINTENANCE

Automatic and Manual Channel Allocation

You can use the automatic channel allocation feature to configure a set of persistent, automatic channels for use in all RMAN sessions. You can use the manual channel allocation feature to specify channels for commands used within a RUN block.

RMAN allocates automatic channels according to the settings in these commands:

  • CONFIGURE DEVICE TYPE ... PARALLELISM

  • CONFIGURE DEFAULT DEVICE TYPE

  • CONFIGURE CHANNEL

For example, you can issue the following commands at the RMAN prompt:

# since you do not manually allocate channels, RMAN uses preconfigured channels
BACKUP DATAFILE 3;
RESTORE TABLESPACE users;

When you run a command that requires channels, and no channels have been allocated using the ALLOCATE command, RMAN automatically allocates channels according to values set with the CONFIGURE command in the following cases:

  • You use commands such as BACKUP, RESTORE, or DELETE outside of a RUN block.

  • You use commands within a RUN block but do not allocate any channels within the RUN block.

You can override automatic channel allocation settings by manually allocating channels within a RUN block. Manual channels always override automatic channels. For example, you override automatic channel allocation when you issue a command as follows:

RUN 
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  BACKUP DATABASE PLUS ARCHIVELOG;
}

RMAN optimizes automatic channel allocation by leaving automatic channels allocated so long as each new command requires exactly the same channel configuration as the previous command. For example, RMAN can use the same preallocated channels for the following series of commands:

BACKUP DATAFILE 1;
BACKUP CURRENT CONTROLFILE;
BACKUP ARCHIVELOG ALL;

If you issue a command such as ALLOCATE or CONFIGURE, then RMAN automatically releases the preallocated channels.

See Also:

"Configuring Channels" to learn how to configure automatic channels

Automatic Channel Device Configuration and Parallelism

The CONFIGURE DEVICE TYPE ... PARALLELISM command specifies the number of automatic channels to allocate for a specified device type. For example, if you configure parallelism to 3 for a device type, then RMAN allocates three channels for the device type when using automatic channels.

You can change a parallelism setting by issuing another CONFIGURE DEVICE TYPE ... PARALLELISM command. This example configures PARALLELISM 2 and then changes it to 3:

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE DEVICE TYPE DISK PARALLELISM 3;

The parallelism setting defines the number of channels for a device that RMAN allocates in parallel. It does not have to correspond to the actual number of channels configured for the device. For example, you can manually configure four different sbt channels and set PARALLELISM for sbt to 2, 1, or 10.

You can view the default setting for parallelism by running the SHOW DEVICE TYPE command. For example:

RMAN> SHOW DEVICE TYPE;
RMAN configuration parameters are:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; #default

As always when the SHOW command is used to view the value of a parameter, RMAN includes a "#default" comment at the end of the line if the RMAN default value has not been overridden.

The following example configures the default device to sbt and then displays the resulting configuration using the SHOW DEVICE TYPE command:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
new RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO 'sbt';
new RMAN configuration parameters are successfully stored

RMAN> SHOW DEVICE TYPE;
RMAN configuration parameters are:
CONFIGURE DEVICE TYPE SBT PARALLELISM 1; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; #
default

See Also:

"Configuring Channel Parallelism"

Automatic Channel Default Device Types

Run the CONFIGURE DEFAULT DEVICE TYPE command to specify a default device type for automatic channels. For example, you may make backups to tape most of the time and only occasionally make a backup to disk. In this case, configure channels for disk and tape devices, but make sbt the default device type:

CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # configure device disk
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; # configure device sbt
CONFIGURE DEFAULT DEVICE TYPE TO sbt;

Now, RMAN will, by default, use sbt channels for backups. For example, if you run the following command:

BACKUP TABLESPACE users;

RMAN only allocates channels of type sbt during the backup because sbt is the default device.

You can override the default device for backups by specifying the target device as part of the command. For example:

BACKUP DEVICE TYPE sbt DATABASE;

If the default device type is DISK, then the preceding command overrides this default and uses the sbt channel configuration. Note that this command fails unless you have configured the sbt device or configured sbt channels.

When restoring files, RMAN allocates all automatic channels according to the settings configured for each device type. The default device type configuration is irrelevant. For example, if you configure PARALLELISM to 3 for the default sbt device and PARALLELISM to 2 for DISK, then RMAN automatically allocates three sbt channels and two DISK channels during the restore.

Automatic Channel Naming Conventions

RMAN uses the following convention for channel naming: ORA_devicetype_n, where devicetype refers to the user's device type (such as DISK or sbt_tape) and n refers to the channel number.

Note:

The sbt and sbt_tape device types are synonymous, but RMAN output always displays sbt_tape whether the input is sbt or sbt_tape.

For example, RMAN names the first DISK channel ORA_DISK_1, the second ORA_DISK_2, and so forth. RMAN names the first sbt channel ORA_SBT_TAPE_1, the second ORA_SBT_TAPE_2, and so forth. When you parallelize channels, RMAN always allocates channels in numerical order, starting with 1 and ending with the parallelism setting (CONFIGURE DEVICE TYPE ... PARALLELISM n), as in this example:

ORA_SBT_TAPE_1
ORA_SBT_TAPE_2
ORA_SBT_TAPE_3

Automatic channel allocation also applies to maintenance commands. If RMAN allocates an automatic maintenance channel, then it uses the same naming convention as any other automatically allocated channel. If you manually allocate a maintenance channel using ALLOCATE CHANNEL FOR MAINTENANCE, then RMAN uses the following convention for channel naming: ORA_MAINT_devicetype_n, where devicetype refers to the user's device type (for example, DISK or sbt) and n refers to the channel number. For example, RMAN uses these names for two manually allocated disk channels:

ORA_MAINT_DISK_1
ORA_MAINT_DISK_2

Note that if you run the CONFIGURE DEVICE TYPE command to configure default settings for a device type and do not run CONFIGURE CHANNEL for this device type, then RMAN allocates all channels without other channel control options. For example, assume that you configure the sbt device and run a backup as follows:

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
BACKUP DEVICE TYPE sbt DATABASE;

In effect, RMAN does the following:

RUN 
{
  ALLOCATE CHANNEL ORA_SBT_TAPE_1 DEVICE TYPE sbt;
  BACKUP DATABASE;
}

Channel names beginning with the ORA_ prefix are reserved by RMAN for its own use. You cannot manually allocate a channel with a name that begins with ORA_.

Automatic Channel Generic Configurations

The CONFIGURE CHANNEL DEVICE TYPE command configures generic settings that are used for all automatic channels of the specified device type. In other words, the command creates a template of settings that RMAN uses for all channels allocated on the device. For example, you can configure disk and tape channels as follows:

CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_SERVER=bksvr1)';
CONFIGURE CHANNEL DEVICE TYPE DISK RATE 5M FORMAT="?/oradata/%U";

Because you do not specify channel numbers for these channels, the channel settings are generic to all automatic channels of the specified type. The configuration acts as a template. For example, if you set PARALLELISM for DISK to 10, and the default device type is DISK, then RMAN allocates ten disk channels using the settings in the CONFIGURE CHANNEL DEVICE TYPE DISK command.

See Also:

"Configuring Channels"

Automatic Channel-Specific Configurations

You can also configure parameters that apply to a specific automatic channel. If you are using a media manager that requires different settings on each channel, then you may find it useful to configure individual channels.

You can mix a CONFIGURE CHANNEL command that creates a generic configuration with a CONFIGURE CHANNEL command that creates a specific configuration. A generic automatic channel creates a configuration that can be used for any channel that is not explicitly configured.

For example, assume that you run these commands:

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2M;
CONFIGURE CHANNEL 3 DEVICE TYPE DISK MAXPIECESIZE = 900K;

In this scenario, RMAN allocates ORA_DISK_1 and ORA_DISK_2 with option MAXPIECESIZE = 2M, using the settings for the DISK channel with no number. RMAN allocates ORA_DISK_3 with MAXPIECESIZE = 900K because this channel was manually assigned a channel number. RMAN always allocates the number of channels specified in the parallelism parameter.

See Also:

"Configuring Channels"

Clearing Automatic Channel Settings

You can specify the CLEAR option for any CONFIGURE command. The CLEAR option returns the specified configuration to its default value. Assume you run these commands:

CONFIGURE DEVICE TYPE DISK CLEAR;     # returns DISK to default PARALLELISM 1
                                      # and backup type to BACKUPSET
CONFIGURE DEFAULT DEVICE TYPE CLEAR;    # returns to default device type of DISK
CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR; # removes all options for sbt channel
CONFIGURE CHANNEL 3 DEVICE TYPE DISK CLEAR; # removes configurations for 3rd ch.

Each CONFIGURE...CLEAR command removes the user-entered settings and returns the configuration to its default value.

The only way to find out the default setting for parameters set through CONFIGURE is to use CONFIGURE... CLEAR to un-set the parameter, so that it takes on the default value, and then run SHOW ALL to view all parameters. For any parameter for which the value is currently set to RMAN'S default, RMAN includes a "#default" comment at the end of that line of the output from SHOW ALL.

See Also:

Oracle Database Backup and Recovery Reference for the default settings for each CONFIGURE command

Determining Channel Parallelism to Match Hardware Devices

RMAN can perform the I/O required for many commands in parallel, to make optimal use of your hardware resources. To perform I/O in parallel, however, the I/O must be associated with a single RMAN command, not a series of commands. For example, it can be more efficient to back up three datafiles using a command such as:

BACKUP DATAFILE 5,6,7;

rather than issuing the commands

BACKUP DATAFILE 5;
BACKUP DATAFILE 6;
BACKUP DATAFILE 7;

When all three datafiles are backed up in one command, RMAN recognizes the opportunity for parallelism and can use multiple channels to do the I/O in parallel. When three separate commands are used, RMAN can only perform the backups one at a time, regardless of available channels and I/O devices.

The number of channels available (whether allocated in a RUN block or configured in advance) for use with a device at the moment that you run a command determines whether RMAN will read from or write to that device in parallel while carrying out the command. Failing to allocate the right number of channels adversely affects RMAN performance during I/O operations.

As a rule, the number of channels used in carrying out an individual RMAN command should match the number of physical devices accessed in carrying out that command. If manually allocating channels for a command, allocate one for each device; if configuring automatic channels, configure the PARALLELISM setting appropriately.

When backing up to tape, you should allocate one channel for each tape drive. When backing up to disk, allocate one channel for each physical disk, unless you can optimize the backup for your disk topography by using multiple disk channels. Each manually allocated channel uses a separate connection to the target or auxiliary database.

The following script creates three backups sequentially: three separate BACKUP commands are used to back up one file each. Only one channel is active at any one time because only one file is being backed up in each command.

RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt;
  ALLOCATE CHANNEL c3 DEVICE TYPE sbt;
  BACKUP DATAFILE 5;
  BACKUP DATAFILE 6;
  BACKUP DATAFILE 7;
}

The following statement uses parallelization on the same example: one RMAN BACKUP command backs up three datafiles, with all three channels in use. The three channels are concurrently active—each server session copies one of the datafiles to a separate tape drive.

RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt;
  ALLOCATE CHANNEL c3 DEVICE TYPE sbt;
  BACKUP DATAFILE 5,6,7;
}

See Also:

Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for information about parallelization in a Real Application Clusters (RAC) configuration.

Channel Control Options for Manual and Automatic Channels

Whether you allocate channels manually or automatically, you can use channel control commands and options to do the following:

  • Control the operating system resources RMAN uses when performing RMAN operations

  • Affect the degree of parallelism for a backup or restore command

  • Set limits on I/O bandwidth consumption in kilobytes, megabytes, or gigabytes (ALLOCATE CHANNEL ... RATE, CONFIGURE CHANNEL ... RATE)

  • Set limits on the size of backup pieces (the MAXPIECESIZE parameter specified on the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands)

  • Set limits on the size of backup sets (the MAXSETSIZE parameter specified on the BACKUP and CONFIGURE commands)

  • Send vendor-specific commands to the media manager (SEND)

  • Specify vendor-specific parameters for the media manager (ALLOCATE CHANNEL ... PARMS, CONFIGURE CHANNEL ... PARMS)

  • Specify which instance performs the operation (ALLOCATE CHANNEL ... CONNECT, CONFIGURE CHANNEL ... CONNECT)

In releases 8.1.5 and later of the database, the ALLOCATE CHANNEL command causes RMAN to contact the media manager whenever the type specified is other than DISK. In earlier releases, the ALLOCATE CHANNEL command does not cause RMAN to contact the media manager; RMAN does not call the media manager until a BACKUP, RESTORE, or RECOVER command is issued.

Note:

When you specify DEVICE TYPE DISK with any version of RMAN, RMAN does not allocate operating system resources other than for the creation of the server session and does not call the media manager.

Because RMAN has one preconfigured automatic DISK channel, you do not have to manually allocate a maintenance channel when running CHANGE, CROSSCHECK, or DELETE against a disk file (that is, an ARCHIVELOG, DATAFILECOPY, or CONTROLFILECOPY).

A maintenance channel is useful only for a maintenance task; you cannot use it as an input or output channel for a backup or restore.

See Also:

Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL syntax, and Oracle Database Backup and Recovery Reference for CONFIGURE syntax

Channel Failover

A BACKUP command is decomposed into multiple independent backup steps by RMAN. Each independent step can be executed on any channel allocated for the type of device used in the command. If you have multiple channels allocated, and one channel fails or encounters a problem during a backup step, then RMAN attempts to complete the work on another channel. Typically, such retriable errors can occur when a media manager encounters problems with one of several tape drives, or when an instance fails in a RAC environment.

RMAN reports a message in V$RMAN_OUTPUT and in the output to the interactive session or log file when it encounters such problems, as in the following example (refer to bold text):

channel ORA_SBT_TAPE_1: backup set failed, re-triable on other channel 
ORA-19506: failed to create sequential file, name="/bkup/63d3c3og_1_1", parms="" ORA-27028: skgfqcre: sbtbackup returned error 
ORA-19511: Error received from media manager layer, error text: failed to open 
           file /bkup/63d3c3og_1_1 for backup, errno = 2 
channel ORA_SBT_TAPE_2: finished piece 1 at 06-SEP-01 piece handle=5ld3blun_1_1 
                        comment=API Version 2.0,MMS Version 3.2.0.0 
channel ORA_SBT_TAPE_2: backup set complete, elapsed time: 00:00:04 
retrying ORA_SBT_TAPE_1 failed backup step on ORA_SBT_TAPE_2 
channel ORA_SBT_TAPE_2: starting full datafile backupset 
channel ORA_SBT_TAPE_2: specifying datafile(s) in backupset input datafile 
                        fno=00004 name=/oracle/dbs/tbs_12.f input datafile 
                        fno=00017 name=/oracle/dbs/tbs_14.f
channel ORA_SBT_TAPE_2: starting piece 1 at 06-SEP-01 piece handle=5ld3buds_1_1 
                        comment=API Version 2.0,MMS Version 3.2.0.0 
channel ORA_SBT_TAPE_2: backup set complete, elapsed time: 00:00:06

Note that if RMAN is executing a script, then the next command in the script will not be executed if there were any errors in the previous command.

See Also:

"Interpreting RMAN Message Output" to learn more about RMAN message and error reporting

About RMAN Backups

When you execute the BACKUP command in RMAN, you create one or more backup sets or image copies. By default, RMAN creates backup sets regardless of whether the destination is disk or a media manager.

About Image Copies

An image copy is an exact copy of a single datafile, archived redo log file, or control file. Image copies are not stored in an RMAN-specific format. They are identical to the results of copying a file with operating system commands. RMAN can use image copies during RMAN restore and recover operations, and you can also use image copies with non-RMAN restore and recovery techniques.

To create image copies and have them recorded in the RMAN repository, run the RMAN BACKUP AS COPY command (or, alternatively, configure the default backup type for disk as image copies using CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY before performing a backup). A database server session is used to create the copy, and the server session also performs actions such as validating the blocks in the file and recording the image copy in the RMAN repository.

You can also use an operating system command such as the UNIX dd command to create image copies, though these will not be validated, nor are they recorded in the RMAN repository. You can use the CATALOG command to add image copies created with native operating system tools in the RMAN repository.

Using RMAN-Created Image Copies

If you run a RESTORE command, then by default RMAN restores a datafile or control file to its original location by copying an image copy backup to that location. Image copies are chosen over backup sets because of the extra overhead of reading through an entire backup set in search of files to be restored.

However, if you need to restore and recover a current datafile, and if you have an image copy of the datafile available on disk, then you do not actually need to have RMAN copy the image copy back to its old location. You can instead have the database use the image copy in place, as a replacement for the datafile to be restored. The SWITCH command updates the RMAN repository indicate that the image copy should now be treated as the current datafile. Issuing the SWITCH command in this case is equivalent to issuing the SQL statement ALTER DATABASE RENAME FILE. You can then perform recovery on the copy.

User-Managed Image Copies

RMAN can use image copies created by mechanisms outside of RMAN, such as native operating system file copy commands or third-party utilities that leave image copies of files on disk. These copies are known as user-managed copies or operating system copies.

The RMAN CATALOG command causes RMAN to inspect an existing image copy and enter its metadata into the RMAN repository. Once cataloged, these files can be used like any other backup with the RESTORE or SWITCH commands.

Some sites store their datafiles on mirrored disk volumes, which permit the creation of image copies by breaking a mirror. After you have broken the mirror, you can notify RMAN of the existence of a new user-managed copy, thus making it a candidate for a backup operation. You must notify RMAN when the copy is no longer available, by using the CHANGE ... UNCATALOG command. In this example, before resilvering the mirror (not including other copies of the broken mirror), you must use a CHANGE ... UNCATALOG command to update the recovery catalog and indicate that this copy is no longer available.

See Also:

About Proxy Copies

During a proxy copy, RMAN turns over control of the data transfer to a media manager that supports this feature. Proxy copy can only be used with media managers that support it, not with disk. The PROXY option of the BACKUP command specifies that a backup should be a proxy copy.

For each file that you attempt to back up with the BACKUP PROXY command, RMAN queries the media manager to determine whether it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN backs the file up as if the PROXY option had not been used. (Use the PROXY ONLY option to force RMAN to fail if a proxy copy cannot be performed.)

Proxy copy can be used with datafiles or archived redo logs, as shown in these examples:

BACKUP DEVICE TYPE sbt PROXY DATAFILE 3;
BACKUP DEVICE TYPE sbt PROXY ONLY DATABASE;
BACKUP DEVICE TYPE sbt PROXY ONLY ARCHIVELOG ALL;

The examples assume that sbt channels have been configured with the appropriate parameters.

Note that control files are never backed up with proxy copy. If the PROXY option is specified on an operation backing up a control file, it is silently ignored for the purposes of backing up the control file.

See Also:

Storage of Backups on Disk and Tape

RMAN can create backups on disk or a third-party media device such as a tape drive. If you specify DEVICE TYPE DISK, then your backups are created on disk, in the file name space of the target instance that is creating the backup. You can make a backup on any device that can store a datafile.

To create backups on non-disk media, such as tape, you must use third-party media management software, and allocate channels with device types, such as SBT, that are supported by that software.

Backups of Archived Logs

There are several features of RMAN backups specific to backups of archived redo logs.

Deletion of Archived Logs After Backups

RMAN can delete one or all copies of archived logs from disk after backing them up to backup sets. If you specify the DELETE INPUT option, then RMAN backs up exactly one copy of each specified log sequence number and thread from an archive destination to tape, and then deletes the specific file it backed up while leaving the other copies on disk. If you specify the DELETE ALL INPUT option, then RMAN backs up exactly one copy of each specified log sequence number and thread, and then deletes that log from all archive destinations. Note that there are special considerations related to deletion of archived redo logs in standby database configurations. See Oracle Data Guard Concepts and Administration for details.

Backup Failover for Archived Redo Logs

RMAN's archived redo log failover allows RMAN to complete a backup even when some archived log destinations are missing logs or have logs with corrupt blocks. If at least one log corresponding to a given log sequence and thread is available in any of the archiving destinations, then RMAN tries to back it up. If RMAN finds a corrupt block in a log file during backup, it searches other destinations for a copy of that log without corrupt blocks.

By default, RMAN only backs up one copy of each distinct log sequence number. For example, assume that you archive logs 121 through 124 to two archiving destinations: /arch1 and /arch2. The control file contains archived log records as follows:

Sequence Filename in /arch1 Filename in /arch2
121 /arch1/archive1_121.arc /arch2/archive1_121.arc
122 /arch1/archive1_122.arc /arch2/archive1_122.arc
123 /arch1/archive1_123.arc /arch2/archive1_123.arc
124 /arch1/archive1_124.arc /arch2/archive1_124.arc

However, unknown to RMAN, a user deletes logs 122 and 124 from the /arch1 directory. Then, you run the following backup:

BACKUP ARCHIVELOG FROM SEQUENCE 121 UNTIL SEQUENCE 125;

With failover, RMAN completes the backup, using logs 122 and 124 in /arch2.

Multiplexed Backup Sets

When creating backup sets, you can multiplex files. In this case, RMAN simultaneously reads multiple files from disk and then writes their blocks into the same backup set. (Image copies, by contrast, are never multiplexed.) For example, RMAN can read from two datafiles simultaneously, and then combine the blocks from these datafiles into a single backup piece.

As Figure 2-2 illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece. This backup piece contains the intermingled data blocks of the three input files.

Figure 2-2 Datafile Multiplexing

Description of Figure 2-2 follows
Description of "Figure 2-2 Datafile Multiplexing"

Algorithm for Multiplexed Backups

RMAN multiplexing is determined by the following algorithm:

  1. The number of files in each backup set is determined by computing the lesser of the following values:

    • The default number of files in a backup set (16 for archived logs, and 4 for datafiles)

  2. The number of files read by each channel.

    The level of multiplexing is determined by the lesser of the following values:

    • The number of files in the backup set (as calculated by the preceding step)

  3. The default number of files that RMAN reads simultaneously on a single channel (8 files for each channel)

Assume that you are backing up twelve datafiles with one RMAN channel. The number of files in each backup set is 4. To determine the level of multiplexing, compare this value to 8 and take the lesser, which is 4. Because the level of multiplexing is 4, the channel includes blocks from four separate datafiles into each backup set.

See Also:

Multiplexing by the Media Manager

Media manager multiplexing occurs when the media manager writes the concurrent output from multiple RMAN channels to a single sequential device, such as a tape drive.

Caution:

Although media manager multiplexing can sometimes provide a performance benefit during backup, it can have a negative impact on restore performance. Oracle recommends using RMAN multiplexing instead of using multiplexing by the media manager.

Manual Parallelization of Backups

When you configure PARALLELISM to greater than 1 or manually allocate multiple channels, RMAN writes multiple backups sets or image copies in parallel. The channels divide the work of backing up the specified files.

Note:

You cannot stripe a single backup set across multiple channels.

By default, RMAN determines which channels should back up which database files. You can use the CHANNEL option of the BACKUP command to manually assign a channel to back up specified files. This example shows a parallel backup to the default disk location that uses the default automatic DISK channels:

BACKUP
  (DATAFILE 1,2,3 
   CHANNEL ORA_DISK_1)
  (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf'
   CHANNEL ORA_DISK_2)
  (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1 
   CHANNEL ORA_DISK_3);

You can also manually allocate channels as in the following example:

RUN 
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server1)";
  ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server2)";
  ALLOCATE CHANNEL c3 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server3)";
  BACKUP
   (DATAFILE 1,2,3
    CHANNEL c1)
   (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf'
     CHANNEL c2)
   (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1
     CHANNEL c3);
}

Figure 2-3 shows an example of parallelization in which channel ch1 backs up datafiles, channel ch2 backs up datafile copies, and channel ch3 backs up logs.

Figure 2-3 Parallelization of Backups

Description of Figure 2-3 follows
Description of "Figure 2-3 Parallelization of Backups"

See Also:

Multiple Copies of RMAN Backups

In RMAN, there are two ways to make multiple, identical copies of backups:

  • Duplex your backups within the BACKUP AS BACKUPSET command, in which case RMAN creates more than one copy of each backup set

  • Back up your files as backup sets or image copies, and then back up the backup sets or image copies using the RMAN BACKUP BACKUPSET or BACKUPCOPY commands.

Duplexed Backup Sets

When backing up datafiles, archived redo log files, server parameter files and control files into backup pieces, RMAN can duplex the backup set, producing up to four identical copies of each backup piece in the backup set on different backup destinations with one BACKUP command. (Note that duplexing is not supported for backup operations that produce image copies.)

There are three ways to specify duplexing of backup sets when using the BACKUP command:

  • Specify a default level of duplexing with CONFIGURE... BACKUP COPIES

    All backup commands that back up data into backup sets will be affected if you use this option, unless you specify different duplexing options for a command using SET BACKUP COPIES or provide a COPIES option for the BACKUP command.

  • Use SET BACKUP COPIES in a RUN block

    All commands in the RUN block will be affected, overriding any CONFIGURE... BACKUP COPIES setting, except those where you provide a COPIES option as part of the BACKUP command.

  • Provide a COPIES option to the BACKUP command

    For this specific BACKUP command, files will be duplexed to produce the number of copies you specify.

The FORMAT option of the BACKUP command specifies the destinations to be used when performing duplexed backups. You can specify up to 4 values for the FORMAT option. RMAN uses the second, third, and fourth values only when BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES is specified. The following example creates 3 copies of the backup of datafile 7:

BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/tmp/%U','?/oradata/%U','?/%U';

RMAN places the first copy of each backup piece in /tmp, the second in ?/oradata, and the third in the Oracle home. Note that RMAN does not produce 3 backup sets, each with a different unique backup set key. Rather, RMAN produces one backup set with a unique key, and generates 3 identical copies of each backup piece in the set, as shown in this sample LIST output:

List of Backup Sets
===================

BS Key  Type LV Size
------- ---- -- ----------
1       Full    64K
  List of Datafiles in backup set 1
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  7       Full 98410      08-FEB-03 /oracle/oradata/trgt/tools01.dbf

  Backup Set Copy #1 of backup set 1
  Device Type Elapsed Time Completion Time Tag
  ----------- ------------ --------------- ---
  DISK        00:00:01     08-FEB-03       TAG20030208T152314

    List of Backup Pieces for backup set 1 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    1       1   AVAILABLE   /tmp/01dg9tb2_1_1

  Backup Set Copy #2 of backup set 1
  Device Type Elapsed Time Completion Time Tag
  ----------- ------------ --------------- ---
  DISK        00:00:01     08-FEB-03       TAG20030208T152314

    List of Backup Pieces for backup set 1 Copy #2
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    2       1   AVAILABLE   /oracle/oradata/01dg9tb2_1_2

  Backup Set Copy #3 of backup set 1
  Device Type Elapsed Time Completion Time Tag
  ----------- ------------ --------------- ---
  DISK        00:00:01     08-FEB-03       TAG20030208T152314

    List of Backup Pieces for backup set 1 Copy #3
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    3       1   AVAILABLE   /oracle/01dg9tb2_1_3

When choosing which FORMAT value to use for each backup piece, RMAN uses the first format value for copy number 1, the second format value for copy number 2, and so forth. If the number of format values exceeds the number of copies, then the extra formats are not used. If the number of format values is less than the number of copies, then RMAN reuses the format values, starting with the first one.

See Also:

Backups of Backup Sets

The RMAN BACKUP BACKUPSET command backs up previously created backup sets. Only backup sets that were created on device type DISK can be backed up using RMAN. They can be backed up to any available device type.

Note:

RMAN issues an error if you attempt to run BACKUP AS COPY BACKUPSET.

The BACKUP BACKUPSET command uses the default disk channel to copy backup sets from disk to disk. To back up from disk to tape, you must either configure or manually allocate a non-disk channel.

Uses for Backups of Backup Sets

The BACKUP BACKUPSET command is a useful way to spread backups among multiple media. For example, you can execute the following BACKUP command weekly as part of the production backup schedule:

# makes backup sets on disk
BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE PLUS ARCHIVELOG; 
BACKUP DEVICE TYPE sbt BACKUPSET ALL; # copies backup sets on disk to tape

Note:

Backups to sbt that use automatic channels require that you first run the CONFIGURE DEVICE TYPE sbt command.

In this way, you ensure that all your backups exist on both disk and tape. You can also duplex backups of backup sets, as in this example:

BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;

(Again, control file autobackups are never duplexed.)

You can also use BACKUP BACKUPSET to manage backup space allocation. For example, to keep more recent backups on disk and older backups only on tape, you can regularly run the following command:

BACKUP DEVICE TYPE sbt BACKUPSET COMPLETED BEFORE 'SYSDATE-7' DELETE INPUT;

This command backs up backup sets that were created more than a week ago from disk to tape, and then deletes them from disk. Note that DELETE INPUT here is equivalent to DELETE ALL INPUT;RMAN deletes all existing copies of the backup set. If you duplexed a backup to four locations, then RMAN deletes all four copies of the pieces in the backup set.

Backup Optimization When Backing Up Backup Sets

If backup optimization is enabled when you issue the command to back up a backup set, and if the identical backup set has already been backed up to the same device type, then RMAN skips the backup of this backup set. For example, when backup optimization is turned on, the following command backs up to tape only those backup sets not already backed up on device type sbt:

BACKUP DEVICE TYPE sbt BACKUPSET ALL;

Backup Failover When Backing Up Backup Sets

When backing up backup sets, if RMAN discovers that one copy of a backup set is corrupted or missing, then it searches for other copies of the same backup set, based on the RMAN repository records about the backup set. This behavior is similar to the behavior of RMAN when backing up archived redo logs that exist in multiple archiving destinations.

For example, assume that backup set with key 872 contains three backup pieces, and that BACKUP COPIES 3 was issued so that three copies of each backup piece were created, each on a different file system. Also assume that some copies have been deleted or corrupted, so that the following table describes the current status of the backup copies:

Backup Piece Number Copy Number of the Piece Status of Copy
1 1 Corrupted
1 2 Intact
1 3 Corrupted
2 1 Missing
2 2 Corrupted
2 3 Intact
3 1 Intact
3 2 Corrupted
3 3 Missing

The following command will cause RMAN to perform automatic failover:

BACKUP BACKUPSET 872;

RMAN copies only the backup pieces listed as "Intact" in the preceding table in its backup set.

Backups of Image Copies

You can use the following commands to back up existing image copies of database files either as backup sets or as image copies:

  • BACKUP AS COPY COPY OF DATABASE

  • BACKUP AS BACKUPSET COPY OF TABLESPACE tablespace_name

  • BACKUP AS BACKUPSET COPY OF DATAFILE datafile

When using these commands, there must already exist an image copy of every datafile specified in the command. If there are multiple copies of a datafile, the latest one is used. If you specify a tablespace or the whole database, RMAN issues an error if there are any datafiles in the database or tablespace specified for which there are no image copy backups in the RMAN repository.

RMAN Backup Options: Naming, Sizing, and Speed

Recovery Manager provides a number of options to control filenames, sizes of backups and speed during backup.

Generating Filenames for RMAN Backup Pieces

You can either let RMAN determine a unique name for backup pieces or use the FORMAT parameter to specify a name. For example, enter:

BACKUP TABLESPACE users;

RMAN automatically generates unique names for the backup pieces in the default backup location.

The FORMAT parameter provides substitution variables that you can use to generate unique filenames. For example, you can run a command as follows:

BACKUP TABLESPACE users FORMAT = '/tmp/users_%u%p%c';

As described in "Manual Parallelization of Backups", you can specify up to four FORMAT values. RMAN uses the second, third, and fourth values only when you run BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES.

Note:

If you use a media manager, then check your vendor documentation for restrictions on FORMAT such as the size of the name, the naming conventions, and so forth.

See Also:

Oracle Database Backup and Recovery Reference for descriptions of the FORMAT parameter and the substitution variables

Generating Filenames for RMAN Image Copies

RMAN can generate filenames for image copies using either FORMAT or DB_FILE_NAME_CONVERT.

Using FORMAT with RMAN BACKUP AS COPY

As with backup pieces,FORMAT variables are also used to specify the names of image copies. The default format %U is defined differently for image copies than for backup pieces. RMAN produces image copies of three types of files: datafiles, control files, and archived logs. The following table describes the meaning of %U for each type of file.

Type of File Meaning of %U
Datafile data-D-%d_id-%I_TS-%N_FNO-%f_%u
Archived log arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u
Control file cf-D_%d-id-%I_%u

Using DB_FILE_NAME_CONVERT With BACKUP AS COPY

When creating image copies, you can also name the output copies with the DB_FILE_NAME_CONVERT option of the BACKUP command. This parameter works identically to the initialization parameter DB_FILE_NAME_CONVERT. Pairs of filename prefixes are provided to change the names of the output files. If a file is not converted by any of the pairs, then RMAN uses the FORMAT specification; if no FORMAT is specified, then RMAN uses the default format %U.

For example, you can run the following command to copy the datafiles whose filename is prefixed with /maindisk/oradata/users so that they are prefixed with /backups/users_ts:

BACKUP AS COPY TABLESPACE users
  DB_FILE_NAME_CONVERT=('/maindisk/oradata/users','/backups/users_ts');

Note:

There are restrictions on using DB_FILE_NAME_CONVERT with BACKUP AS COPY to convert Oracle Managed Files (OMF) filenames. See Oracle Database Backup and Recovery Reference for details on these restrictions.

Using Tags to Identify RMAN Backups

You can assign a user-specified character string called a tag to backup sets and image copies (either copies created by RMAN or copies created by an operating system utility). A tag is a symbolic name for a backup set or file copy, such as weekly_backup. You can specify the tag rather than the filename when executing the RESTORE or CHANGE command. The maximum length of a tag is 30 bytes.

Default RMAN Backup Tag Format

If you do not specify a tag, then RMAN creates a default 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 may receive the tag TAG20030208T133437. The date and time refer to when RMAN started the backup, in the time zone of the instance performing the backup. If multiple backup sets are created by one BACKUP command, then each backup piece is assigned the same default tag.

How Tags Are Applied

When applied to a backup set, a tag applies to a specific copy of the backup set. If you do not duplex a backup set, that is, make multiple identical copies of it, then the backup set has just one tag. For example,

BACKUP COPIES 1 DATAFILE 7 TAG foo;

creates one backup set with tag FOO. Tags are stored in uppercase, regardless of the case used when entering them. However, you can back up this backup set and give this new copy of the backup set the tag BAR. So, the backup set has two identical copies: one tagged FOO and the other tagged BAR.

When applied to image copies, a tag applies to each individual image copy. For example, you run the following command:

# Back up as image copies the datafiles of tablespaces users and tools
# all copies get the TAG 'users_tools' 
BACKUP AS COPY TAG users_tools TABLESPACE users, tools;

You can also copy an image copy with a specific tag, and give the output copy a different tag, as in the following example:

# Create new copies of all image copies of the database that have the tag 
# 'full_cold_copy', and give the new copies the tag 'new_full_cold_copy'
BACKUP AS COPY 
  COPY OF DATABASE 
    FROM TAG=full_cold_copy 
    TAG=new_full_cold_copy;

# Create backup sets of the image copy of tablespace users that has the tag
# 'monday_users', and of tablespace SYSTEM which has the tag 'monday_system'.
# All these new backup # sets receive the tag 'for_audit'.
BACKUP AS BACKUPSET TAG for_audit 
  COPY OF TABLESPACE users FROM TAG monday_users 
    TABLESPACE SYSTEM FROM TAG monday_system;

Uniqueness of Backup Tags

Tags do not need to be unique, so multiple backup sets or image copies can have the same tag, for example, weekly_backup. When you specify that a datafile should be restored from backups that have a specific tag, and more than one backup of the requested file has the desired tag, RMAN restores the most recent backup that has the desired tag (within any other constraints of the restore command, of course, such as a point in time).

Tags can indicate the intended purpose or usage of different classes of backups or copies. For example, you can tag datafile copies that you intend to use in a SWITCH differently (for_switch_only) from file copies that should be used only for RESTORE (for_restore_only).

Note:

If you specify the FROM tag option to the RESTORE or SWITCH command, then RMAN considers only backup sets and image copies with a matching tag when choosing which backup to use

See Also:

Oracle Database Backup and Recovery Reference for SWITCH syntax, and Oracle Database Backup and Recovery Reference for RESTORE syntax

Size of Backup Pieces

RMAN will, by default, put the entire contents of a backup set into one backup piece, regardless of the size of the backup set. If you are backing up to a file system or media manager that has a limit on the maximum file size that can be created, then you may need to restrict the size of backup pieces that RMAN will create.To restrict the size of each backup piece, specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. This option limits backup piece size to the specified umber of bytes. If the total size of the backup set is greater than the specified backup piece size, then multiple physical pieces will be created to hold the backup set contents.

For example, if datafile 1 is 6GB, you can still restrict the backup piece size for disk backups to 2 GB by configuring an automatic disk channel, and then run a backup as follows:

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G;
BACKUP AS BACKUPSET DATAFILE 1;

A LIST BACKUP command reveals that RMAN created five backup pieces rather than one backup piece to conform to the MAXPIECESIZE size restriction:

BS Key  Type LV Size       Device Type Elapsed Time Completion Time     
------- ---- -- ---------- ----------- ------------ --------------------
29      Full    9728M      DISK        00:00:35     NOV 02 2002 18:29:26
  List of Datafiles in backup set 29
  File LV Type Ckp SCN    Ckp Time             Name
  ---- -- ---- ---------- -------------------- ----
  1       Full 177590     NOV 02 2002 18:28:51 /oracle/oradata/trgt/system01.dbf

  Backup Set Copy #1 of backup set 29
  Device Type Elapsed Time Completion Time      Tag
  ----------- ------------ -------------------- ---
  DISK        00:00:35     NOV 02 2002 18:29:26 TAG20021102T152701

    List of Backup Pieces for backup set 29 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    53      1   AVAILABLE   /oracle/dbs/10d85733_1_1
    54      2   AVAILABLE   /oracle/dbs/10d85733_2_1
    55      3   AVAILABLE   /oracle/dbs/10d85733_3_1
    56      4   AVAILABLE   /oracle/dbs/10d85733_4_1
    57      5   AVAILABLE   /oracle/dbs/10d85733_5_1

This option can be used for media managers that cannot manage a backup piece that spans more than one tape. For example, if a tape can hold 10GB, but the backup set being created must hold 80GB of data, then RMAN must be instructed to create backup pieces of 10GB, small enough to fit on the tapes used with the media manager. The backup set media will in this case consist of eight tapes. Media managers supporting SBT2.0 can return a value to RMAN indicating the largest supported backup piece size, which RMAN will use in planning backup activities.

See Also:

Number and Size of Backup Sets

Use the backupSpec clause of the BACKUP command to specify the objects that you want to back up as well as specify other options. Each backupSpec clause produces at least one backup set. The total number and size of backup sets depends for the most part on an internal RMAN algorithm, although you can tune RMAN behavior to a certain extent with the MAXSETSIZE parameter.

Factors Affecting the Number and Size of Backup Sets

In determining the characteristics of the RMAN backup sets, the internal algorithm is influenced by the following factors:

  • The number of input files specified in each backupSpec clause

  • The number of channels that you allocate

  • The default number of files in each backup set (4 for datafiles and 16 for archived logs)

  • The default number of files read simultaneously by a single channel (8)

  • The MAXSETSIZE parameter (specified on the CONFIGURE and BACKUP commands), which specifies a maximum backup set size

The most important rules in the algorithm for backup set creation are:

  • Each allocated channel that performs work in the backup job—that is, each channel that is not idle—generates at least one backup set.

    Note:

    RMAN writes backup pieces sequentially; striping a backup piece across multiple output devices is not supported. For example, RMAN does not simultaneously write half of a backup piece to one device and the other half to another device, nor can it write the first piece of a backup set to one device and the second piece to another device.

  • RMAN always tries to divide the backup load so that all allocated channels have roughly the same amount of work to do.

  • The default number of datafiles in each backup set is determined by an internal RMAN limit (16 for archived logs, 4 for datafiles).

  • The number of datafiles multiplexed in a backup set is limited by the lesser of the number of files in each backup set and the default number of files read by a single channel simultaneously (8).

  • The maximum size of a backup set is determined by the MAXSETSIZE parameter of the CONFIGURE or BACKUP command.

    See Also:

    Oracle Database Backup and Recovery Reference to learn the syntax for the backupSpec clause, and Chapter 11, "Tuning Backup and Recovery" to learn about RMAN buffer management

Overview of the MAXSETSIZE Parameter

To specify the maximum size of each backup set, use the MAXSETSIZE parameter in the CONFIGURE or BACKUP command. By limiting the overall size of the backup set, the parameter indirectly limits the number of files in the set and can possibly force RMAN to create additional backup sets.

Specifying MAXSETSIZE: Example

Assume that you want to back up 50 datafiles, each containing 1000 blocks. To set the maximum size of each backup set to 10 MB, use the following command:

BACKUP DATABASE MAXSETSIZE = 10M;

Caution:

If a datafile being backed up is bigger than MAXSETSIZE then your backup will fail. Always ensure that MAXSETSIZE is as large as your largest datafile.

See Also:

Oracle Database Backup and Recovery Reference for information on the MAXSETSIZE parameter

I/O Read Rate of Backups

By default, RMAN uses all available I/O bandwidth to read/write to disk. You can limit the I/O resources consumed by a backup job with the RATE option of the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. The RATE option specifies the maximum number of bytes for each second that RMAN reads on the channel.

For example, you can configure automatic channels to limit each channel to read 1 MB a second:

CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt RATE 1M;

In effect, the RATE option throttles RMAN so that a backup job does not consume excessive I/O bandwidth on the computer.

See Also:

"Tuning RMAN Backup Performance: Procedure" for tips about how to optimize RMAN performance

RMAN Backup Types

As explained in Table 2-1, RMAN backups can be classified in these ways:

  • Full or incremental

  • Open or closed

  • Consistent or inconsistent

Note that these backup classifications apply only to datafile backups. Backups of other files, such as archivelogs and control files, always include the complete file and are never inconsistent.

Table 2-1 Backup Types

Backup Type Definition

Full

A backup of a datafile that includes every allocated block in the file being backed up. A full backup of a datafile can be an image copy, in which case every data block is backed up. It can also be stored in a backup set, in which case datafile blocks not in use may be skipped, according to rules in Oracle Database Backup and Recovery Reference.

A full backup cannot be part of an incremental backup strategy; that is, it cannot be the parent for a subsequent incremental backup.

Incremental

An incremental backup is either a level 0 backup, which includes every block in the file except blocks compressed out because they have never been used, or a level 1 backup, which includes only those blocks that have been changed since the parent backup was taken.

A level 0 incremental backup is physically identical to a full backup. The only difference is that the level 0 backup is recorded as an incremental backup in the RMAN repository, so it can be used as the parent for a level 1 backup.

Open

A backup of online, read/write datafiles when the database is open.

Closed

A backup of any part of the target database when it is mounted but not open. Closed backups can be consistent or inconsistent.

Consistent

A backup taken when the database is mounted (but not open) after a normal shutdown. The checkpoint SCNs in the datafile headers match the header information in the control file. None of the datafiles has changes beyond its checkpoint. Consistent backups can be restored without recovery.

Note: If you restore a consistent backup and open the database in read/write mode without recovery, transactions after the backup are lost. You still need to perform an OPEN RESETLOGS.

Inconsistent

A backup of any part of the target database when it is open or when a crash occurred or SHUTDOWN ABORT was run prior to mounting.

An inconsistent backup requires recovery to become consistent.

Incremental Backups

The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database.

During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. If it has a choice, then RMAN always chooses incremental backups over archived logs, as applying changes at a block level is faster than reapplying individual changes.

RMAN does not need to restore a base incremental backup of a datafile in order to apply incremental backups to the datafile during recovery. For example, you can restore non-incremental image copies of the datafiles in the database, and RMAN can recover them with incremental backups.

Incremental backups allow faster daily backups, use less network bandwidth when backing up over a network, and provide better performance when tape I/O bandwidth limits backup performance. They also allow recovery of database changes not reflected in the redo logs, such as direct load inserts. Finally, incremental backups can be used to back up NOARCHIVELOG databases, and are smaller than complete copies of the database (though they still require a clean database shutdown).

One effective strategy is to make incremental backups to disk (as image copies), and then back up these image copies to a media manager with BACKUP AS BACKUPSET. Then, you do not have the problem of keeping the tape streaming that sometimes occurs when making incremental backups directly to tape. Because incremental backups are not as big as full backups, you can create them on disk more easily.

Incremental Backup Algorithm

Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. (If block change tracking is enabled, RMAN does not read the portions of the file known to have not changed since the parent incremental backup.) If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block.

One consequence of this mechanism is that RMAN applies all blocks containing changed data during recovery—even if the change is to an object created with the NOLOGGING option. Hence, making incremental backups is a safeguard against the loss of changes made by NOLOGGING operations.

See Also:

Oracle Database Concepts for more information about NOLOGGING mode

Multilevel Incremental Backups

RMAN can create multilevel incremental backups. Each incremental level is denoted by a value of 0 or 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.

A level 1 incremental backup can be either of the following types:

  • A differential backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0

  • A cumulative backup, which backs up all blocks changed after the most recent incremental backup at level 0

Incremental backups are differential by default.

Note:

Cumulative backups are preferable to differential backups when recovery time is more important than disk space, because fewer incremental backups need to be applied during recovery.

The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.

Differential Incremental Backups

In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent incremental backup at level 1 (cumulative or differential) or level 0. For example, in a differential level 1 backup, RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup.

If no level 0 backup is available, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN behaves as it did in previous releases, by generating a level 0 backup.

Figure 2-4 Differential Incremental Backups

Description of Figure 2-4 follows
Description of "Figure 2-4 Differential Incremental Backups"

In the example shown in Figure 2-4, the following occurs each week:

  • Sunday

    An incremental level 0 backup backs up all blocks that have ever been in use in this database.

  • Monday - Saturday

    On each day from Monday through Saturday, a differential incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level 1 or 0. The Monday backup copies blocks changed since Sunday level 0 backup, the Tuesday backup copies blocks changed since the Monday level 1 backup, and so forth.

Cumulative Incremental Backups

In a cumulative level 1 backup, RMAN backs up all the blocks used since the most recent level 0 incremental backup. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.

Figure 2-5 Cumulative Incremental Backups

Description of Figure 2-5 follows
Description of "Figure 2-5 Cumulative Incremental Backups"

In the example shown in Figure 2-5, the following occurs each week:

  • Sunday

    An incremental level 0 backup backs up all blocks that have ever been in use in this database.

  • Monday - Saturday

    A cumulative incremental level 1 backup copies all blocks changed since the most recent level 0 backup. Because the most recent level 0 backup was created on Sunday, the level 1 backup on each day Monday through Saturday backs up all blocks changed since the Sunday backup.

Planning an Incremental Backup Strategy

Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery.

When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 20% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:

SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS 
  FROM V$BACKUP_DATAFILE 
  WHERE INCREMENTAL_LEVEL > 0 
  AND BLOCKS / DATAFILE_BLOCKS > .5 
  ORDER BY COMPLETION_TIME;

Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then take a new level 0 backup when the most recent level 1 backup is about half of the size of the base level 0 backup.

See Also:

Oracle Database Backup and Recovery Basics to learn how make incremental backups

Control File and Server Parameter File Autobackups

Having recent backups of your control file and server parameter file is extremely valuable in many recovery situations. To increase the likelihood that you will have such backups, the database supports control file and server parameter file autobackups. RMAN can automatically back up the control file and server parameter file (SPFILE) in situations in which the RMAN repository data for your database has been updated in a way that affects RMAN's ability to restore your database.

With a control file autobackup, RMAN can recover the database even if the current control file, recovery catalog, and server parameter file are inaccessible. Because the path used to store the autobackup follows a well-known format, RMAN can search for and restore the server parameter file from that autobackup.

After you have started the instance with the restored server parameter file, RMAN can restore the control file from the autobackup. After you mount the control file, use the RMAN repository in the mounted control file to restore the datafiles.

A control file autobackup lets you restore the RMAN repository contained in the control file when the control file is lost and you have no recovery catalog. You do not need a recovery catalog or target database control file to restore the control file autobackup. For example, you can issue:

RESTORE CONTROLFILE FROM AUTOBACKUP;

After you restore and mount the control file, you have the backup information necessary to restore and recover the database. You can connect to the target instance in NOCATALOG mode and recover the database. You can also create a new recovery catalog and register the target database. The RMAN repository records in the control file will be copied to the new recovery catalog.

The automatic backup of the control file occurs independently of any backup of the current control file explicitly requested as part of your backup command. You can turn the autobackup feature on or off by running the following commands:

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP OFF;

Oracle recommends that CONFIGURE CONTROLFILE AUTOBACKUP be set to ON.

How RMAN Performs Control File Autobackups

The first channel allocated during the backup job creates the autobackup and places it into its own backup set; for autobackups after database structural changes, the default disk channel makes the backup. If a server parameter file is used, it is backed up in the same backup set as the control file during a control file autobackup.

After the control file autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log.

The RMAN behavior when the BACKUP command includes datafile 1 depends on the CONFIGURE CONTROLFILE AUTOBACKUP setting. If control file autobackups are ON and the backup includes datafile 1, RMAN writes the control file and SPFILE to a separate autobackup backup set. If control file autobackups are OFF and the backup includes datafile 1, then RMAN includes the current control file and SPFILE in the same backup set as the datafiles.

The control file autobackup filename has a default format of %F for all device types, so that RMAN can guess the file location and restore it without a repository. The substitution variable %F is defined in the description of the CONFIGURE command in Oracle Database Backup and Recovery Basics. You can specify a different format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command. All autobackup formats must include the %F variable.

The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the session only. The order of precedence is:

SET within a RUN block

SET at RMAN prompt

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT

You can configure the autobackup format even when CONFIGURE CONTROLFILE AUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, you must set CONFIGURE CONTROLFILE AUTOBACKUP to ON.

See Also:

When RMAN Performs Control File Autobackups

By default, control file autobackups are turned off, and no control file autobackups are performed. If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the control file and the current server parameter file (if used to start up the database) in one of two circumstances: when a successful backup must be recorded in the RMAN repository, and when a structural change to the database affects the contents of the control file which therefore must be backed up.

Control File Autobackups After Backup Acivities

This means that the control file is backed up in the following situations:

  • After every BACKUP command issued at the RMAN prompt.

  • At the end of a RUN block, if the last command in the block was BACKUP.

  • Whenever a BACKUP command within a RUN block is followed by a command that is not BACKUP.

The first channel allocated during the backup job creates the autobackup and places it into its own backup set. The control file autobackup may be written to disk or tape.

Control File Autobackups After Database Structural Changes

The control file is also automatically backed up after database structural changes such as adding a new tablespace, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, and so on. Losing this information would compromise your ability to recover the database.

This backup is performed by the server process itself, rather than one of the RMAN channels. This type of autobackup, unlike autobackups that occur after a successful backup, is always created on disk. You can use CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set the location for this disk based control file autobackup. Note that a failure of the automatic control file autobackup after a structural change never causes the associated structural change to fail. For example, if you add a datafile, and if the resulting control file autobackup fails, then the datafile addition is still successful.

Backup Retention Policies

You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers backups of datafiles and control files as obsolete, that is, no longer needed for recovery, according to criteria that you specify in the CONFIGURE command. You can then use the REPORT OBSOLETE command to view obsolete files and DELETE OBSOLETE to delete them.

As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention policy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy.

If you have a flash recovery area configured, however, then the database automatically deletes unnecessary files from the flash recovery area based on its internal disk quota rules. The disk quota rules are distinct from the backup retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota.

The term obsolete does not mean the same as expired. A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered expired only when RMAN performs a crosscheck and cannot find the file. In short, obsolete means "not needed," whereas expired means "not found."

From the perspective of a retention policy, a datafile backup is a full or level 0 backup of an individual datafile or control file. It does not matter whether the backup is a datafile image copy, a proxy copy, or part of a backup set. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backups in backup sets, RMAN cannot delete the backup set until all of the individual datafile backups within the backup set are obsolete.

Besides affecting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained.

Note:

RMAN cannot implement an automatic retention policy if backups are deleted by non-RMAN methods, for example, through the media manager's tape retention policy. The media manager should never expire a tape until all RMAN backups on that tape have been removed from the media manager's catalog.

There are two mutually exclusive options for implementing a retention policy: redundancy and recovery window. If no retention policy is configured by the user, then the REPORT OBSOLETE andDELETE OBSOLETE commands use a default retention policy of REDUNDANCY 1.

To configure a retention policy based on a recovery window, use the following command:

  • CONFIGURE RETENTION POLICY TO RECOVERY WINDOW

To configure a retention policy based on redundancy, use the following command:

  • CONFIGURE RETENTION POLICY TO REDUNDANCY

You can also disable the retention policy completely, meaning that RMAN does not consider any backup to be obsolete. To do so, use the following command:

CONFIGURE RETENTION POLICY TO NONE;

Recovery Window

A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then this window of time must extend back exactly seven days from the present so that you can restore a backup and recover it to this point. You implement this retention policy as follows:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then there must always exist one backup of each datafile that satisfies the following condition:

SYSDATE - BACKUP CHECKPOINT TIME >=  7

All backups older than the most recent backup that satisfied this condition are obsolete.

Assume the following retention policy illustrated in Figure 2-6. The retention policy has the following aspects:

  • The recovery window is 7 days.

  • Database backups are scheduled every two weeks on these days:

    • January 1

    • January 15

    • January 29

    • February 12

  • The database runs in ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.

Figure 2-6 Recovery Window, Part 1

Description of Figure 2-6 follows
Description of "Figure 2-6 Recovery Window, Part 1"

As illustrated in Figure 2-6, the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 through 850. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.

Assume the same scenario a week later, as depicted in Figure 2-7.

Figure 2-7 Recovery Window, Part 2

Description of Figure 2-7 follows
Description of "Figure 2-7 Recovery Window, Part 2"

In this scenario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is not obsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because restoring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability to any point within the window, you must save the January 14 backup as well as all archived redo logs from log sequence 500 to 1150.

Backup Redundancy

A redundancy-based retention policy specifies how many backups of each datafile must be retained. For example, you can specify:

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

Although the recovery window is the best practice for specifying a retention policy, it can complicate disk space usage planning because the number of backups that must be kept by the recovery window is not constant and depends on the backup schedule. Use the CONFIGURE RETENTION POLICY TO REDUNDANCY n command to implement a retention policy that maintains a constant number of backups of each datafile. RECOVERY WINDOW and REDUNDANCY-based retention policies are mutually exclusive.

The default retention policy is REDUNDANCY = 1, to maintain compatibility with the behavior of REPORT OBSOLETE in earlier RMAN releases. You can also run the following command to disable the retention policy altogether:

CONFIGURE RETENTION POLICY TO NONE;

If the retention policy is configured to NONE, then REPORT OBSOLETE and DELETE OBSOLETE do not consider any backups to be obsolete.

Batch Deletes of Obsolete Backups

Run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy.

If you configure the retention policy to NONE, then RMAN does not consider any backups as obsolete. Consequently, RMAN issues an error when you run REPORT OBSOLETE without any other options and the retention policy is set to NONE.

A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You should run DELETE OBSOLETE periodically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script.

You can also specify the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands, to override the configured retention policy.

The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:

  1. For each datafile for which there are full backup, datafile copy, or level 0 incremental backups, RMAN identifies the oldest full or level 0 backup or copy that is not obsolete under the retention policy being tested. Any full backup, level 0 incremental backup, or datafile copy of a datafile older than the one identified in this step is considered obsolete.

    Any archived logs and level 1 incremental backups that are older than the oldest non-obsolete full backup are then obsolete because there is no full or level 0 backup to which they can be applied.

    See Also:

Exempting Backups from the Retention Policy

You may want to store a long-term backup, potentially offsite, for much longer than the time dictated by the retention policy. For example, you may make a database backup on the first day of every year to satisfy some regulatory requirement, independent of backups taken for your ongoing backup and recovery strategy.

Such long-term backups should be recorded in the RMAN repository, but they must be exempted from the retention policy because RMAN would quickly consider them obsolete, and they would be removed the next time the DELETE OBSOLETE command is used.

You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command when you create the backup, or the KEEP option of the CHANGE command to exempt an existing backup. Note that backups exempted from the retention policy are still fully valid backups, which can be used in restore and recovery operations like any other if RMAN judges them to be the best choice available.

You can change the exempt status of a backup using the CHANGE... KEEP and CHANGE... NOKEEP commands. The NOKEEP option (default) indicates that the backup is not immune from the configured retention policy.

You can specify the LOGS option to save archived logs for a possible incomplete recovery of the long-term backup. When LOGS is specified, all logs more recent than the backup are kept as long as the backup is kept. In other words, KEEP UNTIL TIME... LOGS means that RMAN will keep all logs required to recover the backup as long as the backup is kept. If you specify NOLOGS, then RMAN does not keep the logs required to recover the backup. Note that if you use KEEP UNTIL TIME... with an inconsistent backup, you must use the LOGS option, or that backup will become unusable when the logs required to recover it are deleted as obsolete.

You can specify an end date using the UNTIL clause, or either specify that the backup should be kept FOREVER. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the UNTIL date has passed. Note that it is an error to specify KEEP FOREVER with the LOGS option, as this would require keeping all redo logs forever.

The following commands are examples of long-term backups:

# Creates a backup and exempts it from retention policy until last day of 2007
BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2007' 'dd-mon-yyyy')" NOLOGS;

# Specifies that backupset 2 is no longer exempt from the retention policy
CHANGE BACKUPSET 2 NOKEEP;

# Creates a backup that is indefinitely exempt from the retention policy
BACKUP TABLESPACE users KEEP FOREVER NOLOGS;

See Also:

Oracle Database Backup and Recovery Reference for CHANGE syntax

Relationship Between Retention Policy and Flash Recovery Area Rules

The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is OBSOLETE in the RMAN repository, it is because it is either not needed for recovery to a point within the recovery window, or it is redundant.

If you configure a flash recovery area, then the database uses an internal algorithm to select files in the flash recovery area that are no longer needed to meet the configured retention policy. These backups have status OBSOLETE, and are eligible for deletion to satisfy the disk quota rules.

There is one important difference between the flash recovery area criteria for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the currently enabled recovery window and so are not obsolete. If you back up these logs to tape, then the retention policy still considers the disk logs as required, that is, not obsolete. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have already been backed up to tape. The logs on disk do not have OBSOLETE status in the repository, but they are eligible for deletion by the flash recovery area. Note, though, that the retention policy is never violated when determining which files to delete from the flash recovery area to satisfy the disk quota rules.

Backup Optimization

If you enable backup optimization, then the BACKUP command skips backing up files when the identical file has already been backed up to the specified device type.

Rules for Identifying Identical Files for Backup Optimization

Table 2-2 describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up.

Table 2-2 Criteria to Determine an Identical File

Type of File Criteria to Determine an Identical File

Datafile

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

Archived redo log

Same thread, sequence number, and RESETLOGS SCN and time.

Backup set

Same backup set recid and stamp.

If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. However, RMAN must do further checking to determine whether to skip the file, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type.

Backup Optimization Algorithm

Table 2-3 describes the algorithm that backup optimization uses when determining whether to skip the backup of an identical file.

Table 2-3 Backup Optimization Algorithm

For an Identical ... Backup Optimization Algorithm

Datafile

With a recovery window-based retention policy:

For backups to tape, RMAN takes another backup of a file, even if a backup of an identical file exists, if the most recent backup is older than the configured recovery window. This is done to allow media to be recycled after the media expires.

For backups to disk, RMAN skips taking the backup if an identical file is available from a backup on disk, even if that backup is older than the beginning of the recovery window. The retention policy causes RMAN to retain the old backup for as long as it is needed.

With a redundancy-based retention policy:

RMAN sets r=1 by default and searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):

If CONFIGURE RETENTION POLICY TO REDUNDANCY r is enabled, then RMAN only skips datafiles when n=r+1 backups exist.

BACKUP ... COPIES n

SET BACKUP COPIES n

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

RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified.

Archived log

By default, n=1. RMAN searches for values of n in this order of precedence (that is, values higher on the list override values lower on the list):

BACKUP ... COPIES n

SET BACKUP COPIES n

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

RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified.

Backup set

By default, n=1. RMAN searches for other values of n in this order of precedence (that is, values higher on the list override values lower on the list):

BACKUP ... COPIES n

SET BACKUP COPIES n

RMAN skips backup only if at least n backups of an identical file exist on the specified device. If RMAN does not skip the backup, then it makes the backup exactly as specified.

For example, assume that at 9 a.m. you back up three copies of all existing archived logs to tape:

BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;

Later, you enable the following configuration setting in preparation for another backup:

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 4;
CONFIGURE BACKUP OPTIMIZATION ON;

Then, you run the following archived log backup at noon:

BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;

In this case, the BACKUP ... COPIES setting overrides the CONFIGURE ... COPIES setting, so RMAN sets n=2. RMAN skips the backup of a log only if at least two copies of the log exist on the sbt device. Because three copies of each log exist on sbt of all the logs generated before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up two copies of all logs generated after 9 a.m. because these logs have not yet been backed up to tape.

At this point, three copies of the logs created before 9 a.m. exist on tape, and two copies of the logs created after 9 a.m. exist on tape. Assume that you run the following backup at 3 p.m.:

RUN
{ 
  SET BACKUP COPIES 3;
  BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
}

In this case, RMAN sets n=3 and so will not back up the logs created before 9 a.m. because three copies already exist on tape. However, only two copies of the logs created after 9 a.m. exist on tape, so RMAN does not optimize backups of these logs. Hence, RMAN backs up three copies of the logs created after 9 a.m.

Requirements for Backup Optimization

Backup optimization is used when the following conditions are true:

  • The CONFIGURE BACKUP OPTIMIZATION ON command has been run to enable backup optimization.

  • You run BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP BACKUPSET ALL.

  • Only one type of channel is allocated, that is, you do not mix channels of type DISK and sbt in the same backup command.

For example, assume that you run these commands:

BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
BACKUP DEVICE TYPE sbt BACKUPSET ALL;

If none of these files has changed since the last backup, then RMAN does not back up the files again, nor signal an error if it skips all files specified in the command.

Overriding and Disabling Backup Optimization

To override backup optimization and back up all files whether or not they have changed, specify the FORCE option on the BACKUP command. For example:

BACKUP DEVICE TYPE sbt BACKUPSET ALL FORCE;

To disable backup optimization on a persistent basis, use the following command:

RMAN> CONFIGURE BACKUP OPTIMIZATION OFF;

Effect of Retention Policies on Backup Optimization for SBT Backups

Backup optimization is not always applied when backing up to SBT devices. The exceptions to normal backup optimization behavior for recovery window-based and redundancy-based retention policies are described in the following sections.

Note:

Use caution when enabling backup optimization if you use a media manager with its own internal expiration policy. Run CROSSCHECK periodically to synchronize the RMAN repository with the media manager. Otherwise, RMAN may skip backups due to optimization without recognizing that the media manager has discarded backups stored on tape.

Backup Optimization for SBT Backups with Recovery Window Retention Policy

If backup optimization is enabled, and if a recovery window retention policy is in effect, then when performing SBT backups RMAN always backs up datafiles whose most recent backup is older than the recovery window. For example, assume that:

  • Today is February 21.

  • The recovery window is 7 days.

  • The most recent backup of tablespace tools to tape is January 3.

  • Tablespace tools is read-only.

On February 21, when you issue a command to back up tablespace tools to tape, RMAN backs it up even though it did not change after the January 3 backup (because it is read-only). RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window.

This behavior allows the media manager to expire old tapes. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools indefinitely. By making a more recent backup of tablespace tools on February 21, RMAN allows the media manager to expire the tape containing the obsolete January 3 backup.

Backup Optimization for SBT Backups With Redundancy Retention Policy

Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only datafiles to SBT when there are r + 1 backups of the files, where r is set in CONFIGURE RETENTION POLICY TO REDUNDANCY r.

For example, assume that you enable backup optimization and set the following retention policy:

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

With these settings, RMAN only skips backups when three identical files are already backed up. Also assume that you have never backed up the users tablespace, which is read/write, and that you perform the actions described in Table 2-4 over the course of the week.

Table 2-4 Effect of Redundancy Setting on Backup Optimization

Day Action Result Redundant Backup

Monday

Take tablespace users offline normal.

    

Tuesday

BACKUP DATABASE

The users tablespace is backed up.

  

Wednesday

BACKUP DATABASE

The users tablespace is backed up.

  

Thursday

BACKUP DATABASE

The users tablespace is backed up.

Tuesday backup

Friday

BACKUP DATABASE

The users tablespace is not backed up.

Tuesday backup

Saturday

BACKUP DATABASE

The users tablespace is not backed up.

Tuesday backup

Sunday

DELETE OBSOLETE

The Tuesday backup is deleted.

  

Monday

BACKUP DATABASE

The users tablespace is backed up.

Wednesday backup

The backups on Tuesday, Wednesday, and Thursday back up the offline users tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). The Friday and Saturday backups do not back up the users tablespace because of backup optimization. Note that the Tuesday backup of users is obsolete beginning on Thursday.

On Sunday, you delete all obsolete backups, which removes the Tuesday backup of users. The Tuesday backup is obsolete because of the retention policy setting. The whole database backup on Monday then backs up the users tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). In this way, you can recycle your tapes over time.

See Also:

"Backing Up Files Using Backup Optimization", and "Configuring Backup Optimization"

Restartable Backups

Using the restartable backups feature, 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.

The unit of restartability is a backup set. If the backup generates multiple backup sets, then the backups that completed successfully do not have to be rerun. 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.

To take better advantage of restartable backups, you can use set the MAXSETSIZE parameter of the BACKUP command. If, for instance, you set MAXSETSIZE to 10MB for a given backup command, a new backup set is produced for each 10MB of backup output. If the backup fails after some backup sets have been produced and must be restarted, the data backed up in those backup sets will not have to be backed up again. (Note that MAXSETSIZE must be large enough that any file can be accommodated in a single backup piece, because files cannot span backup pieces.)

For example, if the largest datafile is less than 10 MB, then you can back up the database daily as follows:

BACKUP DATABASE MAXSETSIZE = 10M;

Then, after a failure you can back up all files in the database that were not backed up in the last 24 hours by issuing:

BACKUP DATABASE NOT BACKED UP SINCE TIME 'SYSDATE-1';

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.

When determining whether a file has been backed up, RMAN compares the SINCE TIME date with the completion time of the most recent backup of the file. The completion time for a backup piece is the completion time of the entire backup set, not an individual backup piece; in other words, all files in the same backup set have the same completion time.

See Also:

"Restarting a Backup After It Partially Completes" and Oracle Database Backup and Recovery Reference for BACKUP syntax

Managing Backup Windows and Performance: BACKUP... DURATION

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

The BACKUP command supports a DURATION argument which lets you specify how long a given backup job is allowed to run. You could, for example, run the following command at 2:00AM:

BACKUP DURATION 4:00 TABLESPACE users;

RMAN backs up the specified data at the maximum possible speed. If the backup is not complete in four hours, the backup is interrupted. Any completed backupsets are retained and can be used in restore operations, even if the entire backup is not complete. Any incomplete backupsets are discarded.

Controlling RMAN Behavior when Backup Window Ends with PARTIAL

By default, when a BACKUP... DURATION command runs out of time before the backup completes, RMAN reports an error. (The effect of this is that if the command is running in a RUN block, the RUN block terminates.) You can control this behavior by adding the PARTIAL option to the BACKUP... DURATION command, as in this example:

BACKUP DURATION 4:00 PARTIAL TABLESPACE users FILESPERSET 1;

When PARTIAL is used, no error is reported when a backup command is interrupted due to the end of the backup window. Instead, a message showing which files could not be backed will be displayed. If the BACKUP command is part of a RUN block, then the remaining commands in the RUN block will continue to execute.

When using DURATION the least recently backed up files are backed up first. Thus, if you retry a job that was interrupted when the available duration expired, each successive attempt covers more of the files needing backup.

Note also the use of FILESPERSET 1 in this example. With this option, RMAN puts each file into its own backupset. This way, when a backup is interrupted at the end of the backup window, only the backup of the file currently being backed up is lost. All backup sets completed during the window are saved, minimizing the lost work due to the end of the backup window.

Managing Backup Performance with MINIMIZE TIME and MINIMIZE LOAD

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. To maximize performance, use the MINIMIZE TIME option with DURATION, as shown in this example:

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

To extend the backup to use the full time available, use the MINIMIZE LOAD option, as in this example:

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

RMAN monitors the progress of the running backup, and periodically estimates how long the backup will take to complete at its present rate. If RMAN estimates that the backup will finish before the end of the backup window, it slows down the rate of backup so that the full available duration will be used. This reduces the overhead on the database associated with the backup.

Note:

Note these issues when using DURATION and MINIMIZE LOAD with a tape backup:

  • Efficient backup to tape requires tape streaming. If you use MINIMIZE LOAD, RMAN may reduce the rate of backup to the point where tape streaming is not optimal.

  • RMAN will hold the tape resource for the entire duration of the backup window. This prevents the use of the tape resource for any other purpose during the backup window.

Because of these concerns, it is not recommended that MINIMIZE LOAD be used with tape. See "Factors Affecting Backup Speed to Tape" for more details on efficient tape handling.

How RMAN Responds to Backup Errors

RMAN detects and responds to two primary types of backup errors: I/O errors and corrupt blocks. This section contains the following topics:

Handling I/O Errors in RMAN Backup: NOT BACKED UP SINCE

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 datafile but the datafile is not on disk, then RMAN terminates the backup.

If multiple channels are being used, or redundant copies of backups are being created, RMAN may be able to continue the backup without user intervention.

If an error occurs during BACKUP AS BACKUPSET, then RMAN needs to rewrite the backup sets that it was writing at the time of the error. However, for any backup job that creates multiple backup sets, if some backup sets were complete during the error then RMAN retains those backups.

The NOT BACKED UP SINCE option of the BACKUP command backs up only files that are not already backed up since the time specified. You can use this clause after an interrupted backup to resume the backup.

Handling Corrupt Datafile Blocks in RMAN Backup: MAXCORRUPT

When RMAN encounters a corrupt datafile block during a backup, the behavior depends upon whether RMAN has encountered this corrupt block during a previous backup. If the block is already identified as corrupt, then it is included in the backup. If the block is not previously identified as corrupt, then RMAN's default behavior is to stop the backup.

You can override this behavior using the SET MAXCORRUPT command with BACKUP in a RUN block. Setting MAXCORRUPT allows a specified number of previously undetected block corruptions in datafiles during the execution of an RMAN BACKUP command. If RMAN detects more than this number of new corrupt blocks while taking the backup, then the backup job aborts, and no backup is created.

As RMAN finds corrupt blocks during the backup process, it writes the corrupt blocks to the backup with a special header indicating that the block has media corruption. If the backup completes without exceeding the specified MAXCORRUPT limit, then the database records the address of the corrupt blocks and the type of corruption found (logical or physical) in the control file. You can access these records through the V$DATABASE_BLOCK_CORRUPTION view.

Note:

If the backup job aborts because more than MAXCORRUPT corrupt blocks are found, theV$DATABASE_BLOCK_CORRUPTION view is not populated, because the information used to populate the view is only available if a backup is successfully created. In such a situation, you can run BACKUP VALIDATE on the datafiles to be backed up, to populate V$DATABASE_BLOCK_CORRUPTION and use block media recovery to repair the corrupt blocks. See Oracle Database Backup and Recovery Basics for details on using BACKUP... VALIDATE, and "Performing Block Media Recovery with RMAN" for more details on block media recovery.

See Also:

Tests and Integrity Checks for Backups

The database prevents operations that result in unusable backup files or corrupt restored datafiles. The database server automatically does the following:

  • Blocks access to datafiles while they are being restored or recovered

  • Allows only one restore operation for each datafile at a time

  • Ensures that incremental backups are applied in the correct order

  • Stores information in backup files to allow detection of corruption

You can use the BACKUP VALIDATE and RESTORE VALIDATE commands to test backup and restore operations without creating output files. In this way, you can check your datafiles for possible problems. If you run RMAN with the following configuration, then it detects all types of corruption that are possible to detect:

  • In the initialization parameter file, set DB_BLOCK_CHECKSUM=TRUE

  • In the RMAN BACKUP and RESTORE commands, do not specify the MAXCORRUPT option, do not specify the NOCHECKSUM option, but do specify the CHECK LOGICAL option

See Oracle Database Backup and Recovery Basics for more details on BACKUP VALIDATE and RESTORE VALIDATE.

Detecting Physical Block Corruption With RMAN BACKUP... VALIDATE

RMAN depends upon database server sessions to perform backups, and the database server can detect many types of physically corrupt blocks during the backup process. Each new corrupt block not previously encountered in a backup is recorded in the control file and in the alert.log. By default, error checking for physical corruption is enabled.

At the end of a backup, RMAN stores the corruption information in the recovery catalog and control file. Access this data using the V$DATABASE_BLOCK_CORRUPTION view.

If the server session encounters a datafile block during a backup that has already been identified as corrupt by the database, then the server session copies the corrupt block into the backup and the corrupt block is recorded the control file as either a logical or media corruption. RMAN copies the block in case the user wants to try to salvage the contents of the block.

If RMAN encounters a datafile block that has media corruption but that has not already been identified as corrupt by the database, then it writes the block to the backup with a reformatted header indicating that the block has media corruption.

Detection of Logical Block Corruption

Besides testing for media corruption, the database can also test data and index blocks for logical corruption, such as corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert.log. If CHECK LOGICAL was used, the block is also logged in the server session trace file. By default, error checking for logical corruption is disabled.

For BACKUP commands the MAXCORRUPT parameter sets the total number of physical and logical corruptions permitted in a file. If the sum of physical and logical corruptions for a file is less than its MAXCORRUPT setting, the RMAN command completes successfully. If MAXCORRUPT is exceeded, the command terminates and RMAN does not read the rest of the file. V$DATABASE_BLOCK_CORRUPTION is populated with corrupt block ranges if the command succeeds. Otherwise, you must set MAXCORRUPT higher and re-run the backup to find out the corrupt block ranges.

See Also:

Oracle Database Backup and Recovery Reference for BACKUP ... MAXCORRUPT syntax

Detection of Fractured Blocks During Open Backups

One danger in making online backups is the possibility of inconsistent data within a block. For example, assume that you are backing up block 100 in datafile users.dbf. Also, assume that the copy utility reads the entire block while DBWR is in the middle of updating the block. In this case, the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. The result is called a fractured block, meaning that the data contained in this block is not consistent. at a given SCN.

When performing backups of an open tablespace without using RMAN, you must put tablespaces in backup mode to prevent the creation of fractured blocks in your backup. When not in backup mode, the database records only changed bytes in the redo stream. When a tablespace is in backup mode, each time a block is changed the database writes the before-image of the entire block to the redo stream before modifying the block. Then, the database also records the changes to the block in the redo log. During user-managed recovery using SQL*Plus, the database applies both the captured block images and the recorded block changes from the redo logs. Applying the block images repairs any possible fractured blocks in the backup being restored and recovered.

RMAN does not require that you put datafiles into backup mode. During an RMAN backup, a database server session reads each block of the datafile and checks whether each block is fractured by comparing the block header and footer. If a block is fractured, the session re-reads the block. If the same fracture is found, then the block is considered permanently corrupt. If MAXCORRUPT is exceeded, the backup stops.

Backup Validation with RMAN

You can run the BACKUP ... VALIDATE command to check datafiles for physical and logical corruption, or to confirm that all database files exist in the correct locations. No backup is taken, but all specified files are scanned to verify that they can be backed up. All corruptions are recorded in theV$DATABASE_BLOCK_CORRUPTION view.

The following example shows how to check your entire database and archived redo log files for physical and logical corruption:

BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;

You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.

See Also:

Oracle Database Backup and Recovery Reference for BACKUP syntax and "Validating Backups with RMAN" for more details on using BACKUP VALIDATE.