Hi Dave,

1. I selected ‘Parallel Processing’ and ‘Let the Server decide’ options for
processing a cube with 15 partitions. The server is AMD Opteron Processor
852; 2.40 GHz; 27.8 GB of RAM. It is 4 proc Dual Core.

I thought that it will process a maximum of 8 partitions in parallel as the
server is 4 proc Dual Core. To my surprise it processed 10 partitions in
parallel. I am bit confused. Is there any documentation that talks about # of
partitions in parallel Vs the number of processors etc?

2. I know that each of these partitions has only 8 aggregations. As I
observe the process messages it generates, it takes about 50 minutes to read
the data from DB2 and to write it to the MSAS, but it takes about 50 minutes
to build those 8 aggregations. I am not sure if it is just the message that
stays dead for some time or it is really taking 50 minutes to build just
these 8 aggregations. Do you know of any bugs on this front? I am using MSAS
2005 November CTP.

3. In case of a ‘Parser Error’ on 1 partition it rolls back all the
previously built successful partitions as well. I think I can avoid this by
choosing ‘Sequential Processing’ & ‘Separate Transactions’ right?
Also, if I choose Sequential processing, will it executes the entire 15
partitions one after the other? Nothing in parallel?

Please confirm,

Thanks,

Sam.

Hi,

1/2. in my case, a single CPU server (with 1Gb of Ram and 1 IDE disk), 4
partitions are processed in parrallel. 25 millions of rows are processed in
30 minutes with 30% of aggregation. Its not a bad thing to process more
partitions then the number of CPUs because the queries takes some times to
be prepared on my source.
I have reduced the number of attributes with "optimize" option set to on to
improve the process performance.
Have you try to force the number of parrallel process to 8?
did you see any difference in the overall processing time?
do you optimize every attribute of your dimensions?

3. Sequential processing process 1 partition at a time, and you can choose
to have only 1 transaction or 1 transaction by partition.

The new parrell process feature is great and save me a lot of time.
for the moment I have don't change the default options.


"Prasad" <Prasad (AT) discussions (DOT) microsoft.com> wrote

Hi Jeje,

I tried building the cube with 8 partitions and founs no significant
improvement.

Coming back to your reply, what do you mean by saying "Do you optimize every
attribute of your dimensions?" & "I have reduced the number of attributes
with "optimize" option set to on to improve the process performance."

Can you please eloborate on both of your statement above? I did not seem to
do any optimization with my attributes. Is there any setting that i missing
here?

Please advice,

Thanks,

Prasad.
"

"Jéjé" wrote:

Hi,

Each attribute in each dimension has a property called
"attributehierarchyoptimizedstate"
by default the value is "FullyOptimized"
so, for example, the first name, last name address of yourr customer's
attributes are optimized and a measure group will aggregate the values for
these attributes, sometimes you don't want this!

look at the physical folder where your cube is stored and look at the number
of files you have...
For example, the adventure works sample, you have some files for the email
adress attribute, this mean that the email address is optimized and the
measure group has been optimized to use this attribute.

Aggregating values for too many attributes will impact the processing time.
its like if in AS2000 you create a cube with 100 hundreds dimensions... its
huge and slow to process.

also look at the attrribute relationshiptype property of a relationship
A Rigid option should improve the performance and reduce the processing time
but a flexible option is recommanded if the relationship between the 2
attributes should change (the gender don't change, but the phone number of
an employee should change)

navigate in the customer dimension of the adventure works sample database to
see different usage and configurations.

Jerome.


"Prasad" <Prasad (AT) discussions (DOT) microsoft.com> wrote

There are three ways to set the maximum degree of parallelism.
First, there is a server property called CoordinatorExecutionMode. This is
server-wide and controls the value for a mutex that controls the # of
requests executed in parallel. For a negative number it is "N times the # of
CPUs". A positive number is just that number.

For individual processing options, such as you've selected 10 partitions to
process at the same time, you can click on "Change Settings" and set the #
of requests in parallel (this is the second). If you look at the resulting
XMLA script code, you will see that there is an element called MaxParallel
which controls the number within the actual XMLA script used (this is the
third way to set it).

Unfortunately, you cannot do a parallel execution and commit each
transaction as it goes along. You only have three options:

1) serially all in one transaction
2) serially but commit the transaction as each request finishes, or
3) in parallel, but only in one transaction. Thus if any processing error
occurs which isn't captured and settled by the error configuration, then the
*entire* transaction, all partitions rollback.

--
Dave Wickert [MSFT]
dwickert (AT) online (DOT) microsoft.com
Program Manager
BI Systems Team
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Jéjé" <willgart (AT) BBBhotmailAAA (DOT) com> wrote