Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
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.
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.
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.
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:
Oracle Database Backup and Recovery Basics to learn how to catalog datafile and archived log image copies
Oracle Database Backup and Recovery Reference for CHANGE
syntax
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:
Oracle Database Reference for more information about V$PROXY_DATAFILE
and V$PROXY_ARCHIVEDLOG
Oracle Database Backup and Recovery Reference for the BACKUP
command and the PROXY
option
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.
There are several features of RMAN backups specific to backups of archived redo logs.
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.
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
.
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.
RMAN multiplexing is determined by the following algorithm:
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.
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:
"I/O Buffer Allocation" to learn how multiplexing affects allocation of disk buffers during backups
Oracle Database Backup and Recovery Reference for BACKUP
syntax
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.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.
See Also:
"Determining Channel Parallelism to Match Hardware Devices" for an overview of how allocated channels affect parallelization
"Determining How Channels Distribute a Backup Workload: Example" to learn how to parallelize backups
Oracle Database Backup and Recovery Reference for reference material on the CHANNEL
parameter of the BACKUP
command