In this post, I will progressively go through processing a partition from full process, to incremental process, and finally to incremental process with out-of-line bindings. This will provide you with additional samples to examine the results of partition processing with XMLA.
Note: these examples use the Adventure Works DW 2008R2 SE sample database available on CodePlex (
Processing with XMLA
Processing is a command that can be executed in a batch and in parallel with similar tasks. This is particularly useful when processing multiple objects that are not dependent on each other, such as dimensions. The basic structure is as follows:
Processing Type Options
This is a list of the most commonly used types when processing SSAS objects.
- ProcessDefault: This will determine the best option based on the condition of the object. Be aware that if SSAS determines that a full process is required, it will do that. I would not recommend using this process type in most production situations.
- ProcessFull: This option completely rebuilds the dimension, partition, cube or even database by removing existing data and reloading the data with aggregations and indexes. In the case of cubes, measure groups and partitions, this is the equivalent of ProcessData + ProcessIndex.
- ProcessClear: This option drops the data and related structures such as indexes and aggregations from the object. Once this run, no data is available in the object.
- ProcessData: This option drops the data and reloads it, but does not rebuild the aggregations or indexes. It works with cubes, measure groups, partitions, and dimensions.
- ProcessAdd: This option adds new data to a partition or dimension. It is not available as an option when processing dimensions from SQL Server Management Studio, but is available in XMLA scripts.
- ProcessUpdate: This options will reread the data and updates the dimension attributes. It is only available for dimensions and will drop flexible aggregations and indexes on related partitions.
- ProcessIndex: This option rebuilds indexes and aggregations for partitions. It requires that the partition has already been loaded with data (ProcessData).
Of these options, the most commonly used when working with XMLA in my experience have been, ProcessFull, ProcessData, ProcessAdd and ProcessIndex. I will use each throughout the examples below and describe the cases where they have applied in my projects over the years.
Processing with XMLA
The process command in XMLA let’s you define the object to be processed, the type of processing to implement, and how to handle any writeback partitions. (NOTE: the ErrorConfiguration options is optional.) Overall the structure is fairly simple. Here is a simple example of XMLA will fully process the Fact Internet Sales measure group.
The syntax is identical for processing dimensions. The <Object> element identifies the object to be processed starting with the database. Next the <Type> element specifies the processing type using the options from the list above. Finally, the <WriteBackTableCreation> element instructs Analysis Services on how to handle a write back partition that has not been fully processed. The default is UseExisting which will use existing table or create a new table if needed. This is only relevant if your cube supports writeback.
Processing Affected Objects
This is a setting that is part of the Process command element. By default it is set to True as in the example above. This means that any objects that are affected will be processed as well. The best example is if you process a dimension and it ends up being fully processed, this will cause all related measure groups to be fully processed as well, keeping the data in a consistent usable state. However, if you are tightly managing your processing jobs, you may need to set this to False to reduce unexpected and blocking processing jobs.
Using Out-of-Line Binding with Incremental Processing
A great feature of XMLA is the ability to dynamically bind data and even connections when processing SSAS objects. This is called “Out-of-Line” binding (
). One of the core concepts behind out-of-line bindings is that you can specify the connection and the data source query or table at run time. This is particularly useful when you want to do incremental processing.
This first example illustrates how to use a query to change the data being added to the partition.
The second example shows the syntax for changing a table or view in the bindings.
In the end, by using the Bindings definitions you can choose what data is getting processed into the SSAS object. Here are some ways that I have used this technique to support my projects.
- Changed the datasource used with the object. I have used this to point to a different data source to test whether it works with the cube without overwriting the existing datassource in the cube definition.
- Changed the table to a view for processing. Because I use XMLA when scheduling most of SSAS process jobs, I can dynamically set the table or view as needed.
- Changed the query definition to limit the data to new rows only. I have used this the most. I have changed the query definition to reflect the latest data for both dimensions and partitions. More importantly, I was able to leverage this in environments where I have not had control over the data source itself, specifically Oracle data warehouses.
Out-of-line bindings are very powerful when controlling your SSAS process options and allow you to maximize the efficiency of your jobs.