Добрый день, All!

Недавно тюнил файловую систему под SQL FILESTREAM, и там делал следующее:
- Отключаем file indexing
- Отключаем 8dot3name
- Отключаем lastaccess update

Смысл этих всех действий в том, что FILESTREAM порождает массу файликов, и данные настройки улучшают производительность файловой системы при работе с ними.
Но - по сути структура хранения SSAS MOLAP похожа - там тоже много файлов . Но явных best practices с похожими настройками не нашел. По идее - выполнение рекомендаций должно помочь или по крайней мере - не навредить. 8dot3name и file indexing - отключал, все ok, с lastaccess - пока не пробовал.
Кто-либо делал что-то подобное?

Alex_496,

Смысл поста был - а делал ли такое кто-нибудь еще, и что думаете?

Краткое резюме.
О системе - SSAS DB - содержит 6 кубов, около 350 групп мер (часть из них - M2M) и 600 измерений. В кубах - примерно 7800 партиций. Процессинг запускается из SSIS пакета, так что хронометраж отслеживается.

Процессинг ежедневный (Dims Process Update + Changed Measure Groups Process Data + Index) - сокращение времени на 3-5%. Процессинг полный - сокращение времени на 5-7%.

Установил на тесте все три опции, пока ошибок нет. Буду мониторить дальше...

Alex_496,

Я и не ожидал большого прироста - иначе был бы вопрос - почему MS явно о таких настройках не говорит.

По количеству мер на куб - вы правы, не мало. С другой стороны, кубы имеют общий набор измерений. Группы мер - привязаны явно к подмножеству измерений, а остальное - через M2M. Далее все сводится в куб - единую витрину.

А какой, на ваш взгляд, будет выигрыш от уменьшения количества групп мер в кубах? Минусы - кубов станет больше, служебных M2M групп мер и их партиций - тоже больше, метаданные вырастут в объеме.
Кубы формировались "по историческому" признаку, при подключении новых систем-источников данных, особо над стратегией разбиения мер по кубам не думал.