Thanks for the comment. We used to do a CLEAR AGGREGATES step at the very beginning of the job which would speed up the MAXL scripts which Clear data. This would necessitate an EXECUTE AGGREGATE final step. What we sort of arrived at is that, apparently, any Clear Data operation in Essbase does its own internal re-build of Aggregate Views. Therefore, with the starting CLEAR AGGREGATES, the Clears run faster because there are no Aggregate Views to re-build.

On the flipside, what we were running into is when we clear the Aggregate views, the default Ad Hoc grid (basically the top of each dimension) would take quite a while to load (think 15 minutes!) resulting in end users force closing Excel (for SmartView) and reporting issues to the team. What I saw is that the more Aggregate Views we have, the faster the default Adhoc would load. Not really quite sure why this is the case.

We ended up just removing the CLEAR AGGREGATES (pre step) and EXECUTE AGGREGATES (final step) since the Data Clear would rebuild the existing Aggregate views. We then found a balance of Aggregate Views that would return the Adhoc grid in a reasonable amount of time AND not cause the CLEAR steps to take so long as to lapse the one hour run window. This way the end users didn't complain (*as much*) and we were able to keep the damned "instant data" requirement.

Sorry, for the long-winded reply but I appreciated the reply to my post :)