[b]Backgrounds:[/b]I have a big table about 180G for size and 4 billion rows on SQL server 2008R2 64bit so far, and growing much very day.So far, we partitioned source DB table by ColumnA, and we have 3 distinct count on ColumnA, ColumnB and ColumnC, then we have 3 measure groups(as some sqlserver&doc required), for example, MG_A, MG_B and MG_C for each distinct count, and we want to partition MG_A, MG_B and MG_C. The final goal is that we can build each measure group partitions incrementally.[b]Goal:[/b]Better performance for building cube with these 3 distinct counts on the same source DB table.[b]Question 1:[/b]For MG_A, ColumnA is OK, source DB table and MG_A are all partitioned by ColumnA, but how about MG_B and MG_C?If source DB table is partitioned by ColumnA, and MG_B is partitioned by ColumnB(this is recommended by some docs), then these two partitions are not aligned one by one(Alignment is required by some doc), then any impact on performance?[b]Question 2:[/b]Any idea for better performance of cube building?Since 3 distinct count is based on the same source DB table, any chance to improve the performance of cube building? otherwise, 3 times work to do just as 3 distinct counts on 3 DB tables.[b]Question 3:[/b]If we partition measure group NOT by distinct column, for example, partition MG_B by ColumnA, instead of ColumnB, is this a correct solution? That means, is it mandatory that partition MG_B by ColumnB?[b]Question 4:[/b]If we partition measure group by distinct column, any chance for only incremental processing? For example, just build the latest partition? Otherwise, we have to re-build all MGs from the scratch. It's too slow.Because I saw some doc said for distinct count aggregatonfunction, you have to re-build all partitions.I know too much questions here, but one depends on another one.[b]All in all, any suggestions about distinct count and incremental cube building?[/b]Thanks.
↧