Query Performance Tuning - Expert Cube Development with SSAS Multidimensional Models - page 209

After assigning an aggregation design to the partition (we'll talk about aggregations
in detail next), the last important property to set on a partition is Slice . The Slice
property takes the form of an MDX member, set or tuple - MDX expressions
returning members, sets or tuples are not allowed, however - and indicates what
data is present in a partition. While you don't have to set it the slice property we
strongly recommend that you do so for ROLAP partitions, and even for MOLAP
partitions for the following reasons:

• While Analysis Services does automatically detect what data is present in a

partition during processing, it doesn't always work as well as you'd expect
and can result in unwanted partition scanning taking place at query time
in a number of scenarios. The following blog entry on the SQLCat team
site explains why in detail (not all of the future improvements mentioned
in this article have actually been implemented at the time of writing):
http://tinyurl.com/partitionslicing .

• It acts as a useful safety mechanism to ensure that you only load the data

you're expecting into a partition. If, while processing, Analysis Services finds
that data is being loaded into the partition that conflicts with what's specified
in the Slice property, then processing will fail.

More details on how to set the Slice property can be found in Mosha Pasumansky's
blog entry on the subject here: http://tinyurl.com/moshapartition .

Planning a partitioning strategy
We now know why we should be partitioning our measure groups and what to
do to create a partition. The next question is: how should we split the data in our
partitions? We need to find some kind of happy medium between the manageability
and performance aspects of partitioning - we need to split our data so that we do
as little processing as possible, but also so the division of data means that as few
partitions are scanned as possible by our users' queries. Luckily, if we partition by
our Time dimension we can usually meet both needs very well. It's usually the case
that when new data arrives in a fact table it's for a single day, week, or month, and
it's also the case that the most popular way of slicing a query is by a time period.
Therefore, it's almost always the case that when measure groups are partitioned they
are partitioned by Time. It's also worth considering, though, if it's a good idea to
partition by Time and another dimension; for example, in an international company
you might have a Geography dimension and a Country attribute, and users may
always be slicing their queries by Country too - in which case it might make sense to
partition by Country.