IlyamIВсем доброго времени.

Имеется куб с количеством данных около 90 Гб.
В проекте куба MS SQL Management Studio описана только одна секция.
Остальные секции нарезаются sql-скриптом по расписанию.

Каждая секция содержит данных примерно на 1 Гб. Пересчет каждой секции занимает примерно 30-40 минут (данные забираются с другого сервера). На данный момент, соответственно, секций насчитывается ~90.

Необходимо добавить новое измерение.
Как это сделать наиболее оптимальным способом, чтобы при этом не пришлось полностью пересчитывать куб, так как это займет примерно двое суток.

С уважением.
Пересобираете на девелоперском сервере, затем делаете syncronise для OLAP базы в сторону боевого. Вместе со всеми кубами и измерениями.
Если 2016-й - будет без проблем. Если 2017-й - не забудьте накатить CU11.

a_voroninAndy_OLAPпропущено...

Пересобираете на девелоперском сервере, затем делаете syncronise для OLAP базы в сторону боевого. Вместе со всеми кубами и измерениями.
Если 2016-й - будет без проблем. Если 2017-й - не забудьте накатить CU11.

На 2014 syncronise такой тормозной был, что был проще обновить заново. Особенно, где много партиций. Как сейчас на 2016 2017? Он кстати держит старую версию БД доступной до своего окнчания?
Коллега, я предполагаю, что у автора темы вариантов не очень много. Пересчитывать вживую куб, предупреждая пользователей, что доступ к нему закрыт до окончания пересчета (через роли), или синхронизировать пересчитанную базу с девелоперского на боевой.

Может быть, у него сетка локальная дохлая - и никакой синхронизации ему не светит. Это только опытным путем можно выяснить.

Если у него есть два сервера, на которых можно поставить опыт, псевдобоевой и псевдодевелоперский, а задача стоит "добавить новое измерение с МИНИМАЛЬНЫМ простоем пользователей", то какие у него еще варианты?

Обновление измерений и кубов в его OLAP базе явно раз в сутки. Ну и обновляет на боевой, затем на девелоперской измерения и прочие кубы, потом подсовывает новое измерение, потом пересчитывает куб, потом вечером, когда все в основном разошлись - запускает синхронизацию и ждет, что она завершится успешно до начала вечернего пересчета и обновления по ночам.

А Вы как-то иначе это делаете?

a_voroninНа 2014 syncronise такой тормозной был, что был проще обновить заново. Особенно, где много партиций. Как сейчас на 2016 2017? Он кстати держит старую версию БД доступной до своего окнчания?
Насколько я помню - на 2016-м синхронизация проходила за время, которое всех устраивало. На 2017-м никто этого делать не будет до выхода SP1.

Ferdipuxa_voronin...
На 2014 syncronise такой тормозной был, что был проще обновить заново. Особенно, где много партиций. Как сейчас на 2016 2017? Он кстати держит старую версию БД доступной до своего окнчания?

Из опыта - есть инсталляция с примерно 15000 партиций, SSAS 2016. Сама синхронизация занимает до пары часов обычно, и затем минут на 20-30 - коммит транзакции NTFS. В это время база гм, ограничено доступна, тупит и выбрасывает пользователей.
Да, процессятся и изменяются не все 15K партиций, примерно 1000-1500.
Пробовали на обоих серверах дефолтные каталоги с OLAP базами сложить на PCIE-SSD, а далее секции кубов перенаправить с помощью storage location на диски D, где SSD/HDD не такие скоростные? Чтобы база "смотрела" на две NTFS вместо одной.

КритикAndy_OLAPА Вы как-то иначе это делаете?

копируем,
выводим сервер из фермы,
детач, замена, аттач,
вводим сервер в ферму

единственный минут - серверов нужно больше 1 )
Это при условии, что на сервере одна OLAP база, в куб которой нужно добавить одно измерение. А если их много? Оптимальнее в таком случае синхронизация. Я так думаю, вполне возможно, я таки ошибаюсь.

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

еще вариант - генерим скриптом новый куб (под другим именем), пересчитываем его, переименоваем (старый в новый, новый в старый)
другого сервера не надо, но надо ресурсы
Переименовать - это означает поменять Name, но не Id. А у ежедневном задании на ProcessFull стоит Id старого куба.

<Process xmlns=" http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Adventure Works DW Multidimensional 2012</DatabaseID>
< CubeID >Adventure Works DW</CubeID>
</Object>
<Type>ProcessFull</Type>
</Process>

И после переименования задания не отработают - потому что у нового куба с новым измерением будет другой CubeID.