Release 2 (9.2)
Part Number A96566-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Recovery Manager User's Guide Release 2 (9.2) Part Number A96566-01 |
|
This chapter describes the basic concepts involved in using the Recovery Manager (RMAN) utility.
This chapter contains these topics:
This section contains these topics:
| See Also:
Oracle9i Real Application Clusters Administration for information about channel allocation and backups in an Oracle Real Application Clusters environment |
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.
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 CONFIGURE CHANNEL 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 CONFIGURE CHANNEL 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.
| See Also:
Oracle9i Recovery Manager Reference for |
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 ALLOCATE CHANNEL command, RMAN allocates automatic channels according to the settings in these commands:
CONFIGURE DEVICE TYPE ... PARALLELISMCONFIGURE DEFAULT DEVICE TYPECONFIGURE CHANNEL DEVICE TYPECONFIGURE CHANNEL n DEVICE TYPEFor 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:
BACKUP, RESTORE, or DELETE outside of a RUN block.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:
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; BACKUP DATABASE PLUS ARCHIVELOG; }
RMAN optimizes automatic channel allocation by leaving automatic channels allocated so long as each new command requires exactly the same channel configuration as the previous command. For example, RMAN can use the same preallocated channels for the following series of commands:
BACKUP DATAFILE 1; BACKUP CURRENT CONTROLFILE; BACKUP ARCHIVELOG ALL;
If you issue a command such as ALLOCATE or CONFIGURE, then RMAN automatically releases the preallocated channels.
| See Also:
"Configuring Automatic Channels" to learn how to configure automatic channels |
The CONFIGURE DEVICE TYPE ... 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 CONFIGURE DEVICE TYPE ... PARALLELISM command. This example configures PARALLELISM 2 and then changes it to 3:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
The parallelism setting defines the number of channels for a device that RMAN allocates in parallel. It does not have to correspond to the actual number of channels configured for the device. For example, you can manually configure four different sbt channels and set PARALLELISM for sbt to 2, 1, or 10.
You can view the default setting for parallelism by running the SHOW DEVICE TYPE command. The default value is followed by a number sign (#). For example:
RMAN> SHOW DEVICE TYPE; RMAN configuration parameters are: CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
The following example configures the default device to sbt and runs another SHOW command:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; new RMAN configuration parameters: CONFIGURE DEFAULT DEVICE TYPE TO 'sbt'; new RMAN configuration parameters are successfully stored RMAN> SHOW DEVICE TYPE; RMAN configuration parameters are: CONFIGURE DEVICE TYPE SBT PARALLELISM 1; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
Run the CONFIGURE DEFAULT DEVICE TYPE command to specify a default device type for automatic channels. For example, you may make backups to tape most of the time and only occasionally make a backup to disk. In this case, configure channels for disk and tape devices, but make the device of sbt the default device:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # configure device disk CONFIGURE DEVICE TYPE sbt PARALLELISM 2; # configure device sbt CONFIGURE DEFAULT DEVICE TYPE TO sbt;
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.
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 |
For example, RMAN names the first DISK channel ORA_DISK_1, the second ORA_DISK_2, and so forth. RMAN names the first sbt channel ORA_SBT_TAPE_1, the second ORA_SBT_TAPE_2, and so forth. When you parallelize channels, RMAN always allocates channels in numerical order, starting with 1 and ending with the parallelism setting (CONFIGURE DEVICE TYPE ... PARALLELISM n), as in this example:
ORA_SBT_TAPE_1 ORA_SBT_TAPE_2 ORA_SBT_TAPE_3
Automatic channel allocation also applies to maintenance commands. If RMAN allocates an automatic maintenance channel, then it uses the same naming convention as any other automatically allocated channel. If you manually allocate a maintenance channel using ALLOCATE CHANNEL FOR MAINTENANCE, then RMAN uses the following convention for channel naming: ORA_MAINT_devicetype_n, where devicetype refers to the user's device type (for example, DISK or sbt) and n refers to the channel number. For example, RMAN uses these names for two manually allocated disk channels:
ORA_MAINT_DISK_1 ORA_MAINT_DISK_2
Note that if you run the CONFIGURE DEVICE TYPE command to configure a device type and do not run CONFIGURE CHANNEL for this device type, then RMAN allocates all channels without other channel control options. For example, assume that you configure the sbt device and run a backup as follows:
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; BACKUP DEVICE TYPE sbt DATABASE;
In effect, RMAN does the following:
RUN { ALLOCATE CHANNEL ORA_SBT_TAPE_1 DEVICE TYPE sbt; BACKUP DATABASE; }
Channel names beginning with the ORA_ prefix are reserved by RMAN for its own use. You cannot manually allocate a channel with the ALLOCATE CHANNEL command and then prefix the channel name with ORA_.
The CONFIGURE CHANNEL DEVICE TYPE command configures generic settings that are used for all automatic channels of the specified device type. In other words, the command creates a template of settings that RMAN uses for all channels allocated on the device. For example, you can configure disk and tape channels as follows:
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_SERVER=bksvr1)'; CONFIGURE CHANNEL DEVICE TYPE DISK RATE 5M FORMAT="?/oradata/%U" MAXOPENFILES=20;
Because you do not specify channel numbers for these channels, the channel settings are generic to all automatic channels of the specified type. The configuration acts as a template. For example, if you set PARALLELISM for DISK to 10, and the default device type is DISK, then RMAN allocates ten disk channels using the settings in the CONFIGURE CHANNEL DEVICE TYPE DISK command.
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:
CONFIGURE DEFAULT DEVICE DEVICE TYPE TO sbt; CONFIGURE DEVICE TYPE sbt PARALLELISM 2; CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT 'node1' PARMS='ENV=(NSR_SERVER=bksvr1)'; CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT 'node2' PARMS='ENV=(NSR_SERVER=bksvr1)';
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 CHANNEL 1 and the ORA_SBT_TAPE_2 channel uses the settings for CHANNEL 2.
You can mix a CONFIGURE CHANNEL command that creates a generic configuration with a CONFIGURE CHANNEL command that creates a specific configuration. A generic automatic channel simply creates a configuration that can be used for any channel that is not explicitly configured. For example, assume that you run these commands:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3; CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2M; CONFIGURE CHANNEL 3 DEVICE TYPE DISK MAXPIECESIZE = 900K;
In this scenario, RMAN allocates ORA_DISK_1 and ORA_DISK_2 with option MAXPIECESIZE = 2M, using the settings for the DISK channel with no number. RMAN allocates ORA_DISK_3 with MAXPIECESIZE = 900K because this channel was manually assigned a channel number. RMAN always allocates the number of channels specified in the parallelism parameter.
You can specify the CLEAR option for any CONFIGURE command. The CLEAR option returns the specified configuration to its default value. Assume you run these commands:
CONFIGURE DEVICE TYPE DISK CLEAR; # returns DISK to default parallelism CONFIGURE DEFAULT DEVICE TYPE CLEAR; # returns to default device type of DISK CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR; # removes all the options for sbt channel CONFIGURE CHANNEL 3 DEVICE TYPE DISK CLEAR; # removes all configurations for 3rd channel
Each CONFIGURE command removes the user-entered settings and returns the configuration to its default value. To see the default configuration settings, run the SHOW ALL command before entering any configurations of your own. The defaults are prefixed with a number sign (#).
| See Also:
Oracle9i Recovery Manager Reference for the default settings for each |
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 nodes.
RMAN internally handles parallelization of BACKUP, COPY, and RESTORE commands. You only need to specify:
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.
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; ALLOCATE CHANNEL c2 DEVICE TYPE sbt; ALLOCATE CHANNEL c3 DEVICE TYPE sbt; BACKUP DATAFILE 5; BACKUP DATAFILE 6; BACKUP DATAFILE 7; }
The following statement uses parallelization on the same example: one RMAN BACKUP command backs up three datafiles, with all three channels in use. The three channels are concurrently active--each server session copies one of the datafiles to a separate tape drive.
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; ALLOCATE CHANNEL c2 DEVICE TYPE sbt; ALLOCATE CHANNEL c3 DEVICE TYPE sbt; BACKUP DATAFILE 5,6,7; }
| See Also:
Oracle9i Real Application Clusters Concepts for information about parallelization in an Oracle Real Application Clusters configuration |
Whether you allocate channels manually or automatically, you can use channel control commands and options to do the following:
FILESPERSET parameter of the BACKUP command)ALLOCATE CHANNEL ... RATE, CONFIGURE CHANNEL ... RATE)MAXPIECESIZE parameter specified on the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands)MAXSETSIZE parameter specified on the BACKUP and CONFIGURE commands)ALLOCATE CHANNEL ... MAXOPENFILES, CONFIGURE CHANNEL ... MAXOPENFILES)SEND)ALLOCATE CHANNEL ... PARMS, CONFIGURE CHANNEL ... PARMS)ALLOCATE CHANNEL ... CONNECT, CONFIGURE CHANNEL ... CONNECT)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.
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.
| See Also:
Oracle9i Recovery Manager Reference for |
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.
When you execute the BACKUP command, you create one or more backup sets. This section contains these topics:
| See Also:
Chapter 9, "Making Backups and Copies with Recovery Manager" to learn how to make backups, and Oracle9i Recovery Manager Reference for information on the |
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 datafiles, control files, archived redo logs, and the current server parameter file. 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:
BACKUP DATABASE; BACKUP TABLESPACE users, tools; BACKUP (SPFILE) (CURRENT CONTROL FILE); BACKUP BACKUPSET 12; BACKUP DATAFILECOPY '/tmp/system01.dbf';
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. |
| See Also:
"Automatic Channel Generic Configurations" to learn about automatic channels, and "Backing Up Database Files and Archived Logs with RMAN" to learn how make backups |
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 CHANGE PROXY command or DELETE PROXY command to change the status of or delete a proxy backup.
| See Also:
Oracle9i Database Reference for more information about |
RMAN can create backup sets that are written to disk or tertiary storage. If you specify DEVICE TYPE 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.
| See Also:
"Backup Retention Policies" to learn how to configure a policy that determines which backups are obsolete |
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.
| See Also:
"Disk Buffer Allocation" and "Tape Buffer Allocation" to learn how RMAN buffers its backups |
RMAN provides additional functionality for backups of archived redo logs. This section contains these topics:
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 ALL INPUT 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.
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 redo log failover. RMAN can do the following:
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: /arch1 and /arch2. The control file contains archived log records as follows:
However, unknown to RMAN, someone accidentally deletes logs 122 and 124 from the /arch1 directory. Then, you run the following backup:
BACKUP ARCHIVELOG FROM SEQUENCE 121 UNTIL SEQUENCE 125;
In this case, RMAN can use the failover feature to back up the archived logs as described in the following table.
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:
ALTER SYSTEM ARCHIVE LOG CURRENT.UNTIL clause or SEQUENCE parameter is specified, RMAN does not try to switch or archive online logs.When making backups, run the BACKUP ... PLUS ARCHIVELOG 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 PLUS ARCHIVELOG is specified, RMAN performs the following actions in sequential order:
ALTER SYSTEM ARCHIVE LOG CURRENT.BACKUP ARCHIVELOG ALL.BACKUP command.ALTER SYSTEM ARCHIVE LOG CURRENT.You cannot specify PLUS ARCHIVELOG 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. |
See Also:
|
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 two 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 data blocks of the three input files.
Multiplexing is affected by the factors described in Table 5-1.
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:
1, 2, and 3 simultaneously and write to the backup piece4, 5 and 6 simultaneously and write to the backup pieceSo in this example, the degree of multiplexing is 3 (the lesser of 6 and 3).
When multiplexing files, you can do the following:
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.
See Also:
|
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.
|
Note: Control file autobackups on disk are a special case and are never duplexed: RMAN always writes one and only one copy. |
You can specify up to 4 values for the FORMAT option. RMAN uses the second, third, and fourth values only when BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES is specified. This example creates 3 copies of the backup of datafile 7:
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/tmp/%U','?/oradata/%U','?/%U';
RMAN places the first copy of each backup piece in /tmp, the second in ?/oradata, and the third in the Oracle home. Note that RMAN does not produce 3 backup sets, each with a different unique backup set key. Rather, RMAN produces one backup set with a unique key, and generates 3 identical copies of each backup piece in the set, as shown in this sample LIST output:
List of Backup Sets =================== BS Key Type LV Size ------- ---- -- ---------- 1 Full 64K List of Datafiles in backup set 1 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 7 Full 98410 08-FEB-02 /oracle/oradata/trgt/tools01.dbf Backup Set Copy #1 of backup set 1 Device Type Elapsed Time Completion Time Tag ----------- ------------ --------------- --- DISK 00:00:01 08-FEB-02 TAG20020208T152314 List of Backup Pieces for backup set 1 Copy #1 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 1 1 AVAILABLE /tmp/01dg9tb2_1_1 Backup Set Copy #2 of backup set 1 Device Type Elapsed Time Completion Time Tag ----------- ------------ --------------- --- DISK 00:00:01 08-FEB-02 TAG20020208T152314 List of Backup Pieces for backup set 1 Copy #2 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 2 1 AVAILABLE /oracle/oradata/01dg9tb2_1_2 Backup Set Copy #3 of backup set 1 Device Type Elapsed Time Completion Time Tag ----------- ------------ --------------- --- DISK 00:00:01 08-FEB-02 TAG20020208T152314 List of Backup Pieces for backup set 1 Copy #3 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 3 1 AVAILABLE /oracle/01dg9tb2_1_3
When choosing which FORMAT value to use for each backup piece, RMAN uses the first format value for copy number 1, the second format value for copy number 2, and so forth. If the number of format values exceeds the number of copies, then the extra formats are not used. If the number of format values is less than the number of copies, then RMAN reuses the format values, starting with the first one.
See Also:
|
When you configure PARALLELISM to greater than 1 or manually allocate multiple channels, RMAN writes multiple backup sets in parallel. The server sessions divide the work of backing up the specified files.
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:
BACKUP (DATAFILE 1,2,3 FILESPERSET = 1 CHANNEL ORA_DISK_1) (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf' FILESPERSET = 2 CHANNEL ORA_DISK_2) (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1 FILESPERSET = 3 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 FILESPERSET = 1 CHANNEL c1) (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf' FILESPERSET = 2 CHANNEL c2) (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1 FILESPERSET = 3 CHANNEL c3); }
Figure 5-4 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:
|
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 DEVICE TYPE sbt or configure an automatic sbt channel.
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 |
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 (except for control file autobackups, which are never duplexed by BACKUP BACKUPSET), 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 DELETE INPUT here is equivalent to DELETE ALL INPUT: RMAN deletes all existing copies of the backup set. If you duplexed a backup to four locations, then RMAN deletes all four copies of the pieces in the backup set.
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;
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 BACKUP COPIES 3 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.
| Backup Piece Number | Copy Number of the Piece | Status of Copy |
|---|---|---|
|
1 |
2 |
Intact |
|
2 |
3 |
Intact |
|
3 |
1 |
Intact |
Recovery Manager provides a number of options to control backups.
This section contains these topics:
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 users;
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 users FORMAT = '/tmp/users_%u%p%c';
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 BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES.
|
Note: If you use a media manager, check your vendor documentation for restrictions on |
| See Also:
Oracle9i Recovery Manager Reference for descriptions of the |
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 CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. This option limits backup piece size to the specified number of bytes.
For example, restrict the backup piece size for disk backups to 2 GB by configuring an automatic disk channel, and then run a backup as follows:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G; BACKUP DATAFILE 1;
A LIST BACKUP command reveals that RMAN created five backup pieces rather than one backup piece to conform to the MAXPIECESIZE size restriction:
BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ -------------------- 29 Full 9728M DISK 00:00:35 NOV 02 2001 18:29:26 List of Datafiles in backup set 29 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- -------------------- ---- 1 Full 177590 NOV 02 2001 18:28:51 /oracle/oradata/trgt/system01.dbf Backup Set Copy #1 of backup set 29 Device Type Elapsed Time Completion Time Tag ----------- ------------ -------------------- --- DISK 00:00:35 NOV 02 2001 18:29:26 TAG20011102T152701 List of Backup Pieces for backup set 29 Copy #1 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 53 1 AVAILABLE /oracle/dbs/10d85733_1_1 54 2 AVAILABLE /oracle/dbs/10d85733_2_1 55 3 AVAILABLE /oracle/dbs/10d85733_3_1 56 4 AVAILABLE /oracle/dbs/10d85733_4_1 57 5 AVAILABLE /oracle/dbs/10d85733_5_1
See Also:
|
Use the backupSpec clause of the BACKUP command to specify the objects that you want to back up as well as specify other options. Each backupSpec clause produces at least one backup set. The total number and size of backup sets depends on which algorithm RMAN uses: the basic algorithm or the advanced algorithm.
RMAN uses the basic algorithm when any of the following conditions is true:
DISKRATIO parameter of the BACKUP command to 0If all of these conditions are false, then RMAN uses the advanced algorithm described in "Number and Size of Backup Sets: Advanced Algorithm". Note that you can always force RMAN to use the basic algorithm by setting DISKRATIO=0.
In determining the characteristics of the RMAN backup sets, the basic algorithm is influenced by the following factors:
backupSpec clauses that you specifybackupSpec clauseFILESPERSET parameter, which limits the number of files for a backup setMAXSETSIZE parameter (specified on the CONFIGURE and BACKUP commands), which specifies a maximum backup set sizeThe most important rules in the algorithm for backup set creation are:
FILESPERSET parameter of the BACKUP command.FILESPERSET and MAXOPENFILES.MAXSETSIZE parameter of the CONFIGURE or BACKUP command.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.
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:
List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 6 Full 320K DISK 00:00:05 08-FEB-02 BP Key: 17 Status: AVAILABLE Tag: TAG20020208T153359 Piece Name: /oracle/dbs/06dg9tv9_1_1 List of Datafiles in backup set 6 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 3 Full 98410 08-FEB-02 /oracle/oradata/trgt/cwmlite01.dbf 4 Full 98410 08-FEB-02 /oracle/oradata/trgt/drsys01.dbf 6 Full 98410 08-FEB-02 /oracle/oradata/trgt/indx01.dbf 8 Full 98410 08-FEB-02 /oracle/oradata/trgt/users01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 7 Full 312K DISK 00:00:07 08-FEB-02 BP Key: 18 Status: AVAILABLE Tag: TAG20020208T153359 Piece Name: /oracle/dbs/07dg9tv9_1_1 List of Datafiles in backup set 7 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 2 Full 98410 08-FEB-02 /oracle/oradata/trgt/undotbs01.dbf 5 Full 98410 08-FEB-02 /oracle/oradata/trgt/example01.dbf 7 Full 98410 08-FEB-02 /oracle/oradata/trgt/tools01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 8 Full 196M DISK 00:00:36 08-FEB-02 BP Key: 19 Status: AVAILABLE Tag: TAG20020208T153359 Piece Name: /oracle/dbs/08dg9tv9_1_1 SPFILE Included: Modification time: 08-FEB-02 List of Datafiles in backup set 8 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 98410 08-FEB-02 /oracle/oradata/trgt/system01.dbf
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:
RMAN> list backup; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 9 Full 144K DISK 00:00:03 08-FEB-02 BP Key: 20 Status: AVAILABLE Tag: TAG20020208T153550 Piece Name: /oracle/dbs/0adg9u2n_1_1 List of Datafiles in backup set 9 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 4 Full 98410 08-FEB-02 /oracle/oradata/trgt/drsys01.dbf 7 Full 98410 08-FEB-02 /oracle/oradata/trgt/tools01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 10 Full 144K DISK 00:00:04 08-FEB-02 BP Key: 21 Status: AVAILABLE Tag: TAG20020208T153550 Piece Name: /oracle/dbs/0bdg9u2n_1_1 List of Datafiles in backup set 10 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 5 Full 98410 08-FEB-02 /oracle/oradata/trgt/example01.dbf 8 Full 98410 08-FEB-02 /oracle/oradata/trgt/users01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 11 Full 144K DISK 00:00:06 08-FEB-02 BP Key: 22 Status: AVAILABLE Tag: TAG20020208T153550 Piece Name: /oracle/dbs/09dg9u2n_1_1 List of Datafiles in backup set 11 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 3 Full 98410 08-FEB-02 /oracle/oradata/trgt/cwmlite01.dbf 6 Full 98410 08-FEB-02 /oracle/oradata/trgt/indx01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 12 Full 152K DISK 00:00:02 08-FEB-02 BP Key: 23 Status: AVAILABLE Tag: TAG20020208T153550 Piece Name: /oracle/dbs/0cdg9u2r_1_1 List of Datafiles in backup set 12 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 2 Full 98410 08-FEB-02 /oracle/oradata/trgt/undotbs01.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 13 Full 196M DISK 00:00:31 08-FEB-02 BP Key: 24 Status: AVAILABLE Tag: TAG20020208T153550 Piece Name: /oracle/dbs/0ddg9u2t_1_1 SPFILE Included: Modification time: 08-FEB-02 List of Datafiles in backup set 13 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 98410 08-FEB-02 /oracle/oradata/trgt/system01.dbf
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.
| See Also:
Oracle9i Recovery Manager Reference to learn the syntax for the |
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 fail because of space restrictions or tape backups to span multiple volumes.
The following table compares the MAXSETSIZE parameter to the FILESPERSET parameter.
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:
FILESPERSET and MAXSETSIZE limits. If necessary, then RMAN creates more backup sets than are calculated in the preceding comparison.MAXSETSIZE limit with the number of files as close to the FILESPERSET limit as possible.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:
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:
RMAN-06183: datafile or datafilecopy larger than MAXSETSIZE: file# 1 /oracle/oradata/trgt/system01.dbf
| See Also:
Oracle9i Recovery Manager Reference for information on the |
The advanced algorithm determines the number and size of backup sets by using the same factors described in "Number and Size of Backup Sets: Basic Algorithm". The difference is that the advanced algorithm is also influenced by the DISKRATIO parameter. If DISKRATIO=n, then each backup set must read data from at least n disk drives. RMAN uses file location information obtained from the database server to determine which datafiles are on which disk drives.
If you set FILESPERSET but not DISKRATIO, then DISKRATIO defaults to the same value as FILESPERSET. If you specify neither parameter, then DISKRATIO defaults to 4. RMAN compares the DISKRATIO value to the actual number of devices involved in the backup and uses the lowest value. For example, if DISKRATIO=4 and the datafiles are located on three disks, then RMAN attempts to distribute the datafiles into three backup sets.
Assume that the database contains 50 datafiles spread across 6 disks, and the operating system is able to deliver this disk contention information to the server. You configure a single sbt channel and then run the following command:
BACKUP DATABASE;
RMAN uses the advanced algorithm. The basic algorithm indicates that because you did not specify FILESPERSET or MAXSETSIZE, RMAN should produce a single backup set. The advanced algorithm also looks at DISKRATIO, which in this case defaults to 4. Hence, each backup set must contain datafiles from at least four disks. Because RMAN is only producing one backup set containing all datafiles from all six disks, DISKRATIO makes no difference.
Assume that you change the backup command as follows:
BACKUP DATABASE FILESPERSET 5;
In this case, the basic algorithm produces ten backup sets. The advanced algorithm also factors in DISKRATIO, which here defaults to 5 (the same value as FILESPERSET). Hence, the advanced algorithm dictates that each of the 10 backup sets must contain datafiles from at least 5 of the 6 disks.
Note that the advanced algorithm also recognizes node affinity. Node affinity is only used when you allocate channels on different nodes in a Real Application Clusters configuration, and RMAN detects that it is more efficient to read specific datafiles from one node than another.
You can limit the speed of a backup by using the RATE option of the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. The RATE option specifies the maximum number of bytes for each second that RMAN reads on the channel.
For example, you can configure automatic channels to limit channel c1 reads to 700 KB a second and channel c2 reads to 1 MB a second:
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL 1 DEVICE TYPE sbt RATE 700K; CONFIGURE CHANNEL 2 DEVICE TYPE sbt RATE 1M; BACKUP (TABLESPACE system, undotbs CHANNEL ORA_SBT_TAPE_1) (TABLESPACE users, tools, indx CHANNEL ORA_SBT_TAPE_2);
In effect, the RATE option throttles RMAN so that a backup job does not consume excessive bandwidth on the computer.
| See Also:
"Improving RMAN Backup Performance" for tips about how to optimize RMAN performance |
This section contains these topics:
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:
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.
This section contains these topics:
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
NOLOGGING option (direct load inserts do not log redo, although they do change data blocks and so are captured by incremental backups)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 BACKUP BACKUPSET 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.
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:
n or lower (the default type of incremental backup, which is called a differential backup)n-1 or lower (called a cumulative backup)
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.
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.
| See Also:
Oracle9i Database Concepts for more information about |
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.
In the example shown in Figure 5-5, the following occurs:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
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.
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.
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.
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.
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.
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.
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.
In the example shown in Figure 5-6, the following occurs:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
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.
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).
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).
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.
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.
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.
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:
SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5 ORDER BY COMPLETION_TIME;
Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0.
In a single-instance database 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.
The BACKUP command can back up the following types of files:
RMAN does not back up the following:
See Also:
|
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 terminate the jobs. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN terminates 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 terminating. The NOT BACKED UP SINCE option of the BACKUP command restarts a backup that partially completed, backing up only 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 command to 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 terminates. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks.
See Also:
|
If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and the current server parameter file (if used) in the following circumstances:
BACKUP or COPY command issued at the RMAN prompt.BACKUP or COPY command within a RUN block is followed by a command that is neither BACKUP nor COPY.RUN block if the last command in the block was either BACKUP or COPY.CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set a nondefault disk location. Note that the autobackup never causes the associated structural change to fail. For example, if you add a datafile, and if the resulting autobackup fails, then the datafile addition is still successful.
The first channel allocated during the backup or copy job creates the autobackup and places it into its own backup set; for post-structural autobackups, the default disk channel makes the backup. RMAN writes the control file and the server parameter file to the same backup piece. After the control file autobackup completes, Oracle writes a message containing the complete path of the backup piece and the device type to the alert log.
As explained by the following table, the RMAN behavior when the BACKUP command includes datafile 1 differs depending on whether CONFIGURE CONTROLFILE AUTOBACKUP is ON or OFF.
The 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 the autobackup feature on or off by running the following commands:
CONFIGURE CONTROLFILE AUTOBACKUP ON; 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 device type with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command. A valid format must include the %F variable as part of the string.
The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the session only. The order of precedence is:
Note that you can configure the autobackup format even when CONFIGURE CONTROLFILE AUTOBACKUP is set to OFF, but RMAN does not generate autobackups in this case. For RMAN to make autobackups, you must set CONFIGURE CONTROLFILE AUTOBACKUP to ON.
See Also:
|
This section contains these topics:
You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers backups 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 REPORT OBSOLETE command to view obsolete files and DELETE OBSOLETE to delete them.
The retention policy is ongoing. As you produce datafile, control file, and archived log 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 REPORT OBSOLETE or DELETE OBSOLETE 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.
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:
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;
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:
ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.
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.
Assume the same scenario a week later, as depicted in Figure 5-8.
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.
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 CONFIGURE RETENTION POLICY TO REDUNDANCY 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 REPORT OBSOLETE 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 REPORT OBSOLETE and DELETE OBSOLETE do not consider any backups to be obsolete.
Run the REPORT OBSOLETE command to determine which backups and copies are currently obsolete according to the retention policy. For example, if you set the recovery window to 7 days with 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 REPORT OBSOLETE 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 DELETE OBSOLETE in a weekly script.
Executing the DELETE OBSOLETE command ensures that you do not waste disk space by storing unnecessary files.
You can also specify the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands. These settings determine what is obsolete when running the commands and override the CONFIGURE RETENTION POLICY settings.
See Also:
|
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 DELETE OBSOLETE command would remove it.
By using the KEEP option 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, KEEP FOREVER LOGS 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 users KEEP FOREVER NOLOGS;
| See Also:
Oracle9i Recovery Manager Reference for |
RMAN's backup optimization refers to its intelligent skipping of files during backups when certain conditions are met.
This section contains these topics:
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-4 describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up.
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.
For example, assume that at 9 a.m. you back up three copies of all existing archived logs to tape:
BACKUP DEVICE TYPE sbt COPIES 3 ARCHIVELOG ALL;
Later, you enable the following configuration setting:
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 4; CONFIGURE BACKUP OPTIMIZATION ON;
Then, you run the following archived log backup at noon:
BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
In this case, the BACKUP ... COPIES setting overrides the CONFIGURE ... COPIES setting, so RMAN sets n=2. RMAN skips the backup of a log only if at least two copies of the log exist on the sbt device. Because three copies of each log exist on sbt of all the logs generated before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up two copies of all logs generated after 9 a.m. because these logs have not yet been backed up to tape.
At this point, three copies of the logs created before 9 a.m. exist on tape, and two copies of the logs created after 9 a.m. exist on tape. Assume that you run the following backup at 3 p.m.:
RUN { SET BACKUP COPIES 3; BACKUP DEVICE TYPE sbt ARCHIVELOG ALL; }
In this case, RMAN sets n=3 and so will not back up the logs created before 9 a.m. because three copies already exist on tape. However, only two copies of the logs created after 9 a.m. exist on tape, so RMAN does not optimize backups of these logs. Hence, RMAN backs up three copies of the logs created after 9 a.m.
Backup optimization is enabled when the following conditions are true:
CONFIGURE BACKUP OPTIMIZATION ON command has been run.BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP BACKUPSET ALL.DISK and sbt.For example, assume that you run these commands:
BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL;
If none of these files has changed since the last backup, then RMAN does not back up the files again, nor signal an error if it skips all files specified in the command.
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 CONFIGURE BACKUP OPTIMIZATION command. The CLEAR option returns backup optimization to its default value of OFF.
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 CONFIGURE RETENTION POLICY TO NONE.
If optimization is enabled, and if 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:
tools to tape is January 3.tools is read-only.On February 21, when you issue a command to back up tablespace tools to tape, RMAN backs it up even though it did not 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 tools indefinitely. By making a more recent backup of tablespace tools on February 21, RMAN allows the media manager to expire the tape containing the superfluous January 3 backup.
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 of the files, where r is set in CONFIGURE RETENTION POLICY TO REDUNDANCY r.
Assume that you enable backup optimization and set the following retention policy:
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
So, RMAN only skips backups when three identical files are already backed up. Also assume that you have never backed up the users tablespace, which is read/write, and that you perform the actions described in Table 5-5 over the course of the week.
The backups on Tuesday, Wednesday, and Thursday back up the offline users tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). The Friday and Saturday backups do not back up the users tablespace because of backup optimization. Note that the Tuesday backup of users is obsolete beginning on Thursday.
On Sunday, you delete all obsolete backups, which removes the Tuesday backup of users. The Tuesday backup is obsolete because of the retention policy setting. The whole database backup on Monday then backs up the users tablespace to satisfy the condition that three backups must exist (one more than redundancy setting). In this way, you can recycle your tapes over time.
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 SINCE TIME parameter, then RMAN only backs up files that have never been backed up.
When determining whether a file has been backed up, RMAN compares the SINCE TIME date with the completion time of the most recent backup of the file. The completion time for a 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 SINCE TIME is later than the completion time, then RMAN backs up the file.
| See Also:
"Restarting a Backup After It Partially Completes" and Oracle9i Recovery Manager Reference for |
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.
This sections contains these topics:
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 ALTER DATABASE RENAME DATAFILE. 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.
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 ALTER TABLESPACE BEGIN BACKUP 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 ... UNCATALOG command. 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.
See Also:
|
You can assign a user-specified character string called a tag to backup sets and image copies (either copies created by RMAN or copies created by an operating system utility). A tag is a case-insensitive 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.
If you do not specify a tag name, then by default RMAN creates a tag for backups and copies (except for control file autobackups) in the format TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, HH is the hour (in 24-hour format), MM is the minutes, and SS is the seconds. For example, a backup of datafile 1 may receive the tag TAG20020208T133437. The date and time refer to when RMAN started the backup. If multiple backup sets are created by one BACKUP command, then each backup piece is assigned the same default tag.
When applied to a backup set, a tag applies to a specific copy of the backup set. If you do not duplex a backup set, that is, make multiple identical copies of it, then a one-to-one correspondence exists between the tag and the backup set. For example, BACKUP COPIES 1 DATAFILE 7 TAG foo creates one backup set with tag foo. However, you can back up this backup set and give this new copy of the backup set the tag bar. So, the backup set has two identical copies: one tagged foo and the other tagged bar.
Tags do not need to be unique, so multiple backup sets or image copies can have the same tag name, for example, weekly_backup. 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 SET UNTIL 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 |
| See Also:
Oracle9i Recovery Manager Reference for |
You can use the COPY ... KEEP command to specify that an image copy should be exempt from the current retention policy. The behavior of this command is the same as BACKUP ... KEEP.
| See Also:
"Backups Exempt from the Retention Policy" for a description of retention policies and how files can be exempt or non-exempt |
This section contains these topics:
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:
You can use the BACKUP VALIDATE command to perform a test run backup without actually producing output files. In this way, you can check your datafiles for possible problems.
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.
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 |
| See Also:
Oracle9i Recovery Manager Reference for |
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.
| See Also:
Oracle9i User-Managed Backup and Recovery Guide for information about backup mode |
You can run the BACKUP ... VALIDATE command to do the following:
RMAN does not actually produce backup sets, but scans the specified files to determine whether they can be backed up. In this sense, the BACKUP VALIDATE command is similar to the RESTORE VALIDATE 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.
| See Also:
Oracle9i Recovery Manager Reference for |
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|