Build Aggregations
Build an aggregation. Essbase selects aggregate views to be rolled up, aggregates them based on the outline hierarchy, and stores the cell values in the selected views.
Building aggregations requires Database Access permission.
Aggregations are intermediate stored consolidations of aggregate storage cubes, consisting of one or more aggregate views. Aggregate views store upper-level intersections. This supports query performance by avoiding dynamic aggregations on the most commonly queried intersections.
If an aggregation includes aggregate cells dependent on level 0 values that are changed through a data load, the higher-level values are automatically updated at the end of the data load process.
To build aggregations:
- On the Applications page, click Jobs.
- From the New Job menu, select Build Aggregations.
- For Application, choose an application.
- For Database, choose a cube.
- Optionally, enter a non-zero value for Ratio To Stop.
Leaving Ratio To Stop at zero (the default) means there is no stopping ratio set.
Consider this option if there is no known common type of query executed by your cube’s users, and you want to improve performance by limiting the cube’s growth. Essbase aggregates the selected views, with the exception that the maximum growth of the aggregated cube must not exceed the given ratio. For example, if the size of a cube is 1 GB, specifying the total size as 1.2 means that the size of the resulting data cannot exceed 20% of 1 GB, for a total size of 1.2 GB.
- Check or clear the box for Based on Query Data.
If you check the box for Based on Query Data, Essbase aggregates a selection of views that is defined based on analysis of user querying patterns. This is a good approach if similar types of queries are typically executed by the users of your cube.
This check box has no effect unless you have first enabled query tracking. For general information about query tracking, see Selecting Views Based on Usage.
After you’ve enabled query tracking, allow sufficient time to collect user data-retrieval patterns before running this job. A good approach is to prepare a set of your most important and long running queries, enable query tracking, run the prepared set of queries, and then run this job to create an aggregate view based on the query tracking.
While query tracking is enabled, the cost of retrieving cells is recorded for every level combination. This recording continues until the application is shut down or until you turn off query tracking (using the MaxL statement alter database <dbs-name> disable query_tracking).
- Select whether to enable alternate rollups.
Consider checking this box if your cube implements alternate hierarchies for shared members or attributes, and you want to include them in the aggregation.
See Also