Memory Management - Microsoft SQL Server 2008 Analysis Services - page 514

When Analysis Services completes writing every aggregation to the buffer, the build-
aggregation job reevaluates its balance. It calculates the income by multiplying the
number of records in the built aggregation by the Income property of the memory model.
Analysis Services calculates the tax as the current memory price multiplied by the size of
the aggregations buffer used to store those records, and multiplies the Tax property of the
memory model.
After reevaluation of the balance, the build-aggregation job requests permission from
Memory Governor to build the next aggregation, and provides the minimum and the
maximum amount of required memory and the new balance. Memory Governor returns
the amount of memory it can reserve, which will be used to calculate the new size of the
aggregations buffer to build the next aggregation. If the new size of the aggregations
buffer cannot fit an aggregation, the content of the buffer is swapped into a temporary
file, and memory is released and is populated with new data.
After the last aggregation of the last segment is built, Analysis Services starts to merge the
data stored on the disk and in memory, and then stores merged aggregations to disk. This
process of merging slows down building aggregations. If you can avoid this step, the
build-aggregation job will take significantly less time. You can avoid this step by increas-
ing the memory allocated for the build-aggregation job, by decreasing the number of
designed aggregations, or by decreasing the size of the partition.
Memory Model of Building Indexes
The memory model of building indexes is a good example of when the amount of
memory required for a job can be calculated precisely and does not require any additional
information from the user (from the configuration file). When Analysis Services builds
indexes, it has to decode data of a segment (see Chapter 21). Analysis Services already
calculated the number of records during partition processing, and it knows the size of a
record; therefore, it can easily calculate the amount of required memory.
To build indexes, Analysis Services has to load decoding tables into memory; otherwise,
the decoding will be not efficient and the building of indexes will take a very long time.
(For more information about decoding tables, see Chapter 20.) Therefore, the building
indexes job should reserve memory for all the decoding tables and should lock those
tables in memory, until decoding is completed. The build indexes job calculates the
amount of memory needed to keep the current segment and decoding tables in memory,
approximates the amount of memory required to build indexes, and then requests this
memory from Memory Governor.
Because partitions from the same measure group require the same decoding tables,
Analysis Services can build indexes for partitions from the same measure group in parallel,
without large memory usage overhead.
If not enough memory is available to load all decoding tables, Analysis Services cannot
build indexes at all. You should review the attributes of the dimensions in the measure
group and disable indexes on some rarely used attributes by setting the
AttributeHierarchyOptimizedState property value to NonOptimized . (You can get more
information about this property in Chapter 5, “Dimensions in the Conceptual Model.”)