A case for the Recovery Catalog

© Valentine Mungyeh, 04/30/2013

The Recovery Catalog (RC) is centralized metadata storage for backup and recovery information and Recovery Manager (RMAN) scripts. RMAN is capable of functioning with or without the RC but configuring RC either as a schema within a database or as a database on its own makes the management of RMAN much easier. When RC is not configured, which is the default condition, all database metadata is stored in the database control file but if RC is configured this metadata is stored both in the database Control file as well as in the RC. In standard practice, especially in environments with a repository (OEM) for centralized monitoring, it makes organizational sense to have both the Recovery Catalog and the repository instance on the same server. That the RC is a database is not quite true. It is a schema that is contained in a database. Best practice stipulates that the RC not be stored in the same instance as the production database. A separate utility dedicated database, kept on separate disks and if possible a separate server from your production databases would be ideal. With RC configured, Oracle still maintains backup metadata in the control file. The RC is essentially a secondary metadata repository.

Here is how the RC is created:

  1. Create database
  2. Create user – sizing the Tablespace should ideally be 15MB/Database/year – considering that the RC does not contain that much hard data – metadata. RC footprint is pretty minimal.
  3. Grant RECOVERY_CATALOG_OWNER role to the user.
  4. Register target databases
  5. Use RC
    1. Connect
      1. $ rman target / catalog rman/password@database_instance                                                                                                                                                                                           (Notice that this connect string achieves the dual objective of connecting not only to the recovery catalog that is set in the o/s environment but also to the target database instance registered to RC).

Stored global RMAN scripts

LOCAL STORED SCRIPTS = Available only to the instance to which RC is connected when the stored script is created.

GLOBAL STORED SCRIPTS= Can be run against any database registered in the RC if RMAN client is connected to the RC and the instance (target database).

RMAN> create script nologs_bkp


RMAN> create global script global_bkp

COMMENT ‘This is a demo of a sample global script’






RMAN> run {execute script global_bkp;}

RMAN> print script global_bkp;

RMAN> print script global_bkp to file ‘minor_db.rman’;




Note that to run LIST SCRIPT NAMES RMAN must be connected to the target instance.

To run LIST GLOBAL SCRIPT NAMES & LIST ALL SCRIPT NAMES RMAN needs to be not connected to the target database.

RMAN> REPLACE SCRIPT global_bkp {***} (to update a script)

RMAN> DELETE SCRIPT global_bkp {***}

Query RC views


The RC is not a separate database. It is a schema that is necessarily stored in a database of its own.

Synchronization with the control file – this is making sure that your database matches item by item, system change number by system change number with the information in the metadata of your RC. That should normally be a given but stuff happens and the need arises for a manual resynchronization –


Backing up the RC

Include the RC in what ever backup and recovery strategy is configured on your system.


RC has a variety of scripts for reporting of which the following 4 stand out as most important:

  • RC_STORED SCRIPTS: This shows us the scripts contained in the RC
  • RC_RMAN_STATUS: This view displays a catalog of RMAN operations through time for all databases associated with the RC. It is almost the same thing as the V$RMAN_STATUS the only difference being that it excludes current session information.
  • RC_RMAN_CONFIGURATION: Like the V$RMAN_CONFIGURATION view, this view list RMAN persistent persistent configuration settings.
  • RC_DATABASE: Shows all metadata pertaining to registered databases


The VPC gives administrators the ability to virtually or logically partition the RC schema for delegated administration. Sarbanes Oxley and other regulations my stipulate that access to certain metadata be granted to privileged users. The VPC facilitates access control, if you may, to data within the RC. This is almost similar to the Database Vault advanced security concept even though the technology is quite different.

Set up Procedure:

  • Create delegated user in RC,
  • Grant RECOVERY_CATALOG_OWNER to the delegated user
  • Create virtual catalog
  • Grant catalog (in RMAN) for specified database to delegated user (This grant statement binds the delegated user exclusively to the database to whose metadata they are being granted access.


  • It allows for longer and broader reporting windows
  • STORED SCRIPTS: It has the ability to store parametrized and robust RMAN backup scripts and call them globally from any registered instance
  • The RC is a more robust solution than storing your information just in the Control file. You can register more than one database with a single RC and have a potentially more comprehensive view of your backup history.


  1. Managing a Recovery Catalog
  2. Oracle Database 11g RMAN Backup & Recovery by Hart M. and Freeman G. Oracle Press, 2010
  3. OCA/OCP Oracle Database 10g: All-in-One Exam Guide by Watson, Ramklass & Bryla. Oracle Press, 2010

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: