Skip Headers
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)

Part Number B14191-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

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

    • The number of files read by each channel.

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

    • 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 parallelized 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: