About the RMAN Environment
The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy.
- RMAN client
The client application
use Oracle Net to connect to a target database
located on any host
- target database
target database control file to gather metadata and to store information
backup and recovery is performed by server sessions running on the target database.
- recovery catalog 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.
- recovery catalog schema
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.
- physical standby database
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 DBID and DB_NAME values as the primary database, but a different DB_UNIQUE_NAME. You can fail over to the standby database if the primary database becomes inaccessible.
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.
The recovery catalog is required when you use RMAN in the Data Guard environment.
Note: A logical standby database is treated as a separate database by RMAN because it has a different DBID from its primary database.
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.
fast recovery area
A 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 Database and RMAN manage the files in the fast recovery area automatically.
A vendor-specific application that enables RMAN to back up to a storage system such as tape
media management catalog
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
RMAN Command-Line Client
Use 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 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 PGA memory, processes it, and writes it to the output device.
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, a channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance.
Channels and Devices
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.
Automatic and Manual Channels
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.
You can also manually allocate 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 reads from or write to this device in parallel while performing the command. When the work is done in parallel, the backup of the files is done 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.
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 an 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 recovery catalog controls which databases each virtual private 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. A target database instance never accesses the catalog 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.
When backing up or restoring, the RMAN client connects to a target database instance and directs the instance to send requests to its media manager. No direct communication occurs between the RMAN client and the media manager.
RMAN Interaction with a 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 the media manager. The default channels are used for all backup and recovery tasks that employ the media manager and for which you have not explicitly allocated 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 must 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. These products may use technologies such as high-speed connections between storage and media subsystems to reduce the 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
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.
Fast Recovery Area
The components that create 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 fast recovery area (also called the recovery area), which automates management of backup-related files.
A fast 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 fast 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 set 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 must reclaim space for new files.
RMAN in a Data Guard Environment
When 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. For RMAN to work correctly in a Data Guard environment, the DB_UNIQUE_NAME must be unique across all the databases with the same DBID.
RMAN Configuration in a Data Guard Environment
To 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 File Management in a Data Guard Environment
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.
Interchangeability of Backups in a Data Guard Environment
RMAN commands use the recovery catalog metadata to function 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.
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.
Association of Backups in a Data Guard Environment
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 it unless you use the CHANGE …RESET DB_UNIQUE_NAME command to associate the backup with a different database.
Accessibility of Backups in a Data Guard Environment
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 they are 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 a file whose SITE_KEY is null with the database to which they are connected as TARGET.
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.
You can transfer a backup from a standby host to a primary host or vice versa, connect as TARGET to the database on this host, and then use the CATALOG command to catalog the backup. After a file is cataloged by the target database, the file is associated with the target database.