I probably should have read the documentation first. The names are still confusing, but after downloading the docs for 18.104.22.168 it looks like the upgrade is done with the OUI with a one-system upgrade.
I wonder how many have done this, it's a little disconcerting to me to do this over my production EM. I only have one place to do this. I guess that's what backups are for.
Em release3 (22.214.171.124) is a patchset release also know as minor release which is incremental release over the base version 12c. To upgrade to EM 126.96.36.199 from 12.1.0.x you have to download the em 188.8.131.52 binaries and then invoke the runinstaller à choose 1-system upgrade option. Note upgrade from 12.1.0.x to 184.108.40.206 is with downtime
Step 1: Bring down your 220.127.116.11 (with bp1) /18.104.22.168 OMS and invoke EM 22.214.171.124 runInstaller
Step 2: Upgrade your OMS and repository (Use1-system option in Installer)
Step 3: You will get Agent upgrade console ( AUC) in the EM 126.96.36.199 console
Step 4: Use AUC to upgrade your 188.8.131.52 (with bp1), 184.108.40.206 agents to 220.127.116.11
Refer following collateral-
Understanding Enterprise Manager 18.104.22.168 Upgrade and Agent Upgrades
You can try the mock upgrade in your test system so that you are aware of the steps. Also make sure that you take back up of OMS, REP, AGENT, central inventory, softwrae lib . before doing any upgrade
1 person found this helpful
I did an upgrade from R2/22.214.171.124 to R3/126.96.36.199 on my production Linux x86-64 EM12c server yesterday. Akanksha's advice about stepping through it in a test system is a great idea but some of us just don't have one. So at least one of us has taken the plunge. I had one small problem with one of my sandbox agents (it was my fault, since I had the agent on a tiny filesystem that filled up and then I accidentally deleted a backup the upgrade process makes), but other than that everything appears to be working perfectly and the upgrade was very smooth. Read through the upgrade guide carefully and it is pretty straightforward.
If you have the capability to do it, my preferred way to back things up is to shutdown your OMS and repository database and take a storage snapshot of the volumes containing them before starting the upgrade. Then you can very quickly revert to the snapshot if you have problems.
Thanks Brian, I appreciate the info.