Why I created a blog

Its been four years since I first created this blog. It has remained true to Essbase and related information over those years. Hopefully it has answered questions and given you insight over those years. I will continue to provide my observations and comments on the ever changing world of EPM. Don't be surprised if the scope of the blog changes and brings in other Hyperion topics.

Tuesday, December 23, 2014

FixParallel–How fast is fast?

I have finally been able to use FixParallel introduced in on an Exalytics server. I’ve used it for for calculations and dataexports, so how fast is it and does it really make a difference?

For my allocations calculations, I really can’t tell you how much of a difference it made, but I know it was a lot faster to do my allocations with FixParalled than without it. I just didn’t capture the times.

For my DataExport, I was able to measure the difference.  I was exporting 1083702 level 0 blocks in column format with a block size of 9984b. I created a Dataexport calc script and set CalcParallel to16 in the script. Running it took 336.95 seconds. I thought that was reasonable, but I wanted better.

I changed the script to use FixParallel using 16 threads across my location dimension which has abut 800 members. The calculation took 9.94 seconds. If I multiply out that number by 16 I come up with 159.04 seconds so it it telling me the FixParrallel calculation is improving performance more than just the parallelization of the script.

What I did not expect is; just like ParallelExport, the FixParallel dataexport created a file for each thread, so instead of one file I ended up with 15. They were named with a suffix of _T? where ? was a number between 1 and 15.  (not sure why I didn’t have 16 files).  I also don’t know what would happen f the file size spanned 2 gig. Would it append a _1 to the file name? I tried reducing the number of threads  to 3 and reran the script. Alas, I ended up with only three files so I can’t give you an answer. But interestingly the script took 690.63 seconds, much longer that the script without FixParallel, so apparently there it tuning we can do to the script.  I could try including another dimension in my FixParallel, but am happy with my less than 10 second export. Perhaps a test for another day.

So is FixParallel worth it, my testing says YES! FixParallel for me was an awesome new feature and one I will use often.

Thursday, December 18, 2014

Essbase Config file changes

Throughout time, I have come up with a list of Essbase configuration file settings that I typically use in my implementations. As the versions come out, new settings are added and it appears in the versions a bunch of new setting are there, or at least I now noticed them.

Some of the new settings I’ll be adding to my list are

DIMBUILDERRORLIMIT – signifies the number of error rows during a dimension build. This is similar to the DATALOADERRORLIMIT Both has a maximum of 65K rows

ENABLERTSVLOGGING – Logs Run time variable usage in log files

ESTIMATEDHASHSIZE – Specifies in millions the number of member name and aliases loaded in memory for outline maintenance. While I don’t know for sure, I think this is meant to allow up to open really big ASO outlines.

ENABLESWITCHTOBACKUPFILE – enables the automated switching to the backup security log file if the Essbase.sec file gets corrupted. Looks good for automated recovery.

SSINVALIDTEXTDETECTION – Controls if an error is shown when a user enter in text that could cause Essbase to misinterpret the the data. Especially useful for asymmetrical grids.


There are a lot more settings that have been added over time. Take time to go back through the tech reference and read each setting. Some have changed like SSPROCROWLIMIT) other have been removed and many more added. Stay current and adjust your systems accordingly. Remember, many settings require a Essbase server restart to take effect.