Database Reference
In-Depth Information
Figure 5.11
Use Case cube1 input and aggregations statistics. (From Oracle Essbase Administration Services. With
permission.)
Table 5.4
Example of Data S
lice Merging Behavior by Cell Count
Load #
Cell Count
Result
1
75,000
1 Slice with 75,000 cells
2
400,000
1 Slice with 475,00 cells (merged because slice one had less than
100,000 cells)
3
1,000,000
2 Slices; 1 with 1,000,000 cells and 1 with 475,000 cells (nothing was
merged because load #3 is greater than two times larger than the
existing slice)
4
300,000
2 Slices; 1 with 1,000,000 cells and 1 with 775,000 cells (load 4 is
merged with loads 1 and 2 because that slice is less than 2 times the
size of the new slice)
beginning was how Essbase counts slices. ten separate loads would be executed with
the expectation that they would result in 10 slices of data. This did not happen. Well,
sometimes it happened … . Sometimes there would be eight slices, sometimes nine, and
other times seven. This was very perplexing. What was later discovered was that Essbase
helps (on its own) to make the system as optimal as possible. When a new data slice is
loaded, it scans the incremental Data Slices and makes a decision on whether to auto-
matically merge one or more incremental slices with the new Data Slice. According to
the DBAg, “… to qualify for an automatic merge, a slice must be smaller than 100,000
cells or smaller than two times the size of the new slice. Slices larger than 5,000,000 cells
are never automatically merged.” It was so good to realize this was a built-in feature, and
not that basic math had somehow suddenly become elusive. Perhaps the mathematical
example in table 5.4 will help make this concept even more concrete.
In the end, it became an accepted fact that Essbase manages Data Slices the way it
needs to in order to be the most efficient. understanding what it was doing, however, did
create an audible sigh of relief in the room.
The final task on Saturday morning is to reaggregate cube2. As was discussed, the
four small cubes are still aggregated on Saturdays because there is time and resource
availability. Additionally, they are small enough that the dimension build and
restructure times are not as grossly affected as they are with cube1. reaggregating
will employ whatever aggregate strategy was developed for the cube. That will typi-
cally be either:
• Default aggregation
• Aggregation based on a specified amount of disk space
• Aggregation based on usage-tracking with a specified saved view
