I wanted to revisit a Hyperion Essbase adage that every Hyperion Essbase Administrator should know by heart – FIX on Sparse, IF on Dense.
If you don’t know this mantra then burn it into your memory and read on to get the content behind it.
When working with calculation (Calc) script in the BSO world, ideally if you are working with allocations or other logical calculations where you need to isolate a smaller set of blocks you will want to FIX on the dimnesions that are sparse. The long and the short of this is that this is really just a best practice. You could of course FIX on a dense dimension as the Essbase parsing engine will allow it. However, doing so will cause you a very inefficient performance hit because multiple passes through the same blocks will take place. On a small cube you probably wouldn’t notice it but a large cube you will take a hit.
Now putting the IF on dense dimensions is again part of the best practice. Doing this will allow the IF logic to be performed while the block is in memory which means it will end up being a single pass operation.
I have to thank Greg V. for bringing this topic up in a recent conversation which led me to this quick post.
BSO still rocks and is alive and kicking in many organizations. And, I’m not just talking about Hyperion Essbase versions < 7 or Hyperion Planning cubes. Even though ASO reared its head in version 7+ an its agg time gets crazy performance gains over BSO we cannot simply move to the new Aggregate Storage option and forget the finer points of BSO and how it all started off in the first place. Keep living BSO, you rock.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
Which RAID should you use with SQL Server? Learn the differences between RAID 0, RAID 1, RAID 5, and RAID 10, along with best practices.