About RMAN Channels

An RMAN channel represents one stream of data to a device type and corresponds to one server session. Allocation of one or more RMAN channels is necessary to execute most backup and recovery commands. As illustrated in Figure 5-1, each channel establishes a connection from the RMAN executable to a target or auxiliary database instance by starting a server session on the instance. The server session performs the backup, restore, and recovery operations. Only one RMAN session communicates with the allocated server sessions.

Figure 5-1 Channel Allocation

You can either allocate channels manually within a RUN block, or preconfigure channels for use in all RMAN sessions using automatic channel allocation. RMAN comes preconfigured with a DISK channel that you can use for backups and copies to disk. You can also run the CONFIGURECHANNEL command RMAN to specify automatic channels to disk or tape. In this way, you do not have to allocate channels every time you perform a backup, restore, or recovery operation.

When you run a command that requires a channel, and you do not allocate a channel manually, then RMAN automatically allocates the channels using the options specified in the CONFIGURE command. For the BACKUP command, RMAN allocates only a single type of channel, such as DISK or sbt. For the RESTORE command and the various maintenance commands (for example, DELETE), RMAN determines which device types are required, and allocates all necessary channels.

If you specify channels manually, then the ALLOCATE CHANNEL command (executed only within a RUN command) and ALLOCATE CHANNEL FOR MAINTENANCE command (executed only at the RMAN prompt) specify the type of I/O device that the server session will use to perform the backup, restore, or maintenance operation.

Whether the ALLOCATE CHANNEL command or CONFIGURECHANNEL causes 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.

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 you to specify channels for commands used within a RUN block.

Unless you manually run an ALLOCATECHANNEL command, RMAN allocates automatic channels according to the settings in these commands:

CONFIGUREDEVICE TYPE...PARALLELISM

CONFIGUREDEFAULTDEVICETYPE

CONFIGURECHANNELDEVICETYPE

CONFIGURECHANNELnDEVICETYPE

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

BACKUP DATAFILE 3;
RUN { RESTORE TABLESPACE users; }

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. You cannot mix automatic and manual channels, so manual channels always override automatic channels. For example, you override automatic channel allocation when you issue a command as follows:

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.

Automatic Channel Device Configuration

The CONFIGUREDEVICETYPE...PARALLELISM command specifies the number of channels that RMAN uses when allocating automatic channels for a specified device type. For example, if you configure parallelism to 3, then RMAN allocates three channels of the default device type whenever it uses automatic channels.

When parallelizing, RMAN always allocates channels in numerical order, beginning with 1 and ending with the parallelism setting. For example, if the device type is sbt and parallelization is set to 4, then RMAN allocates as follows:

ORA_SBT_TAPE_1
ORA_SBT_TAPE_2
ORA_SBT_TAPE_3
ORA_SBT_TAPE_4

You can change a parallelism setting by issuing another CONFIGUREDEVICETYPE...PARALLELISM command. This example configures PARALLELISM2 and then changes it to 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 SHOWDEVICETYPE command. The default value is followed by a number sign (#). For example:

Automatic Channel Default Device Types

Run the CONFIGUREDEFAULTDEVICETYPE 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 the device of sbt the default device:

RMAN only allocates sbt channels when you run backup commands. For example, you may issue the following:

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 and copies by specifying a different device on the command using the channel. For example, run a backup as follows:

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.

During a restore operation, RMAN allocates all automatic channels according to the parallelism 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 (CONFIGUREDEVICETYPE...PARALLELISMn), 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 ALLOCATECHANNELFORMAINTENANCE, 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 CONFIGUREDEVICETYPE command to configure a device type and do not run CONFIGURECHANNEL 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:

Note that channel names beginning with the ORA_ prefix are reserved by RMAN for its own use. You cannot manually allocate a channel with the ALLOCATECHANNEL command and then prefix the channel name with ORA_.

Automatic Channel Generic Configurations

The CONFIGURECHANNELDEVICETYPE 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:

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

Automatic Channel Specific Configurations

You can also configure parameters that apply to one specific automatic channel. If you are running in an Oracle Real Application Clusters configuration or using a media manager that requires different settings on each channel, then you may find it useful to configure individual channels.

For example, in an Oracle Real Application Clusters environment you can enter:

In this example, RMAN allocates 2 channels for every backup job, ORA_SBT_TAPE_1 and ORA_SBT_TAPE_2. The ORA_SBT_TAPE_1 channel uses the settings for CHANNEL1 and the ORA_SBT_TAPE_2 channel uses the settings for CHANNEL2.

You can mix a CONFIGURECHANNEL command that creates a generic configuration with a CONFIGURECHANNEL command that creates a specific configuration. A generic automatic channel simply creates a configuration that can be used for any channel that is not explicitly configured. For example, assume that you run these commands:

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.

Each CONFIGURE command removes the user-entered settings and returns the configuration to its default value. To see the default configuration settings, run the SHOWALL command before entering any configurations of your own. The defaults are prefixed with a number sign (#).

Parallelization for Manually Allocated Channels

If you do not want to use automatic channels, then you can allocate multiple channels manually within a RUN command, thus allowing a single RMAN command to read or write multiple backups or image copies in parallel. Thus, the number of channels that you allocate affects the degree of parallelism within a command. When backing up to tape you should allocate one channel for each physical device, but when backing up to disk you can allocate as many channels as necessary for maximum throughput.

Each manually allocated channel uses a separate connection to the target or auxiliary database. You can specify a different connect string for each channel to connect to different instances of the target database, which is useful in an Oracle Real Application Clusters configuration for distributing work across different nodes.

RMAN internally handles parallelization of BACKUP, COPY, and RESTORE commands. You only need to specify:

Multiple ALLOCATE CHANNEL commands

The objects that you want to back up, copy, or restore

RMAN executes commands sequentially; that is, it completes the current command before starting the next one. Parallelism is exploited only within the context of a single command. Consequently, to create three backups of a datafile, issue a single BACKUP command specifying all three datafiles rather than three separate BACKUP commands.

The following script uses serialization to create the backups: 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.

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 channel copies one of the datafiles.

On some platforms, the channel allocation and channel control commands specify the name or type of an I/O device to use. On other platforms, they specify which operating system access method or I/O driver to use. Not all platforms support the selection of I/O devices through this interface; on some platforms, I/O device selection is controlled through platform-specific mechanisms.

In Oracle9i, the ALLOCATE CHANNEL command causes RMAN to contact the media manager whenever the type specified is other than DISK. In releases before Oracle9i, the ALLOCATE CHANNEL command does not cause RMAN to contact the media manager; RMAN does not call the media manager unless a BACKUP, RESTORE, or RECOVER command is issued.

Note:

When you specify DEVICETYPE 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 a preconfigured automatic DISK channel, you do not have to manually allocate a maintenance channel when running CHANGE...AVAILABLE, CROSSCHECK, or DELETE against a file that is only on disk (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 job.

Hardware Multiplexing by the Media Manager

Hardware multiplexing occurs when the media manager writes multiple RMAN backups to a single sequential device (such as a tape drive). Oracle Corporation does not recommend hardware multiplexing of RMAN backups.

About Backup Sets

A backup set, which is a logical object, contains one or more physical backup pieces. By default, one backup set contains one backup piece. Backup pieces are operating system files that contain the backed up datafiles, control files, or archived redo logs. For example, you can back up ten datafiles into a single backup set containing a single backup piece (that is, a single output file). You cannot split a file across different backup sets or mix archived logs and datafiles into one backup set.

A backup set is a complete set of backup pieces that make up a full or incremental backup of the objects specified in the BACKUP command. Backup sets are in an RMAN-specific format. An image copy, which is a complete image of a single datafile, control file, or archived log, is not in an RMAN-specific format.

You can back up a database, a subset of a database, or archived redo logs. You can also back up another backup set, as when you want to back up a disk backup to tape, or an image copy. For example, you can issue commands such as the following, each of which uses an automatic channel configuration to do the work:

When backing up datafiles, the target database must be mounted or open. If the database is in ARCHIVELOG mode, then the target can be open or closed: you do not need to close the database cleanly. If the database is in NOARCHIVELOG mode, then you must close it cleanly before making a backup.

Note:

You cannot make a backup of a transported tablespace until after it has been specified read/write.

About Proxy Copies

A proxy copy is a special type of backup in which RMAN turns over control of the data transfer to a media manager that supports this feature. 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 using 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 uses conventional backup sets to perform the backup. An exception occurs when you use the PROXY ONLY option, which causes Oracle to issue an error message when it cannot proxy copy.

Oracle records each proxy-copied file in the control file. RMAN uses this data to resynchronize the recovery catalog. Use the V$PROXY_DATAFILE view to obtain the proxy copy information. Use the CHANGEPROXY command or DELETEPROXY command to change the status of or delete a proxy backup.

Note:

If a proxy version of RMAN is used with a non-proxy target database, RMAN will not use proxy copy to create backup sets. If you make backups using proxy copy and then downgrade Oracle to a non-proxy version, RMAN will not use proxy copy backups when restoring and will issue a warning when the best available file is a proxy copy.

Storage of Backup Sets

RMAN can create backup sets that are written to disk or tertiary storage. If you specify DEVICETYPE DISK, then you must back up to random access disks. You can make a backup on any device that can store an Oracle datafile: in other words, if the statement CREATE TABLESPACE tablespace_name DATAFILE 'filename' works, then 'filename' is also a valid backup path name.

Using a media management system that is available and supported on your operating system, you can write backup sets to sequential output media such as magnetic tape. If you specify a device type such as sbt that is other than DISK, then you can back up to any media supported by the media management software.

Backup Set Compression

As Figure 5-2 illustrates, RMAN performs compression on its backups, which means that datafile blocks that have never been used are not backed up. Image copies of a datafile, however, always contain all datafile blocks.

Deletion of Archived Logs After Backups

Although you cannot archive logs directly to tape, you can use RMAN to back up archived logs from disk to tape. If you specify the DELETE INPUT option, then RMAN backs up exactly one copy of each specified log sequence number and then deletes the copy from disk after backing it up.

If you specify the DELETE ALLINPUT option, then RMAN backs up exactly one copy of each specified log sequence number and then deletes the copies that match the specified criteria. For example, if you specify the LIKE parameter, RMAN deletes whichever logs match the string. RMAN automatically restores needed archived logs from tape to disk during recovery.

Backup Failover for Archived Redo Logs

In releases prior to Oracle9i, RMAN only looked in the first archiving destination for archived redo logs when backing them up. In Oracle9i, RMAN can perform archived log failover. RMAN can do the following:

If at least one log corresponding to a given log sequence and thread is available in any of the archiving destinations, then RMAN backs up the available log.

If there is a corrupt block in a log that RMAN is accessing, then RMAN searches other directories for a file without corrupt blocks.

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

Sequence

Filename

121

/log1/log_1_121.arc

121

/log2/log_1_121.arc

122

/log1/log_1_122.arc

122

/log2/log_1_122.arc

123

/log1/log_1_123.arc

123

/log2/log_1_123.arc

124

/log1/log_1_124.arc

124

/log2/log_1_124.arc

However, unknown to RMAN, someone accidentally deletes logs 122 and 124 from the /log1 directory. Then, you run the following backup:

BACKUP ARCHIVELOG FROM SEQUENCE 121 UNTIL SEQUENCE 125;

In this case, RMAN backs up the files as described in the following table.

Sequence

RMAN Searches For

RMAN Finds and Backs Up

121

/log1/log_1_121.arc

/log1/log_1_121.arc

122

/log1/log_1_122.arc (missing)

/log2/log_1_122.arc

123

/log1/log_1_123.arc

/log1/log_1_123.arc

124

/log1/log_1_124.arc (missing)

/log2/log_1_124.arc

Automatic Online Redo Log Switches During Backups of Archived Logs

At the beginning of every BACKUP...ARCHIVELOG command that does not specify an UNTIL clause, RMAN attempts to automatically switch out of and archive the current online redo log. In this way, RMAN can include the current redo log in the backup set.

If the database is open, then at the start of an archived log backup RMAN tries to switch out of and archive the current online log according to these rules:

RMAN runs ALTERSYSTEMARCHIVELOGCURRENT.

If the UNTIL clause or SEQUENCE parameter is specified, RMAN does not try to switch or archive online logs.

Backups of Archived Logs Needing Backups

When making backups, run the BACKUP...PLUSARCHIVELOG command to archive online logs as well as back up archived logs. The purpose of this feature is to guarantee that the backed up datafiles can be recovered to a consistent state.

When PLUSARCHIVELOG is specified, RMAN performs the following actions in sequential order:

Runs ALTERSYSTEMARCHIVELOGCURRENT.

Runs BACKUPARCHIVELOGALL.

Backs up the files specified in the BACKUP command.

Runs ALTERSYSTEMARCHIVELOGCURRENT.

Backs up any remaining archived redo logs generated during backup.

You cannot specify PLUSARCHIVELOG when explicitly backing up archived logs, but only when backing up another object such as the database. For example, you can run this command:

BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;

Note:

If backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the allocated device.

Multiplexed Backup Sets

The technique of RMAN multiplexing is to simultaneously read files on disks and and then write them into the same backup piece. For example, RMAN can read from 2 datafiles simultaneously, and then combine the blocks from these datafiles into a single backup piece. Note that multiplexing in this sense is completely different from duplexing.

As Figure 5-3 illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece. This backup piece contains the intermingled block components of the three input files.

Figure 5-3 Datafile Multiplexing

Table 5-1 RMAN Multiplexing

The minimum of these values: FILESPERSET setting, and the number of files read by each channel.

Multiplexing

The minimum of these values: MAXOPENFILES setting, and the number of files in each backup set.

The FILESPERSET parameter determines how many datafiles should be included in each backup set, while MAXOPENFILES defines how many datafiles RMAN can read from simultaneously.

Assume that you are backing up six datafiles with one RMAN channel. If FILESPERSET is 6 and MAXOPENFILES is 1, then the channel includes 6 datafiles in a set but does not multiplex the files because RMAN is not reading from more than one file simultaneously. The channel reads one file at a time and writes to the backup piece. In this case, the degree of multiplexing is 1.

Now, assume that FILESPERSET is 6 and MAXOPENFILES is 3. In this case, the channel can read and write in the following order:

Read from datafiles 1, 2, and 3 simultaneously and write to the backup piece

Read from datafiles 4, 5 and 6 simultaneously and write to the backup piece

So in this example, the degree of multiplexing is 3 (the lesser of 6 and 3).

When multiplexing files, you can do the following:

Partition the datafiles into backup sets explicitly by assigning channels to specific datafiles, or let RMAN automatically select a partitioning.

Keep a high performance sequential output device streaming by including a sufficient number of datafiles in the backup. Keeping the device streaming is important for open database backups in which the backup operation must compete with the online system for I/O bandwidth.

Include the control file in a datafile backup set. In this case, the control file is written first and its blocks are not multiplexed with datafile blocks.

Create a backup set containing either datafiles or archived logs, but not both together. You cannot write datafiles and archived logs to the same backup set because the Oracle logical block size of the objects in a multiplexed backup must be the same.

Note that multiplexing too many files can decrease restore performance. If possible, group files that will be restored together into the same backup set. Assume that RMAN backs up seventeen files with FILESPERSET = 64 and MAXOPENFILES = 16. You decide to restore data17.f, which is datafile 17. So, RMAN reads the multiplexed data for the first sixteen files and then starts reading the data for data17.f. In this case, moving to the beginning of the backup of data17.f may take more time than the restore itself.

Duplexed Backup Sets

RMAN provides an efficient way to produce multiple copies of each backup piece in a backup set. This functionality is also known as duplexing a backup set.

You can create up to four identical copies of each piece in a backup set by issuing one of the following commands, listed in order of precedence. If multiple commands are in effect simultaneously, then commands higher on the list override commands that are lower on the list.

Command

Command Restriction

Object Restriction

BACKUPCOPIES

BACKUP command only

Any object specified on BACKUP command

SET BACKUPCOPIES

All BACKUP commands within RUN block

Any object specified on BACKUP command

CONFIGURE...BACKUPCOPIES

All BACKUP commands that use automatic channels

Only datafiles and archived logs

You can specify up to 4 values for the FORMAT option. RMAN uses the second, third, and fourth values only when BACKUPCOPIES, SET BACKUPCOPIES, or CONFIGURE...BACKUPCOPIES is specified. This example creates 3 copies of the backup of datafile 7:

BACKUP COPIES 3 DATAFILE 7 FORMAT '/dir1/%U','/dir2/%U','/dir3/%U';

RMAN places the first copy of each backup piece in /dir1, the second in /dir2, and the third in /dir3. 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:

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.

Do not confuse multiplexing, the combining multiple input files into a single backup set, with duplexing, the output of two or more identical backup sets. You can use RMAN to multiplex input files and create multiple copies of the output.

Parallelization of Backups

When you configure PARALLELISM to greater than 1 or manually allocate multiple channels, RMAN parallelizes its operation and writes multiple backup sets in parallel. The server sessions divide the work of backing up the specified files.

Note:

You cannot stripe a backup set across multiple channels.

By default, RMAN determines which channels should back up which database files. You can use the BACKUP...CHANNEL command to manually assign a channel to back up specified files. You can also use the FILESPERSET parameter to limit the number of datafiles included in a backup set. This example shows a parallelized backup to disk that uses the default automatic DISK channels:

Backups of Backup Sets

The RMAN BACKUP BACKUPSET command backs up backup sets rather than actual database files. This command supports disk-to-disk or disk-to-tape backups, but not tape-to-tape backups.

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 manually allocate a channel of DEVICETYPEsbt or configure an automatic sbt 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:

BACKUP DEVICE TYPE sbt BACKUPSET ALL;

Note:

Backups to the sbt device that use automatic channels require that you first run the CONFIGUREDEVICETYPEsbt command.

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

BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;

You can also use BACKUP BACKUPSET to manage backup space allocation. For example, assume that you want more recent backups to exist on disk and older backups to exist on tape, but you do not need backups to exist on both disk and tape at the same time. In this case, you can regularly run the following command:

BACKUP 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 the backup sets from disk. Note that DELETEINPUT here is equivalent to DELETEALLINPUT: 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

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

BACKUP DEVICE TYPE sbt BACKUPSET ALL;

Backup Failover When Backing Up Backup Sets

When backing up backup sets, RMAN searches for all available backup copies when the copy that it is trying to back up is either corrupted or missing. 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 123 contains three backup pieces, and that BACKUPCOPIES3 was issued so that three copies of each backup piece exist. Each copy of a backup piece is on a different file system. The following table indicates that some of the copies of the pieces are corrupted or missing, while others are intact.

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

Assume that you run the following command:

BACKUP BACKUPSET 123;

RMAN performs an automatic failover and includes only the uncorrupted copies in its backup set. The following table indicates which copies RMAN includes.

Filenames for Backup Pieces

You can either let RMAN determine a unique name for backup pieces or use the FORMAT parameter to specify a name. If you do not specify a filename, then RMAN uses the %U substitution variable to generate a unique name. For example, enter:

BACKUP TABLESPACE sales;

RMAN automatically generates unique names for the backup pieces.

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 sales FORMAT = '/backup/%U';

As described in "Duplexed Backup Sets", you can specify up to four FORMAT values. RMAN uses the second, third, and fourth values only when you run BACKUPCOPIES, SETBACKUPCOPIES, or CONFIGURE...BACKUPCOPIES.

Note:

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

Size of Backup Pieces

Each backup set contains at least one backup piece. If you do not restrict the backup piece size, then every backup set contains only one backup piece. To restrict the size of each backup piece, specify the MAXPIECESIZE option of the CONFIGURECHANNEL or ALLOCATECHANNEL commands. This option limits backup piece size to the specified number of bytes.

For example, restrict the backup piece size for disk backups to 9 MB by configuring an automatic disk channel as follows:

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 9M;

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

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 number and size of backup sets depends on the following conditions:

The number of backupSpecclauses that you specify

The number of input files specified or implied in each backupSpec clause

The number of channels that you allocate

The FILESPERSET parameter, which limits the number of files for a backup set

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. By default, this backup set contains one backup piece.

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 disk and the other half to another disk.

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

The maximum number of datafiles in each backup set is determined by the FILESPERSET parameter of the BACKUP command.

The number of datafiles multiplexed in a backup set is limited by the lesser of FILESPERSET and MAXOPENFILES.

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

Using the FILESPERSET Parameter

The FILESPERSET parameter limits the number of files (control files, datafiles, or archived logs) that can go in a backup set. The default value is calculated by RMAN as follows: RMAN compares the value 64 to the rounded-up ratio of number of files divided by the number of channels, and sets FILESPERSET to the lower value. For example, if you back up 70 files with one channel, then RMAN takes 70 divided by÷ 1, compares 70 to 64, and sets FILESPERSET to 64 because it is lower.

The number of backup sets produced by RMAN is the rounded-up ratio of number of datafiles divided by FILESPERSET. For example, if you back up 70 datafiles and FILESPERSET is 64, then RMAN produces 2 backup sets.

RMAN tries to make backup sets roughly the same size as the ratio of total number of blocks divided by total number of sets. The total number of blocks in a backup is equal to the number of blocks in each file that is backed up. For example, if you back up 70 files that each contain 50 blocks, and the number of sets is 2, then RMAN attempts to make each backup set about 3500/2 = 1750 blocks.³³µ¹²¼

Using the Default Value for FILESPERSET: Example

Assume the following example in which RMAN backs up eight files with three channels. Because FILESPERSET is not specified, RMAN compares 64 to 3 (8 divided by÷ 3 and rounded up) and sets FILESPERSET to 3. RMAN creates three backup sets and groups the files into the sets so that each set is approximately the same size. An example of the RMAN LIST output follows:

Specifying FILESPERSET: Example

If you back up eight datafiles with three channels and specify FILESPERSET=2, then RMAN places no more than two datafiles in each backup set. Consequently, RMAN creates at least four (8 divided by 2) backup sets: it may create more depending on the sizes of the datafiles as well as other factors. An example of the RMAN LIST output follows:

For datafile or datafile copy backups, group multiple datafiles into a single backup set to the extent necessary to keep an output tape device streaming, or to prevent the backup from consuming too much bandwidth from a particular datafile.

The fewer the files contained in a backup set, the faster one of them can be restored, because there is less data belonging to other datafiles that must be skipped. For backup sets containing archived logs, group logs from the same time period into a backup set because they will probably need to be restored at the same time.

Using the MAXSETSIZE Parameter

Each channel produces at least one backup set. To specify the maximum size of the 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.

You can use the MAXSETSIZE parameter to restrict the total size of a backup set to the maximum file size supported by your media manager or operating system. In this way, you do not cause either disk backups to abort because of space restrictions or tape backups to span multiple volumes.

Relationship Between MAXSETSIZE and FILESPERSET

The following table compares the MAXSETSIZE parameter to the FILESPERSET parameter.

Parameter

Meaning

You decide ...

RMAN decides ...

MAXSETSIZE

Sets the maximum size in bytes of the backup set without specifying a limit to the number of files in the set.

The maximum size of the backup set.

How many files to put in each set to keep the parameter restriction.

FILESPERSET

Sets a limit to the number of files in the backup set without specifying a maximum size in bytes of the set.

The maximum number of files to include in the backup set.

What size to make the backup sets to keep the parameter restriction.

Because FILESPERSET has a default value, if you set MAXSETSIZE then you must also account for the behavior of FILESPERSET. When both parameters are in use:

The number of backup sets is the greater of the following ratios:

Total number of blocks ÷divided by MAXSETSIZE

Total number of datafiles ÷divided by FILESPERSET

RMAN enforces both the FILESPERSET and MAXSETSIZE limits. If necessary, then RMAN creates more backup sets than are calculated in the preceding comparison.

RMAN uses a complex algorithm of best fit so that the majority of backup sets have a size as close to the MAXSETSIZE limit with the number of files as close to the FILESPERSET limit as possible.

Specifying MAXSETSIZE: Example

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

BACKUP DATABASE MAXSETSIZE = 10M;

Because you did not set FILESPERSET, RMAN calculates the default value for you, comparing 64 to 50/2 and setting FILESPERSET=25. RMAN compares the following values and chooses the higher value:

50000/10000 (total number of blocks/MAXSETSIZE) = 5

50/25 (total number of files/FILESPERSET) = 2

Consequently, RMAN attempts to make five backup sets, with each backup set containing no more than 25 files and totalling no more than 10 MB in size.

Note that if you set MAXSETSIZE to a value smaller than the size of the largest input file, you receive the RMAN-06183 error:

I/O Read Rate of Backups

You can limit the speed of a backup by using the RATE option of the ALLOCATECHANNEL or CONFIGURECHANNEL 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 channel c1 reads to 700 KB a second and channel c2 reads to 1 MB a second:

Backup Types

About Backup Types

With RMAN, you can control the type of backups you produce. As explained in Table 5-2, RMAN backups can be classified in these ways:

Full or incremental

Open or closed

Consistent or inconsistent

Table 5-2 Backup Types

Backup Type

Definition

Full

A backup that is not incremental. A full backup includes all used data blocks in the datafiles. Full backups of control files and archived logs always include all blocks in the files.

Note: A full backup is different from a whole database backup, which is a backup of all datafiles and the current control file.

Incremental

A backup of datafiles that includes only the blocks that have changed since a previous incremental backup. Incremental backups require a full or incremental level 0 backup to serve as a basis.

Online

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

Note: Do not put a tablespace in backup mode with the ALTERTABLESPACEBEGINBACKUP statement. RMAN uses a different method to guarantee consistency in online backups.

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) and was not crashed or shut down with the ABORT option prior to mounting. The checkpoint SCNs in the datafile headers match the header information in the control file and none of the datafiles has changes beyond its checkpoint. Consistent backups can be restored without recovery.

Inconsistent

A backup of any part of the target database when

It is open.

It crashed or a SHUTDOWNABORT was run prior to mounting.

An inconsistent backup requires recovery to become consistent.

Full Backups

A full backup reads the entire file and copies all blocks into the backup set, only skipping datafile blocks that have never been used. RMAN does not skip blocks when backing up archived redo logs or control files.

Note:

A full backup is not the same as a whole database backup: "full" is an indicator that the backup is not incremental.

A full backup has no effect on subsequent incremental backups, which is why it is not considered part of the incremental strategy. In other words, a full backup does not affect which blocks are included in subsequent incremental backups.

RMAN can create and restore full backups of the datafiles, control files, and archived redo logs. Note that backup sets containing archived redo logs are always full backups.

About Incremental Backups

An incremental backup reads the entire file and then backs 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. Note that RMAN can include a control file in an incremental backup set, but the control file is always included in its entirety--no blocks are skipped.

During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. RMAN always chooses incremental backups over archived logs. Note that 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 these datafiles with incremental backups.

The primary reasons for making an incremental backup are

To save tape when using a media manager or disk space when making disk backups

To save network bandwidth when backing up over a network

When the aggregate tape bandwidth available for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os

To be able to recover changes to objects created with the NOLOGGING option (direct load inserts do not log redo, although they do change data blocks and so are captured by incremental backups)

To reduce backup sizes for NOARCHIVELOG databases. Instead of making a whole database backup every time, you can make incremental backups. Note that incremental backups of a NOARCHIVELOG database are only legal after a consistent shutdown.

One effective strategy is to make incremental backups to disk and then run BACKUPBACKUPSET to copy the backups to a media manager. Then, you do not have the problem of keeping tape streaming that sometimes occurs when making incremental backups directly to tape. Because incrementals are not as big as full backups, you can create them on disk more easily.

Multilevel Incremental Backups

RMAN can create multilevel incremental backups. Each incremental level is denoted by an integer, for example, 0, 1, 2, and so forth. 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 backup and a full backup is that a full backup is never included in an incremental strategy. If no level 0 backup exists when you run a level 1 or higher backup, RMAN makes a level 0 backup automatically to serve as the base.

A level n incremental backup in which n is greater than zero backs up either:

All blocks changed after the most recent backup at level n or lower (the default type of incremental backup, which is called a differential backup)

All blocks changed after the most recent backup at level n-1 or lower (called a cumulative backup)

Note:

In most circumstances, cumulative backups are preferable to differential backups because fewer incremental backups need to be applied during recovery.

The benefit of performing multilevel incremental backups is that RMAN does not back up all blocks all of the time. Since RMAN needs to read all of the blocks of the datafile, full backups and incremental backups take approximately the same amount of time.

Incremental backups at levels greater than zero only copy blocks that were modified. The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.

How Incremental Backups Work

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. RMAN reads the entire file every time whether or not the blocks have been used.

The parent backup is the backup that RMAN uses for comparing the SCNs. If the current incremental is a differential backup at level n, then the parent is the most recent incremental of level n or less. If the current incremental is a cumulative backup at level n, then the parent is the most recent incremental of level n-1 or less. 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.

Note that 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 functions as a safeguard against the loss of changes made to NOLOGGING tables.

Differential Incremental Backups

In a differential level n incremental backup, RMAN backs up all blocks that have changed since the most recent backup at level n or lower. For example, in a differential level 2 backup, RMAN determines which level 1 or level 2 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, RMAN makes a new base level 0 backup for this file. Incremental backups are differential by default.

Figure 5-5 Differential Incremental Backups (Default)

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

Monday

A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 0 Sunday backup, so only the blocks changed since Sunday will be backed up.

Tuesday

A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 2 Monday backup, so only the blocks changed since Monday will be backed up.

Wednesday

A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 2 Tuesday backup, so only the blocks changed since Tuesday will be backed up.

Thursday

A differential incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 1 or less is the level 0 Sunday backup, so all the blocks changed since the Sunday level 0 backup will be backed up.

Friday

A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 1 Thursday backup, so only the blocks changed since the Thursday level 1 backup will be backed up.

Saturday

A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 2 Friday backup, so only the blocks changed since the Friday level 2 backup will be backed up.

The cycle is repeated for the next week.

Cumulative Incremental Backups

Oracle provides an option to make cumulative incremental backups at level 1 or greater. In a cumulative level n backup, RMAN backs up all the blocks used since the most recent backup at level n-1 or lower. For example, in a cumulative level 2 backup, RMAN determines which level 1 backup occurred most recently and copies all blocks changed since that backup. If no level 1 backup is available, RMAN copies all blocks changed since the base level 0 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 5-6 Cumulative Incremental Backups

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

Monday

A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 1 (2 minus 1) or less is the level 0 Sunday backup, so only the blocks changed since Sunday will be backed up.

Tuesday

A cumulative incremental level 2 backup occurs. This backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 1 (2 minus 1) or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up. (This backup includes those blocks that were copied on Monday, since this backup is cumulative and includes the blocks copied at backups taken at the same incremental level as the current backup).

Wednesday

A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 1 (2 minus 1) or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up. (This backup includes those blocks that were copied on Monday and Tuesday, since this backup is cumulative and includes the blocks copied at backups taken at the same incremental level as the current backup).

Thursday

A cumulative incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 0 (1 minus 1) or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up.

Friday

A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 1 (2 minus 1) or less is the level 1 Thursday backup, so all the blocks changed since Thursday will be backed up.

Saturday

A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 1 (2 minus 1) or less is the level 1 Thursday backup, so all the blocks changed since Thursday will be backed up.

The cycle is repeated for the next week.

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 backup is taken weekly, and a cumulative level 2 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 50% 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:

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 when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0.

Types of Files That RMAN Can Back Up

RMAN performs backup operations only when an instance has the database mounted or open, because there must be a control file available to record the backup information. In an Oracle Real Application Clusters environment, if the instance where the backup operation is being performed does not have the database open, then the database must not be open by any instance.

The BACKUP and COPY commands support tablespace, datafile, archived log, control file, and backup set backups. The PUT command can also store operating system files such as parameter and password files in the recovery catalog. RMAN does not back up:

Backup Errors

RMAN can handle the two primary types of backup errors: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces cause the system to abort the jobs. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN aborts the backup.

If an RMAN job produces more than one separate backup set and an error occurs, then RMAN needs to rewrite the backup sets that it was writing at the time of the error. However, it retains any backup sets that it successfully wrote before aborting. The NOTBACKEDUPSINCE option of the BACKUP command restarts a backup that partially completed, backing up only those files that did not get backed up.

RMAN copies datafile blocks that are already identified as corrupt into the backup. If RMAN encounters datafile blocks that have not already been identified as corrupt, then it writes them to the backup with a reformatted header indicating that the block has media corruption (assuming that SET MAXCORRUPT is not equal to 0 for this datafile and the number of corruptions does not exceed the limit). In either case, Oracle records the address of the corrupt block and the type of corruption in the control file. Access these records through the V$BACKUP_CORRUPTION and V$COPY_CORRUPTION views.

Use the SET MAXCORRUPT commandto allow a certain number of previously undetected block corruptions in specified datafiles. If a BACKUP or COPY command detects more than this number of corruptions, then the command aborts. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks.

Control File Autobackups

When CONFIGURECONTROLFILEAUTOBACKUP is set to ON, RMAN automatically performs a control file autobackup in these situations:

After every BACKUP or COPY command issued at the RMAN prompt

Whenever a BACKUP or COPY command within a RUN block is followed by a command that is neither BACKUP nor COPY.

At the end of every RUN block if the last command in the block was either BACKUP or COPY.

This automatic backup of the control file occurs in addition to any backup of the current control file that has been performed during these commands. You can turn off the autobackup feature by running this command:

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

The purpose of the control file autobackup is to provide a way to restore the backup repository contained in the control file when the control file is lost and the recovery catalog is either lost or was never used. You do not need a recovery catalog or target 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, then you can use it to obtain the backup information necessary to restore and recover the database. For example, if the recovery catalog database was destroyed along with the target database, you can create a new catalog and register the target database. The new catalog will be populated with backup information from the restored control file. You can also simply connect to the target instance in NOCATALOG mode and restore the database.

The control file autobackup filename has a default format of %F for all device types so that RMAN can restore it without a repository. The substitution variable %F is defined in the description of the CONFIGURE command. You can specify a different format for a specified device type using the CONFIGURECONTROLFILEAUTOBACKUPFORMAT command. A valid format must include the %F variable as part of the string.

The SETCONTROLFILEAUTOBACKUPFORMAT 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 RUN

SET at RMAN prompt

CONFIGURE

Note that you can configure the autobackup format even when CONFIGURECONTROLFILEAUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, CONFIGURECONTROLFILEAUTOBACKUP must be set to ON.

Backup Retention Policies

About Backup Retention Policies

You can use the CONFIGURERETENTIONPOLICY command to create a persistent and automatic backupretentionpolicy. When a backup retention policy is in effect, RMAN considers backups and copies of datafiles and control files as obsolete, that is, no longer needed for media recovery, according to criteria that you specify in the CONFIGURE command. You can then periodically or regularly issue the REPORTOBSOLETE command to view obsolete files and DELETEOBSOLETE to delete them.

The retention policy is ongoing. As you produce datafile and control file backups over time, RMAN keeps track of which to keep and which are obsolete. RMAN does not automatically delete the files for you, but it does perform the record keeping.

The term obsolete does not mean the same as expired. A backup or copy is obsolete when REPORTOBSOLETE or DELETEOBSOLETE determines, based on the user-defined retention policy, that it is not needed for media recovery. A backup or copy expires only when RMAN performs a crosscheck and sees either that the file is missing from disk or that the media manager has returned "Not found" for the file. In short, obsolete means not needed, whereas expired means "not found."

Note that from the perspective of a retention policy, a backup is a backup or copy of an individual datafile or control file. It does not matter whether the backup is a datafile copy, a proxy copy, or part of another 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 datafile and control file backups, the retention policy affects archived logs and archived log backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived log backups that are older than the oldest datafile or control file backup that must be retained. This behavior occurs regardless of whether the retention policy is configured for a recovery window or redundancy.

Note:

RMAN cannot implement an automatic retention policy if backups are deleted using 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.

You have two mutually exclusive options for implementing an retention policy: specifying a recovery window, or specifying redundancy (the default type of retention policy). The retention policy commands are as follows:

CONFIGURERETENTIONPOLICYTORECOVERYWINDOW

CONFIGURERETENTIONPOLICYTOREDUNDANCY

You can also disable the retention policy completely by running the following command, meaning that RMAN does not consider any backup or copy to be obsolete:

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 - (SELECT CHECKPOINT_TIME FROM V$DATAFILE) >= 7

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

Assume the following retention policy illustrated in Figure 5-7. 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 14

January 28

February 4

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

Figure 5-7 Recovery Window, Part 1

As illustrated in Figure 5-7, the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, as 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.

Figure 5-8 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

Besides RECOVERY WINDOW, the CONFIGURE command has another mechanism for controlling how long backups should be retained: the REDUNDANCY parameter. The REDUNDANCY parameter specifies that any number of backups or copies beyond a specified number need not be retained. For example, you can specify:

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

Although the recovery window is the best practice for specifying an retention policy, you choose not to specify it because the number of backups that must be kept by the recovery window is not constant and depends on the backup schedule. Use the CONFIGURERETENTIONPOLICYTOREDUNDANCY command to implement a retention policy that maintains a constant number of backups of each datafile. The RECOVERY WINDOW option is mutually exclusive with the REDUNDANCY option.

By default, the retention policy is configured to REDUNDANCY=1 to maintain compatibility with the behavior of REPORTOBSOLETE in earlier RMAN releases. If you run the following command, then RMAN returns the retention policy to the default value:

CONFIGURE RETENTION POLICY CLEAR;

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 REPORTOBSOLETE and DELETEOBSOLETE do not consider any backups to be obsolete.

Batch Deletes of Obsolete Backups and Copies

Run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy. For example, if you set the recovery window to 7 days using the CONFIGURE command, then you can run the following command to determine which backups and archived redo logs are obsolete:

REPORT OBSOLETE;

Note that if you configure the retention policy to NONE, then RMAN does not consider any backups or copies as obsolete. Consequently, RMAN issues an error when you run REPORTOBSOLETE without any other options.

A companion command, DELETE OBSOLETE, deletes the files rendered obsolete by the retention policy. You can run this command to delete all obsolete backups and copies at once. For example, you can run DELETEOBSOLETE in a weekly script.

Executing the DELETEOBSOLETE command ensures that you do not waste disk space by storing unnecessary files.

You can also specify the REDUNDANCY or RECOVERYWINDOW options on the REPORT or DELETE commands. These settings determine what is obsolete when running the commands and override the CONFIGURERETENTIONPOLICY settings.

Backups Exempt from the Retention Policy

You may want to store a long-term backup, potentially offsite, for much longer than the time dictated by the user's retention policy. For example, you may make a database backup on the first day of every year just to keep a record. You do not intend to use this backup in your backup and recovery strategy, although you may want to restore it at some point for report generation. For example, you may want to see how many customers were in the database 5 years ago.

You do not want to include a long-term backup in the production backup schedule, but you do want to record it in the recovery catalog. A long-term backup should not be included in the retention policy because RMAN would quickly mark it as obsolete, and then a DELETEOBSOLETE command would remove it.

By using the KEEPoption in the BACKUP or COPY command (or the KEEP option of the CHANGE command), you exclude the backup from the retention policy. The backup is still a fully valid backup, however, and can be restored just like any other RMAN backup. The NOKEEP option (default) indicates that the backup is not immune from the configured retention policy. You can change a backup between KEEP and NOKEEP status with the CHANGE command.

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, KEEPFOREVERLOGS means that RMAN not consider logs generated after the long-term backup to be obsolete. If you specify NOLOGS, then RMAN does not keep the logs required to recover the backup. Note that in this case the long-term backup must be consistent.

You can either specify that the backup should be kept FOREVER, or specify an end date using the UNTIL clause. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the UNTIL date has passed.

The following commands are examples of long-term backups:

# exempts the backup from retention policy until last day of 2002
BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2002', 'dd-mon-yyyy')" NOLOGS;
# alters status of backup set 231 from KEEP to NOKEEP
CHANGE BACKUPSET 231 NOKEEP;
# specifies that this backup and the logs required to recover it are indefinitely exempt
# from the retention policy
BACKUP TABLESPACE tbs2 KEEP FOREVER NOLOGS;

If you enable backup optimization, then the BACKUP command skips the backup of a file when the identical file has already been backed up to the allocated device type. Table 5-3 describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up.

Table 5-3 Criteria to Determine an Identical File

Type of File

Criteria to Determine an Identical File

Datafile

Same DBID, checkpoint SCN, and RESETLOGS SCN and time. 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 for skipping. However, RMAN must do further checking to determine whether to skip the file, because both the retention policy feature and the backup duplexing feature influence the algorithm that determines whether RMAN has "enough" backups on the specified device type.

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

Table 5-4 Backup Optimization Algorithm

For an Identical ...

Backup Optimization Algorithm

Datafile

If you configured a recovery window, then RMAN skips a datafile backup only if the latest backup of a file is earlier than the earliest point in the window.

If you did not configure a recovery window, then RMAN sets n=1 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 CONFIGURERETENTIONPOLICYTOREDUNDANCYr is enabled, then RMAN only skips datafiles when n=r+1 backups exist.

BACKUP...COPIESn

SETBACKUPCOPIESn

CONFIGUREDATAFILEBACKUPCOPIESFORDEVICETYPE...TOn

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

SETBACKUPCOPIESn

CONFIGUREARCHIVELOGBACKUPCOPIESFORDEVICETYPE...TOn

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

SETBACKUPCOPIESn

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:

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 Enabling and Disabling Backup Optimization

Backup optimization is enabled when the following conditions are true:

The CONFIGUREBACKUPOPTIMIZATIONON command has been run.

You run BACKUPDATABASE, BACKUPARCHIVELOG with ALL or LIKE options, or BACKUPBACKUPSETALL.

Only one type of channel is allocated, that is, you do not mix channels of type DISK and sbt.

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.

Note:

Whether or not backup optimization is enabled, if you run BACKUPARCHIVELOG and no archived logs exist, then RMAN does not signal an error. Probably no new logs were generated after the previous BACKUPARCHIVELOGALLDELETEINPUT command.

To override backup optimization and back up all files whether or not they have changed, specify the FORCE option on the BACKUP command. To disable backup optimization, specify OFF on the CONFIGUREBACKUPOPTIMIZATION command. The CLEAR option returns backup optimization to its default value of OFF.

Effect of Retention Policies on Backup Optimization

The retention policy influences backup optimization. Because the retention policy defaults to REDUNDANCY=1, a retention policy is always in place unless it is explicitly disabled with CONFIGURERETENTIONPOLICYTONONE.

Note:

Use caution when enabling backup optimization if you use a media manager that has an expiration policy. The media manager can expire tapes containing backups, and RMAN will not make new backups because of optimization. Run CROSSCHECK periodically to synchronize the repository with the media manager.

Backup Optimization and a Recovery Window

If optimization is enabled, and a retention policy is configured for a recovery window, then 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 old_sales to tape is January 3.

Tablespace old_sales is read-only.

On February 21, when you issue a command to back up tablespace old_sales to tape, RMAN backs it up even though it did not changed 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 old_sales indefinitely. By making a more recent backup of tablespace old_sales on February 21, RMAN allows the media manager to expire the tape containing the superfluous January 3 backup.

Backup Optimization and Redundancy

Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only datafiles when there are r + 1 backups, where r is specified in CONFIGURERETENTIONPOLICYTOREDUNDANCYr.

Assume that you enable backup optimization and set the following retention policy:

So, RMAN only skips backups when three identical files are already backed up. Also assume that you have never backed up the old_sales tablespace, and that you perform the actions described in Table 5-5 over the course of the week.

Table 5-5 Effect of Redundancy Setting on Backup Optimization

Day

Action

Result

Redundant Backup

Monday

Take tablespace old_sales offline normal.

Tuesday

BACKUPDATABASE

The old_sales tablespace is backed up.

Wednesday

BACKUPDATABASE

The old_sales tablespace is backed up.

Thursday

BACKUPDATABASE

The old_sales tablespace is backed up.

Tuesday backup

Friday

BACKUPDATABASE

The old_sales tablespace is not backed up.

Tuesday backup

Saturday

BACKUPDATABASE

The old_sales tablespace is not backed up.

Tuesday backup

Sunday

DELETEOBSOLETE

The Tuesday backup is deleted.

Monday

BACKUPDATABASE

The old_sales tablespace is backed up.

Wednesday backup

The backups on Tuesday, Wednesday, and Thursday back up the old_sales 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 old_sales tablespace because of backup optimization. Note that the Tuesday backup of old_sales is obsolete beginning on Thursday.

On Sunday, you delete all obsolete backups, which removes the Tuesday backup. The Tuesday backup is obsolete because of the retention policy setting. The whole database backup on Monday then backs up the old_sales 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.

Restartable Backups

Using the restartable backup feature, RMAN can back up only those files that have not been backed up since a specified date. This feature is intended for cases when a backup fails partway through and you only want to back up the part of the database that did not finish.

The unit of restartability is a single backup set. If the entire database is backed up into one backup set, and if a backup fails, then the entire backup has to be rerun. If the backup generates multiple backup sets, then the backups that completed successfully do not have to be rerun. For this reason, you can set FILESPERSET to a value much lower than the default so that RMAN limits the number of files that it places in each backup set.

For example, you can back up the database daily as follows:

BACKUP DATABASE FILESPERSET = 8;

Then, 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';

Note that if you do not specify the SINCETIMEparameter, then RMAN only backs up files that have never been backed up.

When determining whether a file has been backed up, RMAN compares the SINCETIME date with the completion time of the most recent backup of the file. The completion time for a file in a backup set is the completion time of the entire backup set. In other words, all files in the same backup set have the same completion time. If the SINCETIME is later than the completion time, then RMAN backs up the file.

Image Copies

An image copy contains a single datafile, archived redo log file, or control file that you can use as-is to perform recovery. Run the RMAN COPY command or an operating system command such as the UNIX cp command to create image copies.

An image copy produced with the RMAN COPY command is similar to an operating system copy of a single file, except that an Oracle server session produces it. The server session performs additional actions like validating the blocks in the file and recording the copy in the control file. An image copy differs from a backup set because it is not multiplexed, nor is there any additional header or footer control information stored in the copy. RMAN only writes image copies to disk.

RMAN Image Copies

Use the RMAN COPY command to create an image copy to disk. You cannot use COPY to make a copy to a device other than DISK. If you run a RESTORE command, then by default RMAN restores the image copy of a datafile or control file to its original location.

Note that if you need to replace a current datafile, and if you have an image copy of the datafile, then you do not need to restore the copy. Instead, you can use the SWITCH command to point the control file at the copy and update the repository to indicate that the copy has been switched. Issuing the SWITCH command in this case is equivalent to issuing the SQL statement ALTERDATABASERENAMEDATAFILE. You can then perform recovery on the copy.

RMAN can inspect an existing image copy and enter its metadata into the control file and recovery catalog. This operation is important when the recovery catalog is lost and you must perform disaster recovery. Only image copies and archived logs can be cataloged.

User-Managed Image Copies

Oracle supports image copies created by mechanisms other than RMAN, also known as user-managed copies or operating system copies. For example, a copy of a datafile that you make with the UNIX dd command is an operating system copy. You must catalog operating system copies with RMAN before using them with the RESTORE or SWITCH commands.

You can create an operating system copy when the database is open or closed. If the database is open and the datafile is online and read/write, then you must place the tablespace in backup mode, that is, issue the SQL statement ALTERTABLESPACEBEGINBACKUP before creating the copy.

Caution:

If you do not put a tablespace in backup mode before making an online user-managed backup, the backup can contain fractured blocks and become unrecoverable. Refer to "Detection of Logical Block Corruption".

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 operating system copy, thus making it a candidate for use in a restore operation. You must notify RMAN when the copy is no longer available for restore, however, by using the CHANGE...UNCATALOGcommand. In this example, after resilvering the mirror (not including other copies of the broken mirror), then you must use a CHANGE...UNCATALOG command to update the recovery catalog and indicate that this copy is no longer available.

Tags for Backups and Image Copies

You can assign a user-specified character string called a tag to backup sets and image copies (either copies made by RMAN or copies made 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 characters.

Tags do not need to be unique, so multiple backup sets or image copies can have the same tag. When a tag is not unique, then with respect to a given datafile, the tag refers to the most current suitable file. By default, RMAN selects the most recent backups to restore unless qualified by a tag or a SET UNTIL command. The most current suitable backup containing the specified file may not be the most recent backup, as can occur in point-in-time recovery.

For example, if datafile copies are created each Monday evening and are always tagged mondayPMcopy, then the tag refers to the most recent copy (assuming that no SETUNTIL command is issued before restore or recovery). Thus, if complete recovery is desired, this command switches datafile 3 to the most recent Monday evening copy:

SWITCH DATAFILE 3 TO DATAFILECOPY TAG mondayPMcopy;

Tags can indicate the intended purpose or usage of different classes of backups or file copies. For example, datafile copies that are suitable for use in a SWITCH can be tagged differently from file copies that should be used only for RESTORE.

Note:

If you specify a tag when specifying input files to a RESTORE or SWITCH command, then RMAN considers only backup sets with a matching tag when choosing which backup to use

About Tests and Integrity Checks

Oracle prohibits any attempts to perform operations that result in unusable backup files or corrupt restored datafiles. By using integrity checks, the Oracle server automatically does the following:

Ensures that restore operations do not corrupt the database by applying backups from a previous incarnation of the database

Ensures that incremental backups are applied in the correct order

Prohibits accessing datafiles that are in the process of being restored or recovered

Allows only one restore operation for each datafile at a time

Stores special error checking information in backups to ensure that corrupt backup files are detected

You can use the BACKUPVALIDATE command to perform a test run backup without actually producing output files. In this way, you can check your datafiles for possible problems.

Detection of Physical Block Corruption

Because an Oracle server session is performing backup and copy operations, the server session is able to detect many types of physically corrupt blocks. Each new corrupt block not previously encountered in a backup or copy operation is recorded in the control file and in the alert.log. By default, error checking for physical corruption is enabled.

RMAN queries corruption information at the completion of a backup and stores it in the recovery catalog and control file. Access this data using the views V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.

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 Oracle logs the corruption in 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 with a corrupt header 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.

Note:

RMAN cannot detect all types of block corruption.

Detection of Logical Block Corruption

RMAN tests data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, it then logs the block in the alert.log and server session trace file. By default, error checking for logical corruption is disabled.

Provided the sum of physical and logical corruptions for a file remains below its MAXCORRUPT setting, the RMAN command completes and Oracle populates V$BACKUP_CORRUPTION and V$COPY_CORRUPTION with corrupt block ranges. If MAXCORRUPT is exceeded, the command terminates without populating the views.

Note:

For COPY and BACKUP commands the MAXCORRUPT parameter sets the total number of physical and logical corruptions permitted in a file.

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 database writer 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. In this case, the block is a fractured block, meaning that the data contained in this block is not consistent.

When performing open backups without using RMAN, you must put tablespaces in backup mode in case the operating system reads a block for a backup that is currently being written by the database writer. When not in backup mode, Oracle records only changed bytes in the redo stream, not whole blocks. When a tablespace is in backup mode, Oracle writes the before-image of each changed block in the tablespace to the redo log before modifying it. Then, Oracle also records the changes to the block in the redo log. When you recover using SQL*Plus, Oracle applies the blocks and changes during recovery, so it does not matter that the block in the backup was fractured.

During an RMAN backup, an Oracle server session reads the datafiles, not an operating system utility. The server session reads whole Oracle blocks and determines whether the block is fractured by comparing the header and footer of each block. If the session detects a fractured block, then it rereads the block until it gets a consistent picture of the data. For this and other reasons, RMAN does not require you to place the tablespaces in backup mode, and it is neither desired or correct to place them in backup mode before RMAN is started.

Test Backups Using RMAN

You can run the BACKUP...VALIDATE command to do the following:

Check datafiles for physical and logical corruption

Confirm that all database files exist and are in the correct locations

RMAN does not actually produce backup sets, but scans the specified files to determine whether they can be backed up. In this sense, the BACKUPVALIDATE command is similar to the RESTOREVALIDATE command, except for backups rather than restore jobs.

For example, you can validate that all database files and archived redo logs can be backed up by issuing a command as follows:

BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

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