I have much to say about the in-place upgrade to Hyperion / Oracle EPM 11.2.5. Anybody who knows me well... knows that I pretty much despise Hyperion in-place upgrades, and moving to 11.2.5 in-place is no exception. In fact, it may be one of the harder ones.
We've already talked on this blog previously about how applying the quarterly Oracle Critical Patch Update ("CPU") for Oracle Fusion Middleware - OPatch for Weblogic in particular - currently bricks your in-place upgrade from either 11.2.3 or 11.2.4 to 11.2.5.... unless you backed up your Middleware folder prior to patching it.
But this post is about other factors that'll make you want to tear your hair out.
Let's begin with OPMN.
No matter which version of EPM you're upgrading from, if you're upgrading in-place you will need to edit your opmn.xml. The in-place upgrade doesn't require you to reconfigure Essbase, and that is messy anyway and trying to reconfigure Essbase makes the system think you're trying to add to the Essbase Cluster or create a new one, rather than updating the one that already exists.
One thing I do like about 11.2.5 is the name of the JDK folder is now generic; Oracle finally relented and removed the reference to the version and update numbers in the folder's name. It is now simply \Oracle\Middleware\jdk instead of jdk1.8.0_181 or jdk160_35. But because of this, you'll need to do some surgery.
Edit opmn.xml, find the reference to the jdk folder as shown in my screenshot above, and wipe out the version and update numbers so it is exactly DRIVELETTER:\Oracle\Middleware\jdk\jre\bin\server
The 11.2.5 web version of the README indicates an in-place upgrade on top of either 188.8.131.52 or 184.108.40.206 directly to 220.127.116.11 is "certified". Um... no. Caesar says "thumbs down".
I've been working my way through an in-place update to 11.2.5 for a customer who lagged behind and is still on 18.104.22.168.7xx. I really cannot recommend this approach, despite the README's claim that it is certified. I finally got OHS, Essbase, Planning RMI, and the WebLogic managed servers online. This upgrade path is fraught with multiple problems and should only be attempted by EPM Infrastructure experts.
Look forward to a more detailed post on this 22.214.171.124 -> 126.96.36.199 in-place upgrade -- problems & solutions, after the dust settles. I have one last problem to solve, and this is: why the heck did the upgrade not convert the RA Framework content over to Document Repository? Massaging LCM files isn't the answer as their RA Framework repository is too massive for LCM to handle all in one shot. Ugh!
Great info Dave !!ReplyDelete
What about the hfm 11.2.5? We are upgrading to 11.2.3 for my client who uses hfm quite extensively. We are in our UAT phase and found out that our consolidation is taking double the time of 188.8.131.52. Oracle said its a known bug and they may give the solution in 11.2.5. We are now torn Between whether to try in place upgrade or do a fresh build of 11.2.5ReplyDelete
I cannot in good faith advocate an in-place upgrade from either 184.108.40.206 or 220.127.116.11 to 11.2.5. My reasons for this statement will become readily apparent within my next blog post here on this site.
I have a customer live on HFM 11.2.4. They are reporting inconsistent consolidation performance -- sometimes in line with their prior 18.104.22.168 system -- sometimes taking twice as long. They're having to do more frequent restarts of EPM services AND reboots of the SQL Server because the SQL host server keeps running low on memory now. Another customer I'm upgrading to 11.2.5 now does not have HFM so it will be some time before I have solid evidence "from the wild" on how HFM 11.2.5 behaves in real-life situations.
We are not going to do inplace upgrade to 11.2.x from 22.214.171.124. We faced this consolidation issue after we did the out of place build of 11.2.3. So we were deliberating to go to 11.2.5 in place from 11.2.5. But oracle confirmed that this consolidation timing is an issue in 11.2.4 & 11.2.5 also. Bug 32923720 & Bug 32948461. And (wink wink) there is no ETA for the fix. Development is working on this.Delete
Do you have details on these bugs? We're about a month away from go live on 11.2.4 and we haven't noticed any inconsistencies in consolidation performance. We're on Oracle 19c though. Not sure if what you're seeing is SQL Server specific. Definitely interested in hearing more about this issue.Delete
We are on Oracle 19c..bug 32923720 & bug 32948461ReplyDelete
Description is " consolidations are taking longer time in HFM 11.2.4 release compared to 11.2.4ReplyDelete
We are facing same consolidation performance issue starting from 11.2.3 onwards .Tested 11.2.4,11.2.5,11.2.6 and 11.2.7 in all cases performance did not improve at all. Did you guys moved further with consolidation issue ? If you fixed it can you please let us know what steps you took to take care of this issue . We are on Oracle 19c as well.Opened SR they mention it fixed in 11.2.5 onwards but it does not show any improvement.