A quick post prompted by a recent OTN thread. The Essbase Database Administrator’s Guide tells us that the recommended size of the Data Cache is 1/8 the size of the Data File Cache. Even granted the usual caveats on these recommendations, I think this one is really odd.
When using bitmap compression, squeezing a given set of data into a denser arrangement doesn’t always result in a space saving of the same magnitude
Some Old News
One relatively unsung enhancement to Essbase in 188.8.131.52 was a change to CALCTASKDIMS behavior. Before 184.108.40.206, CALCTASKDIMS defaulted to a value of 1. From 220.127.116.11, 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 18.104.22.168 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.
Block density – that is, the percentage of non-missing dense intersections at a non-missing sparse intersection – is an important performance parameter for BSO databases, but the Essbase documentation does not provide details of the algorithm used to derive the ‘Average Block Density’ statistic visible in EAS or via MaxL. Continue reading