Today I’ve upgraded EM12c for a customer from the second-last version (188.8.131.52) to the last one (184.108.40.206) and the EM Repository from 220.127.116.11 to 18.104.22.168.
The upgrade path was not very easy: EM 22.214.171.124 is not compatible with a repository 126.96.36.199 and EM 188.8.131.52 requires a mandatory patch for the repository if 184.108.40.206 (or an upgrade to 220.127.116.11).
So I’ve done:
- upgrade of the repository from 18.104.22.168 (in Data Guard configuration) to 22.214.171.124
- upgrade of the EM from 126.96.36.199 to 188.8.131.52
- upgrade of the repository from 184.108.40.206 to 220.127.116.11 (in Data Guard configuration), from Solaris to Linux
In my case, I was particularly concerned about my customer’s EM topology:
- two OMS in load balancing
- console secured with a custom SSL certificate
- a good amount of targets (more than 800 total targets, more than 500 targets with status)
- a lot of jobs and custom reports
- a big, shared central software library
- many other small customizations: auth, groups, metrics, templates…
I will not bother with the actual execution steps, every installation may differ, I strongly recommend to read the upgrade documentation (I know, it’s HUGE 🙁 ).
Just to resume, the upgrade guide is here: https://docs.oracle.com/cd/E24628_01/upgrade.121/e22625/toc.htm
in my case I had to read carefully the chapters 3, 4, 5, 6 and appendixes G and K.
By following every step carefully, I had no problems at all and at the end everything was working correctly: all the targets up, the load balancing working in SSL as expected, the jobs restarted and ran successfully…
It has been incredible to see how many operations the OUI has done without raising a single error!!
Ok, it’s not just a Click Next Next Next Next installation, there are a lot of steps to do manually before and afterwards, but still… very good impression.
It took a little more than one hour to upgrade the first OMS (this also upgrades the EM repository) and a little less than 20 minutes to upgrade the second one.
Let a couple of hours for checking everything before, staging the binaries, taking backups/snapshots, creating restore points… and one hours more for upgrading the central agents and cleansing the old installations.
About upgrading/moving the repository, check this good post by Maaz Anjum: MIGRATE ENTERPRISE MANAGER 18.104.22.168.0 TO A PDB FROM A NON-CDB, even if you don’t plan to do it, it’s worth a read.
Latest posts by Ludovico (see all)
- Multitenant Pills: Partial PDB cloning (and cleanup) - May 22, 2020
- Multitenant Pills: Pushing your PDB to the Cloud in one step? - May 18, 2020
- Multitenant Pills – Change DBID for an existing PDB - May 14, 2020