Коллеги, всем доброго дня.
Поделитесь плз ссылками на доку (или tips and tricks или форумы/блоги) по настройке куба, по поиску в нем узких мест, увеличению производительности и т.д.

Пока все что смог найти это несколько советов (кроме 5го пункта - все сделал):
1. если данных в источнике меньше 10 млн строк, партиции в кубе - можно не создавать;
2. если показателей, меньше 20-30 и они не группируются по явным признакам, то группы мер можно не делать;
3. все вычисления, преобразования и т.д. по максимуму проделать на уровне источника;
4. ключевые поля измерений сделать числовыми.
У меня Decimal. Надо на int менять?
5. поместить меру Distinct Count в отдельную собственную группу мер;


Описание.
Источником данных для куба является набор вью в Оракл (схема "звезда", 22 измерения и 1 таблица фактов).
В источнике:
таблица фактов - 8 млн строк,
20 измерений - от 10 до 100 строк,
2 измерения по 90 000 строк,
1 измерения на основе таблицы фактов - также 8 млн строк. Т.е. таблица фактов поделена на 2 вью: все меры (то что можно агрегировать) перенесены в факт,
все атрибуты (то по чему возможен групбай) перенесены в измерение. В основном в этом измерении различные даты.
Измерения время - нет. Заказчику не нужно;
Иерархий на измерениях нет.

Сама проблема.
Куб процессится 20-30 минут, что приемлемо. Но сама работа происходит медленно:
- медленно обновляются в экселе данные в кубе ("обновить все"),
- медленно выполняются запросы, при добавлении очередного измерения в отчет и т.д.

Добрый день.
Спасибо за ответы.
1. Сейчас нахожусь на этапе приведения типов данных связочных полей к INT или BIGUNT. Заметил такую штуку: если в Oracle (наш источник) тип поля number без указания точности, то в SSAS оно Double; если точность указана, например number(10) - то оно bigint. Везде точность указал, но при обновлении представления источника данных это изменение не обнаруживается.
Как сделать так, что бы поля с заново указанной точностью обновились в проекте и стали bigint-ом?

2. И основной вопрос по dim на основе факта (8 млн элементов).
Еще раз поясню какая была идея создания этого измерения. В это измерение вынес все ID и даты, для которых не нужно отдельных измерений, но которые нужно просто отображать в отчете. Т.е. в нем такие поля как "id пользователя из системы 1" not null , "id пользователя из системы 2" not null, "дата 1й покупки" null, "дата 2й покупки" null, "месяц 1го контакта" not null и т.д. - всего 10 таких полей.

Если брать дистинкт по каждому из этих полей то из 8 млн записей
-- месяц 1го контакта - 100 записей
-- id пользователя из системы 1, id пользователя из системы 2, дата 1й покупки, дата 2й покупки - от 100к до 600к записей.

При построении отчета, фильтрация по этому измерению будет происходить по полю "месяц 1го контакта" - т.е. от 8 млн будет браться сотая часть. Все остальные поля этого измерения просто как доп. атрибуты для вывода в отчет. Плюс фильтрация по остальным измерениям и в отчет попадает около сотни записей.

Собственно так и работает, но медленно.

2.1. Что в архитектуре можно изменить?
2.2. Может быть вынести в отдельный DIM "месяц 1го контакта"?
2.3. Или, для тех атрибутов что not null (id пользователя из системы 1, id пользователя из системы 2) тоже сделать отдельные DIM?
2.4. Как правильно работать с такими атрибутами как "дата 1й покупки", которая м.б. NULL. Я бы их, вообще, в кубе оставлял... но тут не получилось. Какую-ть неаддитивную меру и т.д.?