Partiton Cell countMarch 13 2012 at 7:16 PM
No score for this post
from IP address 126.96.36.199
I have a BOS coube and i used the Wizard to convert it to an ASO cube so the 2 cubes them same in terms of dimensions and members. then tried to establish trasparnet partition BSO is the source and ASO is the target. (188.8.131.52). i tested one dimension in the partition area. this dimension has only 2 children and i used @LEVMBRS("Dim1", 0) in both the areas the sorce and the target. then i tried with other dims and i am getting the same diffenrece in terms of the cell count. now matter what dim i used still the same diffrenece ( the cell count changes but the difference remains the same) the cell count does not match. any idea why?
Basic ConstructionNo score for this post
|March 13 2012, 10:18 PM |
The Cell counts from ASO to BSO will almost never match due to how they each handle tags like label only, shared members, implied shares, etc. But a cell count mismatch does not keep you from partitioning. I would not get distracted by that. Does the partition work OK?
Re: Basic ConstructionNo score for this post
|March 14 2012, 1:12 AM |
Cell counts don't matter? That's interesting. I would always be worried about those un-matched cells. What would Essbase do if the target cell doesn't have a corresponding source cells? What about source cells that don't have corresponding target cells?
Anyway, to the OP, to find which dimension(s) is causing the cell count mismatch, create the partition by including one member from each dimension in the area definition. Preferably, these would be level 0, non-dynamic members. You should have a matching cell count of 1 for both source and target.
Then delete one member from both source and target areas. Do the cell counts match? Restore the member and delete the member for the next dimension. Do the cell counts match?
Repeat the activity until you've tested every dimension. That will tell you which dimensions need review.
Hmmm - Different point of viewNo score for this post
|March 14 2012, 2:51 PM |
Seems to me that a quicker way to work with this is to run a validation report and drill on each dimension. I have always validated partitions through functionality and not statistics. They can be statisically correct and break first time someone drills. They can have statistical issues with counts and work perfectly. So for me, the true test is usage. If my data validates at all levels then the partition is working correctly. If every dimension drills to bottom correctly then the partition is not throwing an error due to mismatches in the mapping. I am not saying - just ignire mismatches - but I am saying - if everything works correctly and the data is the same when you query the cube directly vs querying it through the partition, then the mismatch message is inconsequential.
I have a 20 dimension model ASO to BSO. The cell counts never match due to the reasons I implied in the first post. Tracking down the why's can be much simpler then you suggested. If you look at something - like the statistics on stored vs non-stored members by dimension - you will see there where the probable dimensions that are creating the mismatches lie. If your stored members vs dynamic members match match exactly - meaning you have a very simple outline structure - then your cell counts will most likely match. If this is all the same, and I really wanted to know, then I would launch into the process you described in your post.
In my case - I can see that Measures do not match and neither does my time view dimension. When I look at that I can see that this is due to the use of label only members in BSO and inability to use those in the same places in the ASO cube. I am not going to bother mapping around these to have a perfect count. Inconsequential in this case.
Re: Hmmm - Different point of viewNo score for this post
|March 14 2012, 3:02 PM |
Your approach is definitely simpler on databases with a single partition with a single area. A complex partition with multiple areas could return false negatives unless you drill into each dimension across all defined areas. It could take just as long.
I like to avoid those cell count mismatch warnings simply because I don't want them to be a factor IF there are data validation issues.
Also, it will save some time when dealing with the Oracle Tech Support analyst who can't move forward until all those awful warnings are resolved.
Technically Angie I agree but...No score for this post
|March 17 2012, 3:40 PM |
Yes you can have a working partition where the cell counts do not match. But I try to never do it. The legal definition is that if a source cell maps to more than one target cell you are fine. To avoid the message in this case I will always create a second area that repeats the source cell mapping it only to the second target (the first area will also be changed to map the source cell to the first target).
In short the error message only looks for matching cell counts within an area - not accross the union of all areas.
But back to Anonymous original question - Angie is correct that your problem will occour due to differing issues with "Never Share" and "Implied Sharing" - Simply winnow down the size of each area and find where the counts do not match and fix as needed.
But a simple bso to aso conversion will not give you the speed you are looking for - what about attribute dims - you can not map to them in BSO?
Also you need to address stored vs dynamic hierarchies - dynamic will be slow in ASO.
And finally why do you need to map it back to BSO in the first place????????
Very good pointNo score for this post
|March 20 2012, 12:59 PM |
Although I have cubes with 20 or 30 partitioned cubes - I only have 3 with mapping. And they are a much bigger headache and so your point is well taken and something to consider.