Выгрузка dt весит 3гига с копейками, развернутая - 50 гигов.
Розница. Документооборот небольшой. Доработки есть, но немного. Если поставить на замок, проблема сохраняется. ТиИ прогонял.
Нужно обновляться (для честного знака), но проблема в том, что у них нет выходных. А за ночь не успевает отработать переход на новую редакцию - именно обработка данных после обновления.
Может кто сталкивался? Что посоветуете?
Пока вижу единственный вариант - обновлять копию, делать обмен и перекидывать документы за этот период.

(0)На копии всё норм отрабатывает? По итогу ошибок нет?
Если ошибок нет, так пусть доделывает отложенные обработки обновления в реальной базе вместе с работой пользователей.

Взять более мощный комп.

Положить базу на диск в ОЗУ на время обновления.

(0) Сколько ядер, сколько потоков выставлено?

Если приоритет работы пользователей, то перевыставить на обработку данных и указать количество потоков.

(1) все в процессор (i7-7700k) упирается

(1) (2) так не дает войти, пока не закончены обработчики

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

(4) а это монопольные обработчики значит, мы подумали про отложенные

Ну по классике тогда:
1. БД на время обновления в Simple, потом вернуть Full
2. 1С отключить журнал регистрации, потом включить.
3. Запускать обновление не из конфигуратора, а в пользовательском режиме.

Если не поможет, посмотреть что там так долго выполняет. Процедуры обновления в целом все описаны в общих модулях.

(0)

Вопрос в том, а на копии ВСЕ доп.обработчики доходят до конца ? А то могут быть нюансы.
Время работы уже замеряно на копии ?
А то вполне может быть вариант "я думал чуть больше дня, а оно уже неделю молотит".

Если обновлять на копии и переносить, то заранее отрепетировать чем и как будете переносить и откуда брать информацию о новых и измененных объектах:
-- ЖР
-- Версионирование
-- Узел обмена


P.S.

Это в этой версии выпиливали РН.СвободныеОстатки и вводили новый, совершенный, гораздо лучше чем было механизм взаиморасчетов ?

Кстати, релиз конфы 11.5 какой? А то было, что в выпущенных версиях УТ 11.5.26.93, 11.5.26.96 и 11.5.26.100 выявлена проблема, которая не мешает текущей работе пользователей в режиме 1С:Предприятие, однако может проявиться при обновлении конфигурации.

(9) С 11.4 на 11.5.26 только самоубийца будет прыгать.
(0) Смотрите справочники Номенклатура, Номенклатура контрагентов и документы установки цен. База у вас можно сказать маленькая.

даже переход между разными 11.5 - очень ресурсоемкий процесс. тут только переносом остатков. у самого щас похожая задача.

(9) Там, как понимаю, регистр грохался.
Обновитесь на 11.5.22.170 если под ЧЗ

(0)[Может кто сталкивался? Что посоветуете? ]
сталкивались все,
я для ERP делал обновление через копию, т.е. неделю данные вводились в старую базу, обновлялась новая(копию продуктива)  и за 14 часов данные перегрузились

размер конечно посолиднее - 2 Тб

(13) Перегружали через РИБ?

(14) cf - ники разные, УРБД не использовали, писал правила

(3) Тут один любитель же рассказывал, что десктопные процы гораздо лучше серверных)

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

(15) Понял, спасибо.

(0) Скинь базу, готовую к запуску обновления на liveups@yandex.ru, я гляну.

(16) десктопные решения гораздо доступнее, и они имеют место быть. Вопрос лишь в том, какие условия задачи. Мелкий магазин с парой манагеров и одной базой или среднее предприятие с 4-5 базами и порядка 100 пользователями.

(16) Для сервера 1С вполне возможно, т.к. 1С как была частотозависимой, так и осталась. Плюс память с коррекцией ошибок медленнее, чем без. А количество используемых ядер для лицензии ПРОФ и на топовом десктопном процессоре вполне себе сопоставимо.

(21) здесь как всегда распутье. 1: дешево (условно) и ненадежно, 2: дорого и надежно. Возможно, чуть медленнее.
Помимо производительности давайте еще учитывать надежность\отказоустойчивость инфраструктуры.
Опять же, или ларек с шаурмой или завод с 2000 пользователями.

(0) Обработчики обновления ускорять пробовали?

(0) Если вы не сами подрядчик, а на стороне заказчика, то я бы рассмотрел услуги ИжТиСи, например. Там достаточно длительный однопоточный обработчик обновления. Ну, либо переписывать этот обработчик самостоятельно.
По поводу обновления через копию, после статьи https://infostart.ru/1c/tools/1576756/  Brawler'а что-то впечатление, что это выстрел в ногу какой-то. Рекомендую комменты почитать. Ну т.е. т.н. методика по сути сводится к обновлению копии и выгрузке новых/измененных объектов любым доступным способом. Хотя, с другой стороны, тут пишут что вполне получилось, но пришлось писать правила.

(24) Воткнуть пучок индексов по рекомендациям dvm-ки конечно же не стоит, так как нарушает лицензионное соглашение. Ну и сдвинуть границы итогов регистров накопления на начала месяца.

(0) Кстати, реструктуризация v1 или v2?

(26) Нужно быть отважным и делать заранее тесты обновления и бэкапится
У меня еще ни разу ERP не смогла обновиться, валится с ошибками платформы

(27) Я уже года 2 как с v2, никаких проблем

зоопарк конфигураций

(26)
Обновил почти типовую УТ11.4 до УТ11.5.21 через v2.

Обновил 400Гб переписанную УТ11.2 до УТ11.5.21 через v2, в которой десятки тысяч взаиморасчетных заказов клиентов, перенесенных из 7.7 еше в 2017 году.