Как долго обновляется база 1С и что делать, если процесс затянулся

Обновление базы 1С может занять от нескольких минут до нескольких часов — точное время зависит от размера информационной базы, объёма изменений в конфигурации, мощности сервера и количества пропущенных релизов. Типовое обновление небольшой файловой базы на один релиз обычно укладывается в 10–30 минут, а обновление большой серверной базы через несколько версий может длиться час и более.

Дольше всего выполняется не сама загрузка обновления, а этап реструктуризации — перестроение таблиц базы данных под новую структуру метаданных. Именно на этом шаге пользователи чаще всего начинают беспокоиться: индикатор прогресса может «висеть» на одном месте десятки минут, хотя процесс идёт нормально.

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

От чего зависит длительность обновления

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

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

Третья группа факторов — техническая среда: скорость дисковой подсистемы (SSD заметно быстрее HDD), объём оперативной памяти, загруженность сервера 1С и СУБД, пропускная способность сети при файловом режиме по сети. Обновление файловой базы, размещённой на сетевом диске, почти всегда идёт медленнее, чем локальной.

Наконец, влияет сама конфигурация. Типовые конфигурации обновляются предсказуемо, а сильно доработанные требуют дополнительного времени на сопоставление объектов и ручное разрешение конфликтов.

Ориентировочные сроки для разных сценариев

Точное время предсказать невозможно, но практические ориентиры помогают спланировать окно обновления. Небольшая файловая база (до нескольких гигабайт) с обновлением на один-два релиза обычно обрабатывается за 10–40 минут на современном компьютере с SSD.

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

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

Этапы обновления и где тратится время

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

Самый продолжительный этап — реструктуризация: платформа перестраивает таблицы базы данных. Внешне это выглядит как окно с перечнем таблиц и медленно движущимся индикатором. На больших таблицах прогресс может визуально «замирать», потому что копирование миллионов строк не отображается поминутно.

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

Как подготовиться, чтобы обновление прошло быстрее

Подготовка сокращает и длительность, и риски. Первое действие — полная резервная копия базы. Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей или сделать выгрузку в dt. Для серверной — штатный бэкап средствами СУБД.

Второй шаг — выгнать всех пользователей и завершить фоновые задания. Активные сеансы не только блокируют обновление, но и замедляют его: платформа ждёт освобождения ресурсов. В серверном режиме сеансы завершают через консоль администрирования, в файловом — через список активных пользователей.

Полезно заранее освободить место на диске: реструктуризация временно требует дополнительного пространства, сопоставимого с размером крупнейших таблиц. Также имеет смысл выполнить тестирование и исправление базы до обновления — ошибки в данных способны остановить процесс на середине.

1. 1
   Сделайте резервную копию базы и проверьте, что она восстанавливается
2. 2
   Завершите все сеансы пользователей и фоновые задания
3. 3
   Убедитесь, что на диске достаточно свободного места
4. 4
   Выполните тестовое обновление на копии и засеките время
5. 5
   Запланируйте обновление рабочей базы на период минимальной нагрузки

Как понять, что обновление зависло, а не просто идёт долго

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

Если процесс 1С потребляет ресурсы процессора или активно работает с диском — обновление идёт, просто медленно. Если загрузка нулевая, файлы не меняются часами, а индикатор стоит на месте — вероятно зависание или скрытая ошибка, например ожидание ответа на скрытое диалоговое окно.

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

Контрольные точки

Норма или зависание

Загрузка CPU и диска процессом 1С

Норма

Есть заметная активность

Тревожный признак

Нулевая нагрузка в течение часа и более

Размер файлов базы

Норма

Периодически изменяется

Тревожный признак

Не меняется длительное время

Окна сообщений

Норма

Нет скрытых диалогов

Тревожный признак

За главным окном скрыто окно ошибки или вопроса

Прогресс реструктуризации

Норма

Перечень таблиц со временем меняется

Тревожный признак

Одна и та же таблица без активности несколько часов

Что делать при зависании и как не усугубить ситуацию

Главное правило: не снимайте процесс и не выключайте компьютер, пока не убедились, что активность отсутствует полностью. Прерывание реструктуризации оставляет базу в промежуточном состоянии — чаще всего она перестаёт открываться, и единственным выходом становится восстановление из резервной копии.

Если зависание подтверждено, завершите процесс и восстановите базу из резервной копии, сделанной до обновления. Затем разберитесь с причиной: нехватка места на диске, ошибки в данных, конфликт с антивирусом, проблемы сети при сетевом размещении файловой базы. Антивирус на время обновления разумно перевести в режим исключения для каталога базы — проверка каждой записываемой страницы данных сильно тормозит процесс.

После устранения причины повторите обновление сначала на копии. Если ситуация повторяется — выполните тестирование и исправление базы, проверьте логи СУБД и платформы, а при необходимости привлеките специалиста по администрированию 1С.

Как сократить время обновления в будущем

Регулярность — лучший способ удерживать время обновления в разумных пределах. Обновление на каждый релиз или хотя бы раз в несколько месяцев занимает заметно меньше времени, чем редкие «большие прыжки» через десятки версий.

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

В серверном режиме помогает использование возможностей СУБД: актуальная статистика, достаточный размер журналов и временных баз ускоряют массовые операции, из которых состоит реструктуризация.

Частые вопросы

Можно ли работать в базе во время обновления?

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

Обновление висит на одной таблице уже час — это нормально?

Может быть нормой, если таблица очень большая: например, регистр с миллионами записей. Проверьте активность диска и процессора. Если нагрузка есть — процесс идёт. Если активности нет продолжительное время — проверяйте скрытые окна сообщений и журнал регистрации.

Ускорит ли обновление переход с файлового режима на серверный?

Обычно да, особенно если файловая база размещена на сетевом диске. Клиент-серверный режим с производительной СУБД обрабатывает массовые операции реструктуризации заметно эффективнее. Однако сам переход требует подготовки и настройки.

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

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

Как узнать заранее, сколько займёт обновление рабочей базы?

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

Нужно ли обновлять платформу вместе с конфигурацией?

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