Database Reference
In-Depth Information
total output exceed 2 gb, all data beyond 2 gb will be written to files, but not those
defined by the parallel export.
Finally, moving the nonaggregating dimensions to the end of the outline file requires
changes to the CALCtASkDImS setting if parallel calculations are being used. review
the next section for an explanation of task dimensions.
4.5 getting the most From multiple proCessors
using parallelism can have huge benefits, but the relationship between CALCPArALLEL
and CALCtASkDImS is not always obvious. The first thing that needs to be under-
stood is that you cannot have one without the other. There can be no parallelism with-
out a CALCtASkDImS setting. In order for Essbase to utilize multiple processors, the
outline must be evaluated to determine which sections of the outline can be processed
in parallel. The output of the evaluation is called the task list. The CALCtASkDImS
statement tells Essbase how many dimensions to consider when developing the task list.
The key concept here is how BSo determines the dimensions to consider when building
the task list. The largest aggregating dimensions offer the best opportunities for paral-
lelism. reviewing the statement CALCtASkDImS x, Essbase uses the last x dimen-
sions in the outline to determine the task list. If a database having two large aggregating
dimensions uses the hourglass organization, then CALCtASkDImS 2 is a good start-
ing point for testing. on the other hand, if the hourglass on a stick format is used and
the last two dimensions are nonaggregating, CALCtASkDImS must be increased until
the largest dimensions are included in the scope. In the example, testing should start at
three or four to ensure that the large dimensions are evaluated.
4.6 CaChe is king; know the BasiCs
Caches in BSo are a powerful yet poorly understood subject. Let me relay a story that
sums up the state of cache tuning. A few years ago, I visited a customer as a member of
a team that was tasked with addressing a BSo calculation issue. The customer had a cal-
culation script or, more accurately, a Planning business rule that was taking three min-
utes to complete. This was their primary rule that would get executed extensively during
the forecasting period. The rule needed to complete in no more than 10 seconds. my
associate, whom I had never met, was a self described Essbase tuning expert. I will call
him Bill for the sake of the story. Bill immediately viewed the contents of the Essbase.
cfg file. With much confidence Bill declared that he had found the problem. There were
missing entries in the configuration file. The customer was thrilled and I could not wait
to see how he was going to reduce the calculation time from three minutes to a hand full
of seconds. Just when I thought that it could not get stranger, Bill opened the configu-
ration file in the editor. Striking a pose reminiscent of Joey tribbiani's (tv's
Friends
)
smell-the-fart act, Bill added the following to the file:
CALCLOCKBLOCKHIGH 2000
CALCLOCKBLOCKDEFAULT 1000
CALCLOCKBLOCKLOW 500
CALCCACHE TRUE
CALCCACHEHIGH 199000000
CALCCACHEDEFAULT 100000000
CALCCACHELOW 50000000
