| Oracle® Database Backup and Recovery User's Guide 11g Release 1 (11.1) Part Number B28270-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery User's Guide 11g Release 1 (11.1) Part Number B28270-01 |
|
|
View PDF |
This chapter describes the Recovery Manager (RMAN) interface and the basic components of the RMAN environment. This chapter contains the following topics:
The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy.
Table 3-1 lists some of the components in a typical RMAN environment.
Table 3-1 Components of the RMAN Environment
| Component | Description |
|---|---|
|
The client application that manages backup and recovery operations for a target database. The RMAN client can use Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net. |
|
|
A database containing the control files, datafiles, and optional archived redo logs that RMAN backs up or restores. RMAN uses the target database control file to gather metadata about the target database and to store information about its own operations. The work of backup and recovery is performed by server sessions running on the target database. |
|
|
A database containing a recovery catalog, which contains metadata that RMAN uses to perform backup and recovery. You can create one recovery catalog that contains the RMAN metadata for multiple target databases. Unless you are using RMAN with a physical standby database, a recovery catalog is optional when using RMAN because RMAN stores its metadata in the control file of each target database. |
|
|
|
The user within the recovery catalog database that owns the metadata tables maintained by RMAN. RMAN periodically propagates metadata from the target database control file into the recovery catalog. |
|
|
A copy of the primary database that is updated with archived redo logs generated by the primary database. A physical standby database has the same RMAN can create, back up, or recover a standby database. Backups that you make at a standby database are usable at primary database or another standby database for same production database. A recovery catalog is required when you use RMAN in a Data Guard environment. Note: A logical standby database is treated as a separate database by RMAN because it has different DBID from its primary database. See Also: Oracle Data Guard Concepts and Administration to learn how to use RMAN in a Data Guard environment |
|
A copy of the primary database that you can use for testing purposes. The DBID is different from the database from which it was created. |
|
|
An disk location that you can use to store recovery-related files such as control file and online redo log copies, archived redo logs, flashback logs, and RMAN backups. Oracle and RMAN manage the files in the flash recovery area automatically. |
|
|
A vendor-specific application that enables RMAN to back up to a storage system such as tape. |
|
|
A vendor-specific repository of metadata about a media management application. |
|
|
Oracle Enterprise Manager |
A browser-based interface to the database, including backup and recovery through RMAN. |
The only required components in an RMAN environment are a target database and RMAN client, but most real-world configurations are more complicated. For example, you could use an RMAN client connecting to multiple media managers and multiple target databases and auxiliary databases, all accessed through Enterprise Manager.
Figure 3-1 illustrates components in a possible RMAN environment. The graphic shows that the primary database, standby database, and recovery catalog databases all reside on different computers. The primary and standby database hosts use a locally attached tape drive. The RMAN client and Enterprise Manager console run on a separate computer.
See Also:
Oracle Database Net Services Administrator's Guide to learn about Oracle NetUse the RMAN command-line client to enter commands that you can use to manage all aspects of backup and recovery operations. RMAN uses a command language interpreter that can execute commands in interactive or batch mode. Even when you use the backup and recovery features in Enterprise Manager that are built on top of RMAN, an RMAN client executes behind the scenes.
The RMAN client directs database server sessions to perform all backup and recovery tasks. What constitutes a session depends on the operating system. For example, on Linux, a server session corresponds to a server process, whereas 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.
An RMAN channel represents one stream of data to a device, and corresponds to one database server session. The channel reads data into memory, processes it, and writes it to the output device. See "Basic Concepts of RMAN Performance Tuning" for a low-level description of how channels work.
Most RMAN commands are executed by channels, which must be either configured to persist across RMAN sessions, or manually allocated in each RMAN session. As illustrated in Figure 3-2, a channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance.
The RMAN-supported device types are disk and SBT (system backup to tape). An SBT device is controlled by a third-party media manager. Typically, SBT devices are tape libraries and tape drives.
If you use a disk channel for a backup, then the channel creates the backup on disk in the file name space of the target instance creating the backup. You can make a backup on any device that can store a datafile. RMAN does not call a media manager when making disk backups.
To create backups on nondisk media, you must use media management software such as Oracle Secure Backup and allocate channels supported by this software. RMAN contacts the media manager whenever the channel type allocated is not disk. How and when the SBT channels cause the media manager to allocate resources is vendor-specific. Some media managers allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.
You can use the CONFIGURE CHANNEL command to configure channels for use with disk or tape across RMAN sessions. This technique is known as automatic channel allocation. RMAN comes preconfigured with one DISK channel that you can use for backups to disk.
When you run a command that can use automatic channels, RMAN automatically allocates the channels with the options you specified in the CONFIGURE command. For the BACKUP command, RMAN allocates only the type of channel required to back up to the specified media. For the RESTORE command and RMAN maintenance commands, RMAN allocates all necessary channels for the device types required to execute the command. RMAN determines the names for automatic channels.
You also have the option of manually allocating channels. Each manually allocated channel uses a separate connection to the database. When you manually allocate a channel, you give it a user-defined name such as dev1 or ch2.
The number of channels available for use with a device when you run a command determines whether RMAN will read from or write to this device in parallel while carrying out the command. In parallelism, the backup of the files is performed by more than one channel. Each channel may back up more than one file, but unless a multisection backup is performed, no file is backed up by more than one channel.
See Also:
Oracle Database Backup and Recovery Reference for ALLOCATE CHANNEL syntax
Oracle Database Backup and Recovery Reference on ALLOCATE CHANNEL FOR MAINTENANCE
"Configuring Channels for Disk" and "Configuring SBT Channels for Use with a Media Manager"
The RMAN repository is the collection of metadata about the target databases that RMAN uses for backup, recovery, and maintenance. RMAN always stores its metadata in the control file. The version of this metadata in the control file is the authoritative record of RMAN 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, which is a repository of RMAN metadata stored in an Oracle database schema. The control file has finite space for records of backup activities, whereas a recovery catalog can store a much longer history. You can simplify backup and recovery administration by creating a single recovery catalog that contains the RMAN metadata for all of your databases.
The owner of a recovery catalog can grant or revoke restricted access to the catalog to other database users. Each restricted user has full read/write access to his own metadata, which is called a virtual private catalog. When one or more virtual private catalogs exist in a database, the database contains just one set of catalog tables. These tables are owned by the base recovery catalog owner. The owner of the base catalog controls which databases each virtual catalog user can access.
Some RMAN features only function when you use a recovery catalog. For example, you can create a stored script in the recovery catalog and use this script to execute RMAN jobs. Other RMAN commands are specifically related to managing the recovery catalog and so are not available (and not needed) if RMAN is not connected to a recovery catalog.
The recovery catalog is maintained solely by RMAN. The target database 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 control file after any operation that updates the repository, and also before certain operations.
Oracle'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 media devices such as tape drives. A 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 direct communication occurs between the RMAN client and media manager.
Before performing backup or restore to a media manager, you must allocate one or more channels to handle the communication with the media manager. You can also configure default channels for use with the media manager, which will be applied for all backup and recovery tasks that use the media manager where you do not explicitly allocate channels.
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 this stream. When RMAN needs to restore the backup, it asks the media manager to retrieve the byte stream. All details of how and where that stream is stored are handled entirely by the media manager. For example, the media manager labels and keeps track of the tape and names of files on each tape, and automatically loads and unloads tapes, or signals an operator to do so.
Some media managers support proxy copy functionality, in which they handle the entire data movement between datafiles and the backup devices. Such products may use technologies such as high-speed connections between storage and media subsystems to reduce load on the primary database server. 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.
Oracle Secure Backup is a media manager that provides reliable and secure data protection through file system backup to tape. All major tape drives and tape libraries in SAN, Gigabit Ethernet, and SCSI environments are supported.
Although Oracle Secure Backup has no specialized knowledge of database backup and recovery algorithms, it can serve as a media management layer for RMAN through the SBT interface. In this capacity, Oracle Secure Backup provides the same services for RMAN as other supported third-party SBT libraries. Oracle Secure Backup has some features, however, that are not available in other media managers.
See Also:
Oracle Secure Backup Administrator's Guide to learn how to use Oracle Secure BackupThe Oracle Backup Solutions Program (BSP), part of the Oracle Partner Program, is a group of media manager vendors whose products are compliant with Oracle's MML specification. Several products may be available for your platform from media management vendors. For more information, you can contact your Oracle representative for a list of available products, contact individual vendors to ask them if they participate, or access the Backup Solutions Program Web site at:
http://www.oracle.com/technology/deploy/availability
Note that Oracle does not certify media manager vendors for compatibility with RMAN. Questions about availability, version compatibility, and functionality can only be answered by the media manager vendor, not Oracle.
The component that creates different backup and recovery-related files have no knowledge of each other or of the size of the file systems where they store their data. With automatic disk-based backup and recovery, you can create a flash recovery area (also simply called the recovery area), which automates management of backup-related files.
A flash recovery area minimizes the need to manually manage disk space for backup-related files and balance the use of space among the different types of files. In this way, a flash recovery area simplifies the ongoing administration of your database. Oracle recommends that you enable a recovery area to simplify backup management.
When you create a recovery area, you choose a location on disk and an upper bound for storage space. You also set a backup retention policy that governs how long backup files are needed for recovery. The database manages the storage used for backups, archived redo logs, and other recovery-related files for the database within this space. Files no longer needed are eligible for deletion when RMAN needs to reclaim space for new files.
See Also:
"Configuring the Flash Recovery Area" to learn about the flash recovery area and how to configure itWhen using RMAN in a Data Guard environment, a recovery catalog is required. The recovery catalog can store the metadata for all primary and standby databases.
A database in a Data Guard environment is uniquely identified by means of the DB_UNIQUE_NAME parameter in the initialization parameter file. The DB_UNIQUE_NAME must be unique across all the databases with the same DBID for RMAN to work correctly in a Data Guard environment.
See Also:
Oracle Data Guard Concepts and Administration to learn how to use RMAN in a Data Guard environmentTo simplify ongoing use of RMAN for backup and recovery, you can set a number of persistent configuration settings for each primary and physical standby database in a Data Guard environment. These settings control many aspects of RMAN behavior. For example, you can configure the backup retention policy, default destinations for backups to tape or disk, default backup device type, and so on.
You can use the CONFIGURE command with the FOR DB_UNIQUE_NAME clause to create a persistent configuration for a database in a Data Guard environment without connecting to the standby database or primary database as TARGET. For example, you connect RMAN to the recovery catalog, run the SET DBID command, and then can create a configuration for a physical standby database before its creation so that the RMAN configuration applies when the database is created.
RMAN updates the control file of the database when connected to it as TARGET during a recovery catalog resynchronization. If you use FOR DB_UNIQUE_NAME for a database without being connected as TARGET to this database, however, then RMAN changes configurations in the recovery catalog only.
RMAN uses a recovery catalog to track filenames for all database files in a Data Guard environment. The catalog also records where the online redo log files, standby redo log files, tempfiles, archived redo log files, backup sets, and image copies are created.
RMAN commands use the recovery catalog metadata to behave transparently across different physical databases in the Data Guard environment. For example, you can back up a tablespace on a physical standby database and restore and recover it on the primary database. Similarly, you can back up a tablespace on a primary database and restore and recover it on a physical standby database.
Note:
Backups of logical standby databases are not usable at the primary database.Backups of standby control files and nonstandby control files are interchangeable. For example, you can restore a standby control file on a primary database and a primary control file on a physical standby database. This interchangeability means that you can offload control file backups to one database in a Data Guard environment. RMAN automatically updates the filenames for database files during restore and recovery at the databases.
The recovery catalog tracks the files in the Data Guard environment by associating every database file or backup file with a DB_UNIQUE_NAME. The database that creates a file is associated with the file. For example, if RMAN backs up the database with the unique name of standby1, then standby1 is associated with this backup. A backup remains associated with the database that created in unless you use the CHANGE ... RESET DB_UNIQUE_NAME to associate the backup with a different database.
The accessibility of a backup is different from its association. In a Data Guard environment, the recovery catalog considers disk backups as accessible only to the database with which it is associated, whereas tape backups created on one database are accessible to all databases. If a backup file is not associated with any database, then the row describing it in the recovery catalog view shows null for the SITE_KEY column. By default, RMAN associates files whose SITE_KEY is null with the target database.
RMAN commands such as BACKUP, RESTORE, and CROSSCHECK work on any accessible backup. For example, for a RECOVER COPY operation, RMAN considers only image copies that are associated with the database as eligible to be recovered. RMAN considers the incremental backups on disk and tape as eligible to recover the image copies. In a database recovery, RMAN considers only the disk backups associated with the database and all files on tape as eligible to be restored.
To illustrate the differences in backup accessibility, assume that databases prod and standby1 reside on different hosts. RMAN backs up datafile 1 on prod to /prmhost/disk1/df1.dbf on the production host and also to tape. RMAN backs up datafile 1 on standby1 to /sbyhost/disk2/df1.dbf on the standby host and also to tape. If RMAN is connected to database prod, then you cannot use RMAN commands to perform operations with the /sbyhost/disk2/df1.dbf backup located on the standby host. However, RMAN does consider the tape backup made on standby1 as eligible to be restored.
Note:
You can FTP a backup from a standby host to a primary host or vice versa, connect as
TARGET to the database on this host, and then CATALOG the backup. After a file is cataloged by the target database, the file is associated with the target database.See Also:
Oracle Data Guard Concepts and Administration to learn how to perform RMAN backup and recovery in a Data Guard environment
Chapter 12, "Managing a Recovery Catalog" to learn how to manage a recovery catalog in a Data Guard environment
Oracle Database Backup and Recovery Reference for CONFIGURE syntax
