Проблема, на мой взгляд (могу ошибаться), проявляется при следующих условиях:
не все измерения, включенные в виртуальный куб, являются общими для всех кубов, составляющих виртуальный;

среди этих «не общих» измерений есть хотя бы одно достаточно большое;

факты в кубе достаточно разрежены.

Поясню на упрощенном примере:
Куб Остатки с измерениями Время, Товар и показателем Остаток .
Куб Продажи с измерениями Время, Товар, Клиент и показателем Продажа .

Измерения Товар и Клиент приблизительно по 1,5 тыс. элементов на нижнем уровне.
Куб Продажи сильно разрежен. Поэтому даже достаточно объемистые выборки, на полностью развернутых измерениях Товар и Клиент с использованием NonEmptyCrossjoin, работают достаточно быстро.

Создадим виртуальный куб Остатки и Продажи и включим в него все измерения ( Время, Товар, Клиент ) и показатели ( Остаток, Продажа ).

По-прежнему, все нормально, даже если полностью разворачиваем измерения по всем уровням (при условии NonEmptyCrossjoin).

Сделаем тривиальный Calculated Member:
(т.е. основанный на показателе из куба, имеющего меньшее число измерений ).
И вот тут начинаются тормоза!..

Кстати, небольшое отступление:
Раньше для подобных Calculated Members в виртуальном кубе я НЕ использовал функцию ValidMeasure (поскольку не знал о ней :) )…
Но результат получается одинаковый (в т.ч. и по быстродействию) как при использовании ValidMeasure, так и без него. Т.е. варианты типа:
выглядят эквивалентными.
Т.е. попутно вопрос: критично ли использование функции ValidMeasure в таких случаях? Есть ли какие-то подводные камни, которые я на вскидку не вижу?
Или, скажем, ValidMeasure был актуален только для MS OLAP 7.0?

Вернемся к проблеме…
Если я не вывожу в свой сильно развернутый отчет данный Calculated Member, либо убираю «длинное» «не общее» измерение Клиент , то все быстро.
Но в случае, когда в отчете развернуты хотя бы 2 больших измерения, одно из которых «не общее», и выведен Calculated Member, то строится очень долго (до 1,5 мин., хотя в итоге получается порядка 6 тыс. ячеек данных).

Очевидно, что узким местом является NonEmptyCrossjoin (точнее, собственно Crossjoin).
(Повторюсь, что Calculated Member в данном случае строится на основе сильно разреженного показателя и, соответственно, тоже сильно разрежен).

Как я понимаю, логика примерно следующая:
1. Если я вывожу только физические показатели, то сервер просматривает (либо строит) собственно агрегаты , каковых немного.
Таким образом, построение осей для NonEmptyCrossjoin идет как бы "от имеющихся агрегатов".
2. Если я вывожу Calculated Member, то сервер вынужден прежде вычислять его для каждой комбинации Crossjoin (а это в рассматриваемом примере потенциально 1,5 тыс. * 1,5 тыс., т.е. более 2 млн. элементов — сложность расчета возрастает экспоненциально).
Таким образом, в данном случае построение осей для NonEmptyCrossjoin идет как бы "от измерений" .

Все эти объяснения, а также условия, описанные в начале сообщения, — лишь мои предположения.

Пока никакими ухищрениями побороть описанную ситуацию не удалось.
Может, я не в том направлении копаю?..

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

Я как раз вчера нашел описание моей ситуации в документе Microsoft SQL Server 2000 Analysis Services
Performance Guide (http: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/olapunisys.asp )

--------------------------------------------------------------------------------------
Еще раз немного о контексте (вчера я не очень хорошо на этом акцентировал):
Один из показателей виртуального куба зависит не от всех измерений , включенных в виртуальный куб.
Так, Остаток это функция от ( Время, Товар ), а от Клиента , которому товар продавался, естественно, не зависит.
С помощью виртуального куба хотим построить что-то типа Оборотно-сальдовой ведомости.
Т.о., в отчет (за месяц) выведены как измерение Товар , так и измерение Клиент (а также показатели Входящий остаток и Продажи ).
Соответственно, для Входящего остатка вырастает «борода» из клиентов, для которых остаток по определению NULL, и только на уровне Клиенты.All он может иметь значение.
Для физических мер все быстро. Проблема возникает, если я пытаюсь рассчитать --------------------------------------------------------------------------------------

Вот цитата из вышеназванного документа:

раздел "Use Query Time Calculations Sparingly in Very Large and Complex Cubes":When you use a calculated member on the Measures dimension, set the Non Empty Behavior property to the name of a measure, in order to treat the calculated measure as empty if the specified measure is empty. Otherwise, computations that include the NON EMPTY keyword can be slow and consume a lot of client resources, because the calculation is performed for every row or column just to determine whether the result is empty. On sparse cubes, the computation time can be cut dramatically.
Для моего Calculated Member’а я установил Non Empty Behavior = Входящий остаток
Надо сказать, что я почему-то воспринял это фичу с предубеждением — по сути, я расценил эту установку, как указание на tuple ([Measures].[Входящий остаток]) — и подумал, что всегда буду получать NULL для Исходящего остатка, если Входящий остаток является NULL’ом (а это, естественно, было бы некорректно).
Проверил (поспешно) на (довольно навороченном) отчете и убедился (как впоследствии оказалось, ОШИБОЧНО!), что мне это не поможет.

Короче, почему-то (поздний час, наверное :)) ) я воспринял это, как «так и должно быть». И начал решать задачу, вводя [Исходящий остаток] на fact-level (из соображений быстродействия входящие остатки я рассчитываю и храню в DWH — что, может быть, и не совсем верно…)

--------------------------------------------------------------------------------------

Сегодня, чтобы ответить в форуме, для «очистки совести» проверил Non Empty Behavior на простом примере. Работает!!!
Проверил тщательно на реальном. Все ОК!

Ведь действительно в Non Empty Behavior указывается не tuple, а имя Measure, а это как раз и нужно!


Спасибо всем!
Ирине — особо, за вселённую уверенность :))

В запросе действительно используется NON EMPTY CrossJoin(…) — работаю через Excel, так что повлиять на это не могу.
(А раньше я и не подозревал о таких различиях между NON EMPTY CrossJoin(…) и NonEmptyCrossJoin(…) )

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

P.S.
Еще важные выводы, которые я сделал :)) — не стоит делать поспешных заключений, ночью нужно спать, а «утро вечера мудренее» :))