02 - RMAN Architecture

Recovery Manager is a server-managed recovery (SMR). SMR refers to the ability of the database server to perform the backup operations. RMAN is integrated into the RDBMS, it has access to your data at the same level that the database itself uses: the data block. Block-level access is what distinguishes RMAN from any other backup utility

The RMAN architecture has the following components:

• RMAN Utility
• Database Control File
• RMAN Server Processes
• Recovery Catalog
• Auxiliary Database
• Flash Recovery Area

2.0  RMAN Utility

RMAN is a standalone executable that makes a connection to the Oracle database to access internal backup and recovery packages (SYS schema). RMAN is not more than a command interpreter that takes commands you type and turns those commands into remote procedure calls (RPCs) that are executed at the database. The command language is unique to RMAN, and using it takes a little practice.

The RMAN utility is composed of two components: the executable file and the recover.bsq file. The recover.bsq file is the library file, from which the executable file extracts code for creating PL/SQL calls to the target database. The target database refers to the database that is being backed up. It is must be noted that the recover.bsq file and the executable file must be of the same version or nothing will work.

RMAN always connects to the target database as a sysdba user. When you connect to the target, RMAN automatically supplies the “as sysdba” to the connection:

 

For remote connection to the target database, you need to create a tnsnames.ora entry that can connect you to the target database with a dedicated server process. RMAN cannot use Shared Servers to make a database connection. The difference between the two can be seen in the following sample tsnames.ora file.

 PROD_RMAN =
            (DESCRIPTION =
                  (ADDRESS_LIST =
                     (ADDRESS = (PROTOCOL = TCP)
                     (HOST = pc1)
                     (PORT = 1521))
                   )
                   (CONNECT_DATA =(SERVER = DEDICATED)
                   (SERVICE_NAME = prod))
            )
PROD =
            (DESCRIPTION =
                  (ADDRESS_LIST =
                      (ADDRESS = (PROTOCOL = TCP)
                      (HOST = pc1)
                      (PORT = 1521))
                  )
            (CONNECT_DATA =(SERVER = SHARED)
            (SERVICE_NAME = prod))
          )

Running RMAN locally always make a bequeath connection to the database, requiring no password file setup and no tnsnames.ora configuration.

2.1  Database Control File

The database control file acts as a repository of database file information. RMAN uses the control file to compile file lists, obtain checkpoint information, and determine recoverability. The control file also acts as an RMAN data repository. After RMAN completes a backup of any portion of the database, it writes a record of that backup to the control file, along with checkpoint information about when the backup was started and completed.

The control file has two types of records: circular reuse records and noncircular reuse records. Circular reuse records are records that include information that can be aged out of the control file, for instance, archive log history information. Noncircular reuse records are those records that cannot be deleted from the control file. If the control file runs out of space for these records, the file expands to make more room. These records include datafile and log file lists. The record of RMAN backups in the control file falls into the category of circular reuse records, meaning that the records will get aged out if the control file section that contains them becomes full. It must be noted that if the control file does not have a record of your RMAN backup, the backup cannot easily be used by RMAN for recovery. This makes the control file a critical component of the RMAN architecture. You can set a larger timeframe for when the control file will age out records. This is controlled by the init.ora parameter CONTROL FILE_RECORD_KEEP_TIME. By default, this parameter is set to 7 (in days).

RMAN needs a read consistent view of the control file. With the constant updates from the database, this is nearly impossible. To get around this, RMAN uses the snapshot control file, an exact copy of your control file that is only used by RMAN during backup and resync operations. RMAN refreshes the snapshot control file from the actual control file, thus putting a momentary lock on the control file. Then, RMAN switches to the snapshot and uses it for the duration of the backup; in this way, it has read consistency without holding up database activity. By default, the snapshot control file exists in the ORACLE_HOME/dbs directory on Unix  platforms and in the ORACLE_HOME/database directory on Windows. It has a default name of SNCF<ORACLE_SID>.ORA.

2.2  RMAN Server Processes

When RMAN makes a connection to the target database, two server processes are created at the target database. The primary process is used to make calls to packages in the SYS schema in order to perform the backup or recovery operations. The secondary, or shadow, process polls any long-running transactions in RMAN and then logs the information internally. You can view the results of this polling in the view V$SESSION_LONGOPS:

 

You can also view these processes in the V$SESSION view.

In addition to the two default processes, an individual process is created for every channel that you allocate during a backup or restore operation. Channel is the server process at the target database that coordinates the reads from the datafiles and the writes to the specified location during backup. During a restore, the channel coordinates reads from the backup location and the writing of data blocks to the datafile locations. There are only two kinds of channels: disk channels and tape channels. You cannot allocate both kinds of channels for a single backup operation—you are writing the backup either to disk or to tape.

The RMAN server process that coordinates the work of the channels has access to two packages in the SYS schema: DBMS_RCVMAN and DBMS_BACKUP_RESTORE. Both of these RMAN packages are installed by default by running the catproc.sql script when the database is created. These packages have another important trait: they are hard-coded into the Oracle software library files, so they can be called even when the database is not open.

2.3  Recovery Catalog

The recovery catalog is a repository for metadata about RMAN backups. In a sense, you can think of the recovery catalog as merely a copy of the pertinent information out of the control file that RMAN requires for backup and recovery purposes. To use a recovery catalog, you first connect from RMAN to the target database. Then, you make a second Net connection to the recovery catalog from within RMAN, like this:

 

In the connect string to the catalog, you pass the username and password for the user that owns the RMAN catalog. Unlike with the target, the connection to the catalog is not a sysdba connection and does not need this privilege granted to it.

A recovery catalog can serve as a repository for more than one target database, and as such can help centralize the administration of backups of many different databases. Inside of the recovery catalog are two packages: DBMS_RCVMAN and DBMS_RCVCAT. Oracle created a series of views, all prefixed with RC_, that can be used to extract information from the catalog.

2.4  Auxiliary Database

The auxiliary database refers to the instance that will become host to restored files from the target database in the event of a tablespace point-in-time recovery (TSPITR), a duplication operation (cloning the database), or the creation of a standby database using RMAN backups. When you perform any of these tasks, you will be connecting to the target database and the auxiliary database at the same time from within RMAN. In this way, you can utilize the information about the backups in the target database control file to coordinate the restore of those backups to the auxiliary database location. The following shows the connection to both the target database (locally) and the auxiliary database (using an Oracle Net connection):

2.5  Flash Recovery Area

The FRA is a specific location on disk that you set up to house all the Oracle recovery files. Recovery files refers to all files that might be required for a media recovery operation: full datafile backups, incremental backups, datafile copies, backup control files, and archive logs. The FRA also functions as a repository for mirrored copies of online redo log files, the block-change tracking file, and for a current control file. The FRA manages recovery files internally, first based on database name, then on types of files, and then by the dates the files are generated. The files themselves are named according to the Oracle Managed Files (OMF) format.

2.6  RMAN Memory Structure

RMAN utilize memory from PGA and sometime from SGA. There are two kinds of memory buffers. Input buffers are the buffers that are filled with data blocks read from files that are being backed up. Output buffers are the buffers that are filled when the memory-to-memory write occurs to determine whether a particular block needs to be backed up. The memory buffers differ depending on whether you are backing up to or restoring from disk or tape.

You can use the following query to monitor the size of buffers on a per-file basis while the backup is running:

SELECT set_count, device_type, type, filename, buffer_size,  

       buffer_count, open_time, close_time
FROM v$backup_async_io
ORDER BY set_count,type, open_time, close_time;