Database Reference
In-Depth Information
It took them a few days to come back to me and they found exactly one. This allowed me
the freedom to tell my management (with some modicum of honesty) that I was not the
first person to do this.
The final solution had five cubes. one cube held the million member dimension; the
rest were all significantly smaller. For clarity and ease of reference, this case study will
just reference the largest cube—cube1—and just one of the smaller cubes—cube2—
because the small ones were all handled in exactly the same manner. For a reference
point, table 5.2 provides the dimensionality and member counts for cube1.
In contrast, table 5.3 reflects dimensionality and member counts of cube2 (the larg-
est of the four smaller cubes).
The process that was built is fully scripted in shell scripts calling maxL commands.
running on an AIx LPAr, the server is a dual core 64-bit with three (3) CPu and 28
gb of memory. none of the processes described are done manually; everything is fully
automated, although any of it can be run on demand as needed. Assuming that the first
week has occurred already, the weekly process that was put into place is as follows:
• Saturday morning:
• Drop aggregations on cube1 and cube2.
• Export Data on cube1 and cube2.
• merge Slices.
• re-aggregate cube2.
• Sunday morning:
• rebuild Dimensions on cube1 and cube2.
• Aggregate cube1.
Table 5.2
Case Study Cube1 Dimension Members
and Counts
Dimensions of cube1
Total
Stored
metrics
171
169
Dimension1
215
215
Dimension2
6
6
Dimension3
25
11
Dimension4
228
228
Dimension5
1159
1148
Dimension 6
1039504
843779
Table 5.3
Case Study Cube2 Dimension and
Member Counts
Dimensions of cube2
Total
Stored
metrics
41
40
Dimension1
215
215
Dimension2
6
6
Dimension3
25
11
Dimension4
228
228
Dimension5
1159
1148
Dimension 6
480252
479614
