Going in Production - Expert Cube Development with SSAS Multidimensional Models - page 287

• The recommended approach is to use the Deployment Wizard, which allows

us complete control over what actually gets deployed to the production
server. To use it, first we have to build our project in SQL Server Data Tools;
we can then run the wizard, point it to the .asdatabase file that was created
in our project's bin directory when we did the build, and then choose what
happens to roles, partitions, connection strings, and various other properties.

Managing partitions
As we saw in Chapter 8 , Query Performance Tuning , partitioning a measure group
simply involves slicing it up into smaller chunks that are both easier to maintain
and to query. In that chapter, we introduced and explained the basic concepts of
partitioning; now, we are interested in how to manage partitions when the cube
is up and running.

Measure groups are usually partitioned by the Time dimension, for example, with
one partition holding one month of data. Although, there are rare cases where
we might want to partition a measure group based on a different dimension (for
example, Geography is sometimes used), the vast majority of projects we have
worked on use Time as the slicer. This follows on from the fact that new data usually
needs to be loaded into the measure group at regular intervals in time, and this new
data needs to be processed and stored alongside the existing data.

Clearly, since partitioning is so closely linked to the concept of time, we need to be
able to build and process new partitions dynamically when we have new data to
load. We could certainly build extra partitions in our Analysis Services database to
handle our future needs — maybe create 48 empty monthly partitions to last for four
years - but not only would this be time-consuming to do, it would also mean that in
four years' time, someone would need to remember to create some more partitions.
And even then, we'd still need a way of processing only the partition that contained
the latest data, rather than all partitions.

Note that if our partitioning strategy is not dynamic, for example,
if we're partitioning by Geography, this section is of no relevance.
Static partitions can be defined inside SSDT because they do no
change over time.