| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
This chapter describes the basic concepts involved in backing up the database with the Recovery Manager (RMAN) utility.
This chapter contains these topics:
An RMAN channel represents one stream of data to a device type, and corresponds to one server session. Most backup and recovery commands in RMAN are executed by server sessions. As illustrated in Figure 2-1, each channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance. The server session performs the backup, restore, and recovery.
Text description of the illustration bradv030.gif
You can use the CONFIGURE CHANNEL command to configure channels for use with disk or tape in all RMAN sessions using automatic channel allocation, or allocate channels manually within a RUN block. RMAN comes preconfigured with one DISK channel that you can use for backups to disk.
When you run a command that requires a channel without allocating a channel explicitly, then RMAN automatically allocates the channels with the options specified in the CONFIGURE command. For the BACKUP command, RMAN allocates only a single type of channel, such as DISK. For the RESTORE command and maintenance commands (for example, DELETE), RMAN allocates all necessary channels for the device types required to execute the command.
To specify the device type to use for an operation explicitly, use the ALLOCATE CHANNEL command, which must be used within a RUN block, or ALLOCATE CHANNEL FOR MANTAINANCE, which must be executed at the RMAN prompt.
In a Real Application Clusters configuration, there are special considerations regarding channel allocation and backups. See Oracle Real Application Clusters Administrator's Guide for more details.
How and when the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands cause the media manager to allocate resources is vendor-specific. Some media managers allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.
| See Also:
Oracle Database 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 to specify channels for commands used within a RUN block.
RMAN allocates automatic channels according to the settings in these commands:
For example, you can issue the following commands at the RMAN prompt:
# since you do not manually allocate channels, RMAN uses preconfigured channels BACKUP DATAFILE 3; RESTORE TABLESPACE users;
When you run a command that requires channels, and no channels have been allocated using the ALLOCATE command, RMAN automatically allocates channels according to values set with the CONFIGURE command in the following cases:
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. 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 automatic channels to allocate for a specified device type. For example, if you configure parallelism to 3 for a device type, then RMAN allocates three channels for the device type when using automatic channels.
You can change a parallelism setting by issuing another CONFIGURE DEVICE TYPE ... PARALLELISM command. This example configures PARALLELISM 2 and then changes it to 3:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
The parallelism setting defines the number of channels for a device that RMAN allocates in parallel. It does not have to correspond to the actual number of channels configured for the device. For example, you can manually configure four different sbt channels and set PARALLELISM for sbt to 2, 1, or 10.
You can view the default setting for parallelism by running the SHOW DEVICE TYPE command. For example:
RMAN> SHOW DEVICE TYPE; RMAN configuration parameters are: CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; #default
As always when the SHOW command is used to view the value of a parameter, RMAN includes a "#default" comment at the end of the line if the RMAN default value has not been overridden.
The following example configures the default device to sbt and then displays the resulting configuration using the SHOW DEVICE TYPE command:
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; new RMAN configuration parameters: CONFIGURE DEFAULT DEVICE TYPE TO 'sbt'; new RMAN configuration parameters are successfully stored RMAN> SHOW DEVICE TYPE; RMAN configuration parameters are: CONFIGURE DEVICE TYPE SBT PARALLELISM 1; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
Run the CONFIGURE DEFAULT DEVICE TYPE command to specify a default device type for automatic channels. For example, you may make backups to tape most of the time and only occasionally make a backup to disk. In this case, configure channels for disk and tape devices, but make sbt the default device type:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # configure device disk CONFIGURE DEVICE TYPE sbt PARALLELISM 2; # configure device sbt CONFIGURE DEFAULT DEVICE TYPE TO sbt;
Now, RMAN will, by default, use sbt channels for backups. For example, if you run the following command:
BACKUP TABLESPACE users;
RMAN only allocates channels of type sbt during the backup because sbt is the default device.
You can override the default device for backups by specifying a different device on the command. For example:
BACKUP DEVICE TYPE sbt DATABASE;
If the default device type is DISK, then the preceding command overrides this default and uses the sbt channel configuration. Note that this command fails unless you have configured the sbt device or configured sbt channels.
When restoring files, RMAN allocates all automatic channels according to the settings configured for each device type. The default device type configuration is irrelevant. For example, if you configure PARALLELISM to 3 for the default sbt device and PARALLELISM to 2 for DISK, then RMAN automatically allocates three sbt channels and two DISK channels during the restore.
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 a name that begins 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";
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 a specific automatic channel. If you are using a media manager that requires different settings on each channel, then you may find it useful to configure individual channels.
You can mix a CONFIGURE CHANNEL command that creates a generic configuration with a CONFIGURE CHANNEL command that creates a specific configuration. A generic automatic channel creates a configuration that can be used for any channel that is not explicitly configured.
For example, assume that you run these commands:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3; CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2M; CONFIGURE CHANNEL 3 DEVICE TYPE DISK MAXPIECESIZE = 900K;
In this scenario, RMAN allocates ORA_DISK_1 and ORA_DISK_2 with option MAXPIECESIZE = 2M, using the settings for the DISK channel with no number. RMAN allocates ORA_DISK_3 with MAXPIECESIZE = 900K because this channel was manually assigned a channel number. RMAN always allocates the number of channels specified in the parallelism parameter.
You can specify the CLEAR option for any CONFIGURE command. The CLEAR option returns the specified configuration to its default value. Assume you run these commands:
CONFIGURE DEVICE TYPE DISK CLEAR; # returns DISK to default PARALLELISM 1 # and backup type to BACKUPSET CONFIGURE DEFAULT DEVICE TYPE CLEAR; # returns to default device type of DISK CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR; # removes all options for sbt channel CONFIGURE CHANNEL 3 DEVICE TYPE DISK CLEAR; # removes configurations for 3rd ch.
Each CONFIGURE...CLEAR command removes the user-entered settings and returns the configuration to its default value.
The only way to find out the default setting for parameters set through CONFIGURE is to use CONFIGURE... CLEAR to un-set the parameter, so that it takes on the default value, and then run SHOW ALL to view all parameters. For any parameter for which the value is currently set to RMAN'S default, RMAN includes a "#default" comment at the end of that line of the output from SHOW ALL.
| See Also:
Oracle Database Recovery Manager Reference for the default settings for each |
RMAN can perform the I/O required for many commands in parallel, to make optimal use of your hardware resources. To perform I/O in parallel, however, the I/O must be associated with a single RMAN command, not a series of commands. For example, if backing up three datafiles, issue the command
BACKUP DATAFILE 5,6,7;
rather than issuing the commands
BACKUP DATAFILE 5; BACKUP DATAFILE 6; BACKUP DATAFILE 7;
When all three datafiles are backed up in one command, RMAN recognizes the opportunity for parallelism and can use multiple channels to do the I/O in parallel. When three separate commands are used, RMAN can only perform the backups one at a time, regardless of available channels and I/O devices.
The number of channels available (whether allocated in a RUN block or configured in advance) for use with a device at the moment that you run a command determines whether RMAN will read from or write to that device in parallel while carrying out the command. Failing to allocate the right number of channels adversely affects RMAN performance during I/O operations.
As a rule, the number of channels used in carrying out an individual RMAN command should match the number of physical devices accessed in carrying out that command. If manually allocating channels for a command, allocate one for each device; if configuring automatic channels, configure the PARALLELISM setting appropriately.
When backing up to tape, you should allocate one channel for each tape drive. When backing up to disk, allocate one channel for each physical disk, unless you can optimize the backup for your disk topography by using multiple disk channels. Each manually allocated channel uses a separate connection to the target or auxiliary database.
The following script creates three backups sequentially: three separate BACKUP commands are used to back up one file each. Only one channel is active at any one time because only one file is being backed up in each command.
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; ALLOCATE CHANNEL c2 DEVICE TYPE sbt; ALLOCATE CHANNEL c3 DEVICE TYPE sbt; BACKUP DATAFILE 5; BACKUP DATAFILE 6; BACKUP DATAFILE 7; }
The following statement uses parallelization on the same example: one RMAN BACKUP command backs up three datafiles, with all three channels in use. The three channels are concurrently active--each server session copies one of the datafiles to a separate tape drive.
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; ALLOCATE CHANNEL c2 DEVICE TYPE sbt; ALLOCATE CHANNEL c3 DEVICE TYPE sbt; BACKUP DATAFILE 5,6,7; }
| See Also:
Oracle Real Application Clusters Administrator's Guide for information about parallelization in a Real Application Clusters (RAC) configuration. In a RAC configuration you may want to specify different |
Whether you allocate channels manually or automatically, you can use channel control commands and options to do the following:
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)SEND)ALLOCATE CHANNEL ... PARMS, CONFIGURE CHANNEL ... PARMS)ALLOCATE CHANNEL ... CONNECT, CONFIGURE CHANNEL ... CONNECT)In releases 8.1.5 and later of the Oracle database, the ALLOCATE CHANNEL command causes RMAN to contact the media manager whenever the type specified is other than DISK. In earlier releases, the ALLOCATE CHANNEL command does not cause RMAN to contact the media manager; RMAN does not call the media manager until a BACKUP, RESTORE, or RECOVER command is issued.
Because RMAN has one preconfigured automatic DISK channel, you do not have to manually allocate a maintenance channel when running CHANGE, CROSSCHECK, or DELETE against a disk file (that is, an ARCHIVELOG, DATAFILECOPY, or CONTROLFILECOPY).
A maintenance channel is useful only for a maintenance task; you cannot use it as an input or output channel for a backup or restore.
| See Also:
Oracle Database Recovery Manager Reference for |
A BACKUP command is decomposed into multiple independent backup steps by RMAN. Each independent step can be executed on any channel allocatedfor the type of device used in the command. If you have multiple channels allocated, and one channel fails or encounters a problem during a backup step, then RMAN attempts to complete the work on another channel. Typically, such retriable errors can occur when a media manager encounters problems with one of several tape drives, or when an instance fails in a RAC environment.
RMAN reports a message in V$RMAN_OUTPUT and in the output to the interactive session or log file when it encounters such problems, as in the following example (refer to bold text):
channel ORA_SBT_TAPE_1: backup set failed, re-triable on other channel ORA-19506: failed to create sequential file, name="/bkup/63d3c3og_1_1", parms="" ORA-27028: skgfqcre: sbtbackup returned error ORA-19511: Error received from media manager layer, error text: failed to open file /bkup/63d3c3og_1_1 for backup, errno = 2 channel ORA_SBT_TAPE_2: finished piece 1 at 06-SEP-01 piece handle=5ld3blun_1_1 comment=API Version 2.0,MMS Version 3.2.0.0 channel ORA_SBT_TAPE_2: backup set complete, elapsed time: 00:00:04 retrying ORA_SBT_TAPE_1 failed backup step on ORA_SBT_TAPE_2 channel ORA_SBT_TAPE_2: starting full datafile backupset channel ORA_SBT_TAPE_2: specifying datafile(s) in backupset input datafile fno=00004 name=/oracle/dbs/tbs_12.f input datafile fno=00017 name=/oracle/dbs/tbs_14.f channel ORA_SBT_TAPE_2: starting piece 1 at 06-SEP-01 piece handle=5ld3buds_1_1 comment=API Version 2.0,MMS Version 3.2.0.0 channel ORA_SBT_TAPE_2: backup set complete, elapsed time: 00:00:06
Note that if RMAN is executing a script, then the next command in the script will not be executed if there were any errors in the previous command.
| See Also:
"Interpreting RMAN Message Output" to learn more about RMAN message and error reporting |
When you execute the BACKUP command in RMAN, you create one or more backup sets or image copies. By default, RMAN creates backup sets regardless of whether the destination is disk or a media manager.
An image copy is an exact copy of a single datafile, archived redo log file, or control file. Image copies are not stored in an RMAN-specific format. They are identical to the results of copying a file with operating system commands. RMAN can use image copies during RMAN restore and recover operations, and you can also use image copies with non-RMAN restore and recovery techniques.
To create image copies and have them recorded in the RMAN repository, run the RMAN BACKUP AS COPY command (or, alternatively, configure the default backup type for disk as image copies using CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY before performing a backup). A database server session is used to create the copy, and the server session also performs actions such as validating the blocks in the file and recording the image copy in the RMAN repository.
You can also use an operating system command such as the UNIX dd command to create image copies, though these will not be validated, nor are they recorded in the RMAN repository. You can use the CATALOG command to add image copies created with native operating system tools in the RMAN repository.
If you run a RESTORE command, then by default RMAN restores a datafile or control file to its original location by copying an image copy backup to that location. Image copies are chosen over backup sets because of the extra overhead of reading through an entire backup set in search of files to be restored.
However, if you need to restore and recover a current datafile, and if you have an image copy of the datafile available on disk, then you do not actually need to have RMAN copy the image copy back to its old location. You can instead have the database use the image copy in place, as a replacement for the datafile to be restored. The SWITCH command updates the RMAN repository indicate that the image copy should now be treated as the current datafile. Issuing the SWITCH command in this case is equivalent to issuing the SQL statement ALTER DATABASE RENAME FILE. You can then perform recovery on the copy.
RMAN can use image copies created by mechanisms outside of RMAN, such as native operating system file copy commands or third-party utilities that leave image copies of files on disk. These copies are known as user-managed copies or operating system copies.
The RMAN CATALOG command causes RMAN to inspect an existing image copy and enter its metadata into the RMAN repository. Once cataloged, these files can be used like any other backup with the RESTORE or SWITCH commands.
Some sites store their datafiles on mirrored disk volumes, which permit the creation of image copies by breaking a mirror. After you have broken the mirror, you can notify RMAN of the existence of a new user-managed copy, thus making it a candidate for a backup operation. You must notify RMAN when the copy is no longer available, by using the CHANGE ... UNCATALOG command. In this example, before resilvering the mirror (not including other copies of the broken mirror), you must use a CHANGE ... UNCATALOG command to update the recovery catalog and indicate that this copy is no longer available.
See Also:
|
During a proxy copy, RMAN turns over control of the data transfer to a media manager that supports this feature. Proxy copy can only be used with media managers that support it, not with disk. The PROXY option of the BACKUP command specifies that a backup should be a proxy copy.
For each file that you attempt to back up with the BACKUP PROXY command, RMAN queries the media manager to determine whether it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN backs the file up as if the PROXY option had not been used. (Use the PROXY ONLY option to force RMAN to fail if a proxy copy cannot be performed.)
Proxy copy can be used with datafiles or archived redo logs, as shown in these examples:
BACKUP DEVICE TYPE sbt PROXY DATAFILE 3; BACKUP DEVICE TYPE sbt PROXY ONLY DATABASE; BACKUP DEVICE TYPE sbt PROXY ONLY ARCHIVELOG ALL;
The examples assume that sbt channels have been configured with the appropriate parameters.
Note that control files are never backed up with proxy copy. If the PROXY option is specified on an operation backing up a control file, it is silently ignored for the purposes of backing up the control file.
See Also:
|
RMAN can create backups on disk or a third-party media device such as a tape drive. If you specify DEVICE TYPE DISK, then your backups are created on disk, in the file name space of the target instance that is creating the backup. You can make a backup on any device that can store a datafile.
To create backups on non-disk media, such as tape, you must use third-party media management software, and allocate channels with device types, such as SBT, that are supported by that software.
There are several features of RMAN backups specific to backups of archived redo logs.
RMAN can delete one or all copies of archived logs from disk after backing them up to backup sets. If you specify the DELETE INPUT option, then RMAN backs up exactly one copy of each specified log sequence number and thread from an archive destination to tape, and then deletes the specific file it backed up while leaving the other copies on disk. If you specify the DELETE ALL INPUT option, then RMAN backs up exactly one copy of each specified log sequence number and thread, and then deletes that log from all archive destinations. Note that there are special considerations related to deletion of archived redo logs in standby database configurations. See Oracle Data Guard Concepts and Administration for details.
RMAN's archived redo log failover allows RMAN to complete a backup even when some archived log destinations are missing logs or have logs with corrupt blocks. If at least one log corresponding to a given log sequence and thread is available in any of the archiving destinations, then RMAN tries to back it up. If RMAN finds a corrupt block in a log file during backup, it searches other destinations for a copy of that log without corrupt blocks.
By default, RMAN only backs up one copy of each distinct log sequence number. For example, assume that you archive logs 121 through 124 to two archiving destinations: /arch1 and /arch2. The control file contains archived log records as follows:
However, unknown to RMAN, a user deletes logs 122 and 124 from the /arch1 directory. Then, you run the following backup:
BACKUP ARCHIVELOG FROM SEQUENCE 121 UNTIL SEQUENCE 125;
With failover, RMAN completes the backup, using logs 122 and 124 in /arch2.
When creating backup sets, you can multiplex files. In this case, RMAN simultaneously reads multiple files from disk and and then writes their blocks into the same backup set. (Image copies, by contrast, are never multiplexed.) For example, RMAN can read from two datafiles simultaneously, and then combine the blocks from these datafiles into a single backup piece.
As Figure 2-2 illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece. This backup piece contains the intermingled data blocks of the three input files.
Text description of the illustration bradv022.gif
RMAN multiplexing is determined by the following algorithm:
Assume that you are backing up twelve datafiles with one RMAN channel. The number of files in each backup set is 4. To determine the level of multiplexing, compare this value to 8 and take the lesser, which is 4. Because the level of multiplexing is 4, the channel includes blocks from four separate datafiles into each backup set.
See Also:
|
Media manager multiplexing occurs when the media manager writes the concurrent output from multiple RMAN channels to a single sequential device, such as a tape drive.
When you configure PARALLELISM to greater than 1 or manually allocate multiple channels, RMAN writes multiple backups sets or image copies in parallel. The channels divide the work of backing up the specified files.
By default, RMAN determines which channels should back up which database files. You can use the CHANNEL option of the BACKUP command to manually assign a channel to back up specified files. This example shows a parallelized backup to the default disk location that uses the default automatic DISK channels:
BACKUP (DATAFILE 1,2,3 CHANNEL ORA_DISK_1) (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf' CHANNEL ORA_DISK_2) (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1 CHANNEL ORA_DISK_3);
You can also manually allocate channels as in the following example:
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server1)"; ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server2)"; ALLOCATE CHANNEL c3 DEVICE TYPE sbt PARMS="ENV=(BACKUP_SERVER=tape_server3)"; BACKUP (DATAFILE 1,2,3 CHANNEL c1) (DATAFILECOPY '/tmp/system01.dbf', '/tmp/tools01.dbf' CHANNEL c2) (ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 102 THREAD 1 CHANNEL c3); }
Figure 2-3 shows an example of parallelization in which channel ch1 backs up datafiles, channel ch2 backs up datafile copies, and channel ch3 backs up logs.
Text description of the illustration bradv024.gif
See Also:
|
In RMAN, there are two ways to make multiple, identical copies of backups:
BACKUP AS BACKUPSET command, in which case RMAN creates more than one copy of each backup setBACKUP BACKUPSET or BACKUP COPY commands.When backing up datafiles, archived redo log files, server parameter files and control files into backup pieces, RMAN can duplex the backup set, producing up to four identical copies of each backup piece in the backup set on different backup destinations with one BACKUP command. (Note that duplexing is not supported for backup operations that produce image copies.)
There are three ways to specify duplexing of backup sets when using the BACKUP command:
CONFIGURE... BACKUP COPIES
All backup commands that back up data into backup sets will be affected if you use this option, unless you specify different duplexing options for a command using SET BACKUP COPIES or provide a COPIES option for the BACKUP command.
SET BACKUP COPIES in a RUN block
All commands in the RUN block will be affected, overriding any CONFIGURE... BACKUP COPIES setting, except those where you provide a COPIES option as part of the BACKUP command.
COPIES option to the BACKUP command
For this specific BACKUP command, files will be duplexed to produce the number of copies you specify.
The FORMAT option of the BACKUP command specifies the destinations to be used when performing duplexed backups. You can specify up to 4 values for the FORMAT option. RMAN uses the second, third, and fourth values only when BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES is specified. The following example creates 3 copies of the backup of datafile 7:
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/tmp/%U','?/oradata/%U','?/%U';
RMAN places the first copy of each backup piece in /tmp, the second in ?/oradata, and the third in the Oracle home. Note that RMAN does not produce 3 backup sets, each with a different unique backup set key. Rather, RMAN produces one backup set with a unique key, and generates 3 identical copies of each backup piece in the set, as shown in this sample LIST output:
List of Backup Sets =================== BS Key Type LV Size ------- ---- -- ---------- 1 Full 64K List of Datafiles in backup set 1 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 7 Full 98410 08-FEB-03 /oracle/oradata/trgt/tools01.dbf Backup Set Copy #1 of backup set 1 Device Type Elapsed Time Completion Time Tag ----------- ------------ --------------- --- DISK 00:00:01 08-FEB-03 TAG20030208T152314 List of Backup Pieces for backup set 1 Copy #1 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 1 1 AVAILABLE /tmp/01dg9tb2_1_1 Backup Set Copy #2 of backup set 1 Device Type Elapsed Time Completion Time Tag ----------- ------------ --------------- --- DISK 00:00:01 08-FEB-03 TAG20030208T152314 List of Backup Pieces for backup set 1 Copy #2 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 2 1 AVAILABLE /oracle/oradata/01dg9tb2_1_2 Backup Set Copy #3 of backup set 1 Device Type Elapsed Time Completion Time Tag ----------- ------------ --------------- --- DISK 00:00:01 08-FEB-03 TAG20030208T152314 List of Backup Pieces for backup set 1 Copy #3 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 3 1 AVAILABLE /oracle/01dg9tb2_1_3
When choosing which FORMAT value to use for each backup piece, RMAN uses the first format value for copy number 1, the second format value for copy number 2, and so forth. If the number of format values exceeds the number of copies, then the extra formats are not used. If the number of format values is less than the number of copies, then RMAN reuses the format values, starting with the first one.
See Also:
|
The RMAN BACKUP BACKUPSET command backs up previously created backup sets. Only backup sets that were created on device type DISK can be backed up, and they can be backed up to any available device type.
The BACKUP BACKUPSET command uses the default disk channel to copy backup sets from disk to disk. To back up from disk to tape, you must either configure or manually allocate a non-disk channel.
The BACKUP BACKUPSET command is a useful way to spread backups among multiple media. For example, you can execute the following BACKUP command weekly as part of the production backup schedule:
# makes backup sets on disk BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL; # copies backup sets on disk to tape
|
Note: Backups to |
In this way, you ensure that all your backups exist on both disk and tape. You can also duplex backups of backup sets, as in this example:
BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
(Again, control file autobackups are never duplexed.)
You can also use BACKUP BACKUPSET to manage backup space allocation. For example, to keep more recent backups on disk and older backups only on tape, you can regularly run the following command:
BACKUP DEVICE TYPE sbt BACKUPSET COMPLETED BEFORE 'SYSDATE-7' DELETE INPUT;
This command backs up backup sets that were created more than a week ago from disk to tape, and then deletes them from disk. Note that DELETE INPUT here is equivalent to DELETE ALL INPUT;RMAN deletes all existing copies of the backup set. If you duplexed a backup to four locations, then RMAN deletes all four copies of the pieces in the backup set.
If backup optimization is enabled when you issue the command to back up a backup set, and if the identical backup set has already been backed up to the same device type, then RMAN skips the backup of this backup set. For example, when backup optimization is turned on, the following command backs up to tape only those backup sets not already backed up on device type sbt:
BACKUP DEVICE TYPE sbt BACKUPSET ALL;
When backing up backup sets, if RMAN discovers that one copy of a backup set is corrupted or missing, then it searches for other copies of the same backup set, based on the RMAN repository records about the backup set. This behavior is similar to the behavior of RMAN when backing up archived redo logs that exist in multiple archiving destinations.
For example, assume that backup set with key 872 contains three backup pieces, and that BACKUP COPIES 3 was issued so that three copies of each backup piece were created, each on a different file system. Also assume that some copies have been deleted or corrupted, so that the following table describes the current status of the backup copies:
| Backup Piece Number | Copy Number of the Piece | Status of Copy |
|---|---|---|
|
1 |
1 |
Corrupted |
|
1 |
2 |
Intact |
|
1 |
3 |
Corrupted |
|
2 |
1 |
Missing |
|
2 |
2 |
Corrupted |
|
2 |
3 |
Intact |
|
3 |
1 |
Intact |
|
3 |
2 |
Corrupted |
|
3 |
3 |
Missing |
The following command will cause RMAN to perform automatic failover:
BACKUP BACKUPSET 872;
RMAN copies only the backup pieces listed as "Intact" in the preceding table in its backup set.
You can use the following commands to back up image copies of database files either as backup sets or as image copies:
BACKUP AS COPY
COPY OF DATABASE;BACKUP AS BACKUPSET
COPY OF TABLESPACE;BACKUP AS BACKUPSET
COPY OF DATAFILE;When using these commands, there must already exist an image copy of every datafile specified in the command. If there are multiple copies of a datafile, the latest one is used. RMAN issues an error if image copies of every datafile in the database or tablespace do not exist.
Recovery Manager provides a number of options to control filenames, sizes of backups and speed during backup.
You can either let RMAN determine a unique name for backup pieces or use the FORMAT parameter to specify a name. For example, enter:
BACKUP TABLESPACE users;
RMAN automatically generates unique names for the backup pieces in the default backup location.
The FORMAT parameter provides substitution variables that you can use to generate unique filenames. For example, you can run a command as follows:
BACKUP TABLESPACE users FORMAT = '/tmp/users_%u%p%c';
As described in "Manual Parallelization of Backups", you can specify up to four FORMAT values. RMAN uses the second, third, and fourth values only when you run BACKUP COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES.
|
Note: If you use a media manager, then check your vendor documentation for restrictions on |
| See Also:
Oracle Database Recovery Manager Reference for descriptions of the |
FORMAT variables are also used to specify the names of image copies. The default format %U is defined differently for image copies than for backup pieces. RMAN produces image copies of three types of files: datafiles, control files, and archived logs. The following table describes the meaning of %U for each type of file.
| Type of File | Meaning of %U |
|---|---|
|
Datafile |
|
|
Archived log |
|
|
Control file |
|
When creating image copies (and only image copies), you can also name the output copies with the DB_FILE_NAME_CONVERT option of the BACKUP command. This parameter works identically to the initialization parameter DB_FILE_NAME_CONVERT. Pairs of filename prefixes are provided to change the names of the output files. If a file is not converted by any of the pairs, then RMAN uses the FORMAT specification; if no FORMAT is specified, then RMAN uses the default format %U.
For example, you can run the following command to copy the datafiles whose filename is prefixed with /maindisk/oradata/users so that they are prefixed with /backups/users_ts:
BACKUP AS COPY TABLESPACE users DB_FILE_NAME_CONVERT=('/maindisk/oradata/users','/backups/users_ts');
You can assign a user-specified character string called a tag to backup sets and image copies (either copies created by RMAN or copies created by an operating system utility). A tag is a symbolic name for a backup set or file copy, such as weekly_backup. You can specify the tag rather than the filename when executing the RESTORE or CHANGE command. The maximum length of a tag is 30 bytes.
If you do not specify a tag, then RMAN creates a default tag for backups (except for control file autobackups) in the format TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, HH is the hour (in 24-hour format), MM is the minutes, and SS is the seconds. For example, a backup of datafile 1 may receive the tag TAG20030208T133437. The date and time refer to when RMAN started the backup, in the time zone of the instance performing the backup. If multiple backup sets are created by one BACKUP command, then each backup piece is assigned the same default tag.
When applied to a backup set, a tag applies to a specific copy of the backup set. If you do not duplex a backup set, that is, make multiple identical copies of it, then the backup set has just one tag. For example,
BACKUP COPIES 1 DATAFILE 7 TAG foo
creates one backup set with tag FOO. Tags are stored in uppercase, regardless of the case used when entering them. However, you can back up this backup set and give this new copy of the backup set the tag BAR. So, the backup set has two identical copies: one tagged FOO and the other tagged BAR.
When applied to image copies, a tag applies to each individual image copy. For example, you run the following command:
# Back up as image copies the datafiles of tablespaces users and tools # all copies get the TAG 'users-tools' BACKUP AS COPY TAG users-tools TABLESPACE users, tools;
You can also copy an image copy with a specific tag, and give the output copy a different tag, as in the following example:
# Create new copies of all image copies of the database that have the tag # 'full_cold_copy', and give the new copies the tag 'new_full_cold_copy' BACKUP AS COPY COPY OF DATABASE FROM TAG=full_cold_copy TAG=new_full_cold_copy; # Create backup sets of the image copy of tablespace users that has the tag # 'monday_users', and of tablespace SYSTEM which has the tag 'monday_system'. # All these new backup # sets receive the tag 'for_audit'. BACKUP AS BACKUPSET TAG for_audit COPY OF TABLESPACE users FROM TAG monday_users TABLESPACE SYSTEM FROM TAG monday_system;
Tags do not need to be unique, so multiple backup sets or image copies can have the same tag, for example, weekly_backup. When you specify that a datafile should be restored from backups that have a specific tag, and more than one backup of the requested file has the desired tag, RMAN restores the most recent backup that has the desired tag (within any other constraints of the restore command, of course, such as a point in time).
Tags can indicate the intended purpose or usage of different classes of backups or copies. For example, datafile copies that are suitable for use in a SWITCH can be tagged differently (for_switch_only) from file copies that should be used only for RESTORE (for_restore_only).
|
Note: If you specify the |
| See Also:
Oracle Database Recovery Manager Reference for |
RMAN will, by default, put the entire contents of a backup set into one backup piece, regardless of the size of the backup set. If you are backing up to a file system or media manager that has a limit on the maximum file size that can be created, then you may need to restrict the size of backup pieces that RMAN will create.To restrict the size of each backup piece, specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. This option limits backup piece size to the specified umber of bytes. If the total size of the backup set is greater than the specified backup piece size, then multiple physical pieces will be created to hold the backup set contents.
For example, if datafile 1 is 6GB, you can still restrict the backup piece size for disk backups to 2 GB by configuring an automatic disk channel, and then run a backup as follows:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 2G; BACKUP AS BACKUPSET DATAFILE 1;
A LIST BACKUP command reveals that RMAN created five backup pieces rather than one backup piece to conform to the MAXPIECESIZE size restriction:
BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ -------------------- 29 Full 9728M DISK 00:00:35 NOV 02 2002 18:29:26 List of Datafiles in backup set 29 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- -------------------- ---- 1 Full 177590 NOV 02 2002 18:28:51 /oracle/oradata/trgt/system01.dbf Backup Set Copy #1 of backup set 29 Device Type Elapsed Time Completion Time Tag ----------- ------------ -------------------- --- DISK 00:00:35 NOV 02 2002 18:29:26 TAG20021102T152701 List of Backup Pieces for backup set 29 Copy #1 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 53 1 AVAILABLE /oracle/dbs/10d85733_1_1 54 2 AVAILABLE /oracle/dbs/10d85733_2_1 55 3 AVAILABLE /oracle/dbs/10d85733_3_1 56 4 AVAILABLE /oracle/dbs/10d85733_4_1 57 5 AVAILABLE /oracle/dbs/10d85733_5_1
This option can be used for media managers that cannot manage a backup piece that spans more than one tape. For example, if a tape can hold 10GB, but the backup set being created must hold 80GB of data, then RMAN must be instructed to create backup pieces of 10GB, small enough to fit on the tapes used with the media manager. The backup set media will in this case consist of eight tapes. Media managers supporting SBT2.0 can return a value to RMAN indicating the largest supported backup piece size, which RMAN will use in planning backup activities.
See Also:
|
Use the backupSpec clause of the BACKUP command to specify the objects that you want to back up as well as specify other options. Each backupSpec clause produces at least one backup set. The total number and size of backup sets depends for the most part on an internal RMAN algorithm, although you can tune RMAN behavior to a certain extent with the MAXSETSIZE parameter.
In determining the characteristics of the RMAN backup sets, the internal algorithm is influenced by the following factors:
backupSpec clauseMAXSETSIZE 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:
MAXSETSIZE parameter of the CONFIGURE or BACKUP command.
| See Also:
Oracle Database Recovery Manager Reference to learn the syntax for the |
To specify the maximum size of each backup set, use the MAXSETSIZE parameter in the CONFIGURE or BACKUP command. By limiting the overall size of the backup set, the parameter indirectly limits the number of files in the set and can possibly force RMAN to create additional backup sets.
Assume that you want to back up 50 datafiles, each containing 1000 blocks. To set the maximum size of each backup set to 10 MB, use the following command:
BACKUP DATABASE MAXSETSIZE = 10M;
|
Caution: If a datafile being backed up is bigger than MAXSETSIZE then your backup will fail. Always ensure that MAXSETSIZE is as large as your largest datafile. |
| See Also:
Oracle Database Recovery Manager Reference for information on the |
By default, RMAN uses all available I/O bandwidth to read/write to disk. You can limit the I/O resources consumed by a backup job with the RATE option of the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. The RATE option specifies the maximum number of bytes for each second that RMAN reads on the channel.
For example, you can configure automatic channels to limit each channel to read 1 MB a second:
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE sbt RATE 1M;
In effect, the RATE option throttles RMAN so that a backup job does not consume excessive I/O bandwidth on the computer.
| See Also:
"Tuning RMAN Backup Performance: Examples" for tips about how to optimize RMAN performance |
As explained in Table 2-1, RMAN backups can be classified in these ways:
Note that these backup classifications apply only to datafile backups. Backups of other files, such as archivelogs and control files, always include the complete file and are never inconsistent.
The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database.
During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. If it has a choice, then RMAN always chooses incremental backups over archived logs, as applying changes at a block level is faster than reapplying individual changes.
RMAN does not need to restore a base incremental backup of a datafile in order to apply incremental backups to the datafile during recovery. For example, you can restore non-incremental image copies of the datafiles in the database, and RMAN can recover them with incremental backups.
Incremental backups allow faster daily backups, use less network bandwidth when backing up over a network, and provide better performance when tape I/O bandwidth limits backup performance. They also allow recovery of database changes not reflected in the redo logs, such as direct load inserts. Finally, incremental backups can be used to back up NOARCHIVELOG databases, and are smaller than complete copies of the database (though they still require a clean database shutdown).
One effective strategy is to make incremental backups to disk (as image copies), and then back up these image copies to a media manager with BACKUP AS BACKUPSET. Then, you do not have the problem of keeping the tape streaming that sometimes occurs when making incremental backups directly to tape. Because incremental backups are not as big as full backups, you can create them on disk more easily.
Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. (If block change tracking is enabled, RMAN does not read the portions of the file known to have not changed since the parent incremental backup.) If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block.
One consequence of this mechanism is that RMAN applies all blocks containing changed data during recovery--even if the change is to an object created with the NOLOGGING option. Hence, making incremental backups is a safeguard against the loss of changes made by NOLOGGING operations.
| See Also:
Oracle Database Concepts for more information about |
RMAN can create multilevel incremental backups. Each incremental level is denoted by a value of 0 or 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.
A level 1 incremental backup can be either of the following types:
Incremental backups are differential by default.
|
Note: Cumulative backups are preferable to differential backups when recovery time is more important than disk space, because fewer incremental backups need to be applied during recovery. |
The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.
In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent incremental backup at level 1 (cumulative or differential) or level 0. For example, in a differential level 1 backup, RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup.
If no level 0 backup is available, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN behaves as it did in previous releases, by generating a level 0 backup.
Text description of the illustration bradv017.gif
In the example shown in Figure 2-4, the following occurs each week:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
On each day from Monday through Saturday, a differential incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level 1 or 0. The Monday backup copies blocks changed since Sunday level 0 backup, the Tuesday backup copies blocks changed since the Monday level 1 backup, and so forth.
In a cumulative level 1 backup, RMAN backs up all the blocks used since the most recent level 0 incremental backup. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.
Text description of the illustration bradv018.gif
In the example shown in Figure 2-5, the following occurs each week:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
A cumulative incremental level 1 backup copies all blocks changed since the most recent level 0 backup. Because the most recent level 0 backup was created on Sunday, the level 1 backup on each day Monday through Saturday backs up all blocks changed since the Sunday backup.
Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery.
When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 20% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:
SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5 ORDER BY COMPLETION_TIME;
Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then take a new level 0 backup when the most recent level 1 backup is about half of the size of the base level 0 backup.
| See Also:
Oracle Database Backup and Recovery Basics to learn how make incremental backups |
Having recent backups of your control file and server parameter file is extremely valuable in many recovery situations. To increase the likelihood that you will have such backups, the Oracle database supports control file and server paramter file autobackups. RMAN can automatically back up the control file and server parameter file (SPFILE) in situations in which the RMAN repository data for your database has been updated in a way that affects RMAN's ability to restore your database.
With a control file autobackup, RMAN can recover the database even if the current control file, recovery catalog, and server parameter file are inaccessible. Because the path used to store the autobackup follows a well-known format, RMAN can search for and restore the server parameter file from that autobackup.
After you have started the instance with the restored server parameter file, RMAN can restore the control file from the autobackup. After you mount the control file, use the RMAN repository in the mounted control file to restore the datafiles.
A control file autobackup lets you restore the RMAN repository contained in the control file when the control file is lost and you have no recovery catalog. You do not need a recovery catalog or target database control file to restore the control file autobackup. For example, you can issue:
RESTORE CONTROLFILE FROM AUTOBACKUP;
After you restore and mount the control file, you have the backup information necessary to restore and recover the database. You can connect to the target instance in NOCATALOG mode and recover the database. You can also create a new recovery catalog and register the target database. The RMAN repository records in the control file will be copied to the new recovery catalog.
The automatic backup of the control file occurs independently of any backup of the current control file explicitly requested as part of your backup command. You can turn the autobackup feature on or off by running the following commands:
CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP OFF;
Oracle Corporation recommends that CONFIGURE CONTROLFILE AUTOBACKUP be set to ON.
The first channel allocated during the backup job creates the autobackup and places it into its own backup set; for autobackups after database structural changes, the default disk channel makes the backup. If a server parameter file is used, it is backed up in the same backup set as the control file during a control file autobackup.
After the control file autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log.
The RMAN behavior when the BACKUP command includes datafile 1 depends on the CONFIGURE CONTROLFILE AUTOBACKUP setting. If control file autobackups are ON and the backup includes datafile 1, RMAN writes the control file and SPFILE to a separate autobackup backup set. If control file autobackups are OFF and the backup includes datafile 1, then RMAN includes the current control file and SPFILE in the same backup set as the datafiles.
The control file autobackup filename has a default format of %F for all device types, so that RMAN can guess the file location and restore it without a repository. The substitution variable %F is defined in the description of the CONFIGURE command in Oracle Database Backup and Recovery Basics. You can specify a different format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command. All autobackup formats must include the %F variable.
The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN block or at the RMAN prompt, overrides the configured autobackup format in the session only. The order of precedence is:
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:
|
By default, control file autobackups are turned off, and no control file autobackups are performed. If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the control file and the current server parameter file (if used to start up the database) in one of two circumstances: when a successful backup must be recorded in the RMAN repository, and when a structural change to the database affects the contents of the control file which therefore must be backed up.
This means that the control file is backed up in the following situations:
BACKUP command issued at the RMAN prompt.RUN block, if the last command in the block was BACKUP.BACKUP command within a RUN block is followed by a command that is not BACKUP.The first channel allocated during the backup job creates the autobackup and places it into its own backup set. The control file autobackup may be written to disk or tape.
The control file is also automatically backed up after database structural changes such as adding a new tablespace, altering the state of a tablespace or datafile (for example, bringing it online), adding a new online redo log, renaming a file, adding a new redo thread, and so on. Losing this information would compromise your ability to recover the database.
This backup is performed by the server process itself, rather than one of the RMAN channels. This type of autobackup, unlike autobackups that occur after a successful backup, is always created on disk. You can use CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set the location for this disk based control file autobackup. Note that a failure of the automatic control file autobackup after a structural change never causes the associated structural change to fail. For example, if you add a datafile, and if the resulting control file autobackup fails, then the datafile addition is still successful.
You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers backups of datafiles and control files as obsolete, that is, no longer needed for recovery, according to criteria that you specify in the CONFIGURE command. You can then use the REPORT OBSOLETE command to view obsolete files and DELETE OBSOLETE to delete them.
As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention policy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy.
If you have a flash recovery area configured, however, then the database automatically deletes unnecessary files from the flash recovery area based on its internal disk quota rules. The disk quota rules are distinct from the backup retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota.
The term obsolete does not mean the same as expired. A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered expired only when RMAN performs a crosscheck and cannot find the file. In short, obsolete means "not needed," whereas expired means "not found."
From the perspective of a retention policy, a datafile backup is a full or level 0 backup of an individual datafile or control file. It does not matter whether the backup is a datafile image copy, a proxy copy, or part of a backup set. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backups in backup sets, RMAN cannot delete the backup set until all of the individual datafile backups within the backup set are obsolete.
Besides affecting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained.
There are two mutually exclusive options for implementing a retention policy: redundancy and recovery window. If no retention policy is configured by the user, then the REPORT OBSOLETE and DELETE OBSOLETE commands use a default retention policy of REDUNDANCY 1.
To configure a retention policy based on a recovery window, use the following command:
To configure a retention policy based on redundancy, use the following command:
You can also disable the retention policy completely, meaning that RMAN does not consider any backup to be obsolete. To do so, use the following command:
CONFIGURE RETENTION POLICY TO NONE;
A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then this window of time must extend back exactly seven days from the present so that you can restore a backup and recover it to this point. You implement this retention policy as follows:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then there must always exist one backup of each datafile that satisfies the following condition:
SYSDATE - BACKUP CHECKPOINT TIME >= 7
All backups older than the most recent backup that satisfied this condition are obsolete.
Assume the following retention policy illustrated in Figure 2-6. The retention policy has the following aspects:
ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.
Text description of the illustration bradv004.gif
As illustrated in Figure 2-6, the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 through 850. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.
Assume the same scenario a week later, as depicted in Figure 2-7.
Text description of the illustration bradv002.gif
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.
A redundancy-based retention policy specifies how many backups of each datafile must be retained. For example, you can specify:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
Although the recovery window is the best practice for specifying a retention policy, it can complicate disk space usage planning because the number of backups that must be kept by the recovery window is not constant and depends on the backup schedule. Use the CONFIGURE RETENTION POLICY TO REDUNDANCY n command to implement a retention policy that maintains a constant number of backups of each datafile. RECOVERY WINDOW and REDUNDANCY-based retention policies are mutually exclusive.
The default retention policy is REDUNDANCY = 1, to maintain compatibility with the behavior of REPORT OBSOLETE in earlier RMAN releases. You can also run the following command to disable the retention policy altogether:
CONFIGURE RETENTION POLICY TO NONE;
If the retention policy is configured to NONE, then REPORT OBSOLETE and DELETE OBSOLETE do not consider any backups to be obsolete.
Run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy.
If you configure the retention policy to NONE, then RMAN does not consider any backups as obsolete. Consequently, RMAN issues an error when you run REPORT OBSOLETE without any other options and the retention policy is set to NONE.
A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You should run DELETE OBSOLETE periodically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script.
You can also specify the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands, to overrride the configured retention policy.
The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:
See Also:
|
You may want to store a long-term backup, potentially offsite, for much longer than the time dictated by the retention policy. For example, you may make a database backup on the first day of every year to satisfy some regulatory requirement, independent of backups taken for your ongoing backup and recovery strategy.
Such long-term backups should be recorded in the RMAN repository, but they must be exempted from the retention policy because RMAN would quickly consider them obsolete, and they would be removed the next time the DELETE OBSOLETE command is used.
You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command when you create the backup, or the KEEP option of the CHANGE command to exempt an existing backup. Note that backups exempted from the retention policy are still fully valid backups, which can be used in restore and recovery operations like any other if RMAN judges them to be the best choice available.
You can change the exempt status of a backup using the CHANGE... KEEP and CHANGE... NOKEEP commands. The NOKEEP option (default) indicates that the backup is not immune from the configured retention policy.
You can specify the LOGS option to save archived logs for a possible incomplete recovery of the long-term backup. When LOGS is specified, all logs more recent than the backup are kept as long as the backup is kept. In other words, KEEP UNTIL TIME... LOGS means that RMAN will keep all logs required to recover the backup as long as the backup is kept. If you specify NOLOGS, then RMAN does not keep the logs required to recover the backup. Note that if you use KEEP UNTIL TIME... with an inconsistent backup, you must use the LOGS option, or that backup will become unusable when the logs required to recover it are deleted as obsolete.
You can specify an end date using the UNTIL clause, or either specify that the backup should be kept FOREVER. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the UNTIL date has passed. Note that it is an error to specify KEEP FOREVER with the LOGS option, as this would require keeping all redo logs forever.
The following commands are examples of long-term backups:
# Creates a backup and exempts it from retention policy until last day of 2003 BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2003', 'dd-mon-yyyy')" NOLOGS; # Specifies that backupset 231 is no longer exempt from the retention policy CHANGE BACKUPSET 231 NOKEEP; # Creates a backup that is indefinitely exempt from the retention policy BACKUP TABLESPACE users KEEP FOREVER NOLOGS;
| See Also:
Oracle Database Recovery Manager Reference for |
The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is OBSOLETE in the RMAN repository, it is because it is either not needed for recovery to a point within the recovery window, or it is redundant.
If you configure a flash recovery area, then the database uses an internal algorithm to delete files from the flash recovery area that are no longer needed because they are redundant, orphaned, and so forth. The backups with status OBSOLETE form a subset of the files deemed eligible for deletion by the disk quota rules.
There is one important difference between the flash recovery area criteria for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the currently enabled recovery window and so are not obsolete. If you back up these logs to tape, then the retention policy still considers the disk logs as required, that is, not obsolete. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have already been backed up to tape. The logs on disk do not have OBSOLETE status in the repository, yet are eligible for deletion by the flash recovery area. Note, though, that the retention policy is never violated when determining which files to delete from the flash recovery area.
Backup optimization is a feature that avoids creating identical backup copies of files that have not changed since the last time they were backed up. 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 2-3 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 to be skipped. However, RMAN must do further checking to determine whether to skip the file, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type.
Table 2-3 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 in preparation for another backup:
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 4; CONFIGURE BACKUP OPTIMIZATION ON;
Then, you run the following archived log backup at noon:
BACKUP DEVICE TYPE sbt COPIES 2 ARCHIVELOG ALL;
In this case, the BACKUP ... COPIES setting overrides the CONFIGURE ... COPIES setting, so RMAN sets n=2. RMAN skips the backup of a log only if at least two copies of the log exist on the sbt device. Because three copies of each log exist on sbt of all the logs generated before 9 a.m., RMAN skips the backups of these logs. However, RMAN backs up two copies of all logs generated after 9 a.m. because these logs have not yet been backed up to tape.
At this point, three copies of the logs created before 9 a.m. exist on tape, and two copies of the logs created after 9 a.m. exist on tape. Assume that you run the following backup at 3 p.m.:
RUN { SET BACKUP COPIES 3; BACKUP DEVICE TYPE sbt ARCHIVELOG ALL; }
In this case, RMAN sets n=3 and so will not back up the logs created before 9 a.m. because three copies already exist on tape. However, only two copies of the logs created after 9 a.m. exist on tape, so RMAN does not optimize backups of these logs. Hence, RMAN backs up three copies of the logs created after 9 a.m.
Backup optimization is used 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 on a persistent basis, use the following command:
RMAN> CONFIGURE BACKUP OPTIMIZATION 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 recovery window retention policy is in effect, 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 change after the January 3 backup (because it is read-only). RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window.
This behavior allows the media manager to expire old tapes. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools indefinitely. By making a more recent backup of tablespace tools on February 21, RMAN allows the media manager to expire the tape containing the obsolete January 3 backup.
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 2-4 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 backups feature, RMAN can back up only those files that have not been backed up since a specified date. Use this feature after a backup fails to back up the parts of the database missed by the failed backup.
The unit of restartability is a backup set. If the backup generates multiple backup sets, then the backups that completed successfully do not have to be rerun. If the entire database is written into one backup set, and if the backup fails halfway through, then the entire backup has to be restarted.
To take better advantage of restartable backups, you can use set the MAXSETSIZE parameter of the BACKUP command. If, for instance, you set MAXSETSIZE to 10MB for a given backup command, a new backup set is produced for each 10MB of backup output. If the backup fails after some backup sets have been produced and must be restarted, the data backed up in those backup sets will not have to be backed up again. (Note that MAXSETSIZE must be large enough that any file can be accomodated in a single backup piece, because large files cannot span backup pieces.)
For example, if the largest datafile is less than 10 MB, then you can back up the database daily as follows:
BACKUP DATABASE MAXSETSIZE = 10M;
Then, after a failure you can back up all files in the database that were not backed up in the last 24 hours by issuing:
BACKUP DATABASE NOT BACKED UP SINCE TIME 'SYSDATE-1';
If the SINCE TIME is later than the completion time, then RMAN backs up the file. If you use "BACKUP DATABASE NOT BACKED UP" without the SINCE TIME parameter, then RMAN only backs up files that have never been backed up.
When determining whether a file has been backed up, RMAN compares the SINCE TIME date with the completion time of the most recent backup of the file. The completion time for a backup piece is the completion time of the entire backup set, not an individual backup piece; in other words, all files in the same backup set have the same completion time.
| See Also:
"Restarting a Backup After It Partially Completes" and Oracle Database Recovery Manager Reference for |
A backup window is a period of time during which a backup activity must complete. For example, you may want to restrict your database backup activities to a window of time when user activity on your system is low, such as between 2:00 AM and 6:00 AM.
The BACKUP command supports a DURATION argument which lets you specify how long a given backup job is allowed to run. You could, for example, run the following command at 2:00AM:
BACKUP DURATION 4:00 TABLESPACE users;
RMAN backs up the specified data at the maximum possible speed. If the backup is not complete in four hours, the backup is interrupted. Any completed backupsets are retained and can be used in restore operations, even if the entire backup is not complete. Any incomplete backupsets are discarded.
By default, when a BACKUP... DURATION command runs out of time before the backup completes, RMAN reports an error. (The effect of this is that if the command is running in a RUN block, the RUN block terminates.) You can control this behavior by adding the PARTIAL option to the BACKUP... DURATION command, as in this example:
BACKUP DURATION 4:00 PARTIAL TABLESPACE users FILESPERSET 1;
When PARTIAL is used, no error is reported when a backup command is interrupted due to the end of the backup window. Instead, a message showing which files could not be backed will be displayed. If the BACKUP command is part of a RUN block, then the remaining commands in the RUN block will continue to execute.
When using DURATION the least recently backed up files are backed up first. Thus, if you retry a job that was interrupted when the available duration expired, each successive attempt covers more of the files needing backup.
Note also the use of FILESPERSET 1 in this example. With this option, RMAN puts each file into its own backupset. This way, when a backup is interrupted at the end of the backup window, only the backup of the file currently being backed up is lost. All backup sets completed during the window are saved, minimizing the lost work due to the end of the backup window.
When using DURATION you can run the backup with the maximum possible performance, or run as slowly as possible while still finishing within the allotted time, to minimize the performance impact of backup tasks. To maximize performance, use the MINIMIZE TIME option with DURATION, as shown in this example:
BACKUP DURATION 4:00 PARTIAL MINIMIZE TIME DATABASE FILESPERSET 1;
To extend the backup to use the full time available, use the MINIMIZE LOAD option, as in this example:
BACKUP DURATION 4:00 PARTIAL MINIMIZE LOAD DATABASE FILESPERSET 1;
RMAN monitors the progress of the running backup, and periodically estimates how long the backup will take to complete at its present rate. If RMAN estimates that the backup will finish before the end of the backup window, it slows down the rate of backup so that the full available duration will be used. This reduces the overhead on the database associated with the backup.
|
Note: Note these issues when using
Because of these concerns, it is not recommended that |
RMAN detects and responds to 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 or image copies cause RMAN to terminate the backup jobs. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN terminates the backup. If multiple channels are being used, or redundant copies of backups are being created, RMAN may be able to continue the backup without user intervention.
If BACKUP AS BACKUPSET creates more than one complete 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 RMAN stops the backup unless SET MAXCORRUPT has been used. Setting MAXCORRUPT allows a specified number of previously undetected block corruptions in datafiles during the execution of an RMAN BACKUP command. If RMAN detects more than this number of corruptions while taking the backup, then the command terminates. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks by default.
When RMAN finds corrupt blocks, until it finds enough to exceed the MAXCORRUPT limit, it writes the corrupt blocks to the backup with a reformatted header indicating that the block has media corruption. If the backup completes without exceeding MAXCORRUPT,then the database records the address of the corrupt blocks and the type of corruption in the control file. Access these records through the V$DATABASE_BLOCK_CORRUPTION view. Note that if more than MAXCORRUPT corrupt blocks are found, the V$DATABASE_BLOCK_CORRUPTION view is not populated. In such a case, you should set MAXCORRUPT higher and re-run the command to identify the corrupt blocks.
See Also:
|
The database prevents operations that result in unusable backup files or corrupt restored datafiles. The database server automatically does the following:
You can use the BACKUP VALIDATE and RESTORE VALIDATE commands to test backup and restore operations without creating output files. In this way, you can check your datafiles for possible problems. If you run RMAN with the following configuration, then it detects all types of corruption that are possible to detect:
DB_BLOCK_CHECKSUM=TRUEBACKUP and RESTORE commands, do not specify the MAXCORRUPT option, do not specify the NOCHECKSUM option, but do specify the CHECK LOGICAL optionSee Oracle Database Backup and Recovery Basics for more details on BACKUP VALIDATE and RESTORE VALIDATE.
Because an database server session is performing the backups and has a great understanding of files being backed up or copied, the server session is able to detect many types of physically corrupt blocks during the backup process. Each new corrupt block not previously encountered in a backup is recorded in the control file and in the alert.log. By default, error checking for physical corruption is enabled.
At the end of a backup, RMAN stores the corruption information in the recovery catalog and control file. Access this data using the V$DATABASE_BLOCK_CORRUPTION view.
If the server session encounters a datafile block during a backup that has already been identified as corrupt by the database, then the server session copies the corrupt block into the backup and the corrupt block is recorded the control file as either a logical or media corruption. RMAN copies the block in case the user wants to try to salvage the contents of the block.
If RMAN encounters a datafile block that has media corruption but that has not already been identified as corrupt by the database, then it writes the block to the backup with a reformatted header indicating that the block has media corruption.
Besides testing for media corruption, the database can also test data and index blocks for logical corruption, such as corruption of a row piece or index entry. If RMAN finds logical corruption, then it logs the block in the alert.log. If CHECK LOGICAL was used, the block is also logged in the server session trace file. By default, error checking for logical corruption is disabled.
For BACKUP commands the MAXCORRUPT parameter sets the total number of physical and logical corruptions permitted in a file. If the sum of physical and logical corruptions for a file is less than its MAXCORRUPT setting, the RMAN command completes successfully. If MAXCORRUPT is exceeded, the command terminates and RMAN does not read the rest of the file. V$DATABASE_BLOCK_CORRUPTION is populated with corrupt block ranges if the command succeeds. Otherwise, you must set MAXCORRUPT higher and re-run the backup to find out the corrupt block ranges.
| See Also:
Oracle Database 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 copy utility reads a block for a backup that is currently being written by the database writer. When not in backup mode, the database records only changed bytes in the redo stream. When a tablespace is in backup mode, each time a block is changed the datbase writes the before-image ofthe entire block to the redo log before modifying it. Then, the database also records the changes to the block in the redo log. When you recover using SQL*Plus, the database applies both the block images and the changes from the redo logs during recovery. Applying the block images repairs any possible fractured blocks in the backup being restored and recovered.
RMAN does not require that you use backup mode (and it is an error to use backup mode with RMAN). During an RMAN backup, a database server session reads each block of the datafile and checks whether each block is fractured by comparing the block header and footer. If a block is fractured, the session re-reads the block. If the same fracture is found, then the block is considered permanently corrupt. If MAXCORRUPT is exceeded, the backup stops.
You can run the BACKUP ... VALIDATE command to check datafiles for physical and logical corruption, or to confirm that all database files exist in the correct locations. No backup is taken, but all specified files are scanned to verify that they can be backed up. Here is an example:
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.
| See Also:
Oracle Database Recovery Manager Reference for |
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|