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 PGA memory, processes it, and writes it to the output device.
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. 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 database instance creating the backup. You can make a backup on any device that can store a data file. RMAN does not call a media manager when making disk backups. To create backups on non disk 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.
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. When you run a command that can use automatic channels, RMAN automatically allocates the channels with the options that 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 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 multi section 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 toother 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 data file copies into the recovery catalog from the target database control file after any operation that updates the repository.
The Oracle 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 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 store dare 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.
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.
Source: Oracle docs