Database Reference
In-Depth Information
It may seem counterintuitive to add unnecessary CPu (central processing unit) load
for compressing and uncompressing of files, but the increased effective bandwidth is well
worth the cost. I know that these suggestions will work—if you are not already maxed
out on CPu (and cannot buy more). In fact, if you have already added parallel loads and
increased DLthrEADSPrEPArE and DLthrEADSWrItE, you might try reducing
them to give you the CPu headroom to employ compression. It is certainly worth testing.
A final cautionary note regarding testing, particularly of Loading and Aggregation:
most operating systems today use file I/o memory mapping, which allows files once
accessed to be accessed a second time or by another parallel process more quickly. If you
are working in Windows and watching the resource monitor, this is what is happening
when you watch the “Free” memory being eaten up by the “Standby” memory (see the
histogram at the bottom of the memory tab). This effect is found with both the input
files on a data load and the .dat files on aggregation and queries. Assuming that no other
processes are reading the same files (such as two cubes loading the same data), then sim-
ply stopping and starting the application will give you a common basis for comparison
when testing the effects of different member formulae or different ASo cache sizes, or of
different compression settings on input or .dat files.
7.8 a Final worD aBout rule r1, aso CaChe, anD memory
For you who are still concerned about my rule r1:
r1: The Input-level and Aggregation-data for all loaded ASo cubes should fit into
memory (or it ain't really ASo).
I hope you have used some of the rules and techniques in this chapter to make your
cube smaller and faster. If you still do not have enough memory, the real answer is to
get more. Assuming that is not possible, what are the implications and the options? First
of all, you are going to have to live with some suboptimal performance, limited by the
speed of your I/o. Let us look at the options.
7.8.1 Aggregation
We know that there is improvement from creating Aggregated views, but that in some
cases (multiple attribute queries) the level-0 view will be required. Sometimes you sim-
ply need all of the detail in that view. Frequently, however, there is one dimension that is
the main culprit. It has many members and a high degree of cardinality, meaning that
the data is spread widely across the members. With luck, your attributes are not tied to
this dimension or tied to upper-level members in that dimension. With a little more
luck, the detail in this dimension is not frequently needed. Then you can materialize a
view that consolidates this dimension to the top level or, at least, to the level where the
attributes are associated. you must review the suggested aggregations to make sure you
do not start pushing even this new view out of memory.
7.8.2 ASO Cache
The memory dedicated to the ASo cache for each cube is reserved for that cube and
even if no user is querying it, the memory is reserved. That is not to say it might not
be paged out, but you might be better served by minimizing the cache. In particular,
