Database Reference
In-Depth Information
and left it bound to the fact table, we could not have created additional parti-
tions through the wizard.
3. Select FactResellerSales and click on Next . The following screen allows
you to specify the query, which will populate the partition. Once again the wiz-
ard warns you not to include duplicate rows already found in other partitions.
This time replace the WHERE keyword with this code; WHERE DueDateKey
BETWEEN 20051231 AND 20061231 .
4. The following screen allows you to specify processing and storage locations
for the partition. You can process the partition on the current instance or on a
remote instance.
5. Although processing on a remote instance is possible and could reduce the
resource usage on the current instance, this feature is used very seldom and
isn't trivial to implement. Keep the default option of processing on the current
instance.
6. The choice of storage location is useful in case your database grows so large
that you cannot fit all the partitions on the same drive/data volume. By de-
fault, a partition is saved in the current instance's data folder as specified in
the msmdsrv.ini configuration file. I recommend using the default option
unless storing the new partition in the current data folder is impossible due
to storage limitations. Choosing a non-default location will require additional
work should you need to synchronize or restore the database from a backup.
Simply click on Next to move on to the screen, allowing you to name the par-
tition. In addition, to choosing a descriptive name for the partition, it is very
useful to use the same naming convention for all the partitions within a given
measure group. For large implementations with dozens or hundreds of par-
titions, a common naming scheme will save you many maintenance head-
aches. Let's name the new partition "Reseller Sales 2006" since the sample
database is small and yearly partitions will suffice.
Search WWH ::




Custom Search