Почему одна база обновляется 15 минут, а другая всю ночь

Обновление типовой 1С на один релиз в небольшой файловой базе занимает примерно 15–40 минут. Клиент-серверная база на десятки гигабайт обновляется 1–3 часа, а фоновая обработка данных после этого может идти ещё несколько часов. Доработанная конфигурация добавляет к сроку работу программиста: от пары часов до нескольких дней.

Главное, что определяет время обновления 1С, — не скорость интернета, а размер базы, количество пропущенных релизов и то, менялась ли конфигурация. Скорость канала влияет только на скачивание пакета, а это минуты.

Что больше всего влияет на время обновления 1С

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

• 📦 Размер базы. Реструктуризация и обработчики обновления проходят по таблицам. База на 2 ГБ и база на 80 ГБ — это разница не в минутах, а в часах.
• 🔗 Сколько релизов пропущено. Нельзя перескочить с очень старого релиза сразу на последний. Программа ставит цепочку промежуточных релизов, и каждый шаг — это отдельная реструктуризация и отдельные обработчики.
• 🛠️ Доработки конфигурации. Типовая база без изменений обновляется автоматически. Снятая с поддержки или изменённая требует сравнения и объединения в Конфигураторе вручную.
• 💽 Диск и сервер. Файловая база на SSD обновляется в разы быстрее, чем на HDD или сетевом ресурсе. Для серверной базы важны диск СУБД и память сервера.
• 🔄 Тип обновления. Смена релиза внутри одной редакции — рутина. Переход на новую редакцию (например, ЗУП 2.5 → 3.1) — это перенос данных, отдельный проект.
• 🛡️ Антивирус. Проверка каждого обращения к файлу базы может растянуть реструктуризацию файловой базы в несколько раз.

Из каких этапов состоит обновление и сколько длится каждый

Полный цикл обновления типовой базы выглядит так. Время указано ориентировочно для типовой БП 3.0 на 5–10 ГБ.

1. Получение файлов обновления — 1–5 минут. Программа скачивает пакет .cfu через интернет -поддержку или вы указываете файл, скачанный заранее.
2. Резервная копия — 2–20 минут. Для файловой базы это копия файла 1Cv8.1CD, для серверной — бэкап средствами СУБД или выгрузка .dt.
3. Загрузка новой конфигурации — 2–10 минут. Обновляется основная конфигурация, база пока работает на старой.
4. Обновление конфигурации базы данных (реструктуризация) — от 1 минуты до часа и больше. Платформа перестраивает таблицы под новую структуру. Здесь нужен монопольный доступ.
5. Обработчики обновления при первом запуске — 5–60 минут. Это окно «Выполняется обновление версии программы» с прогресс-баром. Пока оно не закончится, работать в базе нельзя.
6. Отложенная обработка данных — от нескольких минут до суток. Идёт в фоне, пользователи уже работают. Часть отчётов и функций может быть недоступна, пока обработка не дойдёт до нужных данных.

Ход фоновой обработки видно в разделе Администрирование → Обслуживание, в группе про результаты обновления программы. Там же показано, какие обработчики завершились с ошибкой.

💡 Если цепочка из пяти релизов, этапы 3–5 повторяются пять раз. Поэтому база, которую не обновляли год, может обновляться в 5–10 раз дольше обычного.

Файловая база против клиент-серверной: где быстрее

У файловой и серверной базы разные узкие места, поэтому и ориентиры по времени разные.

Файловый вариант

Вся база — один файл 1Cv8.1CD. Реструктуризация читает и переписывает его целиком по затронутым таблицам. Всё упирается в скорость диска и в то, сколько места занимает файл.

Ориентиры на один релиз БП 3.0 или ЗУП 3.1:

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

Клиент-серверный вариант

Таблицы хранятся в СУБД (MS SQL, PostgreSQL). Реструктуризация идёт быстрее на крупных объёмах, но и базы здесь обычно больше: 20–200 ГБ.

Ориентиры:

• 🟢 база до 20 ГБ — 30–60 минут на релиз;
• 🟡 20–100 ГБ — 1–3 часа плюс фоновая обработка в течение рабочего дня;
• 🔴 больше 100 ГБ — закладывайте ночь или выходные и обязательно тестовый прогон на копии.

У серверной базы есть плюс: резервную копию средствами СУБД делать быстрее, чем выгрузку в .dt. На базе в 50 ГБ выгрузка .dt может идти час, а бэкап SQL — 10–15 минут.

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

Типовая и доработанная конфигурация: разница в сроках

Типовая конфигурация на поддержке без возможности изменения обновляется кнопкой. Весь срок — это время платформы и обработчиков, человек только ждёт.

С изменённой конфигурацией всё иначе. Обновление идёт через Конфигуратор: Конфигурация → Поддержка → Обновить конфигурацию. Платформа показывает окно сравнения и объединения, где программист решает по каждому изменённому объекту, чья версия остаётся.

Расширения — главный приём, который сокращает срок для доработанных баз. Код в расширении не смешивается с основной конфигурацией, поэтому объединять при каждом релизе нечего. Остаётся проверить, что расширение подключилось и работает на новом релизе.

Отдельная история — переход на новую редакцию (например, с БП 2.0 на 3.0 или с ЗУП 2.5 на 3.1). Это перенос данных через обработку, сверка остатков и обучение людей. Здесь счёт идёт на дни и недели.

Как сократить время обновления: проверенные приёмы

Большую часть простоя можно убрать без изменения железа.

До обновления

• 🧹 Сжать таблицы базы. В Конфигураторе: Администрирование → Тестирование и исправление, флажок сжатия таблиц информационной базы. Файл после долгой работы может уменьшиться заметно, и реструктуризация пойдёт быстрее. Делайте это на копии или после бэкапа.
• 🗂️ Сначала прогнать на копии. Обновите копию базы и засеките время. Так вы получите точный срок для своей базы, а не ориентир из статьи.
• 🛡️ Отключить проверку антивирусом для каталога базы и временных файлов 1С на время обновления.
• 💾 Перенести файловую базу на SSD. Самый дешёвый способ ускорить реструктуризацию в разы.

Во время обновления

• 🌙 Запускать вне рабочего времени. Длинные этапы с монопольным доступом — на вечер, фоновую обработку — на ночь.
• 🚫 Не прерывать окно обработчиков. Если закрыть его принудительно, при следующем запуске обработчики начнутся заново или база не откроется.

Режим обновления

Чем реже обновляетесь, тем дольше каждое обновление. Регулярная установка каждого релиза — это 20–30 минут раз в месяц. Пропуск полугода — это цепочка из нескольких шагов и уже несколько часов за раз.

Платформу обновляйте отдельно и заранее. Установка новой версии платформы на компьютер занимает 5–15 минут, но на каждом рабочем месте и на сервере. Новый релиз конфигурации может требовать версию платформы не ниже определённой — без неё обновление не стартует.

Пример: как рассчитать окно обновления для своей базы

Ориентиры из таблиц дают порядок величины. Точный срок для конкретной базы получают на копии. Вот как это сделать за один вечер.

1. Посмотрите текущий релиз: в программе откройте окно «О программе» (значок i или меню с тремя полосками в правом верхнем углу).
2. Узнайте, какой релиз целевой и сколько промежуточных шагов в цепочке. Помощник обновления показывает это перед стартом.
3. Сделайте копию базы и разверните её как отдельную информационную базу.
4. Обновите копию и засеките время каждого этапа: загрузку, реструктуризацию, первый запуск, фоновую обработку.
5. Прибавьте к сумме 30–50% запаса на рабочую базу: в ней больше сеансов, а на сервере идёт другая нагрузка.

Пример расчёта для серверной базы УТ на 40 ГБ, цепочка из трёх релизов:

Значит, пользователей нужно предупредить о трёх часах простоя: например, с 19:00 до 22:00. Фоновую обработку оставляют на ночь, утром проверяют её результаты.

Если тест на копии показал больше 4–5 часов простоя, это повод разбить обновление: сначала пройти часть цепочки в одни выходные, остаток — в следующие.

Почему обновление идёт дольше нормы и что с этим делать

Если обновление растянулось в 2–3 раза относительно прошлого раза, причина обычно одна из этих. Проверяйте по порядку.

Если обновление упало на середине реструктуризации, не пытайтесь «дожать» базу повторными запусками. Восстановите резервную копию и начните заново, разобравшись с причиной.

Частые вопросы о длительности обновления