|
|
|
CREATE SESSION CUBE не работает с ReadOnly SSAS DB
|
|||
|---|---|---|---|
|
#18+
Для повышения производительности 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, чтобы к какому бы серверу пользователей не кинуло, везде были запрещены группировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2019, 05:13 |
|
||
|
CREATE SESSION CUBE не работает с ReadOnly SSAS DB
|
|||
|---|---|---|---|
|
#18+
Max_11111, хоть и не сталкивался с таким случаем/конфликтом но да, похоже что для схожести результатов master-ноду (processing mode) нужно будет после process тоже в read-only переводить (query mode, причём лучше пошаманив с настройками соответствующих приоритетов) через тот-же Detach/Attach (т.к. Alter ReadWriteMode property не получится) если функциональность Session Cube критична - в принципе что мешает работать не с одной копией данных (в ReadOnly), а со множеством копий одних и тех-же данных (Clone-Attach/Sync/Restore и т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2019, 05:47 |
|
||
|
CREATE SESSION CUBE не работает с ReadOnly SSAS DB
|
|||
|---|---|---|---|
|
#18+
..кроме как из-за ограничения свободного места (которое нынче довольно дешевое) дискового пространства.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2019, 05:49 |
|
||
|
CREATE SESSION CUBE не работает с ReadOnly SSAS DB
|
|||
|---|---|---|---|
|
#18+
Как вариант - поробовать использовать сторонний железный балансировщик, а "внизу" пусть лежат базы в обучном режиме. Но будет ли это работать - фиг его знает, чисто теоретически должно. На прошлой работе мы использовали самописный софтовый балансировщик, оставшийся от предыдущей команды - он достаточно хорошо работал. Но чтобы его написать с нуля, придется потратить месяцев 5-6 плюс для этого нужны весьма специфические знания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2019, 07:49 |
|
||
|
CREATE SESSION CUBE не работает с ReadOnly SSAS DB
|
|||
|---|---|---|---|
|
#18+
vikkivMax_11111, что мешает работать не с одной копией данных (в ReadOnly), а со множеством копий одних и тех-же данных (Clone-Attach/Sync/Restore и т.д.) Сейчас кластер состоит из 2 физических машин и 4 виртуалок, располагающихся на 1 мощном сервере и работающих с 1 файлом. Синхронизация состоит из 2-х копирований файлов (встроенной синхронизацией SSAS, по сути являющейся простым копированием) и длится примерно по пол часа на копию. Если вместо 3 копий иметь 6 - то время и затраты на синхронизацию увеличатся (минимум на пол часа, если копировать параллельно) А если количество серверов ещё увеличится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2019, 09:33 |
|
||
|
CREATE SESSION CUBE не работает с ReadOnly SSAS DB
|
|||
|---|---|---|---|
|
#18+
КритикКак вариант - поробовать использовать сторонний железный балансировщик, а "внизу" пусть лежат базы в обучном режиме. Но будет ли это работать - фиг его знает, чисто теоретически должно. На прошлой работе мы использовали самописный софтовый балансировщик, оставшийся от предыдущей команды - он достаточно хорошо работал. Но чтобы его написать с нуля, придется потратить месяцев 5-6 плюс для этого нужны весьма специфические знания. О, а Вас я помню. Год назад Вы так и не раскрыли код Вашего балансировщика :) К самому балансировщику вопросов нет, NLB нас почти полностью устраивает. А нынешний колхоз (между прочим описанный в книгах по SSAS как наиболее правильный) позволяет сократить время на синхронизацию серверов после обработки OLAP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2019, 09:43 |
|
||
|
|

start [/forum/topic.php?fid=49&gotonew=1&tid=1857573]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
150ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 259ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...