Database Reference
In-Depth Information
the larger ASo cache settings are only needed during original data loads (slice load-
ing generally does not involve a large enough dataset to require changing the ASo
cache) and, to a lesser extent, aggregation. The tEmP tablespace is used when ASo
cache is not available. Therefore, make sure your tEmP tablespace is on a separate
disk drive from your main tablespaces.
If there is an SSD drive available, it will be
best used for the TEMP tablespace
. Finally, if you have a number of cubes running
simultaneously, you might want to test taking a portion of your limited rAm and
configuring it as a rAm drive. It should be listed first in your tEmP tablespace list
for each cube. This will work to some extent as a shared ASo cache. nevertheless,
you will have to test.
7.8.3 Memory
The final word on memory really is:
Get more
.
If you are far from fitting your cubes into memory, you might do well to investigate
adding extra SAn or channel adapters to increase the speed with which you can get
data to and from your disk drives. If your CPus are not at 100% utilization, you should
test system level compression of the mAIn and tEmP tablespaces, as suggested in the
previous section.
other than that, your next dollars are probably best spent on memory.
7. 9 s u m m a ry
Dynamic mDx—Where Is It okay?
Stored hierarchy or Stored members
Where Did I Load That Data?
Solve-order: now What?
Who Is on First? What Is on Second?
The answer is to think about your code in terms of translation and redirection. Sure,
some of your mDx will have to be actual calculations; after all, you cannot compute
ratios with Stored consolidations. other than these cases, you should have to write rela-
tively little mDx in your cube. or, at least, only a few long chunks of complex mDx
on very few members. By thinking in terms of translation and redirection of the type
shown for ytD, you impart a kind of object orientation to your cube. once you write a
piece of mDx (and document it then and there with comments), you should be able to
forget about it. Additionally, consider writing comments on those members that are the
targets of your mDx. It is important to identify members as unused directly by the users
and which pieces of mDx will redirect where.
Also, organize your dynamic consolidations and mDx by Solve-order groups
starting from the highest dynamic Solve-order. remember that while the lowest Solve-
order is
computed
first, then the next lowest, etc., the query engine resolves or interprets
the
highest
Solve-order first. These are the Solve-order ranges that I generally use to
help organize my cube's calculations:
• 200-225: variances
• 150-175: Interdimensional calculations
• 100-125: Intradimensional calculations
• 85-90: xrEFs (if you really must use these performance killers)
• 50-75: translation/redirection
