The documentation for the ProcessingPriority property of a dimension says:
Determines the processing priority of the dimension during background operations such as lazy aggregation, indexing, or clustering.
So if I run an XMLA batch which says:
Code Snippet
<Parallel>
<Process>
<Object>
<DatabaseID>myDB</DatabaseID>
<DimensionID>myDim1</DimensionID>
</Object>
<Type>ProcessFull</Type>
</Process>
<Process>
<Object>
<DatabaseID>myDB</DatabaseID>
<DimensionID>myDim2</DimensionID>
</Object>
<Type>ProcessFull</Type>
</Process>
</Parallel>
Will ProcessingPriority on one of those dimensions have any impact on which order they get processed in for the main part of the processing (the part that fires off SQL queries, not the part that happens after all the SQL queries are done)?
I have one dimension which has lots of rows and lots of attributes and it's very flat in terms of not being able to have indirect attribute relationships. I'm wanting to get that dimension to process first so that there's not as much competition for memory. We tend to run out of memory on our 32-bit dev box when that dimension and others are processing simultaneously. I'm wondering if ProcessingPriority can help me or if I need to manually control the order of dimension processing in my XMLA script.
For ProcessingPriority, a higher number means higher priority, right? Can you use negative numbers? How does zero compare to a high number? I assume zero means low priority, but I thought I'd ask.
If you run these in parallel, I believe the order of the SQL statement and result set processing will be in parellel. One dimension may gain priority over another for memory or other resources for the operations you describe, but that's not the same as running in a serial mode. If you need one to run before the other, remove the <parallel> instruction and the batch will default to serial mode.
Good luck,
Bryan
No comments:
Post a Comment