First of all, via Jamie Thomson, there’s a new white paper out detailing all the server properties for AS2005:
There’s a lot of good information on configuration here.
Secondly, from Teo Lachev, news of an incredible U-turn in terms of best-practice on designing cubes:
So we’re no longer meant to be building one large cube with multiple measure groups, but to go back to a more AS2K-like multi-cube approach and then glue them together with linked measure groups? OK…
–See the last update at the bottom of this post…
/*
Thirdly, Mark Garner points out that there are some performance costs associated with using role-playing dimensions:
I hadn’t realised they had no aggregations built for them although now that I’ve looked, it is mentioned in the Project REAL documentation; it’s a big reason not to use them. To me, the main benefit of using role-playing dimensions is to have better manageability – the reduced processing time is a good thing too, but slightly less important and I’d sacrifice some of this benefit to have aggregations.
*/
Finally, although I mentioned this in passing yesterday and the important information isn’t out in the public domain yet, Mark Hill has some important news regarding the fact that you supposedly don’t need to set the data slice on your partitions any more:
UPDATE: Mark Hill has got all the details about the partitioning problem:
This tallies with what I was seeing: I had created hundreds of very small partitions because I knew the users were going to be running very finely sliced queries; unfortunately this must have worked against me: my partitions must have been too small and large numbers of them ended up being scanned when I ran a query.
UPDATE: Akshai Mirchandani has clarified the situation regarding role-playing dimensions and aggregations; see his comment on Mark’s blog posting here:
It was a bug in the Project REAL docs and you can build aggregations for role-playing dimensions.
Chris
I have to question what Mark is saying… I don\’t think his statement about no aggregations for role-playing dimensions is correct. When looking at the aggregation design for some of my cubes, attributes from role-playing dimensions are indeed part of some of the designed aggregations.
Michael
Well… I have to correct myself. Having investigated the issue further, it does seem that attributes from a referenced dimension are not included in any aggregations. At least this is the case for the partitions in a database I am working on right now, where we have used the aggregation design wizard to build an aggregation level of 70% – none of these included attributes from the (single) referenced dimension i a particular measure group.
I knew about reference dimensions having performance problems; it was role-playing dimensions that had the question mark hanging over them. Are you getting confused between the two as well?
Chris,
Sorry about all the go-round about this issue. I\’ve corrected it on my blog. I probably should have doubted the docs a little more before I posted. I guess I just thought I was the only one who didn\’t know. 🙂
Mark
Well… Yes… I was confusing the two types of dimensions. Embarrassing! 🙂 Anyway – I\’m still puzzled that I am not seeing any aggregations on a referenced (materialized) dimension. I will have to try and see if I can build some manually, in case the Aggregation Design Wizard doesn\’t consider them.
I am still confused reading the postings. Can someone confirm: Whether ”Implement reference (or role-playing) dimensions but make the referenced dimensions materialized.” resulted in aggs using the agg wizard or not?
If not – did creating aggs by hand for reference dims improve performance?
I think the situation is that you can\’t build aggregations for reference dimensions at all, either manually or with the wizard. Building aggregations for role-playing dimensions isn\’t a problem.