Database Reference
In-Depth Information
Going in Production
When the Analysis Services cube development is completed, its life - from the
developer's point of view - is over. Nevertheless, its real life, from the user's point of
view, has just begun. During development we probably didn't care too much about
what would happen once the cube was in production, but of course there are a whole
new set of problems that must be dealt with when a cube has gone live. We are going
to address these problems in this chapter.
The focus in this chapter is on the following topics:
Making changes to a cube in production : These changes will still need to
be made to the cube once it's in production, but we need to be very careful
about how we make them in case we accidentally break reports, overwrite
properties, or unprocess objects.
Managing partitions : Partitioning our cube is good for two reasons: to
improve query performance and to reduce the amount of processing we
need to do. In production, new data will need to be loaded into the cube on a
regular basis and this means we'll need a way of automatically creating new
partitions when they are necessary.
Processing : Having a lot of data to process forces us to find the most efficient
way of processing it. If, as is usually the case, we don't have enough time
available to do a full process on our Analysis Services database every time
we load new data into it, we need to understand what other options are
available for cube and dimension processing.
Copying databases from one server to another : On larger implementations,
we'll have several instances of Analysis Services, for example, in a network
load balanced cluster. In this scenario, we will not want to process the same
database more than once; instead, we'll need to look at the methods we can
use for copying a newly processed database from one instance to another.
Search WWH ::




Custom Search