11.2.5 Install - First Impressions
Last week Oracle dropped 11.2.5 on e-delivery and I gave a quick summary of what was found in the read me and promised to get back to you with a first impressions from an install.
I've done the install now for two (2) scenarios:
Clean 11.2.5 Install using SQL Server
Apply Maintenance Patch to 11.2.4 > 11.2.5
This is my experience, and your mileage may vary but here goes….
Install:
The install was straight forward in both scenarios. The installer does it's normal pre-checks and then either asked what I wanted to install or showed me a list of what was installed and asked if I wanted to upgrade. There were no surprised here and it performed as I expected.
One thing to note in 11.2.x - in a new install all packages are checked by default at the parent level. HFM however is only checked for the SDK, make sure you expand all the levels and select the components you want installed. I forgot this and ended up running the installer twice to get the HFM WebApp and HFM server installed.
From here let’s cover each scenario separately….
In both installs I am using Windows Server 2019 as my OS choice.
SCENARIO 1: CLEAN INSTALL
Windows Server 2019
MsSQL Server 2017 Edition
After I fixed the HFM install, the config went smoothly based on the documentation. RCU config worked
And I updated the RCU.properties file before running the configuration tool.
Once configured and then started I verified some things about the new middleware:
WL Version is 12.2.1.4.0
Node Manager is 12.2.1.4.0
Oracle-HTTP-Server-12.2.1.4.0/2.4.39
Build ODI_12.2.1.4.0_GENERIC_190913.1025
Java is now: 1.8.0_251
Some Infra things to note:
Java:
Oracle changed the path to the primary JAVA instance, instead or using a version like …\oracle\middleware\jdk_1.0.8_251 path at has been done in the past it is now simply …\Oracle\Middleware\jdk. I'm sure this was done to make updating the java version simpler going forward.
Planning RMI issue still exists:
Planning RMI still does not correctly start. This is a known issue, still not resolved in 11.2.5. The RMI Property "JVM Library" in the registry must be updated to use a 32-bit java. The path the installer populates the registry with is, …Oracle\Middleware\EPMSystem11R1\common\JRE\Sun\1.6.0\jre\bin\client\jvm.dll ,this does not work for two reasons, 1. it references 1.6.0 in the property which is invalid (1.8.0 is installed), it points to a 64-bit java which does not work…
C:\Oracle\Middleware\EPMSystem11R1\common\JRE\Sun\1.8.0\bin
The path needs to be updated to the Oracle DB Client JRE included, if you installed the native Oracle client, which I do even when using MsSQL server, down the road we may want to use an Oracle Data Source so why not?
That path is: C:\Oracle\Middleware\dbclient32\jdk\jre\bin\client\jvm.dll
FDMEE:
Some of you may have noticed in prior 11.2 version FDMEE process logs incorrectly echo out a JAVA_HOME pointing to 1.6.0. It did not seem to affect the functionality, but it was confusing and misleading in the log files..
The issue is a value in the FDMEE tables. There is a table AIF_PROFILE_OPTION_VALUES with a row for JAVA_HOME. If you look in any 11.2 version prior to 11.2.5 you will see an invalid 1.6.0 path. In 11.2.5 Oracle fixed this and the value now correctly reflects the path to …Oracle\Middleware\jdk.
If you are on a previous 11.2 release you can update this value in the table to clean up your logs.
For the remining components there were no surprises. Everything came up as expected and the validation tool showed they were all functional. I even restarted the server and did a clean start to verify everything was working.
SCENARIO2: Maintenance Application on top of existing 11.2.4 install
Windows Server 2019
MsSQL Server 2016
Configuration Experience:
RCU.properties
First thing I noticed was the RCU.properties file was overwritten with a blank template.
I was not intending to re-build the WL Domain, so this was not too big an issue for me. I left it blank to see what would happen and my application deployments all completed successfully. From what I can tell, the config tool only needs this file the first time it builds the WL domain folder on each server.
FDMEE:
For a maintenance upgrade there are new MANUAL CONFIGURATION steps for FDMEE that need to be done prior to starting the system. These center around an OCI upgrade utility, on windows named ua.bat. I ran into issues running this utility and have opened an SR for its behavior but was able to find a workaround.
For my install in SQL server my FDMEE database is named EPM_FDMEE, but I do not use separate credentials for each database, my user hypsql has "dbo" access to all the databases. This is not uncommon on the SQL side, but very different from the ORACLE side. I started the utility and made the selections outlined in the documentation which brought me to a Database Connection panel. I entered the MS SQL information and made the connection using the button in the utility and it automatically populated a drop-down box titled "SCHEMA" below the connect info with "EPM_FDMEE." This box has another below it that says, "SCHEMA PASSWORD." In MsSQL server this is not a conventional idea. I did not have a login with the name "EPM_FDMEE" I had a database by that name. There simply was not password. I tried several different things for this value - the pw for HYPSQL, I changed my connection identity to SA hoping it would let me use HYPSQL for the schema identity, but nothing worked. The drop down that was filled with "EPM_FDMEE" was auto populated and there was no way to change the value and clicking the "drop-down" had no content.
I have opened an SR for this, but I was able to find a workaround. I created a native id named EPM_FDMEE and gave it "dbo" access to my Database EPM_FDMEE. Then I had a password to put into the utility and that worked. For installs where you use login ID's that match database names you might never encounter this issue, but in my experience MsSQL DBA's like to give me one ID with access to all the databases.
Once I figured all that out, I was able to run the config tool successfully and it did not error on any of the tasks. All Web Deployments reported successful, even though the RCU.properties file was still blank. After everything was configured and then started I verified some things about the new middleware:
WL Version is 12.2.1.4.0
Node Manager is 12.2.1.4.0
Oracle-HTTP-Server-12.2.1.4.0/2.4.39
Build ODI_12.2.1.4.0_GENERIC_190913.1025
Java is now: 1.8.0_251
Then I ran the EPM Validation tool to make sure everything was working. Everything returned green. I stopped all the services and rebooted the server. Once the server came back I logged in and started node manager, then OHS, and then ran the "start.bat" file to start all the component on the server.
I was on the home stretch! Until I ran the validation tool. APS was not happy.
APS:
I went to the WL domain folder for APS and went to logs\ and opened the AnalyticProviderServices0.log
This reported a "classdefnotfound" error when trying to start the "aps" deployment. I've encountered this before, so I was half expecting it, but my success with the clean install had me hopeful. The Oracle KB can be searched and the recommended "fix" for this is to install an 11.1.2.4 patch for APS. "11.1.2.4.040", I downloaded the patch. Stopped all the services and used opatch to install the patch.
OPATCH was successful, and the README does not say you have to re-deploy so I tried that first. I deleted the tmp, logs, and cache dirs from the WL domain for AnalyticProviderServices0 and started the service in windows - NO DICE! Still got the same error. To keep the story short, I and several of my colleagues went through every reconfig option we could come up with to solve this issue. We did not solve it. My APS server still will not start in 11.2.5. I have a bug opened with oracle. Although I followed the Oracle KB what has worked in the past, did not work for me in 11.2.5.
Conclusion:
Other than APS, everything else seems to be happy. Logging into workspace I was able to open everything including a sample HFM app, data management and Planning. For a clean install 11.2.5 went smoothly. As a maintenance patch I ran into a few more issues, and would not be ready to upgrade anyone with APS in the mix, until Oracle provides me with an answer to my SR.