Understanding differences between to cubes that should be equal

Question

Hello everybody:
I have got two cubes with the same configuration and outline (one is a copy of the other). On the second cube I add a sparse new dimension ( Area ) with 3 parent members and about 20 child members (all stored). All are empty except +'N/A'+ (parent member) which is the member selected to save all information for the rest of dimensions.
These are the statistics:
     Cube 1     Cube 2
Number of existing blocks     28.222     28.222
Block size (B)     42.912     42.912
Potential number of blocks     1.176.252     29.406.300
Existing level 0 blocks     18.270     18.270
Existing upper-level blocks     9.952     9.952
Block density (%)     10,79     10,79
% of maximum blocks exist.     2,4     0,1
Compression ratio     1     1
Average clustering ratio     1     1
Index space (ind files)     8.024     8.024
Data space (pag files)     887.049     1.106.671
Why is there such a difference in space between cubes? I know that the second has an extra dimension, but data is saved only in one of these members and it is a sparse dimension. Therefore block size and number of blocks are the same. And I have restructured both cubes.     
There is a calc that is spending 8 minutes for cube 1 and 16 for cube 2. The differences are observed in two subcalcs:
1) CALC DIM of one sparse dimension (different from 'AREA'). It takes twice the time.
2) One member of one dimension ('accumulated data' member) based on UDAS. For the first cube takes 12 seconds and for the second 5 minutes. How is possible this difference?
Could somebody shed some light on these questions?
Thank you
Regards
Javier

Answer 1

Hello everybody:
TimG, you are right. That is my point. The fragmentation is dense, but I will check it again. And I have not checked fragmentation due to the fact that the second cube is a copy of the first one. I will also check this.
Srinivas, as TimG have said, I am talking about .pag space. I could understand that index were bigger but not data saved. I will try with FIX statement as you say, but I think data I/O should be the same. When Essbase look up the index, the information required could be more (old information + new dimension information); but afterwards reads data blocks that should have the same size. And it has to recover the same amount of blocks.
And about the calc, one like this:
FIX(@UDA("UPE_MS_Last").....)
TD_ACCUM;
ENDFIX
Where TD_ACCUM formula is:
IF (@ISUDA(Accounts,"UPE_MS_Last"))
IF (@ISLEV(PERIOD,0))
TD_MONTHLY;
ENDIF;
ENDIF
IF (@ISUDA(Accounts,"UPE_TR_Monthly"))
IF (@ISLEV(PERIOD,0))
+@SUMRANGE(TD_MONTHLY,@CURRMBRRANGE(PERIOD,LEV,0,,0));+
ENDIF
ENDIF
IF (@ISUDA(Accounts,"UPE_MS_Sum"))
IF (@ISLEV(PERIOD,0))
+@SUMRANGE(TD_MONTHLY,@CURRMBRRANGE(PERIOD,LEV,0,,0));+
ENDIF
ENDIF
IF (@ISUDA(Accounts,"UPE_MS_Avg"))
IF (@ISLEV(PERIOD,0))
+@AVGRANGE(SKIPNONE,TD_MONTHLY,@CURRMBRRANGE(PERIOD,LEV,0,,0));+
ENDIF
ENDIF
Thank you
Regards
Javier