MS SQL2000 + MS AS 2000. П4-2.4 + 1Гб рам.
Виртуальный куб План-Факт. 3 реальных измерения(Дата, товар, ТипКлиента) +3 виртуальных от товара (Производитель, Подкатегория, Бренд) + Данные "Количество" и "сумма".
Исходные кубы агрегированы со 100% perfomance, номенклатура ок 400 поз, время-2года. В кубах детализация до уровня День.
Одна из основных и частых задач - сведения о выполнии плана НАРАСТАЮЩИМ итогом с НАЧАЛА МЕСЯЦА.
Проблема - долгий (до 5мин) расчет к концу месяца развернутого отчета,
т.е. при выбранной дате по подкатегории, бренд, товар - отображение плана нараст итогом, факта нар итогом, отклонения абсолютного и в % (все сделано CM). Расчет идет на сервере.
В MDX выражениях перепробовал разные варианты функций
PeriodsToDate([Месяц],[Дата].CurrentMember),
Mtd([Дата].CurrentMember)
[Дата].CurrentMember.Parent.FirstChild:[Дата].CurrentMember

Но результат примерно одинаковый.

Прошу помощи спецов. Как можно убыстрить/оптимизировать сию модель в рамках имеющегося ПО и железа?

Для "ФактТ нарастающим с начала месяца" :

iif([Дата].CurrentMember.Level.Name = "День", sum(MTD(), Measures.[ФактТ]), Measures.[ФактТ])

Клиент: MS ExcelXP

Provider=MSOLAP.2;Integrated Security=SSPI;Persist Security Info=False;Data Source=SQLSRV;Initial Catalog=РРР;Client Cache Size=25;Auto Synch Period=10000;Execution Location=3;Large Level Threshold=100;

"Расчет на сервере" - имелось в виду, что Execution Location=3 в парам соединения.

to Quark:
Делал, не помогает. Они, в принципе, маленькие, 2-10 листьев, так что особо не повлияли.

to backfire:
Часть строки выкинул, выполняться стало на клиенте, ~10% быстрее. Но дело в том, что при расчете СМ в основном грузится проц, а на клиенте в основном стоят Cel. Так что выигрыша не получится особого :(

А можно немного подробнее про объявление СМ в TimeDimension?

спасибо, щас попробую

to backfire:
К сожалению, использование СМ в TimeDimension не принесло кардинальных улучшений (запускал по нескольку раз MDX запросы к прилинкованному OLAP серверу через Query Analyzer на самом сервере).
По видимому, проблема все таки в функции PeriodsToDate (как писал В.Иванов) и ее аналогах, где бы они не использовались, везде выбираются все листья и только потом суммируются.

Вопрос В.Иванову:
Чем все таки обойти эту проблему? Чем заменить использование Mtd() для расчета нараст итога с нач месяца?
Хотя бы в каком направлении копать и возможно ли решение данного вопроса в рамках MDX и средств MS AS?

To Jurii:

В форуме я перечитал все что говорилось по этому поводу.
Еще раз обращаю внимание, что нужен нарастающий итог С НАЧАЛА МЕСЯЦА ДО Текущей (или выбранной даты месяца). Как же тут использовать агрегаты Год, Квартал, Месяц и НЕ использовать агрегаты по дням текущего месяца?

Или я где то торможу?

To Jurii:

Фух, а то я уже рвал на себе волосы :)
Я понимал, что СОВСЕМ без агрегатов по дням не обойтись.
Для общего случая решение использовать укрупненные агрегаты было известно.
Не хотелось бы неделю вводить, но попробую.
Жаль, что чудес на свете не бывает.

Это понятно.
Но в данном конкретном случае, наверное, MDX запрос сильно не прооптимизируешь.

а PowerPlay качает на клиентскую машину данные порциями, и вычисления проводятся только для отрисовки текущего отчета...

Если это так, то PowerPlay работает как OWC, там действительно расчитывается "кусками" для отображения на экране, в отличие от Excel XP, кот считает сразу по всем развернутым листьям.
Я пробовал запускать мой запрос через IE, все достаточно чудненько и быстренько считается - неск сек, но только для отображаемых листьев, как только PageDown или копировать в эксел - уходит в более долгий расчет.

to backfire:
Я по клиентам вообще измерение не делал, толлько признак внешний/внутренний, а по продукту Head, Top - не проходит, надо все сразу, причем сразу в виде Тип/Категория/Товар (короче говоря, нужна сводка план-факт по товарам и типам клиентов в кол и сумме с нараст итогом с нач месяца).