Upgrading to 11.2.15

Oracle recently released 11.2.15 as a Quarterly update. This update is more involved than previous versions with 11.2.15 essentially being an in-place upgrade. A rather large change for this upgrade affects Essbase, which is upgraded to 21c. 11.2.8 was the last update that included an installer, since then, the updates have been a set of patches that were applied. This release, 11.2.15, is a full install. If you’re running as an update (and not a new install), you must patch to at least 11.2.12 before you can update to 11.2.15. One of the warnings in the documentation is that as of now, there is no migration between 11.2.14 and 11.2.15. You must do an in-place upgrade and can only migrate objects between 11.2.15 installs. They plan to release a patch to allow object migration between 11.2.14 and 11.2.15, but there is no date provided for that release.

The install documentation gives the normal warnings about backups, etc. This is not a ‘make sure your backups are up-to-date’ warning. You must make copies of the folders that you have immediate access to. For this, we used 7-zip to keep the size down while still having immediate access.

For our testing, we used a 2-server Windows 2019 environment. Essbase (ESS15) was installed on one server, while all other products were installed on a separate server (HSS15). This is a common configuration in many on-premises environments.

Installation

The installation starts as any other maintenance update – you are locked in, and you must select all the products available that are installed and can’t select anything else. Some items such as WebLogic and the Oracle DB clients aren’t selected and can’t be – this is because those products don’t need updating.

You will find some differences. The largest is that there’s only one item under Essbase instead of the multiple items in 11.2.8 and prior.

11.2.8 Product selection:                                                   11.2.15 Product selection:

The Essbase server will show up for upgrade wherever Essbase, Essbase Amin Services or Provider Services are installed. This is because the three are options within the Essbase server now instead of separate installs.

When you get to the install screen, you will notice that on servers with Essbase installed, it will read ‘Maintenance’, while servers with EAS or APS only will show as ‘Install’.

RCU Configuration

Because Essbase 21c is WebLogic-based, the RCUSchema.properties file will become necessary on the Essbase server, which is new. The install documentation becomes a bit confusing at this point and it took multiple attempts to successfully complete Essbase configuration.

It wasn’t clear if the RCU.bat needed to be run on the Essbase server, but since the properties file has variables and will now be in use, it felt safest to go ahead and run it to create the WebLogic schemas for that server. As always, each server must be unique. HSS15 was used as the prefix on the Foundation server, so ESS15 on the Essbase server.

This is where it gets confusing. The steps for running RCU tells you to deselect the (new) Essbase option in the RCU:

But it then tells you to add the Essbase RCU prefix in the RCUSchema.properties.

After opening RCUSchema.properties on both servers, a new section with 2 variables was added to the bottom of the file.

Because the instructions weren’t clear, a couple of variations were tried.

• Not including Essbase in the RCU run but using ESS15 as schemaPrefixEssbase (it being the same as schemaPrefix in the same file) which failed.
• Running the RCU and selecting Essbase with a new prefix….that failed too.

The solution was to NOT run the RCU Essbase option and to enter a NEW (unused for anything yet) prefix for schemaPrefixEssbase. The configuration tool runs the RCU with that prefix, so if it exists already, the configuration fails.

SchemaPrefixEssbase values of HSS15E and ESS15E were added for the 2 servers and also added the database connection string for dbURLEssbase on each. The rest of the files on the Essbase server (the Foundation was already filled out from the original configuration) had to be completed.

Once the above steps were completed correctly, the errors during configuration ceased.

Configuration Tool

There’s a misleading instruction in the documentation.

Starting the WebLogic Admin Server was always necessary when deploying from other servers but was a problem if you had it running when deploying on the local server. This appears like they changed the behavior, requiring WL Admin server to run for both local and remote deployments.

However, when following this instruction, the same results occurred as would have in previous versions – the configuration utility closed the admin window when run on the server hosting WL Admin services. WebLogic Admin Server doesn’t fully shut down and remains locked. As in the past when this happened a reboot and manual removal of the file to start the WebLogic Admin Server was required.

So contrary to the new message, the behavior remains the same as it has in the past. WebLogic Admin Server should not be running when deploying on that server but should be running when deploying on any other server.

Post upgrade, it’s required to deploy all application servers again select ‘Configure Application server’ for HFM and run Configure Essbase Server.

EAS and Provider services no longer show up for configuration and are no longer listed on the deployment page.

While waiting for the application deployment to complete, a step to clear each application deployment’s ‘tmp’ folders was going to be completed, as is normally required in an update and the configuration tool removed the folders.

The Essbase configuration was a little strange.  When running the Foundation server (where both EAS and APS were installed), the screen came up with only APS selected and would not allow modifications on the screen – so it had to be selected as-is.

On the Essbase server, that also seemed to be the case. There was no ability to add or remove Enable status but the ability to modify Essbase items was allowed.  The Cluster name and ARBORPATH reset to default values, so it had to be modified to the correct name/location.

After a little testing and research, it appears you can only select Enable on one of the items the very first time you run the configuration. After that, it’s locked in. Since this is an upgrade, those selections have already been made. From research of other 21c documentation, it appears EAS must be on the same server as Essbase Server.

Note that the port range has changed by default. If you have opened firewall ports, you will need to make a modification – either open a new range of ports or update the default port range. ESSLANG is gone (21c only uses UTF8, so this variable can no longer be set) and the binding host is gone.

Web Configuration must be run one last time to update for the changes in Essbase.

Post Configuration

A single ‘Oracle Essbase Service’ replaces the Essbase OHS service, EAS and APS.

Even though the previous configuration was set to use a specific user (.\opc), Essbase was configured using a ‘Local System account’. This is easy to update but should be kept in mind.

The configuration creates a new domain on each server running an Essbase component:

Looking at OHS, the final config updated the mod_wl_ohs.conf – removing old EAS / APS entries and adding the new ones for 21c.

The first thing you must do after starting services is to follow the Workspace refresh instructions.  The document tells you to use port 9000 – that’s only if it’s a single instance deployment. In most cases, you will have to use port 28080.

Running the validation report shows Essbase with new connection information:

EAS has a slightly different look:

But everything else seems to have updated correctly and checked out.

This is a BIG update.  Be prepared for that.  The readme has several warnings that are important to note before starting.  Essbase cubes are updated to UTF8, so unless you’re already using Unicode for your cubes, it may take a while to convert.