ProcessUpdate
applies only to dimensions. It is the equivalent of incremental dimension processing in Analysis Services 2000. It sends SQL queries to read the entire dimension table and applies the changes—member updates, additions, deletions.
Can handle deletion without invalidating cube/dim!! - WIN!
Since ProcessUpdate reads the entire dimension table, it begs the question, "How is it different from ProcessFull?" The difference is that ProcessUpdate does not discard the dimension storage contents. It applies the changes in a "smart" manner that preserves the fact data in dependent partitions. ProcessFull, on the other hand, does an implicit ProcessClear on all dependent partitions. ProcessUpdate is inherently slower than ProcessFull since it is doing additional work to apply the changes.
Depending on the nature of the changes in the dimension table, ProcessUpdate can affect dependent partitions. If only new members were added, then the partitions are not affected. But if members were deleted or if member relationships changed (e.g., a Customer moved from Redmond to Seattle), then some of the aggregation data and bitmap indexes on the partitions are dropped. The cube is still available for queries, albeit with lower performance.
Aggregations may be temporarily removed during proc update but they still exist in the agg design. Running procIndex will rebuild the missing indexes.
ProcessAdd
applies only to dimensions and partitions.
ProcessAdd is a new processing option for dimensions that did not exist in Analysis Services 2000. It essentially optimizes ProcessUpdate for the scenario where only new members are added. ProcessAdd never deletes or updates existing members. It only adds new members. The user can restrict the dimension table so that ProcessAdd reads only the new rows.
ProcessAdd for partitions is the equivalent of incremental partition processing in Analysis Services 2000. The user typically specifies an alternate fact table or a filter condition pointing to the new rows. ProcessAdd internally creates a temporary partition, processes it with the specified fact data, and merges it into the target partition.
Index - rebuilds indexes on any already processed partitions. No unprocessed parts will be processed.
Data - no aggs or indexes are built - data only.
Lazy processing
is the mechanism by which the Analysis server automatically builds bitmap indexes and aggregations for dimensions and partitions. Lazy processing is done in the background at a low priority, so it does not interfere with foreground operations such as user queries. The advantage of lazy processing is that it reduces the foreground processing time and the cube is available earlier to users, albeit with lower performance.
Lazy processing is enabled on a dimension, cube, measure group or partition by setting the DDL property ProcessingMode to LazyAggregations. The Analysis server has a background thread that loops through all objects and initiates a ProcessIndexes job on any object that has ProcessingMode=LazyAggregations and needs bitmap indexes or aggregations to be built. The ProcessingPriority DDL property can be used to control the order in which the background thread processes the objects.
Database administrators can monitor lazy processing using Profiler, just like any other processing operation.
The alternative to lazy processing is to send a ProcessIndexes command explicitly to the server.
NullProcessing - property of dimension attribute key column. If you specify the table PK as the attribute key then shouldnt be a problem as a PK enforces CREATE UNIQUE INDEX. Favour setting it to error as it means it will tell you when you havent set up your table properly if a NULL gets into the tables PK.