It sounds so simple – but in this specific case a bit of doc reading is required as upgrading the RMAN catalog to handle Oracle 12.1.0.2 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 12.1.0.2 this week. A simple “upgrade catalog” is not the correct step once you’d like to handle backups of Oracle 12.1.0.2 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:
http://docs.oracle.com/database/121/BRADV/rcmcatdb.htm#BRADV848
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:
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;
It should work now 🙂
-Mike
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
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.
Cheers,
Mike
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.
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 😉
Cheers
Mike
I had performed multiple successful RMAN catalog upgrades from "11.02.00.03" to "12.01.00.01" before posting my last comment. No errors during the upgrade and database Syncs to RMAN catalog are occurring just fine.
Abdul,
thanks for your update – but please read my post carefully.
I’ve said "ORACLE 12.1.0.2".
That change got introduced with Oracle 12.1.0.2 – if you had done RMAN Catalog Upgrades in 12.1.0.1 you won’t see this.
Please see the headline of my blog post.
Cheers
Mike
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?
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.
Cheers
Mike
Please apply Patch# 20432873 — target database
and
and set event="28131 trace name context forever" — on catalog db server
restart the catalog database
Okay this is the doing on the CATALOG. But should I use something also in the Client DB – rsync catalog?
BTW: BUG in Doc https://docs.oracle.com/cd/B28359_01/backup.111/b28273/rcmsynta052.htm#RCMRF161 …. they talk upgrade from 10 to 11.
c.u.
Oliver
Oliver,
as far as I know nothing is necessary for the client. But I’m not an RMAN expert.
Thanks and CU soon at DOAG
Mike
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".
Please set
event="28131 trace name context forever" in catalog database and
issue UPGRADE CATALOG command;
Does RMAN Catalog supports 19c Database version and if so, do you have documentation on how to upgrade from 12.1.0.2.0 to 19c.
Thank you
Sure it does.
https://docs.oracle.com/en/database/oracle/oracle-database/19/rcmrf/rman-compatibility.html#GUID-7A453809-3FB2-4126-AB6F-F8C24C8F8879
And please check the 19c guide – steps are the same:
https://docs.oracle.com/en/database/oracle/oracle-database/18/rcmrf/UPGRADE-CATALOG.html#GUID-E6080FD7-5C15-4659-8D4E-C56E6D9004D1
Cheers, Mike