Recovery Catalog Purpose:
The RMAN recovery catalog is a schema created inside of a new or existing database that is used to store metadata about Oracle databases. It’s recommended by XTIVIA that the catalog be created in its own dedicated database due to the importance of its role in database recovery. A few benefits for the recovery catalog include:
- The recovery catalog stores database metadata history for much longer than the controlfile. Also, if the target database’s controlfile and all backups are lost, the metadata is still stored inside of the recovery catalog.
- The recovery catalog can be used as a centralized location to store information about all of your Oracle databases. This makes it much easier to run various reports about the backups.
- If the preferred method is using backup scripts instead of command files, they can be stored in the database for safekeeping. This is useful when the server is lost and the backup scripts along with it.
Recovery Catalog Concepts:
Enrolling a database in a recovery catalog for use with RMAN is called “registration.” It’s recommended that all databases in the environment are registered in a single recovery catalog. This helps keep that centralized metadata repository mindset for Oracle backups.
For access to the recovery catalog, permissions will need to be granted by the owner of the centralization recovery catalog. This is also known as the “base Recovery catalog.” It can revoke permissions already given or grant new permissions to others. Each user of the recovery catalog has full access (read/write) to their own metadata. This is called a “virtual private catalog.” The recovery catalog owner picks which objects each virtual private catalog user can access.
When running backup, restore, and cross-checking commands, RMAN first updates the controlfile and then the metadata inside of the recovery catalog. This process of syncing data is known as “recovery catalog resynchronization.” This ensures that RMAN has the correct metadata from the controlfile.
As mentioned above you’re able to store scripts inside of the recovery catalog. There are two types of scripts, local and global. The local scripts are assigned to a target database registered with the catalog. The local scripts can only be used by the target database. The global scripts can be used for any registered database in the recovery catalog. In order to edit the global scripts, we must first connect to the “base recovery catalog.”
In order to manage backups between a primary and standby database in a Data Guard configuration, it’s highly recommended to have a recovery catalog. There are ways to take standby backups and restore them; however, the recovery catalog makes that process much easier and is a best practice recommended by Oracle as well.
Create an RMAN catalog:
Refer to the charts below for RMAN compatibility.
To create an RMAN catalog, you first need to create a user with the correct privileges. Connect to a new or existing database where the catalog will reside. You will then create a user and grant the user the RECOVERY_CATALOG_OWNER role. Starting with Oracle 220.127.116.11 the recovery catalog database must use Enterprise Edition. Your recovery catalog database needs to be the same version or higher than the database you are creating the catalog for.
SQL>create user reco_cat identified by password
default tablespace tablespace_name
quota unlimited on tablespace_name;
SQL>grant create session to reco_cat;
SQL>grant recovery_catalog_owner to reco_cat;
Once the user has been created, you can now connect to the recovery catalog database and create the catalog. Make sure you have updated the tnsnames.ora file with an entry to the recovery catalog database. From the command prompt log into RMAN and connect to the recovery catalog database, reco_db.
RMAN>connect catalog reco_cat/password/@reco_db
Once the catalog has been created you can now register the database.
RMAN>connect target /
Congratulations, you’re now ready to perform RMAN operations in conjunction with an RMAN recovery catalog for your newly registered database.