An in-place upgrade from either Hyperion / Oracle EPM 126.96.36.199 or 188.8.131.52 (the only certified paths to get to 184.108.40.206) 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 220.127.116.11.
- 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 18.104.22.168 and FDMEE 22.214.171.124 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 126.96.36.199 and will perform the in-place upgrade to 188.8.131.52 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 184.108.40.206 Middleware backup, restore it to my botched/patched 220.127.116.11->18.104.22.168 in-place upgrade VM and see if I can put Humpty Dumpty back together again.
And here we thought RCU was difficult....