ShIgorsese,

тогда если это все сворачивается меньше чем в 4096 строк, то посмотрите настройку IndexBuildThreshold в msmdsrv.ini

а вообще тема древняя и мало что изменилось с того времени ( тут )

Кстати, Моша в статье Get most out of partition slices в разделе Related attribites так и пишет: "FE (formula engine) does coordinate decoding lazily, only if it really needs to" и дальше объясняет, что если слайс = Год, но CurrentMember этого атрибута в запросе не используется, то и декодирования его не будет, а значит и слайс тоже не получит указание использовать только эту партицию.
А у Вас очень похожая ситуация - слайс - год, а в запросе иерархия ГМД с указанием члена только на уровне день.
Он еще мог слайс записать как [Дата].[Год].&[2018], а нужно было как [Дата].[Год-Месяц-День].&[2018], потому что первый вариант - это неключевой атрибут, а второй вариант - это уровень иерархии, под которым явно собраны все даты 2018-го года...

seseAndy_OLAP,


авторЧто касается перебора.
create dynamic set currentcube.[Set_of_Days_without_Hierarchy] AS existing [Дата].[День].[День];
create dynamic set currentcube.[Set_of_Days_with_Hierarchy] AS existing [Дата].[Год - Месяц - День].[День];
Вот с этого нужно начать.


В свое время я было пытался креативить named set-ы, но меня раздражало то, что при первом в сессии обращении к кубу всё приличненько так зависало на вычислении этих сетов. И как-то не пошло у меня с named set-ами. Так что сейчас придется погружаться повторно с нуля =) Ладно, пасиб за подсказки!
Потому что Вы делали named set как filter(крупное измерение, условие отбора по группе мер на лету), а тут достаточно как existing набор уровней иерархии или existing набор ключевых атрибутов измерения, без отбора по физической мере (который постоянно будет требовать сканирование всех секций такой группы мер), а или без условия, или по условию, которое можно не засовывать в named set, а каждый раз копи-пастить внутрь формулы для calculated measure.

sese,
Вот так неправильно.


А вот так правильно.

Andy_OLAP,
Для красоты поправим, взяв явно в фигурные скобки.

seseИ еще заметил интересный эффект: если вдруг имя сета совпадет с именем любого
"вдруг" имя сета никак не может совпасть. Ведь его ВЫ пишете, а не дядя Вася, слесарь 6-го разряда.

Используйте уникальные кошерные имена, типа set1, set2, set3, всегда их описание в начало calculation для куба - и будет все хорошо!

seseAndy_OLAP,

ну и вот это я пока не смог постичь:




В чем отличие




от сета 1 ? Зачем нужен физический счетчик дней?
Потому что для красоты. У Вас в измерении дней пользователи могут выбрать дни праздников, когда фактов быть не может, могут выбрать даты из будущего.
И тогда для скажем средней цены продаж Вы посчитаете продажи только в реальные дни продаж и поделите на календарный счетчик count(existing [Дата].[День].[День]). Это не оптимально. А когда есть физические меры типа количества дней, количества праздничных дней, количества будней и так далее, привязанных напрямую Regular к измерению дней в отдельной группе мер - решение получается гибким.

Но это эстетика, кто как хочет.

seseAndy_OLAP,


авторУ Вас в измерении дней пользователи могут выбрать дни праздников, когда фактов быть не может, могут выбрать даты из будущего.



Прошу простить, но, как мне кажется, это - шаг сильно в сторону от мучающей меня проблемы.

1. Я предлагаю говорить только о СОСТОЯНИИ. Не про аддитивные меры и не про среднее. Только о состоянии. При изменении состояния делаются две записи: старое состояние с минусом и новое с плюсом. Состояние на любой момент есть сумма или с начала времен (тогда моя проблема чтения всей истории перестает быть проблемой), или от некоего начального состояния (и вот тут - я позволю себе напомнить - я сталкиваюсь с ненужным чтением партиций, принадлежащих периодам ДО даты начального состояния).
В принципе все сказанное о состоянии полностью применимо и к остатку, когда остаток на любой момент времени есть опорный остаток плюс сумма всех движений. И совершенно без разницы, есть ли в выбранную пользователем дату какие-либо изменения состояния (или товарные движения, изменяющие остаток). А так же совершенно без разницы, праздничный то день или будний. Не вижу криминала в желании пользователя посмотреть в самый праздничный день, какой у него остаток на складе или сколько скю являются бестселлерами\дедстоками.
Что же до выбора пользователем будущих дней, то тут все просто: чтобы Last Child хорошо считал результат выше листевого уровня для незавершившегося периода и не нужно было отдельно приравнивать результат текущего месяца последнему дню (что чревато ошибками, кстати), я просто сделаю календарь, который будет заканчиваться днем последнего состояния\остатка. Если я в хранилище загружаю каждый день вчерашний день, то мое измерение времени каждый день будет заканчиваться вчерашним днем. И все, пользователь в принципе не выберет ненаступивший день. И LastChild всегда будет давать результат текущего незавершившегося месяца и незавершившегося года.
Но тема ненаступивших дней в общем-то тоже слабо относится к проблеме.
2. Задачу состояния (или остатка) на любой момент я решал с помощью двух физических мер (Sum & Last Child) и скоупа, связывающего одно с другим.
3. Мне вами было предложено использовать иерархию "Год-Месяц-День" и два именованных набора: [Дата].[День].[День] и [Дата].[Год-Месяц-День].[День]. И, насколько я понял, вы предлагаете отказаться от физической меры вообще и LastChild-a в частности.

Могу я попросить раскрыть именно путь в пункте 3?
Я прописываю на партициях Slice ГМД, но не добиваюсь результата, чтение идет всей истории.
Я пытаюсь получить сет с набором дней от начального состояния до последней даты выбранного пользователем периода, но и тут не преуспеваю - см. выше.
И вот от этого впадаю в меланхолию и очень хочется, чтобы кто-то наставил на путь истинный =(

"Состояние на любой момент есть сумма или с начала времен " - таки да. Поэтому Value - агрегация SUM, Value2 - агрегация Last-Child, мера из группы мер со счетчиком дней, которая связана только с измерением дат.
А далее scope value2,день this = sum(null:[Дата].[Год-Месяц-День].CurrentMember,Value) и так далее.

Но есть нюанс. Вот если агрегация last-non-empty - все хорошо. А для last-child нужно в каждом месяце в первом числе иметь кошерный входящий остаток и считать внутри месяца (или другого периода). И тогда не просто sum, а mtd() или ytd() и так далее.

И если периоды в секциях привязаны с учетом иерархии, в которой присутствуют нарезанные периоды, например, [Дата].[Год-Месяц-День].[Месяц].&[201711], то все будет хорошо. И никаких лишних чтений.

Что касается Вашего случая - видимо, между днем и месяцем как атрибутами, которые затем ложатся в одноименные уровни иерархии, нет rigid и не выбран тип атрибута - не Regular, а Days и Months. Тогда и mtd() будет хорошо работать, и лишних чтений не будет.

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