Получил сегодня по рассылке интереснейшую статью с видео, про обновление баз 1С, вернее, про его ускорение этого процесса. Вот ссылка: https://курсы-по-1с.рф/news/2022-03-24-how-to-speed-up-restructuring/ . Не реклама, просто правда интересно.

А теперь основные вопросы ) . Стоит задача обновления доработанной Розницы, через 10 промежуточных релизов, объем базы порядка 15 Гб. На MS SQL. Как посоветуете ускорить процесс (ну если в стандартном варианте, без использования предложений по ссылке выше)?
Я сторонний программист, работаю по удаленке, в другом городе. По rdp. Надо ли как-то договориться с сисадминами о предоставлении большего объема оперативки (как вообще посмотреть, сколько мне сейчас выделено?), о каких-то еще изменениях в системе, чтобы обновление шло у меня быстрее? Они согласятся, просто мне надо знать, чего от них нужно.

Ну и в дополнение - кто-то вариант по ссылке пробовал? ) Тоже очень интересно.

К скорости это не относится, но может быть кому-нибудь пригодится.

Сейчас пока делаю обновление на SQL-копии базы розницы, и сразу же столкнулся с той же проблемой, с которой уже сталкивался и о которой спрашивал на этом форуме. но нужного ответа не получил: Обновление Розницы 2.2 - 2.3. Ошибка при обновлении .

На первой же итерации обновления, после установки нужных параметров обновления и обновления конфигурации базы данных с реструктуризацией, при запуске 1С в режиме Предприятия возникла ошибка: "Слишком много фактических параметров" (по ссылке более подробно написано).

В прошлый раз я просто перенес обновление на файловый вариант базы, и это помогло. Но в этот раз решил действовать "до победного" на SQL - и понял, в чем тут дело.

Сначала несколько раз перезагрузил Предприятие - не помогло. А потом вспомнил, что перед обновлением я отключил ВСЕ регламентные задания, которые могли выполняться в фоне. Зашел в консоль администрирования серверов 1С Предприятия - и увидел, что там опять стали выполняться фоновые задания. Наверное, включились сами после обновления.Несколько раз подряд опять перезапустил Предприятие, попутно отключая самозапускающиеся фоновые задания через консоль, и когда получилось "успеть" - все ЗАРАБОТАЛО, и первое обновление прошло успешно!

Может быть, кому пригодится...

(1) >> Несколько раз подряд опять перезапустил Предприятие, попутно отключая самозапускающиеся фоновые задания через консоль, и когда получилось "УСПЕТЬ"

А зачем такие пляски с бубном? В Рознице есть какие-то проблемы с блокировкой регламентных через консоль сервера?

(2) Мне стыдно, но я об этом ничего не знал. Где можно получить подробную информацию о работе с консолью серверов?

(3) Честно сказать, и не знаю даже. Может, подскажет кто. Ну, кроме традиционных источников — вероятно, в руководстве администратора это есть, может где-нибудь в методических рекомендациях на партнёрском портале это в удобной форме как-нибудь изложено, там вообще много интересного. В любом случае, хоть что-нибудь-то почитать нужно бы. Ну, хотя бы просто внимательно изучить консоль управления и погуглить все интересные пункты, тогда бы точно стало известно про блокировку регламентных, там же прямо бросается в глаза этот пункт.

// Зашел в консоль администрирования серверов 1С Предприятия - и увидел, что там опять стали выполняться фоновые задания.

т.е. все у него по идее включено. Доступ ему админы предоставили в RDP на минимально необходимое для нормальной работы админ-саппорта1С

И момент, на который часто наступают, как на грабли.

Если конфа на актуальных релизах БСП, то установливать блокировку регламентых заданий на всю базу не желательно. Поскольку в конфигурацию встроено использование фоновых заданий, а они как раз и реализованы в виде регламентных. Уж не знаю как там получается с путаницей наименований терминов.
По идее, регламентное - это для обслуживания базы по какому-то регламенту. А рамках работы с конфигурацией получается не только обслуживание базы, но и произвольные фоновые задания тоже проходят в виде "регламентных", если смотреть на них из консоли администрирования

Регламентное задание - это запуск фонового задания по расписанию.
Все действия,которые вызываются неявно,вызываются через регламентные задания.
Блокировка регламентных заданий не мешает их явному запуску из программного кода.

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

В файловой базе регламентные задания выполняются только после запуска хоть одного подключения в режиме предпртятия,поэтому,при для обновления файловой базы ничего отключать не нужно,так как ничего нет.
Опубликованная файловая база,однако,требует остановки web-сервеоа,так как может быть им захвачена.

(7) теорию услышал. Все верно.
на практике - не желательно устанавливать этой галочки по избежание необъяснимых трудностей при обновлении.

А кто-нибудь пробовал такой вариант длительного пошагового обновления через несколько релизов:

+(9) 1. Выгружаем базу, загружаем на SQL копию, обновляем.
2. За те 2-3 дня, что мы это делали, в рабочей базе, естественно, накопилась куча документов, новых элементов справочников и т.д., но сама конфигурация не менялась, они по прежнему идентичны. Используя обработку для обмена между идентичными базами (Выгрузка/загрузка данных XML для 8.3), переносим данные за этот период из рабочей базы в копию.
3. Загружаем копию в рабочую базу.

Какие здесь возможны подводные камни?

+(10) Да, и, конечно, надо предупредить всех пользователей, что если они что-то поменяют в старых документах вне этого периода, эти изменения так и останутся в старой базе )
Но это уже мелочи.

Больше меня беспокоит, будет ли эта обработка переносить новую номенклатуру - причем не всю, а именно НОВУЮ.

(10) Разница все-таки в конфигурациях будет, пусть и небольшая, все-таки вы обновления поставите. Но думаю особых проблем быть не должно, разве что серьезно поменяются сами документы, справочники. Я делал так не раз, но то была обычная БП 3.0. Насколько помню проблемы были лишь с документами по ЗП, правильный алгоритм выгружать их без движений, а уже после перепроводить.
Справочник Номенклатуры я выгружал полностью, проблем не было. Но тут конечно все зависит от его объема, у меня был не такой большой

(10) С чего бы это они идентичные? Одну обновили, вторая старая. В выходные стопануть или не сразу все 10, а постепенно делать. Переносить новое - геморно и главное непредсказуемо в плане косяков. В итоге наверняка попадалово вылезет.

(14) "С чего бы это они идентичные? "

Да, это я действительно сказал ерунду какую-то. Структура поменяется, без КД 2.1 здесь точно не обойтись...

Лучше уж начну обновление прямо на рабочей, и пока не закончу - фиг кто в базу сунется! )

(14) Насчет "В выходные стопануть" - не получится, это магазин, работает без выходных...

(0) Что-то я не услышал ответа на основной, первый вопрос этой ветки )

Но это я сам виноват - сразу на "фоновые задания" перескочил.

"Я сторонний программист, работаю по удаленке, в другом городе. По rdp. Надо ли как-то договориться с сисадминами о предоставлении большего объема оперативки (как вообще посмотреть, сколько мне сейчас выделено?), о каких-то еще изменениях в системе, чтобы обновление шло у меня быстрее? Они согласятся, просто мне надо знать, чего от них нужно.".

(16) Тогда не сразу 10 релизов, а рубить хвост кусочками. Возможно даже в режиме накатил парочку, они недельку поработали, всякие ошибочки поправил. Доработки мало ли как согласуются с новым функционалом. Оно может и дольше получится - но зато спокойнее.

(17) Если база нормально работает на текущем железе - ну плюс-минус обновление тоже отработает в разумные сроки. Не надо ничего трогать, тем более с позиции "стороннего программиста". Оно охота до кучи еще разбираться потом с "до тебя все работало, а после твоих настроек умерло"?

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

(0) если что, реструктуризация v2 может закончится порчей базы и это, не обратимый процесс.
И от неё уже нельзя отказаться, в отличии от v1, где будет показ окошка с изменениями, что будет и что было.

и помимо v2 есть еще рекомендации с ИТС на счет реструктуризации и регламентов в sql, типа мдоп увеличить и перевода базы в симпл + отключение планов на время реструктуризации и т.д.
Ну и это всё, не для ларьков с Розницей.

5 копеек... если идет перескок через множество релизов и при этом это типовая, то работу с базой стопорить все-таки придется.

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

Стопорнул базу для пользователь в удобный момент времени.
Зная о всех граблях, на высокой скорости накатил обновления структуры метаданных типовым обновлением до актуального релиза.
Заливаешь на актуальный релиз свою подготовленную обновленную и измененную конфигурацию.

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

(0) >Стоит задача обновления доработанной Розницы, через 10 промежуточных релизов, объем базы порядка 15 Гб
Дальше не читал, такие вопросы задают с базами >100Гб (редко), чаще >1Тб

На стороне SQL:
Сделать резервную копию
MDOP выставить в 0 или > 1 (количество потоков)
Simple Mode (чтобы не генерировать записи в журнал транзакций).
Обновить базу
Вернуть настройки обратно
Сделать резервную копию

(24) как раз хинты MDOP = 0 уже работает и без V2. А вот если ТС "отважится" на V2 тогда (21) и (22)

(0) Я так понимаю, это то же самое https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/
Пробовали, реально быстрее, 20 минут вместо 1 часа 50 минут