November 13, 2007

Oracle OpenWorld - Day Three - Tips and Tricks for Essbase

I had an opportunity to talk briefly with Steve Liebermensch from Oracle before his presentation on "Tips and Tricks for Hyperion Essbase - System 9." I hadn't seen him since Hyperion Top Gun back in January when Steve, Carol Crider, and I sat in the back of a 64-bit Essbase optimization presentation arguing over the presenter's tips.

Since Steve had an hour to go until his presentation, I struck up a conversation on how most of the Essbase tips that people recommend today have been around since Leah Wheelan's ASFG (Arbor Field Services Group) created them 10+ years ago. The only time the tips change is when new features (dynamic calcs, for instance) get introduced and they don't so much change as get added to the existing tips.

My pet peeve in particular was the recommendation that block size in Essbase databases should be 100 KB or so. This recommendation has been in the Database Administrator's Guide for at least 7 years. He commented that he actually lets the dimensionality needs drive the block size these days and is okay with blocks (in 32-bit) getting up to 250 KB. I had the exact opposite stance that the optimal block size is 1-8 KB to take better advantage of parallel calculation and the dynamic calculation of the tops of sparse dimensions. Considering how far apart we were on the block size topic, I think the only outcome of our discussion is that we conclusively proved that Essbase optimization is an art and not a science.

I also brought up proper ordering of dense dimensions. He said to order them in whatever way is necessary to support order of calculations of dynamic members. I agreed with the exception that Time should be the first dense dimension with RLE (Run Length Encoding) compression turned on.

Steve's presenting in the same room that I did yesterday. It holds around 150, but I expect that unlike my presentation, his will be standing room only. There are so few technical presentations on Hyperion here that people are diving at the opportunity for content like "Tips and Tricks for Essbase." He may get some walkouts, though, because a close reading of his abstract shows that he primarily plans on talking about Essbase Aggregate Storage Option, and people may leave if they thought they were going to get Essbase Block Storage tips.

I have lunch scheduled with a prospective client out of the Northeast at E&O Trading Company which apparently is some sort of South Asian restaurant. I'm always up for trying something one time. I'll blog more after lunch.

2 comments:

Anonymous said...

Just to clarify the quotes I am attributed with…

As Edward R. indicated in his post there is both art and science to working with and optimizing Essbase. Unique circumstances arise from database to database and require creativity to resolve within the features that are present in the product.

He quoted me accurately but there is additional context around the implementations where the situations I described occur. Balancing requirements for functionality, performance, user experience, and accurate calculation results all weigh on the ultimate decision on block size and dimension ordering.

Regarding the quote on RLE compression and Time dimension placement we actually agree as that is generally how maximum compression is achieved under that algorithm.

Regards,
Steve L.

Edward Roske said...

Thanks for the clarification, Steve! I want to be accurate in my "quoting."