An in-place upgrade from either Hyperion / Oracle EPM 22.214.171.124 or 126.96.36.199 (the only certified paths to get to 188.8.131.52) fails if one applied the OPatch update necessary to subsequently apply the quarterly Oracle Critical Patch Update ("CPU") for Oracle Fusion Middleware - most notably WebLogic and OHS.
The commenter community seems to be in agreement that the best approaches are:
- If Oracle Middleware, Opatch in particular, has yet to be patched, back it up! If disk space is available, back up \Oracle\Middleware in its entirety before applying the quarterly Cracle Critical Patch Updates.
- If the system is unpatched, it is apparently safe to perform the in-place upgrade to 184.108.40.206.
- If the system was patched, it will be necessary to restore \Oracle\Middleware\Opatch and perhaps \Oracle\Middleware\wlserver and \Oracle\Middlware\oracle_common. The jury is out on exactly where the bug resides with respect to patching. All that is known for certain is Opatch is a primary culprit and the Opatch update cannot be rolled back without performing a filesystem restore for the Opatch folder structure.
Additionally, I experienced issues with missing jar files where ODI 220.127.116.11 and FDMEE 18.104.22.168 is concerned. I have yet to determine if this is due to the issue mentioned above.... an EPM 11.2 customer-facing upgrade that just got handed over from me to the UAT team has eaten up all of my "free time".
I've installed a fresh VM and a fresh/unpatched EPM 22.214.171.124 and will perform the in-place upgrade to 126.96.36.199 to vet if ODI/FDMEE is truly broken or not in this release. The EPM Configurator tool does not reveal the problem when FDMEE is broken, but there's a way I can see it on the back-end.
Finally, time permitting, I'll take my unpatched 188.8.131.52 Middleware backup, restore it to my botched/patched 184.108.40.206->220.127.116.11 in-place upgrade VM and see if I can put Humpty Dumpty back together again.
And here we thought RCU was difficult....