There are some techniques you can pursue to alleviate this:
1) Have a nightly defrag process. This won't help if you calc five times a day, but if it's only once, you're in the catbird seat.
2) Do you really need a CALC ALL? Maybe only portions of the db need to be aggregated -- a focused aggregation at least will fragment less of the database.
3) What about Intelligent Calc. If done correctly, this can just affect the blocks that need to be aggregated, thus cutting down on the bits of data that haven't changed.
4) Consider ASO -- if your calculation is just CALC ALL it is possible that your database is just a rack and stack db that just aggregates data (okay, and does a little more, ASO is getting more and more functionality). There is no *data* fragrementation issue with ASO (or not an appreciable one -- we're talking angels on the head of a pin wrt slices) although there are issues around the *outline* getting fragmented.
Regards,
Cameron Lackpour
Scoring disabled. You must be logged in to score posts.
If you have formulas on sparse members, consider making them dynamically calc or structure them as alternate hierarchies as they can drag your calcs right down
Scoring disabled. You must be logged in to score posts.
It is unlikely you have that much changing between calcs - so I would think with intelligent calc set up correctly you would go 24 in, 5 min, 5 min or something like that... Well worth the try. What changes between the calcs? Sounds like in your testing, nothing is changing... you are just running back to back calc alls - which then makes me think your compounding time is a little odd even for essbase/bso. I would explore more - has to be a concrete explanation - it ain't magic.
Scoring disabled. You must be logged in to score posts.
SO what is changing between calcs? Fragmentation, Upper blocks having been created that minght not have been their on the initial run. I would be interested if on a fully calced database, if you forced a restructure, then calced it, then forced a restructure and calced agin if the times would be consistent. I'll bet they would
Scoring disabled. You must be logged in to score posts.
CALC ALL is a real no-no in my opinion. I would recommend spending some time figuring out the bare minimum amount of calculations required to produce correct results. Your calc script should represent this bare minimum. Only calculate the dimensions that need calculating. If possible, don't calculate your dense dimensions at all (make calcs dynamic where possible). Fragmentation may still be an issue, however almost any amount of effort can improve on the results of a CALC ALL.
Scoring disabled. You must be logged in to score posts.
we found that difference between calc all and calc dim with 64 bit on our apps was so small it was not even wortht he effort and in some cases a calc call was faster than the calc dim. So don't think that statement is true across the board...
Scoring disabled. You must be logged in to score posts.
CALC ALL faster than calculating some of the blocks?
No score for this post
July 7 2009, 2:39 PM
Like within a FIX that limited Year, Scenario, etc., etc.?
I guess anything is possible, but that seems pretty unlikely based on the number of blocks Essbase has to cycle through (all versus some). Well, maybe if there was only one year, one scenario, one etc. And if you were using Intelligent Calc. <-- That could be huge.
I haven't been able to get away with a CALC ALL in forever, but I am envious of those who can.
Regards,
Cameron Lackpour
Scoring disabled. You must be logged in to score posts.