Для повышения производительности OLAP у меня развёрнут NLB кластер из нескольких машин. На нескольких машинах SSAS в режиме REadOnly обращается к одной многомерной БД (сделано в соответствии с документацией MS: общее сетевое хранилище и несколько серверов, работающих с одной копией данных).
Всё было бы хорошо, но пользователи начали жаловаться что их Excel таблицы не обновляются с ошибкой "Изменение dimension ... невозможно вследствие принадлежности к базе ..., доступной только для чтения". В процессе выяснения причины такого поведения выяснил, что пользователи используют группировку строк сводной таблицы в Excel, при этом Excel выполняет команду "CREATE SESSION CUBE" и затем работает уже с ним. Нашёл что это не баг, а фича: https://docs.microsoft.com/ru-ru/sql/analysis-services/multidimensional-models/database-readwritemodes?view=sql-server-2017 . "При режиме работы БД SSAS ReadOnly Пользователи Excel не могут использовать функцию группирования в сводных таблицах, так как внутренне эта функция реализована с помощью команд CREATE SESSION CUBE ."

Кто-нибудь сталкивался с такой проблемой? Какие есть идеи по тому как обойти её?
Из-за того что часть БД ReadOnly, а часть - ReadWrite (используют свои БД), у пользователей возникает вопросы типа: "сегодня работает, вчера не работало, а позавчера снова работало". Я пока склоняюсь к тому, чтобы после обновления все многомерные БД переводить в режим ReadOnly, чтобы к какому бы серверу пользователей не кинуло, везде были запрещены группировки.

vikkivMax_11111,
что мешает работать не с одной копией данных (в ReadOnly), а со множеством копий одних и тех-же данных (Clone-Attach/Sync/Restore и т.д.)
Сейчас кластер состоит из 2 физических машин и 4 виртуалок, располагающихся на 1 мощном сервере и работающих с 1 файлом. Синхронизация состоит из 2-х копирований файлов (встроенной синхронизацией SSAS, по сути являющейся простым копированием) и длится примерно по пол часа на копию.
Если вместо 3 копий иметь 6 - то время и затраты на синхронизацию увеличатся (минимум на пол часа, если копировать параллельно)
А если количество серверов ещё увеличится...

КритикКак вариант - поробовать использовать сторонний железный балансировщик, а "внизу" пусть лежат базы в обучном режиме. Но будет ли это работать - фиг его знает, чисто теоретически должно.

На прошлой работе мы использовали самописный софтовый балансировщик, оставшийся от предыдущей команды - он достаточно хорошо работал. Но чтобы его написать с нуля, придется потратить месяцев 5-6 плюс для этого нужны весьма специфические знания.
О, а Вас я помню. Год назад Вы так и не раскрыли код Вашего балансировщика :)
К самому балансировщику вопросов нет, NLB нас почти полностью устраивает. А нынешний колхоз (между прочим описанный в книгах по SSAS как наиболее правильный) позволяет сократить время на синхронизацию серверов после обработки OLAP