Dimension and Partition Processing - Microsoft SQL Server 2008 Analysis Services - page 392

. ProcessFull deletes existing partition data, indexes, and aggregations and fully

reprocesses a partition.

. ProcessData deletes existing partition data, indexes, and aggregations and loads

only data in a partition.

. ProcessIndex builds indexes and aggregations for a partition.

. ProcessClearIndexes deletes partition indexes and aggregations.

. ProcessAdd incrementally updates a partition by adding new data to it.

. ProcessClear deletes partition data, indexes, and aggregations.

Therefore, the ProcessFull option could be seen as three consecutive commands:
ProcessClear , ProcessData , and ProcessIndex .

Loading Data into a Partition
The ProcessData option enables you to organize and schedule processing of your data.
Because building indexes and aggregations might require large amount of memory, you
can separate loading of data into partitions from building indexes and aggregations.

We recommend configuring the BufferMemoryLimit server configuration property to
maximize the number of partitions you can process in parallel. The processing perfor-
mance in many cases depends on the speed at which relational database can supply data
to Analysis Services. You can use the SQL Server Profiler application to see the SQL queries
Analysis Services generates during partition processing and try to optimize your relational
database for such requests by building additional indexes. Use SQL Server Database Engine
Tuning Advisor for that. Also, Join clauses have a large effect on SQL query execution.
You can avoid joins by redesigning your conceptual model or changing the binding to the
relational data source.

To process a partition, Analysis Services typically utilizes two CPUs. Because partition-
processing threads are often waiting (to receive the next portion of data from the
network or during I/O operations), you can schedule parallel processing of more parti-
tions than enabled by number of your CPUs. Therefore, if you have four processors in
your machine, you can start processing two or more partitions in parallel to utilize your
machine. On the other hand, you shouldn't start too many parallel operations. Doing so
will cause a situation in which processing operations are spending too much time fight-
ing for shared resources.

Based on empirical data at the time this topic was written, if you can process 50K records
in a second, you can consider your processing performance as good. If you can load 100K
records per second, you can consider your processing performance optimized.

We recommend parallel processing of partitions from the same measure group, and serial-
izing the processing of partitions from different measure groups. Partition processing
requires Analysis Services to load hash and decoding tables for the granularity attributes.
Different measure groups have different granularity attributes, and Analysis Services could
consume a great deal of memory and might have to swap hash and decoding tables to
disk while processing in parallel partitions from different measure groups.