Database Reference
In-Depth Information
•
Finally, it has some very comprehensive functionality to allow you to test
the performance of the aggregations you build (see
http://tinyurl.com/
testaggs
).
Unsurprisingly, if you need to do any serious work designing aggregations manually
we recommend using BIDS Helper over the built-in functionality.
Common aggregation design issues
Several features of your cube design must be kept in mind when designing
aggregations, because they can influence how Analysis Services storage engine
queries are made and therefore which aggregations will be used. These include:
•
There's no point building aggregations above the granularity you are slicing
your partitions. Aggregations are built on a per-partition basis, so for example
if you're partitioning by Month there's no value in building an aggregation at
the Year granularity since no aggregation can contain more than one month's
worth of data. It won't hurt if you do it, it just means that an aggregation
at Month will be the same size as one at Year but useful to more queries. It
follows from this that it might be possible to over-partition data and reduce
the effectiveness of aggregations, but we have anecdotal evidence from people
who have built very large cubes that this is not an issue.
Search WWH ::
Custom Search