Ferdipux,

Ну, не факт, что причина в этом. Может быть это было банальное опережающее чтение.

Alex_496Может не совсем в тему отвечу, но:

я делаю практически всегда Rigid связи, т.к. у меня Process Data и Process Index разнесены на отдельные шаги.
И если значения атрибутов измерения изменятся, то нужно выполнить Process Index, а читать из источников данные в факты групп мер (Process Data) не нужно.

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

Каким образом это работает? Ведь в случае жестких связей требуется full-процессинг после того, как элемент изменил свое положение в иерархии. В случае большого куба это чревато тем, что в начале рабочего дня кубы будут не обновлены.

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

Alex_496Критик,

если у Автора измерения не в десятки миллионов элементов, то чего волноваться за full processing измерений. Если натуральные иерархии в 4-5 уровней с хорошим коэффициентом отношения уровня к предыдущему уровню - вообще класс.
Ентерпрайз сейчас поди уж не удивить 1Тб оперативной памяти.

Кстати, может кто подскажет как еще ускорить process index больших измерений

Дык измерение маленькое, а фактов куча. К тому же в процессе обработки нужно отдельную делать ветку, в которой нужно будет перепроцешивать весь куб.

По большим измерениям я исследовал вопрос - у меня все уперлось в производительность на ядро. Видимо, в коде процессинга SSAS имеется кусок, который не распараллеливается.