10< i>g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
10< i>g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
This chapter describes the Recovery Manager (RMAN) interface and t he basic components of the RMAN environment.
This chapter contains these topics:
Recovery Manager (RMAN) is a client application that performs backup and recovery operations. The
Table 1-1 lists po ssible components of the RMAN environment.
The only required components in an RMAN environment are the target database and the RMAN client, but most real-world configurations are more complicated. One might use an RMAN client connecting to multiple media managers and multiple target, recovery catalog, and auxiliary databases, all accessed through Enterprise Manager.
The RMAN client application directs database server sessions to perfor m all backup and recovery tasks. The meaning of "session" in this sense depends on the operating system. For example, on UNIX, a serv er session corresponds to a server process, while on Windows it corresponds to a thread within the database service.
The RMAN client itself does not perform backup, restore, or recovery operations. When you connect the RMAN client to a target database, RMAN allocates server sessions on the target instance and directs them to perform the operations. The RM AN client uses internal, undocumented PL/SQL packages to communicate with the target database and recovery catalog.
Use the RMAN command line client to enter comm ands that you can use to manage all aspects of backup and recovery operations.
Even when yo u use the backup and recovery features in Enterprise Manager that are built on top of RMAN, an RMAN client executes behind the scenes .
RMAN processes most commands in the two phases discussed in this section:
During the compilation phase, RMAN determines which objects the command will access (for example, resolving a tablespace n ame into its component datafiles). Then, RMAN constructs a sequence of remote procedure calls (RPCs) that instruct the server session s on the target database to perform the desired operation.
Du ring 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 sessi ons are concurrently executing an RPC call.
RMAN uses a command language interpreter (CLI) that can execute commands in interactive or batch mode.
To run RMAN commands interactively, start RMAN and then type commands into the co mmand-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;
A command file is a text file which contains RMAN commands as you would enter them at the co mmand line. You can run the a command file by specifying its name on the command line. The contents of the command file will be inter preted as if entered at the command line. If the LOG command line argument is specified, RMAN directs output to the named log file. C ommand files are one way to automate scheduled backups through an operating system job control facility.
In this example, a sample RMAN script is placed into a command file called commandfile.rcv. You can run th
is file from the operating system command line and write the output into the log file outfile.txt as follows:
% rman TARGET / CATALOG rman/cat@catdb CMDFILE commandfile.rcv LOG outfile.txt
| See Also:
Oracle Database Recov ery Manager Reference for more information about RMAN command line options |
A stored script is a block of RMAN job commands t hat is stored in the recovery catalog. By storing scripts in the recovery catalog, the script is available to any RMAN client that co nnects to the catalog and the target database. Stored scripts can be associated with a single database in the catalog, or they can be global stored scripts, which can be executed against any target database in the catalog.
| See Also:
"Working with RMAN Stored Scripts in the Recovery Catalog"<
/a> for more on stored scripts. Also refer to the sample scripts in the |
There are RMAN commands which are only vali
d in RUN blocks. These typically involve setting up the environment within which the statements in the RUN block will execute. Typica
l of this group are ALLOCATE CHANNEL and SET NEWNAME FOR DATAFILE. Using these commands outsid
e of a RUN block will generate an error.
| See Also:<
/font>
The syntax diagrams for the RUN command in Oracle Database Recovery Manager Reference regarding which command s are valid in RUN blocks |
There are a number of RMAN commands which cannot be used in RUN blocks. Typically these are used to control the RMAN environment (connecting to different databases, or configuring RMAN defaults), or to manage or query the recovery catalog (including creating and using stored scripts). Here are some examples:
CONFIGURECREATE CATALOG, DROP CATALOG, UPGRADE CATA
LOGCREATE SCRIPT, DELETE SCRIPT, REPLA
CE SCRIPTLISTREPORTYou can include these commands inside command files, as long as they are not wrapped inside a RUN block. You cannot use them inside a stored script from the recovery catalog, because the contents of a stored script are executed within a RUN block.
| See Also:
The syntax diagrams for the RUN command in Oracle Database Recovery Manag er Reference regarding which commands are valid in RUN blocks |
When you run RMAN in command line mode, it sends the output to the terminal. If
you specify the LOG option, then RMAN writes the output to a specified log file instead.
Output for currently executing RMAN jobs is also stored in the V$RMAN_OUTPUT view, which reads only from memo
ry (that is, the information is not stored in the control file). The V$RMAN_STATUS view stores metadata about jobs in pr
ogress as well as completed jobs. The metadata for completed jobs is stored in the control file.
The RMAN repository is the collection of metadata about the target databases that RMAN uses for backup, recovery, and mai ntenance. RMAN always stores this information in records in the control file. The version of this information in the control file is the authoritative record of RMAN's backups of your database. This is one reason why protecting your control file is a important part of your backup strategy. RMAN can conduct all necessary backup and recovery operations using just the control file to store the RMAN repository information, and maintains all records necessary to meet your configured retention policy.
You can also create a recovery catalog, an external Oracle database in which to stor e this information. The control file has finite space for records of backup activities, while a recovery catalog can store a much lon ger history. The added complexity of operating a recovery catalog database can be offset by the convenience of having the extended ba ckup history available if you have to do a recovery that goes further back in time than the history in the control file.
There are also a few features of RMAN that only function when you use a recovery catalog. For example, RMAN stored scripts are stored in the recovery catalog, so commands related to them require the use of a recovery catalog. Other RMAN commands are specifically related to managing the recovery catalog and so are not available (and not needed) if RMAN is not connecte d to a recovery catalog.
The recovery catalog's version of the RMAN repository is maintaine d solely by RMAN. The target instance 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 after any operation tha t updates the repository, and also before certain operations.
| See Also:
Oracle Database Backup and Recovery Basics for details on how to mana ge the RMAN repository, and Chapter 13, "Managing the Recovery Catalog" to learn more about f eatures specific to the recovery catalog |
It is recommended that you store the recovery catalog in a dedicated database. If you stor e the recovery catalog alongside other data in some other database, then if you lose that other database you will lose your recovery catalog as well. This will make your recovery more difficult.
The enrolling of a database in a recovery catalog is called registrat
ion. You can register more than one target database in the same recovery catalog. For example, you can register databases prod2, and prod3 in a single catalog owned by catowner in the database catdb. Because RMAN distinguishes databases by unique database identifier (DBID), each database registered in a given catalog
must have a unique DBID.
| See Also:<
/strong>
"Registering a Database in the Recovery Catalog" , and Orac le Database Utilities to learn how to use the DBNEWID utility to change the DBID of a database |
The recovery catalog contains information about R MAN operations, including:
The recovery catalog obtains crucial RMAN metada ta 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.
| See Also:
"Types of Records in the Control File" for more information about control file records, and < a href="rcmrepos.htm#1013661">"When Should You Resynchronize?" |
RMAN creates a snapshot control f ile, which is a temporary backup control file, in an operating system specific location each time it performs a full resynch ronization. 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 checkpoi nt in the recovery catalog to indicate the currency of the recovery catalog.
The database s erver 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 na me and location of the snapshot control file. For instructions, refer to "Setting the Snapshot Control File Location". |
| See Also:
"Managing the Control File When You Use a Recovery Catalog" to learn how to resynch ronize the recovery catalog, and Oracle Database Recovery Manager Reference for syntax |
A single recovery catalog is able to store information for multiple target databases. Co nsequently, 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 in an environment where you have run past version s of the Oracle database, you can wind up with versions of the RMAN client, recovery catalog database, recovery catalog schema, and t arget database that all originated in different releases of the database. You will find a compatibility matrix in Oracle Database Recovery Manager Reference t hat describes supported interoperability scenarios.
Because most information in the recovery catalog is also available in the target da
tabase's control file, RMAN supports an operational mode in which it uses the target database control file instead of a recovery cata
log. This mode is especially appropriate for small databases where installation and administration of a separate recovery catalog dat
abase 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 i s the exclusive source of information about backups and copies as well as other relevant information. The control file contains two t ypes of records: circular reuse records and noncircular reuse reco rds.
Circular reuse records contain noncritic
al information that is eligible to be overwritten if the need arises. These records contain information that is continually generated
by the database. Circular reuse records are arranged in a logical ring. When all available record slots are full, the database eithe
r 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.
| <
/a>See Also:
Oracle Database Backup and Recovery Basi cs to learn how to manage the handling 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 thread s.
To make it easier to restore and recov er the database without using a recovery catalog, Oracle Corporation recommends that you:
If you lose the current contr ol files, then you can restore a control file autobackup even if you do not use a recovery catalog.
| <
/a>See Also:
"Control File and Server Parameter File Autobackups" to learn about disaster recovery using control file autobackups |
Oracle Corporation's Media Management Layer (MML) API lets third-party vendors build a media manager, software that works with RMAN and the vendor's hardware to allow backups to sequential med ia devices such as tape drives. The media manager handles loading, unloading and labeling of sequential media such as tapes. You must install media manager software to use RMAN with sequential media devices.
When backing up or restoring, the RMAN client connects to the target instance and directs the instance to send requests to its media manager. No dire ct communication occurs between the RMAN client and media manager.
The Oracle Backup Solutions Program (BSP), part of the Oracle Partner Program, is a group of leading media manager vendors whose products are co mpliant with Oracle Corporation's MML specification. Several products may be available for your platform from media management vendor s. For more information, you can contact your Oracle representative for a list of available products, contact individual vendors to a sk them if they participate, or access the Backup Solutions Program Web site at:
http://otn.oracle.com/deploy/availability
Note that Oracle Corporation does not certify media manager vendors for compatibility with RMAN. Questions abo ut availability, version compatibility, and functionality can only be answered by the media manager vendor, not Oracle Corporation.
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|
