invm,

хочу парировать на тему "секционирование - средство администрирования"
т.к. сам пользуюсь именно для ускорения обсчета кубов, а не для удобства управления.
но никогда тесты не проводил, а теперь вдруг захотелось.

имеем базу и 2 аналогичные таблицы на ~300млн строк,
одна (t1) с кластерным индексом по полю типа datetime (со временем), вторая (t2) секционирована по полю типа int в формате YYYYMM (т.е. месяц года) в каждой секции примерно 11млн записей

и на том же сервере, но на другом диске куб с тремя измерениями:
dates - с 09/2016 по 03/2019, ключ типа int в формате YYYYMMDD
clients - примерно 4млн записей, ключ типа bigint
sales_orders - ключ типа инт - тупая нумерация продаж в некоем разрезе, не больше 1000 записей
и 4 группы мер у которых:
1. из t1 в группу мер sales_1_1 c одной секцией
2. из t1 в группу мер sales_1_N c ежемесячными секциями по условию (пример) sale_date between '20181201' and '20181231 23:59:59'
3. из t2 в группу мер sales_N_1 c одной секцией
4. из t2 в группу мер sales_N_N c ежемесячными секциями по условию (пример) sale_month = 201812

в каждой, 2 меры, сумма по полю sales_fact и distinct_count по полю order_number (связь с измерением sales_order) что накладывает требование по дополнительной сортировке данных.

обработка измерений сделана заранее.
обработка групп мер - full process. причем, для каждого случая предварительно рестарт SQL и SSAS, и две последовательные обработки, на графиках, каждый раз вторая.

дальше графики, единственное пояснение для них всех - гафики начинаются с момента старта процессинга. до начала получения данных (розовый толстый) это как раз и есть работа SQL по сортировке (эту оптимизацию не делал нигде, никак).
(модераторов прошу простить за широкие графики и пустые места, которые можно было бы сократить, но сделано это только для удобства сравнения)
смотрим:

sales_1_1

sales_1_N

sales_N_1

sales_N_N

да, забыл, в настройках процессинга 20 соединений максимум, т.е. одновременно не более 20 секций