Release 2 (9.2)
Part Number A96566-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Recovery Manager User's Guide Release 2 (9.2) Part Number A96566-01 |
|
This chapter describes the Recovery Manager (RMAN) interface and the basic elements of the RMAN environment.
This chapter contains these topics:
| See Also:
Oracle9i Database Migration for information about RMAN compatibility and upgrade issues |
This section contains these topics:
Recovery Manager (RMAN) is a client application that performs backup and recovery operations. The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy.
The RMAN environment can be as simple as an RMAN executable connecting to a target database, or as complex as an RMAN executable connecting to multiple media managers and multiple target, recovery catalog, and auxiliary databases, all accessed through Oracle Enterprise Manager. Table 4-1 lists possible components of the RMAN environment.
As the table illustrates, the only required components in an RMAN environment are the target database and the RMAN executable. Nevertheless, most real-world configurations are more complicated.
Figure 4-1 depicts an example of a realistic RMAN environment. In this environment, five nodes are networked together, with each machine serving a different purpose. The five nodes share duties as follows:
In this scenario, you can run the RMAN executable from a client machine, and then connect to the target, catalog, and auxiliary databases. You can then run backup and recovery jobs. You can also connect to the client hosting Oracle Enterprise Manager and use the GUI interface to access RMAN.
The RMAN client application directs database server sessions to perform all backup and recovery tasks. The meaning of "session" in this sense depends on the operating system. For example, on a UNIX system a server session corresponds to a server process. On a Windows NT system, an server session corresponds to a thread within the Oracle service.
When you connect the RMAN client to the target database server, RMAN allocates server sessions on the target instance and directs them to perform the backup and recovery operations. The RMAN client itself does not perform the backup, restore, or recovery.
Because RMAN manages backup and recovery operations, it requires a place to store necessary information about the database. RMAN always stores this information in the target database control file. You can also store RMAN metadata in a recovery catalog schema contained in a separate database. The recovery catalog schema must be stored in a database other than the target database. RMAN periodically migrates information from the control file to the recovery catalog.
Use the RMAN interface to enter commands that you can use to manage all aspects of backup and recovery operations.
This section contains these topics:
| See Also:
Oracle9i Recovery Manager Reference for a complete description of RMAN commands and their syntax |
The RMAN executable uses PL/SQL packages to communicate with the target database and recovery catalog. The packages are internal and undocumented.
RMAN processes most commands in the two phases discussed in this section:
During the compilation phase, RMAN determines which objects the command will access by, for example, translating a TABLESPACE keyword into the names of its component datafiles. Then, RMAN constructs a sequence of remote procedure calls (RPCs) that instruct the target database to perform the desired operation, such as backing up, restoring, or recovering datafiles.
During the execution phase, RMAN sends the RPC calls to the target database, monitors their progress, and collects the results. If more than one channel is allocated, then RMAN can execute certain commands in parallel so that all of the channels' target database sessions are concurrently executing an RPC call. RMAN coordinates this parallel execution and monitors the progress on all channels that are doing work.
RMAN commands can be divided in this way:
RUN commandRUN commandBesides these commands, RMAN also supports a number of command-line arguments that you can specify when you start RMAN.
| See Also:
Oracle9i Recovery Manager Reference for a complete description of RMAN commands and command-line options |
Unlike job commands, standalone commands cannot appear as subcommands within RUN. Following are some of the commands that you must use on the RMAN prompt:
CONNECTCONFIGURECREATE CATALOG, DROP CATALOG, UPGRADE CATALOGCREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPTLISTREPORT
| See Also:
Syntax entries in Oracle9i Recovery Manager Reference to determine which must be executed at the RMAN prompt |
Unlike standalone 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, then 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:
Oracle9i Recovery Manager Reference to learn about |
Although some commands are either standalone commands or job commands exclusively, other commands can be issued either at the prompt or within a RUN command. Whether issued at the prompt or within RUN, the commands can make use of automatic channels. Note that you can manually allocate channels only within a RUN command, and in this case the manually allocated channels override any configured automatic channels.
The following are examples of commands that can function as both standalone and job commands:
RMAN uses a command language interpreter (CLI) that can 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.
| See Also:
"Terminating an RMAN Command" to learn how to end an RMAN session |
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/oracle@trgt CATALOG rman/cat@catdb
After the RMAN prompt is displayed, you can enter commands such as the following:
RMAN> BACKUP DATABASE;
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 must 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). Batch mode is most suitable for performing regularly scheduled backups through an operating system job control facility.
In this example, a sample RMAN script is placed into a command file called b_l0.rcv. You can run this file from the operating system command line and write the output into the log file log.f as follows:
% rman TARGET / CATALOG rman/cat@catdb CMDFILE b_l0.rcv LOG log.f
| See Also:
Oracle9i Recovery Manager Reference for more information about RMAN command line options |
A stored script is a block of RMAN job commands that is stored in the recovery catalog. Stored scripts allow you to plan, develop, and test commands for backing up, restoring, or recovering the database. Also, scripts minimize the potential for user errors. Note that each stored script relates to one and only one target database.
To create a stored script, either enter the script interactively into the RMAN command-line interface, or enter the RMAN commands into a command file and run the file. You must be connected to a target database and recovery catalog.
Following is an example of a stored script:
REPLACE SCRIPT b_whole_l0 { # back up whole database and archived logs BACKUP INCREMENTAL LEVEL 0 TAG b_whole_l0 FILESPERSET 6 DATABASE PLUS ARCHIVELOG; }
You can execute this stored script from the RMAN prompt as follows:
RUN { EXECUTE SCRIPT b_whole_10 };
View 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:
"Managing RMAN Scripts Stored in the Recovery Catalog" for more on stored scripts. Also see to the sample scripts in the |
The RMAN pipe interface is an alternative method for issuing commands to RMAN and receiving the output from those commands. With this interface, RMAN obtains commands and sends output by using the DBMS_PIPE PL/SQL package. RMAN does not read or write any data using the operating system shell. By using this interface, it is possible to write a portable programmatic interface to RMAN.
The pipe interface is invoked by using the PIPE command-line parameter. RMAN uses two private pipes: one for receiving commands and the other for sending output. The names of the pipes are derived from the value of the PIPE parameter. For example, you can invoke RMAN with the following command:
% rman PIPE abc TARGET SYS/oracle@trgt
RMAN opens the following pipes in the target database:
ORA$RMAN_ABC_IN, which RMAN uses to receive user commandsORA$RMAN_ABC_OUT, which RMAN uses to send all outputAll messages on both the input and output pipes are of type VARCHAR2.
Note that RMAN does not permit the pipe interface to be used with public pipes, because they are a potential security problem. With a public pipe, any user who knows the name of the pipe can send commands to RMAN and intercept its output.
| See Also:
"Executing RMAN Commands Through a Pipe" to learn how to execute RMAN commands through a pipe |
Use the Run RMAN Script feature to issue any command or script within Oracle Enterprise Manager that can also be called from the RMAN command line. The rman script will be run as a job through the Oracle Enterprise Manager Job System when you submit or schedule it.
Oracle Enterprise Manager's Job System enables the automation of standard and administrative tasks. With the Job System, you can create and manage jobs, schedule their execution, and view and share information about defined jobs with other administrators.
The RMAN repository is the collection of metadata about the 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.
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:
Chapter 16, "Managing the Recovery Manager Repository" to learn how to manage the RMAN repository, and "Understanding Catalog-Only Command Restrictions" for a list of catalog-only commands |
The recovery catalog is an optional repository of information about the target databases that RMAN uses and maintains. It is recommended that you store the catalog in a dedicated 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.
This section contains these topics:
The enrolling of a database in a recovery catalog is called registration. You can register more than one target database in the same recovery catalog. For example, you can register databases prod1, prod2, and prod3 in a single catalog owned by catowner in the database catdb. You can register a database only once in a given catalog schema: for example, you cannot register prod1 in the catowner schema and then register prod1 again in the catowner schema.
Because RMAN distinguishes databases by unique database identifier (DBID), each database registered in a given catalog must have a DBID. You cannot register two databases with the same DBID in the same catalog. For example, you cannot register database prod1 with DBID 862893450 and database prod2 with DBID 862893450 in the same catalog. However, each database does not have to have a unique database name. For example, you can register database prod1 with DBID 862893450 and a different database called prod1 with DBID 951781249 in the same recovery catalog.
If you use operating system commands to copy a database, then the copied database has the same DBID as the original database. Thus, you cannot copy a database manually and then register it in the same catalog with its parent unless you change the DBID of the copied database. For this reason, it is easiest to use the DUPLICATE command to create a copied database because RMAN automatically gives the copied database a different DBID. You can also use the DBNEWID utility to change the DBID (or the database name) of any Oracle database. DBNEWID is useful when you have already created multiple databases with the same DBID and you now want to register them all in the same recovery catalog.
| See Also:
Oracle9i Database Utilities to learn how to use the DBNEWID utility to change the DBID of a database |
The recovery catalog contains information about RMAN operations, including:
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, and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.
RMAN 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, which you should do in the cases described in "When Should You Resynchronize?".
To ensure that the catalog stays current, run the RESYNC CATALOG command periodically. A good rule of thumb is to run it at least once every n days, where n is the setting for the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME. Because the control file employs a circular reuse system, backup and copy records eventually get overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and so are not lost.
| See Also:
"Types of Records in the Control File" for more information about control file records |
RMAN generates a snapshot control file, which is a temporary backup control file, each time it performs a full resynchronization. This snapshot control file ensures that RMAN has a consistent view of 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 the currency of the recovery catalog.
The Oracle9i 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 the snapshot control file. For instructions, refer to "Configuring the Snapshot Control File Location". |
| See Also:
"Managing the Control File When You Use a Recovery Catalog" to learn how to resynchronize the recovery catalog, and Oracle9i Recovery Manager Reference for syntax |
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.
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 the catalog.
| See Also:
"Backing Up the Recovery Catalog" to learn how to back up the recovery catalog |
When you use RMAN with a recovery catalog, the RMAN environment contains the following components:
Each of these components has a release number associated with it. For example, you can use a release 8.0.6.1 RMAN executable with a release 8.1.6 target database, and store the repository in a release 8.1.5 recovery catalog database whose catalog schema was created in release 8.1.6.
| See Also:
Oracle9i Recovery Manager Reference for a chart describing the compatibility of the components in the RMAN environment |
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 a separate recovery catalog database is burdensome. The only RMAN feature that is not supported in NOCATALOG mode is stored scripts.
When you do not use a recovery catalog, the control file is the exclusive source of information about backups and copies as well as other relevant information. The control file contains two types of records: circular reuse records and noncircular reuse records.
Circular reuse records contain noncritical information that is eligible to be overwritten if the need arises. These records contain information that is continually generated by the database. Some examples of information circular reuse records include:
Circular reuse records are arranged in a logical ring. When all available record slots are full, Oracle either expands the control file to make room for a new record or overwrites the oldest record. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in days of a record before it can be reused.
| See Also:
"Monitoring the Overwriting of Control File Records" to learn how to manage Oracle's treatment of circular reuse records |
Noncircular reuse records contain critical information that does not change often and cannot be overwritten. Some examples of information in noncircular reuse records include datafiles, online redo logs, and redo threads.
To restore and recover the database without using a recovery catalog, Oracle recommends that you:
If you lose the current control files, then you can restore a control file autobackup even if you do not use a recovery catalog.
See Also:
|
To use tape storage for 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 backing up and recovering data.
Oracle publishes a media management API that third-party vendors can use to build software that works with RMAN. 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.
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.
The following RMAN command performs a datafile backup to tape:
BACKUP DEVICE TYPE sbt DATAFILE 1;
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 makes a request to the media manager to 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, then the media manager automatically loads and unloads the tapes required by Oracle; if not, the media manager requests 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:
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 restore to the media manager, which in turn makes all decisions regarding how and when to move the data.
A client program, sbttest, is a standalone 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 a vendor's media management product. Only use the sbttest program at the direction of Oracle support.
The Oracle Backup Solutions Program (BSP), part of the Oracle Partner Program, is a group of leading media management software vendors whose products are compliant with Oracle's MML specification. Software that is compliant with the MML interface enables an Oracle server session to back up to a media manager and request the media manager to restore backups.
Note that RMAN does not issue specific commands to load, label, or unload tapes. When backing up, RMAN gives the media manager a stream of bytes and associates a unique name with that stream. When RMAN needs to restore the backup, it asks the media manager to retrieve the identical byte stream. All details of how and where that stream is stored are handled entirely by the media manager.
Several products may be available for your platform from media management vendors. For a current list of available products, you can access the Backup Solutions Program Web site at:
http://otn.oracle.com/deploy/availability
You can also contact your Oracle representative for a complete list.
To use a specific media management product, contact the media management vendor directly to determine whether it is a member of Oracle BSP. Note that Oracle Corporation 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 Corporation.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|