доброго времени суток.
вводная:
ms sql 2005 Enterprise Edition (64-bit) +
yah

yahдоброго времени суток.
вводная:
ms sql 2005 Enterprise Edition (64-bit) +
yah
виноват, ентер задел.
продолжаю.
+ssas.
есть куб довольно большой и по данным и по метаданным. Причем, с довольно строгим ЖЦ.
поэтому затаскивать в него что-то временное не очень хочется.
есть необходимость видеть некую дополнительную инфу в некоторых разрезах этого куба и сравнивать ее с мерами основного куба.
придуманное и реализованное решение:
в той же базе создается куб, у которого
1. измерения = часть измерений большого куба
2. несколько гм - линкованные гм большого куба
3. еще одна гм - "своя гм" имеющая регулярные связи с измерениями.
ожидалось, что когда большой куб развернут, достаточно передеплоить гм№3 и маленький куб становится виден.
однако, почему-то он остается в состоянии "недоступен", хотя единственная партиция единственной "своей" гм - благополучно отпроцешшена.

вопрос: "куды бечь"?

[quot yah]yahвопрос: "куды бечь"?
отвечу сам себе: rtfm ;-)
так что вопрос закрыт. ну и детали - если кому интересно:
"Для получения самых последних изменений следует удалить и повторно создать все связанные группы мер на основе измененного исходного объекта."
отсюда :
https://msdn.microsoft.com/ru-ru/en-en/library/ms174899(v=sql.120).aspx
иными словами, если с гм произведены любые действия, требующие ее полного процессинга - например, добавлена мера - надо пересобрать куб заново - отвязать гм, привязать гм, поквасить лишние измерения, которые ссас в куб понапихает.
после чего отпроцессить куб целиком.
процесситься при этом будет только "своя" гм, ну, это как раз естественно и ожидаемо.

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

конкретика для понимания:
Пересобрать этот куб с линкованными объектами у меня занимает минут 10. Отдеплоить 10 -20. Нагрузка на сервак некритичная совершенно.

Единственная альтернатива, которая видится - продублировать в маленьком кубе те ГМ из большого куба, которые нужны.
Даже с учетом того, что 3\4 партиций будут выкинуты (все данные раньше 16 года), это приводит к приличной нагрузке на сервак в течение деплоймента, а идёт он часа 3.
при этом обновлять данные мне приходится ежедневно, а на fullDeploiment я попадаю раз в неделю - не чаще