Database Reference
In-Depth Information
4 and 6, the two [1st half] and [2nd half] views, then which could be used to compute
view 18? of the four remaining views in the list enumerated in the paragraph above,
view 10 is the smallest. It should be noted that view 15 at .373747 mb is almost nine times
larger than view 4. If the [1st half] and [2nd half] are queried 1/9 or less as often, it prob-
ably pays not to create the “half ” views. note that view 10 is a view at the “Qtr” level.
Because a query that would have run against view 18 still can be run from another
Aggregated view that is not at level-2 (the half level), it still can perform well. you do
not always need the most optimal view.
The goal is always the smallest total size of
meaningful
aggregations. Aggregated views
should not be created just because they are small; their resource impact is cumulative and
can be nontrivial. only create Aggregations that will aid in querying or calculation.
okay, let us suppose that we decided to eliminate all of the 8 “half ” views. my first
inclination was to go to the Design Wizard and uncheck each of the eight (4, 5, 6, 7, 13,
18, 20, and 23). When I uncheck view 4, the wizard unchecks all higher views 5-25 auto-
matically. This is because the cost column was derived for each view assuming that the
prior views had already been built. The wizard does not check to see which of the specific
higher views is dependent on view 4; it assumes they all are and unchecks them. The wiz-
ard does not want to go to the trouble of evaluating dependency by executing rule r12.
other than by adding hints in the outline, how would we eliminate a specific view or
set of views? We first need to understand the structure of the .csc file.
I want to complete a comment made above about the small size of the ASosamp
cube with the dataset delivered in the file dataload.txt (after all, how many people worry
about performance on a 6-mb cube?). In comparison, consider the following Design
Aggregation run on ASosamp with a much larger dataset (Figure 7.11).
The 11.896 gb of the cube with all of its 35 Aggregated views is only 16.5% larger
than the level-0 view. The aggregated cube in Figure 7.10 was 558% larger than its level-0
view. The outlines are identical, so the actual data really does matter a great deal. notice
views 15 and 25 (the 16
th
and the 26
th
) seen in Figure 7.10, each of which were over 95%
of the input-level view, are no longer called for by the wizard in Figure 7.11 because it
found better things to do with your time and memory.
7.5.5 Design Aggregation CSC File
Let us briefly look at how the data in the Aggregation Wizard is represented in the
Aggregation in the CSC file. At first glance, the content of Figure 7.12 looks quite differ-
ent from the guI representation seen in Figure 7.10. File that can be run using maxL:
Figure 7.12 corresponds to Figure 7.10. The first number (in the medium oval), 26,
is the number of views contained within the script, including the level-0 view, which
must be included. The second number (4142187940) is an outline ID that is tied to the
otL (outline) file to which this script pertains. Certain types of edits of an otL file
will cause a restructure of the outline that could result in changes to the Bitmap, which
would invalidate this script. I refer you to tim german's presentation
(
Essbase ASO:
Optimizing Aggregations)
referenced earlier.
These two descriptive members are followed by pairs of numbers for each view. The
first pair (in the small circle) is always for the level-0 view and will always be 0 and 1,
the view ID followed by the view ID size as a percentage of the size of the level-0 view
(100% for the first pair). This continues for the remaining pairs, each of which corre-
sponds to the remaining views. The view ID, the first half of each pair, is a shorthand
reference to the [0, 0, 2/0, 0, 1, 0, 2, 1, 0/0, 2/0, 3/0] notation seen in the wizard.
