Essbase 19c appeared on the Oracle Cloud Marketplace back in September 2019, but that initial release was only available on a “BYOL” (bring your own license) basis. That meant that only customers who already owned – or went out and bought – on premises licenses were able to comply with its license terms. The list price for a single processor on premises Essbase license being USD138,000 – plus a cool USD30k and change for annual maintenance – this presented a barrier to entry for potential users accustomed to subscription or usage models for cloud systems. It was also a problem for medium sized consulting shops and people like me who had been in the habit of running the local installations permitted under previous license terms for educational purposes. I’m sure I was not alone in making this point frequently and vigorously to Oracle (aka harassing Product Management) and I’m glad to report that an additional Marketplace option has now appeared under which Essbase is licensed on the Universal Credits Model or “UCM”. This means that there are two competing pricing models for Essbase 19c on Oracle Cloud Infrastructure. So how do they pencil out?
Snappy title, huh?
This post is a quick note on a powerful but hopefully non-obvious feature of MDX against Essbase, inspired by an interesting thread on the Network54 Essbase board. That discussion is about implementing custom groupings from the reporting layer – i.e. being able to retrieve roll-ups that don’t exist in the underlying cube. For example, the ASOsamp.Sample Products dimension looks like this:
Suppose that you want to do some reporting on the total of [Personal Electronics] and [Home Entertainment], for which there is no roll-up in the cube. MDX can do the summing, of course. But won’t that mess up any ratio- or variance-type measures, by adding the values for [Personal Electronics] and [Home Entertainment] together? As it turns out, the answer is ‘not necessarily’. Continue reading
Some Old News
One relatively unsung enhancement to Essbase in 126.96.36.199 was a change to CALCTASKDIMS behavior. Before 188.8.131.52, CALCTASKDIMS defaulted to a value of 1. From 184.108.40.206, Essbase selects a value for CALCTASKDIMS automatically unless overridden by the user with either the CALCTASKDIMS .cfg file setting or the SET CALCTASKDIMS calculation command.
So why am I blogging about this years after 220.127.116.11 came out? First, there is a good theoretical reason why the above Essbase ‘enhancement’ might have a seriously negative effect on calculation performance, which can be especially surprising when it occurs following a supposed upgrade. Second, this actually bit a coworker a few days ago, and it’s always satisfying (for me, if not my coworker) when empirical data and theory coincide.