Monday, 20 August 2012

11g R2 – Maintain Recovery Catalogs


My name is Mark Tiger, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g).

Gathering information for some DBA tasks can be time-consuming, even although the commands that you need to issue eventually can be over quite quickly.  I have gone through this process over and over again, and have decided to help other Oracle DBA’s in the community.

In this blog, I will give you the details of how to carry out those tasks; that typically need a lot of research, before you can do them.  I will try to present the information in an easy to understand way.  My hope is that this will save you lots of time in research, and help to make you more productive as an Oracle DBA.  The illustrations are primarily meant for Linux, since this is a Platform; that enjoys preference from Oracle.  However they are easily adaptable for versions of UNIX/AIX and windows etc.

11g R2 – Maintain Recovery Catalogs                                 

Overview of the Recovery Catalog

A Recovery Catalog is a Database Schema used by RMAN to store metadata about one or more Oracle databases.  Typically you store the catalog in a dedicated database.  The following benefits are associated with a Recovery Catalog.
·         A Recovery Catalog creates redundancy for the RMAN repositorystored in the control file of each target database.  The recovery catalog serves as a secondary metadata repository.  If the control file and all the backups are lost, then the RMAN metadata still exists in the recovery catalog.
·         A Recovery Catalog centralizes metadata for all your target databases.  Storing the metadata in one place, makes reporting and administrative tasks easier to perform.
·         A recovery catalog can store metadata history much longer than the control file.  This capability is useful, if you need to do a recovery that goes back further in time than the history in the control file.  The added complexity of managing a recovery catalog database can be offset by the convenience of having the extended backup history available.

Some RMAN only function when used with a recovery catalog.  For example stored scripts, need to be stored in a recovery catalog.  A RMAN script is available to any RMAN client that can connect to the target database, and the recovery catalog.  Command files are only available if the RMAN client has access to the file system on which they are stored.

A Recovery Catalog is required when you use RMAN in a Data Guard environment.  By storing backup metadata for all primary and standby databases, the catalog enables you to offload backup tasks to one standby database while  enabling you to restore backups on another database in the environment.

The recovery catalog contains metadata about RMAN for each registered target database.  When RMAN is connected to the catalog, then RMAN obtains its metadata exclusively from the recovery catalog.  The recovery catalog includes the following types of metadata:
·         Data file and archived redo log backup sets and backup pieces
·         Data file copies
·         Archived redo logs and their copies
·         Database structures, tablespaces and data files
·         Stored scripts, which are names user-created sequences of RMAN commands
·         Persistent RMAN configuration settings

The process of enrolling of a database in a recovery catalog for RMAN use is called “registration”.  The recommended practice is to register every target database in your environment in a single recovery catalog.

The owner of a centralized recovery catalog, which is also called the “base 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”.  The RMAN metadata is stored in the schema of the Virtual Private Catalog owner.  The owner of the base recovery catalog determines which objects each virtual private catalog user can access.

You can use a recovery catalog in an environment in which you use or have used different versions of the Oracle Database.  As a result your environment can have different versions of the RMAN client, recovery catalog database, recovery catalog schema, and target database. 

For RMAN operations such as backup, restore, and crosscheck, RMAN always first updates the control file and then propagates the data to the recovery catalog.  This flow of metadata from the mounted control file to the recovery catalog is known as Recovery Catalog “Resynchronization”.  This process ensures that the metadata that RMAN accesses from the Control file is current.

You can use a stored script as an alternative to using a command file, especially useful for frequently used sequences of RMAN commands.  The script is stored in the recovery catalog, rather than in the file system.

A local stored script is associated with the target database to which RMAN is connected when the script is created.  To execute this script you must be connected to the same target database.  A global stored script can be run against any database registered in the recovery catalog.  A virtual private catalog user has read-only access to global scripts.  To create or update a Global script, you must be connected to the Base Recovery Catalog.

In a Data Guard environment, you must use a recovery catalog to manage Metadata for  all physical databases, both primary and standby.  RMAN references the recovery catalog as the single source of truth for entire Data Guard environment.

You can update a primary or standby control file with a “reverse resynchronization” mechanism, using RMAN.  In “reverse resynchronization”, the metadata flows from the catalog to the control file, rather than the standard way, which is the other way around.  RMAN will automatically perform resynchronizations in most situations in which it is needed.  This means that you will only need to use the manual RESYNC command on rare occasions.

Steps for Managing a Recovery Catalog
1.       Create the Recovery Catalog
2.       Register your target database in the recovery catalog.  RMAN can then store the metadata for your target database
3.       If necessary; catalog older backups whose records have aged out of the control files
4.       Create Virtual Private Catalogs for users, and determine what metadata they will have access to
5.       Protect the Recovery Catalog, by including it in your backup and recovery strategy

Mark Tiger,
Need a Database Health Check, Remote Monitoring, Support, Maintenance, or a Security Audit?

P.S. I am busy preparing Nine books on preparing for the Oracle 11g R2 OCM DBA exam.  Watch this spot for details on the books, as they start becoming available.

1 comment:


    Professional trading signals sent to your mobile phone daily.

    Start following our signals today and gain up to 270% per day.