Patching Essbase in OAC to 17.3.3-926 with Oracle 11g RDBMS
I recently applied the 17.3.3-926 patch to Oracle Essbase Cloud Service (ESSCS) in Oracle Analytics Cloud (OAC). If you have not patched OAC yet, the good news is that this process is as close to “one-click” as it can get, with the capability to perform a “pre-check” of the instance (and while we have yet to see this fail, it is good to know that we can check to see if any known conditions for failure exist).
When the patching is initiated, it first performs a backup of the instance, just in case a rollback is needed. Once the backup is successful, the patching process begins. In our experience, this process takes about 30 minutes, including the backup. However, I fully expect that will vary depending on how much content is housed within the instance.
When I restarted the instance after the patch, I found that Essbase would not start. Digging through the log files on the instance, I found an error message that indicated that a “schema update” failed with the error message: “ORA-02000: missing ( keyword.”
Since the patching process in ESSCS is hidden from the customer, we contacted Oracle Support. After consulting with the product development team, we found out that the issue was because we were using Oracle Database 11g as our relational data store, a.k.a. DBaaS (Database-as-a-Service). By default, the update assumes that the latest version of the Oracle database (12c) is being used. To overcome this, Oracle Support provided a fix that required an update to a server script. The script being updated (setDomainEnv.sh) is found at the location “/u01/data/domains/esscs/bin” and Oracle Support advises backing up this script before making changes.
To change this script, one needs to change to the “Oracle” user with the command “sudo su – oracle.” Find the following words in the script: “-Dessbase.datasource=BIPlatformDatasource”
and replace it with “-Dessbase.datasource=BIPlatformDatasource -Dessbase.schema.update.disabled=true.”
Once the changes are made, log out of the instance and restart it using the “My Services: console. The updates will tell Essbase to skip the “Schema Update” step. As long as there isn’t anything else broken with the instance, this should allow Essbase to start up.
Oracle confirms that there is no functionality lost in using Oracle database 11g with ESSCS, and this issue will be fixed in patch 17.4, which is expected out in a couple of months.
However, this stresses the importance of having a pre-production instance to verify that the deployed patches will not introduce issues with your setup. Since a PaaS like OAC allows for a lot of flexibility in how one uses one’s environment, it is important that such system changes are tested before they are released.
While included pre-checks can check for conditions on the Essbase server itself, when we consider the ways the instance can be connected to other services, whether in the Oracle Cloud or outside services like on-premise systems, not every possible condition can be checked for. That is because the tools included with OAC are robust and flexible enough to allow for solutions restricted only by one’s imagination.