Database Reference
In-Depth Information
The approach we suggest taking here is to first select I Click Stop and then click on
the Start button. On some measure groups this will complete very quickly, with only
a few small aggregations built. If that's the case click on Next ; otherwise, if it's taking
too long or too many aggregations are being built, click on Stop and then Reset, and
then select Performance Gain Reaches and enter 30% and Start again. This should
result in a reasonable selection of aggregations being built; in general around 50-100
aggregations is the maximum number you should be building for a measure group,
and if 30% leaves you short of this try increasing the number by 10% until you feel
comfortable with what you get.
In the final step of the wizard, enter a name for your aggregation design and save
it. It's a good idea to give the aggregation design a name including the name of the
measure group to make it easier to find if you ever need to script it to XMLA.
It's quite common that Analysis Services cube developers stop thinking
about aggregation design at this point. This is a serious mistake; just
because you have run the Aggregation Design Wizard does not mean
you have built all the aggregations you need, or indeed any useful ones
at all! Doing Usage-Based Optimization and/or building aggregations
manually is absolutely essential.
Usage-Based Optimization
We now have some aggregations designed, but the chances are that despite our best
efforts many of them will not prove to be useful. To a certain extent we might be able
to pick out these aggregations by browsing through them; really, though, we need
to know what queries our users are going to run before we can build aggregations to
make them run faster. This is where Usage-Based Optimization comes in; it allows
us to log the requests for data that Analysis Services makes when a query is run and
then feed this information into the aggregation design process.
 
Search WWH ::




Custom Search