Release 8.1.5
A67773-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Backup and Recovery Guide Release 8.1.5 A67773-01 |
|
This chapter describes the basic concepts for the Oracle Recovery Manager (RMAN) utility, and includes the following topics:
Recovery Manager (RMAN) is an Oracle tool that allows you to back up, copy, restore, and recover datafiles, control files, and archived redo logs. You can invoke RMAN as a command line utility from the O/S prompt or use the GUI-based Enterprise Manager Backup Manager.
RMAN automates many of the backup and recovery tasks that were formerly performed manually. For example, instead of requiring you to locate appropriate backups for each datafile, copy them to the correct place using O/S commands, and choose which archived logs to apply, RMAN manages these tasks automatically.
When you start RMAN, the following operations occur:
When you use RMAN to connect to your target database, RMAN uses server sessions to perform the backup and recovery operations through a PL/SQL interface. RMAN physically stores its backups and copies on disk or, if you use media management software, on tape.
RMAN stores metadata about its backup and recovery operations in the recovery catalog, which is a centralized repository of information, or exclusively in the control file. Typically, the recovery catalog is stored in a separate database. If you do not use a recovery catalog, RMAN uses the control file as its repository of metadata.
See Also: For information about RMAN compatibility and upgrade issues, see Oracle8i Migration.
RMAN automates important backup and recovery procedures. For example, Recovery Manager is able to:
See Also: For a description of RMAN features that are new to this version of Oracle, see Getting to Know Oracle8i.
RMAN is not:
RMAN provides commands that you can use to manage all aspects of backup and recovery operations. Note that all RMAN commands for Oracle release 8.0 work in release 8.1.
This section contains the following topics:
See Also: For a complete account of RMAN commands and their syntax, see Chapter 11, "Recovery Manager Command Syntax".
The RMAN executable uses PL/SQL procedures to interpret commands. The PL/SQL packages perform two main functions:
The DBMS_RCVCAT and DBMS_RCVMAN packages are created by the create catalog command. RMAN uses DBMS_RCVCAT to maintain information in the recovery catalog and DBMS_RCVMAN to query the recovery catalog or control file.
The DBMS_BACKUP_RESTORE package is created by the dbmsbkrs.sql and prvtbkrs.plb scripts. This package is automatically installed in every Oracle database when the catproc.sql script is run. This package interfaces with the Oracle server and the operating system to provide the I/O services for backup and restore operations as directed by Recovery Manager.
See Also: For more information about the DBMS_RCVCAT, DBMS_RCVMAN, and DBMS_BACKUP_RESTORE packages, see the Oracle8i Supplied Packages Reference.
Recovery Manager processes commands in two phases:
When you issue a Recovery Manager command such as backup, RMAN generates output alerting you to the various phases of command processing. Following is sample output for a backup tablespace command. Note the RMAN messages that begin RMAN-03xxx:
RMAN-03022: compiling command: backup RMAN-03023: executing command: backup RMAN-08008: channel ch1: starting full datafile backupset RMAN-08502: set_count=48 set_stamp=346765191 creation_time=15-OCT-98 RMAN-08010: channel ch1: specifying datafile(s) in backupset RMAN-08522: input datafile fno=00017 name=/oracle/dbs/tbs_14.f RMAN-08522: input datafile fno=00003 name=/oracle/dbs/tbs_11.f RMAN-08522: input datafile fno=00004 name=/oracle/dbs/tbs_12.f RMAN-08522: input datafile fno=00007 name=/oracle/dbs/tbs_13.f RMAN-08013: channel ch1: piece 1 created RMAN-08503: piece handle=/oracle/dbs/1gaamds7_1_1 comment=NONE RMAN-08525: backup set complete, elapsed time: 00:00:04 RMAN-03023: executing command: partial resync RMAN-08003: starting partial resync of recovery catalog RMAN-08005: partial resync complete RMAN-08031: released channel: ch1
During the compilation phase, RMAN performs two operations:
Most RMAN commands require you to identify what object the command should operate on. Name translation is the operation whereby RMAN translates what you specified in the command into a list of one or more entities that it really operates on. An entity in this sense can be a datafile, an archived redo log, a datafile copy, a control file copy, and so forth. For example, when you enter the command backup database, RMAN translates the keyword database into a list of all the datafiles that are in the database. Similarly, when you issue the following:
backup archivelog from time='xxx' until time='yyy'
RMAN translates the archivelogRecordSpecifier clause (the from ... until ... part of the command) into a list of archived redo logs.
RMAN performs its work by dynamically generating one or more PL/SQL programs and then executing them. In essence, RMAN compiles the commands you issue into PL/SQL programs. RMAN itself contains a copy of the PL/SQL engine, and executes the PL/SQL programs internally during the execution phase. These programs make remote procedure calls to the target database to perform backup, restore, and other necessary operations.
A single RMAN command can result in the generation of multiple PL/SQL programs. For example, a backup database command generates one PL/SQL program for each backup set that is to be created. Similarly, restore database generates one PL/SQL program for each backup set that needs to be restored.
During the execution phase, RMAN schedules and runs the PL/SQL programs it compiled during the compilation phase. RMAN assigns one PL/SQL program to each channel (that is, each server session) that you have allocated. The channels execute their PL/SQL program concurrently. For example, if you allocate three channels, then RMAN executes three of the PL/SQL programs at the same time.
RMAN is able to execute concurrent PL/SQL programs because the remote procedure calls (RPCs) that the programs make to the target database use the non-blocking User Program Interface (UPI) feature, thereby allowing RMAN to switch to another channel when one channel makes a non-blocking RPC call. RMAN uses an internal polling mechanism to detect when a non-blocking RPC call has completed. After it completes, RMAN resumes the PL/SQL program.
RMAN uses two basic types of commands: stand-alone commands and job commands. With the exception of the change, crosscheck, and delete commands, stand-alone commands are self-contained. In contrast, job commands must appear within the brackets of a run command.
After you connect to the target and optional recovery catalog, you will execute most of your RMAN commands within run. Following is a typical example of a run statement:
run { allocate channel c1 type 'sbt_tape'; restore database; recover database; } See Also: See Chapter 11, "Recovery Manager Command Syntax" for an exhaustive description of RMAN syntax.
Unlike job commands, stand-alone commands do not appear as sub-commands within run. Following are some of the commands that can appear by themselves:
Some of these commands are not strictly stand-alone, however, since they must be preceded by an allocate channel for maintenance command.
See Also: To learn about stand-alone command syntax, see "rmanCmd".
Unlike stand-alone commands, job commands must appear within the brackets of a run command. Following are examples of job commands:
RMAN executes the job commands inside of a run command block sequentially. If any command within the block fails, RMAN ceases processing--no further commands within the block are executed. In effect, the run command defines a unit of command execution. When the last command within a run block completes, Oracle releases any server-side resources such as I/O buffers or I/O slave processes allocated within the block.
See Also: To learn about job command syntax, "run".
Most commands are either stand-alone commands or job commands. If you try to issue a job command outside of a run block or issue a stand-alone command inside a run block, RMAN issues a syntax error message. The following exceptions, however, can function as both stand-alone and job commands:
RMAN supports a number of command-line arguments that you can specify when you connect to RMAN. You can specify most of these arguments only on the command line; the exceptions are target and catalog, which you can specify either on the command line or via the connect command after RMAN has started. The connect command allows you to avoid putting passwords on the command line, since this practice sometimes poses a security problem.
See Also: To learn about command-line options, see "cmdLine".
RMAN uses a command language interpreter (CLI) that allows you to execute commands in interactive or batch mode. You can also specify the log option at the command line to write RMAN output into a log file.
To run RMAN commands interactively, start RMAN and then type commands into the command line interface. For example, you can start RMAN from the UNIX command shell and then execute interactive commands as follows:
% rman target sys/sys_pwd@prod1 catalog rman/rman@rcat RMAN> run { 2> allocate channel d1 type disk; 3> backup database; 4> }
You can type RMAN commands into a file, and then run the command file by specifying its name on the command line. The contents of the command file should be identical to commands entered at the command line.
When running in batch mode, RMAN reads input from a command file and writes output messages to a log file (if specified). RMAN parses the command file in its entirety before compiling or executing any commands. Batch mode is most suitable for performing regularly scheduled backups via an operating system job control facility.
In this example, the RMAN sample script from "Interactive Mode" has been placed into a command file called b_whole_10.rcv. You can run this file from the O/S command line and write the output into the log file rman_log.f as follows:
% rman target / catalog rman/rman@rcat @b_whole_l0.rcv log rman_log.f
See Also: For more information about RMAN command line options, see "cmdLine".
A stored script is a set of RMAN commands that is enclosed in braces and stored in the recovery catalog. Maintaining a stored script allows you to plan, develop, and test a set of commands for backing up, restoring, or recovering the database. Stored scripts also minimize the potential for operator errors. Each stored script relates to only one database.
To create a stored script, either enter your script interactively into the RMAN command-line interface, or type your RMAN commands into a command file and run the command file.
Following is an example of a stored script:
replace script b_whole_l0 { # back up whole database and archived logs allocate channel d1 type disk; allocate channel d2 type disk; allocate channel d3 type disk; backup incremental level 0 tag b_whole_l0 filesperset 6 format '/dev/backup/prod1/df/df_t%t_s%s_p%p' (database); sql 'ALTER SYSTEM ARCHIVE LOG CURRENT'; backup filesperset 20 format '/dev/backup/prod1/al/al_t%t_s%s_p%p' (archivelog all delete input); } View your stored scripts by querying the recovery catalog view RC_STORED_ SCRIPT: SQL> SELECT * FROM rc_stored_script; DB_KEY DB_NAME SCRIPT_NAME ---------- ------- ------------------------------------------------------ 1 RMAN full_backup 1 RMAN incr_backup_0 1 RMAN incr_backup_1 1 RMAN incr_backup_2 1 RMAN log_backup
See Also: For more information on scripts, see "Storing Scripts in the Recovery Catalog". Also refer to the sample scripts stored in your /demo directory.
On various occasions it may be important for you to determine whether RMAN successfully executed your command. For example, if you are trying to write a script that will perform an unattended backup using RMAN, you may want to know whether the backup was a success or failure.
The simplest way to determine whether RMAN encountered an error is to examine its return code. RMAN will return 0 to the operating system if no errors occurred, 1 otherwise. For example, if you are running UNIX and using the C shell, RMAN outputs the return code into a shell variable called $status.
The second easiest way is to search the Recovery Manager output for the string RMAN-00569, which is the message number for the error stack banner. All RMAN errors are preceded by this error message. If you do not see an RMAN-00569 message in the output, then there are no errors. Following is sample output for a syntax error:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01005: syntax error: found "}": expecting one of: "archivelog, backup, backupset, channel, comma, controlfilecopy, current, database, datafile, datafilecopy, delete, diskratio, filesperset, format, include, (, parms, pool, ;, skip, setsize, tablespace, tag" RMAN-01007: at line 1 column 58 file: standard input
The RMAN metadata is the information about your target databases that RMAN uses to conduct its backup, recovery, and maintenance operations. You can either create a recovery catalog in which to store this information, or let RMAN store it exclusively in the target database control file. Although RMAN can conduct all major backup and recovery operations using just the control file, some RMAN commands function only when you use a recovery catalog (see "Consequences of Using the Control File for RMAN Metadata" for a list of the catalog-only commands).
The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file.
See Also: To learn how to manage RMAN metadata, see Chapter 6, "Managing Recovery Manager Metadata".
The recovery catalog is an optional repository of information about your target databases that RMAN uses and maintains. Conveniently, you do not need an additional database for storing the recovery catalog, since you can put the recovery catalog in an existing database. RMAN uses the information in the recovery catalog, which is obtained from the control file, to determine how to execute requested backup and recovery operations.
The recovery catalog contains information about:
See Also: For information about recovery catalog compatibility for different releases of the database, see Oracle8i Migration.
The recovery catalog obtains crucial RMAN metadata from the target database control file. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current.
Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed data, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments (only if the database is open), and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.
When you issue certain commands in RMAN, the program automatically detects when it needs to perform a full or partial resynchronization and executes the operation as needed. You can also force a full resynchronization by issuing a resync catalog command. It is a good idea to run RMAN once a day or so and issue the resync catalog command to ensure that the catalog stays current.
RMAN generates a snapshot control file, which is a temporary backup control file, each time it resynchronizes. This snapshot control file ensures that RMAN has a consistent view of the control file either when refreshing the recovery catalog or when querying the control file. Because the snapshot control file is intended for RMAN's short-term use, it is not registered in the recovery catalog. RMAN records the snapshot control file checkpoint in the recovery catalog to indicate how current the recovery catalog is.
The Oracle8i server ensures that only one RMAN session accesses a snapshot control file at any point in time. This safeguard is necessary to ensure that two RMAN sessions do not interfere with each other's use of the snapshot control file.
|
Note: You can specify the name and location of a snapshot control file. For instructions, see "Determining the Snapshot Control File Location". |
See Also: To learn how to resynchronize the recovery catalog, see "Resynchronizing the Recovery Catalog". For resync catalog syntax, see "resync".
A single recovery catalog is able to store information for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. You should back up the recovery catalog frequently.
Because the recovery catalog resides in an Oracle database, you can use RMAN to back it up by reversing the roles of the recovery catalog database and the target database. In other words, the target database can become the recovery catalog database and the recovery catalog database can be treated as a target database. Several other backup options are available.
If the recovery catalog is destroyed and no backups of it are available, then you can partially reconstruct the catalog from the current control file or control file backups. Nevertheless, you should always aim to have a valid, recent backup of your recovery catalog.
See Also: To learn how to back up the recovery catalog, see "Backing Up the Recovery Catalog".
Because most information in the recovery catalog is also available in the target database's control file, RMAN supports an operational mode in which it uses the target database control file instead of a recovery catalog. This mode is especially appropriate for small databases where installation and administration of another database for the sole purpose of maintaining the recovery catalog is burdensome.
Oracle does not support the following features in this operational mode:
To restore and recover your database without using a recovery catalog, Oracle recommends that you:
See Also: For a complete list of commands that are disabled unless you use a recovery catalog, see "Consequences of Using the Control File for RMAN Metadata".
To utilize tape storage for your database backups, RMAN requires a media manager. A media manager is a utility that loads, labels, and unloads sequential media such as tape drives for the purpose of backing up and recovering data.
Some media management products can manage the entire data movement between Oracle datafiles and the backup devices. Such products may use technologies such as high-speed connections between storage and media subsystems, which can remove much of the backup load from the primary database server.
To use RMAN to make backups to sequential media such as tape, integrate media management software with your Oracle software. Note that Oracle does not need to connect to the media management library (MML) software when it backs up to disk.
Because RMAN uses the same media management API as the Oracle7 Enterprise Backup Utility (EBU), RMAN is compatible with the same media managers as EBU. Check with your media vendor, however, to determine whether the version of the media software you own has been certified to be compatible with RMAN (see "Backup Solutions Program").
Figure 4-4 shows the architecture for a media manager integrated with Oracle.
The Oracle executable is the same used when a user connects to the database. The MML in the diagram above represents vendor-supplied media management software that can interface with Oracle. Oracle calls MML software routines to back up and restore datafiles to and from media controlled by the media manager.
The following Recovery Manager script performs a datafile backup to a tape drive controlled by a media manager:
run { # Allocating a channel of type 'sbt_tape' specifies a media management device allocate channel ch1 type 'sbt_tape'; backup datafile 10; }
When Recovery Manager executes this command, it sends the backup request to the Oracle server session performing the backup. The Oracle server session identifies the output channel as a media management device and requests the media manager to load a tape and write the output.
The media manager labels and keeps track of the tape and names of files on each tape. If your site owns an automated tape library with robotic arm, the media manager will automatically load and unload the tapes required by Oracle; if not, the media manager will request an operator to load a specified tape into the drive.
The media manager handles restore as well as backup operations. When you restore a file, the following steps occur:
Sometimes tapes in the media management library become unavailable. RMAN can perform crosschecks to determine that backup pieces are still available; in this way, the recovery catalog stays synchronized with the media management catalog.
For example, you can issue a crosscheck backup command to check all backups on tape. If RMAN cannot find a particular backup, it will change its status to expired in the RMAN metadata. Issue a list command or access the recovery catalog views to determine the status of backups and copies.
See Also: To learn how to perform crosschecks, see "Crosschecking RMAN Metadata". For crosscheck and change ... crosscheck command syntax, see "crosscheck" and "change".
Oracle has integrated proxy copy functionality into its media management API. Vendors can use this API to develop media management software that takes control of backup and restore operations. RMAN provides a list of files requiring backup or recovery to the media manager, which in turn makes all decisions regarding how and when to move the data.
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 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 a record of each proxy-copied file in the control file. RMAN uses this information to resynchronize the recovery catalog. Access the V$PROXY_DATAFILE and V$PROXY_ARCHIVEDLOG dynamic performance views to obtain the proxy copy information. Use the change ... proxy command to delete or change the status of a proxy backup.
See Also: For more information about V$PROXY_DATAFILE and V$PROXY_ARCHIVEDLOG, see the Oracle8i Reference. For backup command syntax, see "backup".
A new client program, sbttest, is a stand-alone test of the media management software that is linked with Oracle to perform backups to tape. Use it when Oracle is unable to create or restore backups using either the bundled Legato Storage Manager or another vendor's media management product. Only use the sbttest program at the direction of Oracle support.
The Oracle Backup Solutions Program (BSP) provides a range of media management products that are compliant with Oracle's Media Management Library (MML) specification. Software that is compliant with the MML interface enables an Oracle server session to issue commands to the media manager to back up or restore a file. The media manager responds to the command by loading, labeling, or unloading the requested tape.
One MML-compliant product is the Legato Storage Manager (LSM), which is available for several common platforms. Oracle includes the LSM with software that it ships for these platforms. If your version of the Oracle software includes the LSM, refer to the Legato Storage Manager Administrator's Guide to learn about its features. If your shipment includes other BSP media management products, then refer to your platform-specific documentation for information.
Several other products may be available for your platform from media management vendors. For a current list of available products, refer to the BSP web site at:
http://www.oracle.com/st/products/features/backup.html
You can also contact your Oracle representative for a complete list.
If you wish to use a specific media management product, contact the media management vendor directly to determine whether it is a member of the Oracle BSP. Note that Oracle does not certify media vendors for compatibility with RMAN, so any questions about availability, version compatibility, and functionality should be directed to the media vendor, not Oracle.
Use RMAN's report and list commands to gain information about backups and image copies. RMAN obtains the information from your metadata repository: either the control file or the recovery catalog.
The list command lists the contents of RMAN's metadata repository, whereas the report command performs a more detailed analysis. RMAN writes the output from these commands to the screen or to a log file.
The list command queries the recovery catalog or control file and produces a record of its contents. Use it to list:
See Also: To learn how to generate lists of backups and image copies, see "Generating Lists". For reference material on the list command, see "list".
RMAN reports are intended to provide analysis of your backup and recovery situation. An RMAN report can answer questions such as:
Issue the report need backup and report unrecoverable commands regularly to ensure that the necessary backups are available to perform media recovery, as well as to ensure that you can perform media recovery within a reasonable amount of time.
The report command lists backup sets and datafile copies that can be deleted either because they are redundant or because they are unrecoverable. A datafile is considered unrecoverable if an unrecoverable operation has been performed against an object residing in the datafile subsequent to the last backup.
The report command allows you to list orphaned backups. Orphaned backups are backups that are unusable because they belong to incarnations of the database that are not direct ancestors of the current incarnation.
For example, see the incarnation scenario depicted in Figure 4-7:
Incarnation A of the database started at SCN 1. At SCN 10, assume that you performed a RESETLOGS operation and created incarnation B. At SCN 20, you performed another RESETLOGS operation on incarnation B and created a new incarnation C.
The following table explains which backups are orphans depending on which incarnation is current:
See Also: To learn how to generate reports, see "Generating Reports". For reference material on the report command, see "report".
You must allocate a channel before you execute backup and recovery commands. Each allocated channel establishes a connection from RMAN to a target or auxiliary database (either a database created with the duplicate command or a temporary database used in TSPITR) instance by starting a server session on the instance. This server session performs the backup and recovery operations. Only one RMAN session communicates with the allocated server sessions.
The allocate channel command (executed within a run command) and allocate channel for maintenance command (executed 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. Each channel usually corresponds to one output device, unless your media management library is capable of hardware multiplexing.
See Also: For reference material on the allocate channel command, see "allocate". For reference material on the allocate channel for maintenance command, see "allocateForMaint".
Use channel control commands to:
On some platforms, these commands specify the name or type of an I/O device to use. On other platforms, they specify which O/S 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.
Whether the allocate channel command actually causes your O/S to allocate resources is O/S-dependent. Some operating systems allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.
You must allocate a maintenance channel before issuing a change ... delete command, which calls the O/S to delete a file, or a change ... crosscheck command. 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. You can only allocate one maintenance channel at a time.
See Also: For reference material on the set command, see "set". For reference material on the allocate channel for maintenance command, see "allocateForMaint".
You can allocate multiple channels, 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 allocate channel or allocate auxiliary channel command 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 Parallel Server (OPS) configuration for distributing the workload across different nodes.
RMAN internally handles parallelization of backup, copy, and restore commands. You only need to specify:
RMAN executes commands serially; that is, it completes the current command before starting the next one. Parallelism is exploited only within the context of a single command. Consequently, if you want 5 datafile copies, issue a single copy command specifying all 5 copies rather than 5 separate copy commands.
The following RMAN script uses serialization to create the file copies: 5 separate copy commands are used to back up the files. Only one channel is active at any one time.
run { allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; allocate channel c4 type disk; allocate channel c5 type disk; copy datafile 22 to '/dev/prod/backup1/prod_tab5_1.dbf'; copy datafile 23 to '/dev/prod/backup1/prod_tab5_2.dbf'; copy datafile 24 to '/dev/prod/backup1/prod_tab5_3.dbf'; copy datafile 25 to '/dev/prod/backup1/prod_tab5_4.dbf'; copy datafile 26 to '/dev/prod/backup1/prod_tab6_1.dbf'; }
The following statement uses parallelization on the same example; one RMAN copy command copies 5 files, with 5 channels available. All 5 channels are concurrently active--each channel copies one file.
run { allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; allocate channel c4 type disk; allocate channel c5 type disk; copy datafile 5 to '/dev/prod/backup1/prod_tab5_1.dbf', datafile 23 to '/dev/prod/backup1/prod_tab5_2.dbf', datafile 24 to '/dev/prod/backup1/prod_tab5_3.dbf', datafile 25 to '/dev/prod/backup1/prod_tab5_4.dbf', datafile 26 to '/dev/prod/backup1/prod_tab6_1.dbf'; }
See Also: For information about parallelization in an OPS configuration, see Oracle8i Parallel Server Concepts and Administration.
When you execute the backup command, you create one or more backup sets. A backup set, which is a logical construction, contains one or more physical backup pieces. Backup pieces are O/S files that contain the backed up datafiles, control files, or archived redo logs. You cannot split a file across different backup sets or mix archived redo logs and datafiles into a single backup set.
A backup set is a complete set of backup pieces that constitute a full or incremental backup of the objects specified in the backup command. Backup sets are in an RMAN-specific format; image copies, in contrast, are available for use without additional processing.
When backing up files, the target database must be mounted or open. If the database is mounted and was not shut down abnormally prior to mounting, then RMAN produces a consistent backup. The control file must be current.
If the database is in ARCHIVELOG mode, then the target database can be open or closed; you do not need to close the database cleanly (although Oracle recommends you do so that the backup is consistent). If the database is in NOARCHIVELOG mode, then you must close it cleanly prior to taking a backup.
This section contains the following topics:
See Also: To learn how to make backups, see Chapter 8, "Making Backups and Copies with Recovery Manager". For information on the backup command, see "backup".
RMAN can create backup sets that are written to disk or tertiary storage. If you specify 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 a valid backup pathname.
Using a sequential output device or media management system that is available and supported by Oracle on your operating system, you can write backup sets to sequential output media such as magnetic tape. If you specify type 'sbt_tape', then you can back up to any media supported by the media management software.
Note that you cannot archive directly to tape, but RMAN does allow you to back up archived redo logs from disk to tape. If you specify the delete input option, RMAN deletes the file after backing it up. RMAN automatically stages the required archived logs from tape to disk during recovery.
RMAN performs compression on its backups, which means that the server session does not write datafile blocks that have never been used. Image copies of a datafile, however, always contain all datafile blocks.
Data blocks in the datafile are grouped into buffers. When RMAN encounters a used data block in a buffer, it writes only the used block to the backup set. When RMAN encounters four contiguous buffers of unused input blocks, it writes one compression block (of size DB_BLOCK_SIZE) to the backup set.
Use the DB_FILE_DIRECT_IO_COUNT initialization parameter to set the size of the buffer. For example, set the parameter to a value of 64K. In this case, RMAN writes one compression block for each 256K of contiguous unused input blocks in the input file.
You can either let RMAN determine a unique name for the backup piece or use the format parameter to specify a name. If you do not specify a filename, RMAN uses the %U substitution variable to guarantee a unique name. The backup command provides substitution variables that allow you to generate unique filenames.
See Also: For reference material on the format parameter and the substitution variables of the backup command, see "backup".
Each backup set contains at least one backup piece. If you are writing to disk, use the setsize operand of the backup command to restrict the size of a backup piece to the maximum file size supported by your media manager or O/S. If you do not restrict this size, Oracle will generate a backup set containing only one file.
RMAN writes the pieces of a backup set serially; striping a backup set across multiple output devices is not supported. If multiple output devices are available, you can partition your backups so that Oracle creates multiple backup sets in parallel. RMAN can perform this backup partitioning automatically.
See Also: For information on the setsize parameter, see "backup".
Use the backupSpec clause to list what you want to back up as well as specify other useful options. The number of backup sets that RMAN produces depends on:
Each backupSpec clause produces at least one backup set. If the number of input files specified or implied in a backupSpec clause exceeds the filesperset limit, then RMAN produces multiple backup sets. If you do not specify a filesperset limit, then each backupSpec produces exactly one backup set.
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 that are contained in a backup set, the faster one of them can be restored, since 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: To learn about the backupSpec clause, see "backup".
Oracle takes the datafile blocks included in the same backup set and multiplexes them, which means that the data blocks from all of the datafiles in the backup set are interspersed with one another. As Figure 4-11 illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece; this backup piece is constituted by the intermingled block components of the three input files.
Use the filesperset parameter to control the number of datafiles that Oracle backs up concurrently to a backup set. Controlling concurrency is helpful when you want to keep a tape device streaming without saturating a single datafile with too many read requests, since these requests can subsequently degrade online performance. Limit the read rate by using the readrate option of the set limit channel command.
When multiplexing files, you can:
See Also: To learn how to tune backup performance, see Oracle8i Tuning. To learn how to multiplex backups, see "Multiplexing Datafiles in a Backup".
For reference material on the filesperset parameter of the backup command, see "backup". For reference material on the set option of the run command, see "set_run_option".
RMAN provides an efficient way to produce multiple copies of an archived redo log or datafile backup set. Create up to four identical copies of a backup set by issuing the set duplex command.
You should not confuse multiplexing, which is combining multiple input files into a single backup set, with duplexing, which is the output of two or more identical backup sets. RMAN allows you to multiplex your input files and duplex the output.
See Also: To learn how to duplex backups, see "Duplexing Backup Sets". For reference material on the set duplex command, see "set_run_option".
If you want to create multiple backup sets and allocate multiple channels, then RMAN automatically parallelizes its operation and writes multiple backup sets in parallel. The allocated server sessions divide up the work of backing up the specified files.
RMAN automatically assigns a backup set to a device. You can specify that Oracle should write all backup sets for a backupSpec to a specific channel using the channel parameter, as in the following example:
run { allocate channel ch1 type disk; allocate channel ch2 type disk; allocate channel ch3 type disk; backup (datafile 1,2,3 filesperset = 1 channel ch1) (controlfilecopy '/oracle/copy/cf.f' filesperset = 1 channel ch2) (archivelog all filesperset = 3 channel ch3); }
Table 4-13 show an example of parallelization in which channel 1 backs up datafiles, channel 2 backs up datafile copies, and channel 3 backs up archived redo logs.
See Also: For an overview of how allocated channels affect parallelization, see "Channel Parallelization". To learn how to parallelize backups, see "Parallelizing Backup Sets". For reference material on the channel parameter of the backup command, see "backup".
RMAN is equipped to handle the two primary types of backup errors: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces cause the system to abort the jobs. RMAN will need to rewrite the backup sets that it was writing at the time of the error, but it retains any backup sets that it successfully wrote prior to the abort.
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, 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 control file records through the V$BACKUP_CORRUPTION view.
Use the set maxcorrupt command to limit the number of previously undetected block corruptions that Oracle allows in a specified datafile or list of datafiles. If a backup or copy command detects more than this number of corruptions, then the command aborts. The default limit is zero, meaning that RMAN will not tolerate any corrupt blocks.
See Also: For more information about fractured and corrupt blocks, see "Integrity Checks". For more information on V$BACKUP_CORRUPTION, see the Oracle8i Reference. For reference information on set maxcorrupt, see "set_run_option".
Recovery Manager allows you to control the type of backups you produce. RMAN backups can be classified in these ways:
A full backup reads the entire file and copies all blocks into the backup set, skipping only datafile blocks that have never been used. The server session does not skip blocks when backing up archived redo logs or control files.
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.
Oracle allows you to create and restore full backups of the following:
Note that backup sets containing archived redo logs are always full backups.
An incremental backup reads the entire file and then backs up only those data blocks that have changed since a previous backup. Oracle allows you to create and restore 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.
The primary reasons for making an incremental backup are:
If none of these criteria apply, then full backups are usually preferable because the application of the incremental backup increases recovery time while the cost savings is negligible.
This section contains the following topics:
RMAN allows you to create multi-level incremental backups. Each incremental level is denoted by an integer, e.g., 0, 1, 2, etc. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. When you generate a level n incremental backup in which n is greater than 0, you back up:
The benefit of performing multi-level incremental backups is that you do not back up all of the blocks all of the time. Since RMAN needs to read all of the blocks of the datafile, full backups and incremental backups taking approximately the same amount of time (assuming that the output of the backup is not a bottleneck).
Incremental backups at levels greater than 0 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 an SCN, which is the SCN at which the last 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. The parent backup is the backup that RMAN uses for comparing the SCNs, so the parent can be a level 0 backup or, depending on the incremental level, a level 1 or level 2 backup. If the SCN in the input data block is greater than the checkpoint SCN of the parent, then RMAN copies the block.
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 since that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup. Incremental backups are differential by default.
In the example above:
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.
An 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.
An 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 only the blocks changed since the Sunday level 0 backup will be backed up.
An 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.
An 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 above:
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 2-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 2-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 2-1 or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up. (This backup includes those which 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 1-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 2-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 2-1 or less is the level 1 Thursday backup, so all the blocks changed since Thursday will be backed up.
Choose your backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a 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 will never have to apply more than a day's worth of redo for complete recovery.
When deciding how often to take 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 your differential or cumulative backups to your 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.
RMAN performs backup operations only when an instance has the database mounted or open. In an Oracle parallel server environment, if the instance where the backup operation is being performed does not have the database open, then the database must not be open by any instance.
RMAN supports tablespace, datafile, archived redo log, and control file backups. It does not back up:
See Also: For more information about backup constraints in a parallel server environment, see Oracle8i Parallel Server Concepts and Administration.
An image copy contains a single datafile, archived redo log file, or control file that you can use as-is to perform recovery. Use the RMAN copy command or an O/S command such as the UNIX cp command to create image copies.
An image copy produced with the RMAN copy command is similar to an O/S 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 registering 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.
Use the RMAN copy command to create an image copy. If the original file needs to be replaced, and if the image copy is of a datafile, then you do not need to restore the copy. Instead, Oracle provides a switch command to point the control file at the copy and update the recovery catalog 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 media recovery to make the copy current.
RMAN can catalog an image copy and read the metadata. 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 O/S copies. For example, a copy of a datafile that you make with the UNIX cp command is an O/S copy. You must catalog such O/S copies with RMAN before using them with the restore or switch commands.
You can create an O/S copy when the database is open or closed. If the database is open and the datafile is not offline normal, then you must place the tablespace in hot backup mode, i.e., issue the SQL statement ALTER TABLESPACE BEGIN BACKUP before creating the copy.
|
WARNING: If you do not put a tablespace in hot backup mode before making an online backup, Oracle can generate fractured blocks. See "Detection of Logical Block Corruption". |
Some sites store their datafiles on mirrored disk volumes, which permits the creation of image copies by breaking the mirrors. After you have broken the mirror, you can notify RMAN of the existence of a new O/S 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, if the mirror is resilvered (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: To learn how to catalog copies, see "How Do You Catalog an O/S Backup?". For reference material on the change command, see "change".
You can assign a user-specified character string called a tag to backup sets and image copies (either RMAN-created copies or O/S-created copies). A tag is a symbolic name for a backup set or file copy such as weekly_backup; you can specify the tag rather than the filename when executing the restore or change command. The maximum length of a tag is 30 characters.
Tags do not need to be unique: multiple backup sets or image copies can have the same tag. When a tag is not unique, then with respect to a given datafile, the tag refers to the most current suitable file. By default, Recovery Manager 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. Thus, 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.
See Also: For reference information on the switch and restore commands, see Chapter 11, "Recovery Manager Command Syntax".
Use the RMAN restore command to restore datafiles, control files, and archived redo logs from backup sets or image copies on disk. Because a backup set is in an Oracle proprietary format, you cannot simply import it; you must use the RMAN restore command to extract it. In contrast, Oracle can use image copies created using RMAN without additional processing.
You can restore:
RMAN completely automates the procedure for restoring files. You do not need to go into the O/S, locate the backup or copy that you want to use, and manually copy files into the appropriate directories. RMAN directs a server session to restore the correct backups and copies to either:
See Also: To learn how to restore backup sets and copies, see "Restoring Datafiles, Control Files, and Archived Redo Logs". For reference material on the restore command, see "restore".
RMAN uses the recovery catalog (or target database control file if no recovery catalog is available) to select the best available backup sets or image copies for use in the restore operation. It gives preference to image copies rather than backup sets. When multiple choices are available, RMAN uses the most current backup sets or copies, taking into account whether you specified the untilClause.
All specifications of the restore command must be satisfied before RMAN restores a backup set or file copy. The restore command also considers the device types of the allocated channels when performing automatic selection.
If no available backup or copy in the recovery catalog satisfies all the specified criteria, then RMAN returns an error during the compilation phase of the restore job. If the file cannot be restored because no backup sets or datafile copies reside on media compatible with the device types allocated in the job, then create a new job specifying channels for devices that are compatible with the existing backup sets or datafile copies.
Note the following constraints on the restore command:
Media recovery is the application of online or archived redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time. Use the RMAN recover command to perform media recovery and apply incremental backups automatically. You can only recover current datafiles.
If possible, make the recovery catalog available to perform the media recovery. If it is not available, then RMAN uses information from the target database control file. Note that if control file recovery is required, then you must make the recovery catalog available. RMAN cannot operate when neither the recovery catalog nor the target database control file is available.
The generic steps for media recovery using RMAN are:
See Chapter 9, "Restoring and Recovering with Recovery Manager" for detailed restore and recovery procedures.
See Also: To learn how to recover datafiles, see "Recovering Datafiles". For reference material on the recover command, see "recover".
If RMAN has a choice between applying an incremental backup or applying redo to the restored datafiles, then it always chooses to use the incremental backup. If over-lapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.
If RMAN cannot find an incremental backup, it looks for an archived redo log. Whenever ARCn archives a redo log, Oracle immediately records it in the control file. Recovery Manager propagates that information into the recovery catalog during resynchronization, classifying archived redo logs as image copies. Use the list command to display them.
During recovery, RMAN looks for the appropriate archived redo logs in the default locations specified in the parameter file. If it cannot find them anywhere on disk, it looks in backup sets and restores archived redo logs as needed to perform the media recovery.
By default, RMAN restores the archived redo logs to the current log archive destination specified in the init.ora file. Use the set archivelog destination command to specify a different restore location.
See Also: For set archivelog destination syntax, see "set_run_option".
RMAN can perform either complete or incomplete recovery. Using the set until command, you can specify a time, SCN, or log sequence number as a limit for incomplete recovery. Typically, you use this command before issuing the restore and recover commands. After performing incomplete recovery, always open the database with the RESETLOGS option and then immediately back up the database.
Recovery Manager automated Tablespace Point-in-Time Recovery (TSPITR) enables you to recover one or more tablespaces to a point-in-time that is different from that of the rest of the database. RMAN TSPITR is most useful in these situations:
Similar to a table export, RMAN TSPITR enables you to recover a consistent data set; however, the data set is the entire tablespace rather than just one object.
See Also: To learn how to perform TSPITR using RMAN, see Appendix A, "Performing Tablespace Point-in-Time Recovery with Recovery Manager".
Use the RMAN duplicate command to create a test database on which to practice your backup and recovery procedures. The command takes backup sets located on disk of your primary database's files and uses them to create a new database. A test database is especially useful if your production database must be up and running 24 hours per day, 7 days a week.
As part of the duplicating operation, RMAN manages the following:
Note also the following features of RMAN duplication. You can:
The method you use to duplicate your database depends on whether you are creating your duplicate database on the same or a different host and whether the duplicate directory structure is the same as your target database filesystem. For example, in some cases you can keep the same directory structure and filenames in your duplicate database, while in other cases you must reset the filenames using set newname commands, the DB_FILE_NAME_CONVERT initialization parameter, or both.
See Also: To learn how to make a duplicate database, see Chapter 10, "Creating a Duplicate Database with Recovery Manager". For duplicate command syntax, see "duplicate".
Oracle prohibits any attempts to perform operations that will result in unusable backup files or corrupt restored datafiles. Oracle performs integrity checks to:
Because an Oracle server session is performing backup and copy operations, the server session is able to detect many types of 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.
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 RMAN 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.
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 can test data and index blocks that pass physical corruption checks for logical corruption, e.g., corruption of a row piece or index entry. If RMAN finds logical corruption, it logs the block in the alert.log and server session trace file.
Provided the sum of physical and logical corruptions detected for a file remain 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.
When performing open backups without using Recovery Manager, you must put tablespaces in hot backup mode in case the operating system reads a block for a backup that is currently being written by DBWn, and is thus inconsistent. Thus, the block is a fractured block.
When performing a backup using RMAN, an Oracle server session reads the datafiles, not an operating system utility. The Oracle server session reads whole Oracle blocks and checks to see whether the block is fractured by comparing control information stored in the header and footer of each block. If the session detects a fractured block, then it re-reads the block. For this reason, do not put tablespaces into hot backup mode when using Recovery Manager to back up or copy database files.
See Also: For information about hot backup mode, see "Backing Up Online Tablespaces and Datafiles".
