Hi,

I have created a new cube which contain only 1 measure which is a DCount
measure. (Dcount of employees)
when I process this cube the processor usage is strange...

I have 4 CPUs

the processors go to 100% during 10-15sec. then drop down to 5% for 1 CPU
only (the others are at 0%) for 30sec to 2 minutes!
then again my proc. go up to 100%...
and again...

during 100% pick the rows created/sec is between 350 000 and 450 000, during
"down" steps the number of rows is 15 000 to 30 000

and also, more I advance in the aggregations more the "down" step is long!
so the first "down" step takes 10sec, after 200 aggregations the down step
is more then 2minutes.

other counters:
during 100% usage: memory size rows go from 0 to 5 millions, temp file rows
is 0
during 5% usage: memory size rows still at 5 millions, but the temp file
rows is 200 000 to 400 000

if I monitor the olap temporary folder, the files here are allways a 0
bytes. and the temp file bytes written/sec has no values!

the overall process time is 35minutes for 7millions of rows, the equivalent
cube, without the dcount measure, takes only 5 minutes!!!

and to finish with my stats...
the disk usage of this cube is:
fact.data = 140mb
agg.rigid.data = 171mb
agg.flex.data= 50mb

the equivalent non-dcount cube is:
fact.data = 107mb
agg.rigid.data = 3mb
agg.flex.data= 36kb

(other files are equivalent in the 2 cubes)

I have try changing some aggregations in my cube without success.
I have double the buffer size and read-ahead buffer, but there is no
changes.
and another strange point: the number of rows (memory size row counter) is
11 millions while I have only 7millions in my source DB!!!!

any idea?
can I do something?
why there is a so high rigid.data and flex.data sizes?
I plan to test cube partitioning.

thanks for your comments.

jerome.