RMAN Catalog Upgrade to Oracle

It sounds so simple – but in this specific case a bit of doc reading is required as upgrading the RMAN catalog to handle Oracle databases is not as trivial as in the past.

Thanks to a German customer and a friendly colleague from Sales Consulting in Stuttgart I have learned my RMAN lesson for Oracle Database this week. A simple “upgrade catalog” is not the correct step once you’d like to handle backups of Oracle databases in your current catalog schema. 

Even though you may not have ever heard before about Virtual Private Catalogs you need to follow this guideline:


The doc tells you to run this step first:

SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
  • Please ignore the “-all” option printed in the doc – this is a known docu bug
  • If you miss this step the upgrade of the catalog will fail with a warning that your user lacks privileges
$ rman CATALOG my_catalog_owner@catdb
recovery catalog database Password:

It should work now 🙂


Share this:

13 thoughts on “RMAN Catalog Upgrade to Oracle

  1. It also now appears that the RMAN catalog must reside in a Enterprise Edition Database. I hit the issue above, however the subsequent "Upgrade Catalog" resulted in

    RMAN> upgrade catalog;

    error creating create_deleted_object_seq
    RMAN-00571: ===========================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
    RMAN-00571: ===========================================
    RMAN-06004: ORACLE error from recovery catalog database: ORA-00439: feature not enabled: Partitioning

  2. I’m not aware of this – would you please mind to open an SR for this as it sounds a bit strange to myself?

    If you don’t mind to mail me directly (firstname.lastname@oracle.com) I will get back to you directly.


  3. The scenario given in the linked Doc is applicable to "Upgrading Virtual Private Catalogs (VPC)". Otherwise the process is the same as pre-12c. I was able to upgrade mine without these issues. VPC is still an option in 12c, not mandatory. It allows you to use single RMAN catalog for all databases, yet restrict access to data for individual databases. This is practical when different DBAs/DBOs DON’T have access to all databases, but only to specific databases.

  4. Thanks but I disagree!

    Regardless if you’ll ever use Virtual Private Catalogs you will have to execute the dbrmansys.sql script – otherwise your UPGRADE CATALOG will fail.

    The doc is pretty misleading here as it sounds as if you would need that script ONLY IF … but in fact everybody will need to run it to ensure the privs set correctly before the catalog can be upgraded.

    Give it a try without if you don’t believe it 😉


  5. I had performed multiple successful RMAN catalog upgrades from "" to "" before posting my last comment. No errors during the upgrade and database Syncs to RMAN catalog are occurring just fine.

  6. Abdul,

    thanks for your update – but please read my post carefully.

    I’ve said "ORACLE".
    That change got introduced with Oracle – if you had done RMAN Catalog Upgrades in you won’t see this.

    Please see the headline of my blog post.


  7. What happens if you did not run the script dbrmansys.sql and the update fails? now what?

    How would you recover? DBUA could not locate two control files… the automatic restore from RMAN backup did not leave us with a usable database and it took out the listener in the process…trouble associating a new 11.1 listener to the damaged database so I can connect with RMAN to retrieve the control files.

    so what actually happened to the database, RMAN/VPC catalogs, and control files during the upgrade?

  8. Sorry for that – but I can’t really see the relation to the failed RMAN Catalog upgrade. Or are those two separate questions?

    If the latter is true (2 questions), then I can answer the first one:
    – you would see errors about missing privileges. Run the script and redo the catalog upgrade and all is fine.

    For the 2nd question:
    Please open an SR. I can image what has happened but this goes far beyond what I can offer you via the blog. In fact I wouldn’t have done the recover but started the manual upgrade on the command line. As the upgrade on the command line is rerunable (whereas DBUA isn’t) this may have done the trick.


  9. Please apply Patch# 20432873 — target database
    and set event="28131 trace name context forever" — on catalog db server
    restart the catalog database

  10. If you connect to the target database as well as the catalog (rman target / catalog rman_dev/xyz@RMAN_CATALOG_DB) while performing RMAN backups, it will automatically resync. Most RMAN commands perform a resynchronization automatically when the target control file is mounted and the catalog is available. You may choose to connect to target database only to speed up the RMAN backups and then periodically "resync catalog".

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required


I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.