Last night we decided to patch our OAC instance to the awaited 106 release for Essbase Cloud. There were actually 2 patches made available, one for Essbase Cloud and one for BI Cloud. I installed them consecutively (although you can run all patches at once since they hit different VM’s – we haven’t tried this yet) and it took about an hour total doing it this way.

Notification & Prep

The first step is to know that you have a new patch. I actually didn’t realize that a new one went out and just happened to stumble across it when performing another admin task in My Services within OAC. Our team was also notified by the Oracle Product Development team, as this is an anticipated release with fixes and new features. We are actively working with the Oracle Product team to find a better way to notify customers.

The next step is to ensure that an Analytics Service Administrator is logged into My Services to run the patch. Note that an administrator in My Services is not the same thing as an administrator in Essbase Cloud. Essbase Cloud currently uses native security so these types of administrator rights are independent and focused on Essbase application and cube administration tasks.

I first ran the Essbase Cloud patch (which begins by doing a full backup) and noted the following times for each step of this process, although I imagine that these times will vary depending on how many apps/cubes and storage space you’re using:

• Essbase Cloud backup: ~10 minutes
• Essbase Cloud patch: ~20 minutes

After the Essbase Cloud patch was completed, I ran the BI Cloud patch and noted the following times. Again, these theoretically should vary depending on your unique environment:

• BI Cloud backup: ~7 minutes
• BI Cloud patch: ~12 minutes

Patching OAC

Within My Services, navigate to the OAC tile, click the action menu, and navigate to Open Service Console:

Notice that patches are available to both of the OAC instances:

I decided to go the Essbase route first. Click on the service instance name. You’ll be given more information that a patch is available, both on the left-hand side, as well as on the Patching screen.

You’ll want to take note of a couple of things here. First, the release date. Although the date stamped here won’t make much sense, I’ve been told that it’s the date that the patch was first released internally. Then Oracle’s teams spend about a month testing it before it’s finally released to the public. The second item to note is whether or not a restart is required. If a restart is required, add at least 15 minutes to the overall process. Regardless of the restart requirement, alert your users and admin teams to when the patching will occur. They should expect to be out of the system during this process.

Note that if you open up the Readme (which will give you formal notes about what’s in the patch), the “Component Version Configuration” link doesn’t work. I’ve reported this to the Oracle Product Development team and they are working to fix this. Right now, this Readme is the best way to find out more about what’s in the new patch.

Click the action menu to the right side of the patch name and run a precheck just to verify that the patch will not result in ramifications or possible conflicts:

This precheck takes less than a minute.

Remember to refresh the available patches section manually, as shown by the refresh icon below. Otherwise, you’ll just sit there wondering if it’s done. There is also a message at the bottom indicating that a precheck is in progress:

When the precheck is done you’ll see a green check mark. You can click on the hyperlink to read more information about the precheck.

Next, it’s time to patch! For Essbase Cloud, devote at least a half hour of total wait time. Note that every time a patch runs, a full backup is completed first. Select to Patch the instance:

Enter an optional note. This is an internal note for your company.

Then the patch runs. There are several indicators that a patch is being applied to Essbase Cloud: the logo changes, a message is displayed:

And the left-hand pane will let you know that the system is patching, as well as which version it’s being patched to:

As mentioned before, a full backup runs first. You can check the progress of this first process in the Backup tab:

Note that backups are kept for about a month. The expiration date is listed under the backup date and time stamp. These backup snapshots can be downloaded if you need an archive of them.

Once the backup is completed, a green check mark will appear:

Switch over to the Patching tab to check the progress of the next step, the actual patching. Once this step is complete, a green check mark will appear next to the patch icon and the patch itself will move from the “Available Patches” section to the “Patch and Rollback History” section. Yes, you can rollback a previously applied patch.

Now it’s onto the BI Cloud patch! I’m going to keep this section abbreviated, as the steps are the same.

Look at the information on the patch to see if you need to add extra time to the entire patching process due to a restart. In this case, no:

Run the precheck. If it’s successful, run the actual patch.

The backup will run first.

Once the backup is completed, the patch will run.

Luckily, both patches ran without error.

Post-Patch: Hiccup and Fix

The last time our interRel team attempted a patch, the patch was successful, no further steps were required, and the patch only applied to Essbase Cloud. This time, however, there was a small hiccup. I noticed that I couldn’t connect to any cubes when attempting to connect several minutes after the BI Cloud patch was completed:

In My Services, I also noticed that our OAC instances were in an odd state. Normally they display 2 total instances instead of “1 configuring” and 1 normal:

When I attempted to reach the Essbase Cloud web interface, the page briefly came up and then went blank:

Something was definitely wrong, but based on the Essbase error message, I knew it was fixable. Our team had seen this once before during the setup and configuration process of our OAC environment. My plan was to connect to the Essbase Cloud server via SSH, log into MaxL, and enable commands and connects. This is a familiar step that Essbase admins sometimes need to do during maintenance with on-prem. So that’s what I did.

Although I have since confirmed that this is a bug and the Oracle Product Development team is now working on preventing this in the future, I detail out these steps for you in case you need to use them. You might need to use this in general and not necessarily related to patching OAC.

The Oracle Product development team is not keen on folks connecting to the Essbase Cloud server directly, and will eventually put in enhancements so that we won’t have to. Note that you can get to MaxL through the EssCLI (Essbase Command Line interface) – however, you can’t run MaxL interactively. Therefore, I chose the SSH route since I’m comfortable with it. For a refresher on how to connect to the Essbase Cloud server use SSH, check out this blog post.

Here are the commands that I used (with some security editing):

ssh -i (location of private key file) opc@(public IP Essbase server address)
sudo -su oracle
cd /u01/data/logs/essbase/essbase/app
ls
(* then make a note of all apps listed in this directory)
cd /u01/data/domains/esscs/esstools/bin/
./startMAXL.sh
login (admin user) (password) on localhost;

Then for each application on your environment run the following 2 MaxL commands:
alter application (app name) enable commands;
alter application (app name) enable connects;

Finally, log out of MaxL and your terminal client.

There is probably a faster way (scripting via the EssCLI?) to handle this, but the above is what I did because I knew it would work.

A Preview of Some New Essbase Cloud Patch 106 Features

I personally haven’t read up on all of the patch 106 new features yet. Glenn Schwartzberg will be blogging about them soon. However, I immediately noticed a few changes in the web UI with this release:

Exciting stuff!