What to Do about RMAN Recovery Catalog When You Upgrade Oracle Database

When you upgrade your Oracle Database, you want to ensure your backup strategy is not compromised. The RMAN recovery catalog is a key part of your backup strategy. What do you need to take care of when upgrading Oracle Database? Don’t let the upgrade of your Oracle Database jeopardize your RMAN backup strategy.

First, let’s agree on the terminology:

  • Target Database – The database that you want to backup. There is where your data is stored.
  • Catalog Database – A regular Oracle Database with one or more catalog schemas.
  • Catalog Schema – A schema inside the catalog database which holds the metadata about the RMAN backups. You can register multiple databases in the same catalog schema.
  • Recovery Catalog – The catalog schema and catalog database together form the recovery catalog.

The topology of RMAN catalog and Oracle Database

What’s Required?

RMAN Client

The RMAN client you use for the backup must be the same version as the target database. I find it easiest to always use the RMAN executable from the same Oracle Home as the target database.

Previously, this was not a requirement, but it is in current versions.

Catalog Schema

The catalog schema version must be the same or higher compared to the RMAN client. When you upgrade the target database and start to use a newer RMAN client, you also need to upgrade the catalog schema.

  • Upgrade the target database.
  • Start RMAN using the executable from the target database Oracle Home.
  • Connect to the target database and recovery catalog and perform the upgrade:
    $ $ORACLE_HOME/bin/rman
    RMAN> connect target /
    RMAN> connect catalog <catalog_schema>/<catalog_schema_password>@<catalog_database_alias>
    RMAN> upgrade catalog noprompt;

If you register multiple databases into the same catalog schema, and you have already upgraded another target database to the same version, then there is no need to upgrade the catalog schema again.

Since the catalog schema is backward compatible, you can downgrade the target database and still use a higher version catalog schema. In case of a target database downgrade, no changes are needed in the catalog schema.

Catalog Database

As long as the catalog database runs on a supported version, you should be home safe. Target databases on Oracle Database 19c support using catalog databases all the way back to Hopefully, you don’t use such old versions anymore. The version of the catalog database does not have to match either the catalog schema or the target database.

You can upgrade the catalog database like any other database. Use AutoUpgrade in deploy mode, and that’s it. A catalog database requires no special attention. But you can always run $ORACLE_HOME/rdbms/admin/dbmsrmansys.sql in the catalog database to ensure all the prerequisites are met (plus dbmsrmanvpc.sql for VPC users).

If your catalog database is on Oracle Database 11g, there are a few details in My Oracle Support Doc ID 1970049.1 to be aware of.

In some situations, building a new catalog database is desirable. Like:

  • Your catalog database is on Standard Edition. Nowadays, a catalog database must be Enterprise Edition.
  • Your catalog database is very old and can’t be directly upgraded.

The IMPORT CATALOG command can move a recovery catalog or selected catalog schemas into a new catalog database.


Given the above requirements, here is an example:

  • You have three target databases running on various releases, let’s say Oracle Database 19c,, and
  • Those target databases must use a catalog schema matching their respective release. You have three catalog schemas in total:
    • One catalog schema is on catalog schema version 19
    • One catalog schema is on catalog schema version
    • One catalog schema is on catalog schema version
  • You have just one catalog database. The catalog database is on Oracle Database 21c.
  • You can store all three catalog schemas in the same catalog database. The catalog schema version and the catalog database release do not have to match.

Now imagine you upgrade the database to Now, you must upgrade the catalog schema version to using the [UPGRADE CATALOG](https://docs.oracle.com/en/database/oracle/oracle-database/19/rcmrf/UPGRADE-CATALOG.html#GUID-E6080FD7-5C15-4659-8D4E-C56E6D9004D1) command. Also, you must switch to an RMAN client on

What About Zero Data Loss Recovery Appliance?

If you are fortunate to have a (ZDLRA), you must not touch the catalog database yourself. All operations on the catalog database must happen via racli. When you update the appliance software, it will upgrade the catalog database underneath the hood.

You can still upgrade the catalog schema using RMAN and the upgrade catalog command.

My Recommendation

  1. Keep your catalog database on Long-Term Support releases. At then time of writing, it means keeping your catalog database on Oracle Database 19c.
  2. Upgrade your catalog database to the next Long-Term Support release before you upgrade the target databases.
  3. Apply Release Updates regularly.


Thanks to my good colleagues, Jony and Andrew, for their help and good pointers. Much appreciated.

Further Reading

4 thoughts on “What to Do about RMAN Recovery Catalog When You Upgrade Oracle Database

  1. Most of the time we replace the RMAN-Catalog databases with a database coming from a template having the new release and re-register the target database + dbnewid for the new RMAN database.

    Our RMAN catalog databases are very small (~3,25 GB) … so.


  2. Hi Christian,
    This is also an option. However, the new recovery catalog for that database will be completely empty. The next time you run a backup, all backup metadata that is stored in the target database control file syncs into the new recovery catalog. But most of the time the control file backup retention time is much lower than what you had in the previous recovery catalog.
    If you don’t care about losing that metadata, then it is a perfectly fine solution. Otherwise, you can use import the backup metadata from the old recovery catalog.


  3. Hi Daniel!
    Is it best practice to use a separate catalog schema for each database (“Each catalog schema belongs to one target database”)? We have all (> 100) target databases in one catalog schema; this makes administering more easy and we have one place to query about missing backups (e.g. to use in EM-metrics). What is the reason to store only one target database in one catalog schema?


  4. Hi Kay,
    That’s a good point. My point was unclear and confusing in this case. Actually, it is the other way around. For easy maintenance, Oracle recommends storing multiple databases in the same catalog schema:
    For increased security, you might want to either use multiple catalog schemas or implement VPC.
    Thanks for the comment. I have updated the post to make it clearer.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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