RMAN in RAC Environment

October 12, 2016 by S4

Filed under Oracle

Last modified October 12, 2016

  1. Introduction

We are familiar with the following characteristics of RMAN in Oracle  9i ,

  • Backup the database, tablespaces, datafiles, control files and archive logs
  • Store frequently executed backup and recovery operations
  • Perform incremental block-level backup
  • Skip unused blocks
  • Specify limits for backups
  • Detect corrupted blocks during backup
  • Increase performance through:
    • Automatic parallelization
  • Manage backup and recovery tasks
  • RMAN repository is metadata about target database, backup and recovery operations.
  • RMAN repository is always stored in the control file of the target database.
  • CONTROL_FILE_RECORD_KEEP_TIME determines the minimum age in days of a record before it can be overwritten.
  • The control file can grow in size

But with 10G and RAC environment, following are the few features which are added   ,

o   Channel Connections to Cluster Instances

o   Node Affinity Awareness of Fast Connections

o   Autolocation for Backup and Restore Commands

o   Parallel Recovery in Real Application Clusters

  • RMAN Backup encryption
  • Using Flash Recovery Area in ASM  as backup Location
  • Enhanced Backup Job Monitoring Views
  • Enhanced & Simplified RMAN Commands


2.  Using RMAN to Create Backups in Real Application Clusters

Oracle provides RMAN for backing up and restoring the database. RMAN enables you to back up, restore, and recover datafiles, control files, SPFILEs, and archived redo logs. RMAN is included with the Oracle server and it is installed by default.  In addition, RMAN is the recommended backup and recovery tool if you are using Automatic Storage Management (ASM).

The procedures for using RMAN in RAC environments do not differ substantially from those for Oracle single-instance environments.

Ø  Channel Connections to Cluster Instances

Channel connections to the instances are determined using the connect string defined by channel configurations. For example, in the following configuration, three channels are allocated using user1/pwd1@service_name. If you configure the SQL Net service name with load balancing turned on, then he channels are allocated at a node as decided by the load balancing algorithm.


However, if the service name used in the connect string is not for load balancing, then  you can also use manually allocated channels to backup your database files. For example, the following command backs up the spfile, controlfile, datafiles and archived logs:


During a backup operation, as long as at least one of the channels allocated has access to the archived log, RMAN automatically schedules the backup of the specific log on that channel. Because the control file, spfile, and datafiles are accessible by any channel, the backup operation of these files is distributed across the allocated channels.

For a local archiving scheme, there must be at least one channel allocated to all of the nodes that write to their local archived logs. For a CFS archiving scheme, assuming that every node writes to the archived logs in the same CFS, the backup operation of the archived logs is distributed across the allocated channels.

During a backup, the instances to which the channels connect must be either all mounted or all open. For example, if the node1 instance has the database mounted while the node2 and node3 instances have the database open, then the backup fails.

Ø  Node Affinity Awareness of Fast Connections

In some cluster database configurations, some nodes of the cluster have faster access to certain datafiles than to other datafiles. RMAN automatically detects this, which is known as node affinity awareness. When deciding which channel to use to back up a particular datafile, RMAN gives preference to the nodes with faster access to the datafiles that you want to back up. For example, if you have a three-node cluster, and if node 1 has faster read/write access to datafiles 7, 8, and 9 than the other nodes, then node 1 has greater node affinity to those files than nodes 2 and 3.

Ø  Autolocation for Backup and Restore Commands

RMAN automatically performs autolocation of all files that it needs to back up or restore. If you use the non-cluster file system local archiving scheme, then a node can only read the archived redo logs that were generated by an instance on that node. RMAN never attempts to back up archived redo logs on a channel it cannot read.

During a restore operation, RMAN automatically performs the autolocation of backups. A channel connected to a specific node only attempts to restore files that were backed up to the node. For example, assume that log sequence 1001 is backed up to the drive attached to node 1, while log 1002 is backed up to the drive attached to node 2. If you then allocate channels that connect to each node, then the channel connected to node 1 can restore log 1001 (but not 1002), and the channel connected to node 2 can restore log 1002 (but not 1001).




3.Media Recovery in Real Application Clusters

Media recovery must be user-initiated through a client application, whereas instance recovery is automatically performed by the database. In these situations, use RMAN to restore backups of the datafiles and then recover the database. The procedures for RMAN media recovery in RAC environments do not differ substantially from the media recovery procedures for single-instance environments.

The node that performs the recovery must be able to restore all of the required datafiles. That node must also be able to either read all of the required archived redo logs on disk or be able to restore them from backups.

Ø  Parallel Recovery in Real Application Clusters

Oracle automatically selects the optimum degree of parallelism for instance, crash, and media recovery. Oracle applies archived redo logs using an optimal number of parallel processes based on the availability of CPUs. You can use parallel instance recovery and parallel media recovery in RAC databases as described under the following :

  • Parallel Recovery with RMAN
  • Disabling Parallel Recovery

Parallel Recovery with RMAN

With RMAN’s RESTORE and RECOVER commands, Oracle automatically makes parallel the following three stages of recovery:

Restoring Datafiles When restoring datafiles, the number of channels you allocate in the RMAN recover script effectively sets the parallelism that RMAN uses. For example, if you allocate five channels, you can have up to five parallel streams restoring datafiles.

Applying Incremental Backups Similarly, when you are applying incremental backups, the number of channels you allocate determines the potential parallelism.

Applying Archived Redo Logs With RMAN, the application of archived redo logs is performed in parallel. Oracle automatically selects the optimum degree of parallelism based on available CPU resources.

Ø  Disabling Parallel Recovery

You can override this using the procedures under the following topics:

  • Disabling Instance and Crash Recovery Parallelism
  • Disabling Media Recovery Parallelism

Disabling Instance and Crash Recovery Parallelism

To disable parallel instance and crash recovery on a multi-CPU system, set the RECOVERY_PARALLELISM parameter to 0.

Disabling Media Recovery Parallelism

Use the NOPARALLEL clause of the RMAN RECOVER command or the ALTER DATABASE RECOVER statement to force Oracle to use non-parallel media recovery.

4.Using a Flash Recovery Area in Real Application Clusters


The Flash Recovery Area is a single storage location on a filesystem or Automatic Storage Management (ASM) disk group that organizes all recovery-related files and activities for an Oracle database. All files that are required to fully recover a database from media failure reside in the Flash Recovery Area, including control files, archived log files, data file copies, and RMAN backups. What differentiates the Flash Recovery Area from simply keeping your backups on disk is a set of features for proactive management of backups. For example, obsolete backups and archived logs that fall outside of the RMAN retention policy or are already backed up to tape are automatically removed when there is no disk space to create new files.


To use a flash recovery area in RAC, you must place it on an ASM disk group, a Cluster File System, or on a shared directory that is configured through a network file system file for each RAC instance. In other words, the flash recovery area must be shared among all of the instances of a RAC database. In addition, set the parameter DB_RECOVERY_FILE_DEST to the same value on all instances.

Enterprise Manager enables you to set up a flash recovery area. To use this feature:

  1. From the Cluster Database home page, click the Maintenance
  2. Under the Backup/Recovery options list, click Configure Recovery Settings.
  3. Specify your requirements in the Flash Recovery Area section of the page.
  4. Click the Help for this page for more information.


5. RMAN Backup Encryption

RMAN now creates encrypted backups that cannot be restored by unauthorized people. There are 3 modes of backup encryption:

  • Transparent encryption
  • Password encryption
  • Dual-mode encryption using either transparent or password encryption

Backup encryption is a regulatory requirement for many customers. The presence of this capability in Oracle obviates the need to purchase it elsewhere

If you wish to modify your existing backup environment so that all RMAN backups are encrypted, perform the following steps:

Set up the Oracle Encryption Wallet

Issue the following RMAN command:


After these steps, all RMAN backup sets created by this database will be encrypted,   unless you explicitly override this behavior for an RMAN session with:


This remains in effect until you issue the SET ENCRYPTION OFF command during an RMAN session, or change the persistent setting again with:


6. Enhanced RMAN Backup Job Views

The new RMAN views correlate and simplify the metadata of an RMAN backup job. For example, a backup job can be associated with its backup sets, and a backup set with its composite control file, archived logs, or datafiles. Additional details such as I/O file sizes and compression ratio can be found in the new views.

This features enhances the manageability of RMAN backups by providing a SQL interface to find additional statistics on the backup job and files.

View Description
V$PROCESS Identifies currently active processes.
V$SESSION Identifies currently active sessions. Use this view to determine which database server sessions correspond to which RMAN allocated channels.
V$SESSION_LONGOPS Provides progress reports on RMAN backup and restore jobs.
V$SESSION_WAIT Lists the events or resources for which sessions are waiting.
V$BACKUP_SYNC_IO Displays rows when the I/O is synchronous to the process (or thread on some platforms) performing the backup.
V$BACKUP_ASYNC_IO Displays rows when the I/O is asynchronous to the process (or thread on some platforms) performing the backup.

Note: Where asynchronous I/O is not supported by the host operating system, it may be implemented using slave I/O processes.


Monitoring RMAN Job Performance

Monitor backup and restore performance by querying V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO.


7. Simplified & Enhanced RMAN Commands

RMAN COPY Obsolescence

The RMAN COPY command has been replaced by the BACKUP AS COPY command; allowing a database, multiple tablespaces, data files, or archived logs to be copied in a single command, rather than having to use a RMAN COPY command for each single file.

RMAN Backup Throttling

In Oracle Database 10g, RMAN backup rate can be throttled to fit within a backup window, a period of time during which a backup activity must complete, to meet required service levels. For example, you may want to restrict your

database backup activities to a window of time when user activity on your system is low, such as between 2:00 AM and 6:00 AM.


The DURATION option for the RMAN BACKUP command allows RMAN to automatically compute the rate of backup (bytes/sec/file) based on:

Oracle Database 10g Recovery Manager Feature Overview

  • A backup window (e.g. 4 hours)
  • Optional parameter to minimize time or system load within the specified backup windowWith the MINIMIZE TIME optional parameter, RMAN attempts to perform the backup as fast as possible under the specified duration, with little attention to system load. With MINIMIZE LOAD, RMAN will reduce the backup rate if it can detect that the job will complete before the end of the specified backup window.
    Automatic Data File Creation

    When a new tablespace or datafile is added, it must then be immediately backed up with a separate RMAN job. With automatic datafile creation, this separate job is no longer needed. RMAN will recreate the datafiles automatically upon RESTORE or RECOVER command, provided that all archived logs dating back to the creation of the datafile are available.

    Proxy Copy Archived Log Backups

    Archived logs can now be backed up and restored by a media manager that supports the RMAN Proxy Copy feature.


Cataloging Backup Pieces and Multiple Files

The process of adding backup metadata to the RMAN repository is known as cataloging. Cataloging a backup piece, with the CATALOG command, adds it to the RMAN repository so that it is available for use in recovery operations.

In addition, multiple files can be cataloged with a single command, using the new CATALOG START WITH command. The CATALOG START WITH command will automatically detect the type of file that is being examined, and catalog its information appropriately.

These new commands are useful to keep the catalog updated, when you make a copy of a backup piece or image copy with an operating system utility, or when you move a backup piece or image copy from one disk to another so that it has a different pathname.

Drop Database

When a database is no longer needed, the DROP DATABASE command can be used to remove all of a database’s files, including data files, online logs, control files, and, optionally, archivelogs and backups.

Unregister Database

The UNREGISTER DATABASE command deletes all recovery catalog data for one target database. Since this command does not remove any information from the control file, you can still register this database in the same or a different recovery catalog.

Backup/Restore Standby Controlfile

RMAN can back up a standby database’s controlfile. To back up the standby controlfile, use the normal BACKUP command while connected to the standby database. When restoring a controlfile, you can specify that a standby controlfile will be restored by using the STANDBY option on the RESTORE command.


  1. Configuration Steps – Recovery Catalog

The Configuration Of Catalog, Registering the Database into Catalog does not differ much for RAC. Catalog Database may or may not be RAC, though the databases getting registered is RAC.And also we have to register the database once irrespective of number of instances available for the Database.

Below  is the overview of SRMAN Database as Catalog DB SRMAN and Register SRMAN  itself in to Catalog.

Start by creating a database schema (usually called rman). Assign an appropriate tablespace to it and grant it the recovery_catalog_owner role. Look at this example:

Sqlplus  sys

SQL> create user rman identified by rman;

SQL > alter user rman default tablespace tools temporary tablespace temp;

SQL> alter user rman quota unlimited on tools ;

SQL> grant Connect ,resource ,recovery_catalog_owner to rman;


Next, log in as rman  user and create the catalog schema. Prior to Oracle 8i this was done by running the catrman.sql script.

Rman>catalog rman/rman

Rman>create catalog tablespace tools;

You can now continue by registering your (SRMAN) database in the catalog. Look at this example:

Export ORACLE_SID=srman

Rman>catalog rman/rman target /

Rman> Register database;


One can also use the “upgrade catalog;” command to upgrade to a new RMAN release, or the “drop catalog;” command to remove an RMAN catalog.



  1. Test Case : Cloning RAC Database – RMAN


Primary Database SID:      SRMAN
Duplicate Database SID:    CRMAN

RMAN Catalog SID:          SRMAN

Steps in Brief

1.  Backup the primary database.(Hot Backup)

2.  Determine how much disk space will be required.

3.  ensuring you have enough space on your target server.

4.  Creating the init.ora & administration directories for the duplicate database.

5.  Ensuring SQL*NET connections to primary database and RMAN catalog are working.

6.  Prepare Auxiliary (Duplicate) and RMAN duplicate script.

7.  Execute the RMAN script.
Steps in Detail


  1. Backup the primary database

The  srman instance hot backup with datafiles and archivelogs  to /local/srman/hot_backup as below :

Rman target / catalog=rman/rman@srman



run { allocate channel d1 type disk ;

backup format ‘/local/srman/hot_backup/%d_t%t_s%s_p%p’ database ;

sql ‘alter system archive log current’ ;

backup format ‘/local/srman/hot_backup/al_t%t_s%s_p%p’ archivelog all;

release channel d1;



    If we are taking Cold Backup , Then bring the database to Mount state and execute only,


backup format ‘/local/srman/hot_backup/%d_t%t_s%s_p%p’ database;


     Note :srman is instance name  of Database SRMAN , Other Instance name is s1rman. But through out  our example we go along with srman instance leaving other instance undisturbed.


  1. Determine how much disk space will be required



select DF.TOTAL/1048576 “DataFile Size Mb”,
LOG.TOTAL/1048576 “Redo Log Size Mb”,
CONTROL.TOTAL/1048576 “Control File Size Mb”,
(DF.TOTAL + LOG.TOTAL + CONTROL.TOTAL)/1048576 “Total Size Mb” from dual,
(select sum(a.bytes) TOTAL from dba_data_files a) DF,
(select sum(b.bytes) TOTAL from v$log b) LOG,
(select sum((cffsz+1)*cfbsz) TOTAL from x$kcccf c) CONTROL;





  1. Ensuring you have enough space on your server

      As we are cloning the database with files in ASM Diskgroup.

Please ensure the files will get accommodated in ASM diskgroup.

Say now we are  going to  use SAND Diskgroup , hence we will

Create directory to place the files , as below


sqlplus “/ as   sysdba ‘

SQL> alter diskgroup SAND  add directory ‘+SAND/oracle/data/crman’ ;

  1.  Creating the init.ora & administration directories for the duplicate database


Copy the initsrman.ora into initcrman.ora .

Ensure the we alter the database name, dump directories and controlfile locations.Along with this changes we have to make the below entries:





Also create the dump directories mentioned in initcrman.ora




  1. Ensuring SQL*NET connections to primary database and RMAN catalog are working


            tnsping srman  ( As SRMAN is primary database and catalog here)



  1. Prepare  Auxiliary( Duplicate ) Database and RMAN duplicate script


export ORACLE_SID=crman ( Duplicate /Auxiliary Database)


Sqlplus  “ / as  sysdba “

SQL>Startup nomount ;



RMAN Script to Duplicate the Primary DB  :


run {

allocate auxiliary channel ORA_AUX_DISK_1 device type disk;

duplicate target database to crman;



 7.  Execute the RMAN script


rman target sys/srman@srman catalog  rman/rman@srman auxiliary /



run {

allocate auxiliary channel ORA_AUX_DISK_1 device type disk;

duplicate target database to crman;



Now the Non-RAC database  CRMAN is Opened with Archive log as we have duplicated the SRMAN. We can disable the archivelog later if needed .Now the database can be shutdown and  can start  instances in each server for crman as

crman1(server1) ,


With initcrma1.ora and initcrman2.ora having


*.cluster_database_instances=<n>    n – number of instances

Leave a Comment