Showing posts with label fairly. Show all posts
Showing posts with label fairly. Show all posts

Saturday, February 25, 2012

Designing Aggregations

I have a fairly large partition (100M rows, 30 measures) and am attempting to create aggregations through the Aggregation Design Wizard. Regardless of the option I select, either percent or file size, the wizard always completes after designing only about 50 aggregtions for 0% and only 200kb. I cannot believe that to be right. On a much smaller partition I created about 600 aggregations to 30% for 2GB.

I've double checked to ensure I have all of my dimension attribute relationships defined.

Any ideas why I cannot get the large partition to build the aggregations or why it completes after building about 50? I have plenty of disk space and and cube processing time is not an issue, so I would like to create up to 25-30GB of aggregations.

Thanks

Have you established your attribute relationships?

WIthout them the system does not know that natural hierarchies may be available and by default it only creates aggregations along natural hierarchies.

_-_-_ Dave

|||

Thanks Dave, but I have established the attribute relationships. What confuses me is that the wizard shows that it will create about 250 aggregations, 0%, 125kb. I use the option to manually stop the aggregation design (but never do. I let if finish on its own) and it always comes out roughly the same.

When I process the partition I can see that the aggregations are being created. When I look in the file system I see a bunch of .tmp files being created (e.g. AggMerge_5800_54_8s64d_28.tmp), all of them for about 1.5GB. I eventually run out of space on the drive and the processing fails.

All together these .tmp files take about 150GB. The source database is only about 200GB.

Any thoughts? Ideas? The aggregation design wizard tells me the aggregations will take up about 125kb, but the .tmp files tell me something different.

Designing "XML Proof" databases?

Hello All,
I'm fairly new to the XML game. I am designing a database that will contain
online books. Each book will be broken into parts, each part into chapters,
each chapter into sections, each section into... you get the idea. I think
this is the perfect opportunity for the XML data type in Yukon. However, I
did to put this database together in the next few weeks.
My question is whether there are any best practices for designing
traditional heirarchical databases today that will smoothly transition into
an XML future. (Books, articles, suggestions here, etc.?)
I need to have each text snippet as it's own record in one table (snippetID,
title, body, etc.) I was thinking that I would create a second table for the
heirarchy itself where I would maintain the relationships tied back to the
specific snippetID's. My plan was to use SQLXML to represent the data as XML
(which I think could drive a cool DHTML menu). But, I wonder if this is the
right approach given that yukon is around the corner (yet that I need this
before Yukon's release date?)
Thanks so much,
Brian
What do you do with the data once it is stored in the database?
Do you store and retrieve the document as a whole? In that case, I would
keep the document as an NTEXT or TEXT field depending on the encoding of the
XML and propagate some lookup info into other columns. This will be easily
converted into the XML datatype.
If you are planning on doing extensive reshaping and or selecting only
parts, you may want to partition the XML into separate components and then
do the same as above...
Best regards
Michael
"Brian Madden" <brian@.brianmadden.com> wrote in message
news:uF2NsxF3EHA.1396@.tk2msftngp13.phx.gbl...
> Hello All,
> I'm fairly new to the XML game. I am designing a database that will
> contain online books. Each book will be broken into parts, each part into
> chapters, each chapter into sections, each section into... you get the
> idea. I think this is the perfect opportunity for the XML data type in
> Yukon. However, I did to put this database together in the next few weeks.
> My question is whether there are any best practices for designing
> traditional heirarchical databases today that will smoothly transition
> into an XML future. (Books, articles, suggestions here, etc.?)
> I need to have each text snippet as it's own record in one table
> (snippetID, title, body, etc.) I was thinking that I would create a second
> table for the heirarchy itself where I would maintain the relationships
> tied back to the specific snippetID's. My plan was to use SQLXML to
> represent the data as XML (which I think could drive a cool DHTML menu).
> But, I wonder if this is the right approach given that yukon is around the
> corner (yet that I need this before Yukon's release date?)
> Thanks so much,
> Brian
>