![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hi All , I am reviewing a cube which has thousands of partitions (at least trying to) as opening in analysis manager is like watching paint dry .. in the end we wrote a program to dump the structure to an XML file as watching paint dry is no fun. Many of these partitions are very small and I can't believe that AS is really benefitting from this strategy.. Fact Tables and partitions are created programmatically based on various data values in the source data systems by a "clever" program but it all feels like it is ending up with way too many files. Build times are pretty poor as dimensions change regularly requiring cube rebuilds. Data size of largest composite cube is only a few GB so I just don't see the point of them all and I'm a little concered that as the number of partitions get bigger and bigger that AS may choke at some point .. I guess the question is .. am I wrong and this strategy really is not a problem for AS just a problem for the poor support guys who have to manage 2000+ fact tables and associated stored procs. I'm a great believer in keeping things simple and this doesn't feel simple but I'd welcome any other opinions. Thanks ps Its AS2000 |
#3
| |||
| |||
|
|
Did you mean to say 2000+ partitions instead of 2000+ facts? I think (if I remember correctly) AS2000 had some pretty good recommendations around the maximum number of rows that should be in a partition. Sounds like your automated program is over-partitioning the cube unless you have that many rows. I want to say I read 500,000 rows per partition... How many rows in your underlying fact table? mpsatwork (AT) gmail (DOT) com> wrote in message news:1149371619.326618.93320 (AT) i40g2000cwc (DOT) googlegroups.com... Hi All , I am reviewing a cube which has thousands of partitions (at least trying to) as opening in analysis manager is like watching paint dry .. in the end we wrote a program to dump the structure to an XML file as watching paint dry is no fun. Many of these partitions are very small and I can't believe that AS is really benefitting from this strategy.. Fact Tables and partitions are created programmatically based on various data values in the source data systems by a "clever" program but it all feels like it is ending up with way too many files. Build times are pretty poor as dimensions change regularly requiring cube rebuilds. Data size of largest composite cube is only a few GB so I just don't see the point of them all and I'm a little concered that as the number of partitions get bigger and bigger that AS may choke at some point .. I guess the question is .. am I wrong and this strategy really is not a problem for AS just a problem for the poor support guys who have to manage 2000+ fact tables and associated stored procs. I'm a great believer in keeping things simple and this doesn't feel simple but I'd welcome any other opinions. Thanks ps Its AS2000 |
![]() |
| Thread Tools | |
| Display Modes | |
| |