Today I’ve upgraded EM12c for a customer from the second-last version (126.96.36.199) to the last one (188.8.131.52) and the EM Repository from 184.108.40.206 to 220.127.116.11.
The upgrade path was not very easy: EM 18.104.22.168 is not compatible with a repository 22.214.171.124 and EM 126.96.36.199 requires a mandatory patch for the repository if 188.8.131.52 (or an upgrade to 184.108.40.206).
So I’ve done:
- upgrade of the repository from 220.127.116.11 (in Data Guard configuration) to 18.104.22.168
- upgrade of the EM from 22.214.171.124 to 126.96.36.199
- upgrade of the repository from 188.8.131.52 to 184.108.40.206 (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 220.127.116.11.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)
- Oracle Grid Infrastructure 18c patching part 3: Executing out-of-place patching with the local-mode automaton - January 13, 2019
- Oracle Grid Infrastructure 18c patching part 2: Independent Local-mode Automaton architecture and activation - December 16, 2018
- Oracle Grid Infrastructure 18c patching part 1: Some history - November 16, 2018