Re: Timeout problems due to huge Fact Table
- From: "Will Alber" <junk@xxxxxxxxxxxxxxx>
- Date: Mon, 28 Jan 2008 18:05:52 -0000
I've also experienced very poor performing queries that the cube itself has
generated based on a table - however, typically when having a large number
of dimensions & with 'materialize' set on the relationships in the dimension
usage tab.
I've one measure group that takes around an hour to process, and it has only
10 million rows. :(
"Jeje" <willgart@xxxxxxxxxxx> wrote in message
news:623301D2-D55C-430F-A2D4-D109F4931F80@xxxxxxxxxxxxxxxx
from what I understand,
to fill your cube you are using a very complex query instead of a table.
(right?)
have you try to do it in your ETL process instead-of a view?
or part of the query can be evaluated in the ETL this can reduce the query
complexity used for the cube.
indexed views is not a solution you'll be a winner by playing at the ETL
level and adding required table in the database.
how many rows do you have in the table?
and have you optimized the tempdb database?
and on how many disks your database is and your tempdb is?
"Harry Leboeuf" <HarryLeboeuf@xxxxxxxxxxxxxxxxx> wrote in message
news:eyDZjKYYIHA.4272@xxxxxxxxxxxxxxxxxxxxxxx
I would like to have some thoughts on how other people deal with this
problem.
It's mostly in our testing environment that this problem occurs.
The production server is q very performant machine and can still deal
with the huge fact table, but one day we will get performance problems
there too.
Ok, at that moment servers might be again double so fast ....
But how do you people deal with a fact table that (even when just doing
the select in Sql) that needs over 6 hours to complete.
Workign with a staging table would nog completely solver the problem as
building the staging table would take the same time.
The performance problem is not in SSAS, is just the huge query.
I could create an indexed view of the query but still .....
And working with daily uploads would create a quite difficult upload
system as we have (even historical) quite volatille (chaging) data.
If anybody has some thoughts, suggestions ... feel free.
Kind Regards, Harry
.
- Follow-Ups:
- Re: Timeout problems due to huge Fact Table
- From: Jeje
- Re: Timeout problems due to huge Fact Table
- References:
- Timeout problems due to huge Fact Table
- From: Harry Leboeuf
- Re: Timeout problems due to huge Fact Table
- From: Jeje
- Timeout problems due to huge Fact Table
- Prev by Date: RE: MDX - CrossJoin not summing correctly
- Next by Date: Re: MDX - PROPERTIES MEMBER_KEY
- Previous by thread: Re: Timeout problems due to huge Fact Table
- Next by thread: Re: Timeout problems due to huge Fact Table
- Index(es):
Relevant Pages
|
Loading