К статье
Практический материал

Администрирование · 11 мин

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

Как снять задачу обновления конфигурации 1С: отмена через конфигуратор, очередь обновлений, фоновые задания и снятие блокировки базы. Разбор ошибок и рисков.

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

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

Определите, на каком этапе находится обновление

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

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

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

Конфигуратор открыт, реструктуризация не запущенаОбновление не применено

Можно отказаться от обновления без риска для данных

Идёт реструктуризация таблицКритичный этап

Прерывать нельзя — дождитесь завершения или восстанавливайтесь из копии

База работает, но идут отложенные обработчикиФоновое обновление данных

Можно отменить или приостановить обработчики штатными средствами

База заблокирована, сеанс «висит»Зависший сеанс обновления

Завершите сеанс через консоль кластера или Администрирование серверов

Сделайте резервную копию перед любыми действиями

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

Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей или выполнить выгрузку в dt через конфигуратор (Администрирование → Выгрузить информационную базу). Для клиент-серверной базы используйте средства СУБД: backup базы в MS SQL Server или PostgreSQL.

Отмена обновления до запуска реструктуризации

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

Если изменения уже загружены в конфигурацию поставщика, но конфигурация базы данных не обновлялась, можно вернуться к конфигурации базы данных: Конфигурация → Конфигурация базы данных → Вернуться к конфигурации БД. Это сбросит загруженные, но не применённые изменения.

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

Порядок действий при отмене до реструктуризации
  1. 1
    Закройте окно обновления, не подтверждая обновление конфигурации базы данных
  2. 2
    Откройте Конфигурация → Конфигурация базы данных → Вернуться к конфигурации БД
  3. 3
    Проверьте через сравнение конфигураций, что различий нет
  4. 4
    Сообщите пользователям, что версия не изменилась

Снятие зависшей задачи и блокировки базы

Частая ситуация: обновление запущено, сеанс завис, а база заблокирована — пользователи видят сообщение о выполнении обновления или о том, что база заблокирована администратором. Здесь задача снимается через завершение зависшего сеанса.

В клиент-серверном варианте откройте консоль кластера серверов 1С, найдите зависший сеанс (обычно это сеанс конфигуратора или фоновое задание) и завершите его. Также проверьте список соединений — иногда «висят» именно соединения с СУБД.

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

Отмена и приостановка отложенных обработчиков обновления

В типовых конфигурациях на базе БСП (Библиотека стандартных подсистем) после обновления версии выполняются обработчики обновления данных. Они бывают монопольными (выполняются при первом запуске) и отложенными (выполняются в фоне, пока пользователи работают).

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

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

Снятие регламентного задания обновления

Иногда под «задачей обновления» понимают регламентное задание — например, автоматическое обновление через интернет-поддержку или фоновое задание, которое периодически запускает обработчики. Такие задания отключаются штатно.

Откройте «Администрирование → Регламентные и фоновые задания», найдите нужное задание (например, связанное с обновлением или загрузкой данных) и снимите флаг «Используется» либо измените расписание. Для блокировки всех регламентных заданий на время работ используйте консоль заданий или обработку управления регламентными заданиями.

Маршрут решения

Как выбрать действие

Обновление загружено, но реструктуризация не запускаласьВернитесь к конфигурации базы данных — данных это не затронет
Идёт реструктуризация и процесс реально работаетНе прерывайте, дождитесь завершения
Сеанс обновления завис, активности нетЗавершите сеанс в консоли кластера, снимите блокировку, проверьте целостность
Мешают отложенные обработчикиПриостановите их в форме результатов обновления, ошибочные — перезапустите после исправления
Срабатывает регламентное задание обновленияОтключите его в списке регламентных и фоновых заданий

Проверка результата после снятия задачи

После отмены обновления убедитесь, что база находится в рабочем состоянии. Войдите в базу под пользователем с полными правами и проверьте версию конфигурации (Справка → О программе) — она должна соответствовать ожидаемой.

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

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

Как проверить результат

Версия конфигурации
Норма

Соответствует целевой (старой или новой — по вашему решению)

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

Версия «подвисла» между релизами, при входе требуется обновление

Доступ пользователей
Норма

Все входят без сообщений о блокировке

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

Сообщение о блокировке или о выполнении обновления

Журнал регистрации
Норма

Нет повторяющихся ошибок обновления

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

Ошибки обработчиков повторяются при каждом запуске

Фоновые задания
Норма

Нет зависших заданий обновления

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

Задание «выполняется» часами без прогресса

Типичные ошибки при снятии задачи обновления

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

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

Типичные ошибки
01
Завершение процесса 1cv8.exe во время реструктуризации — повреждение структуры базы
02
Повторный запуск обновления без анализа журнала регистрации — накопление ошибок
03
Удаление отложенных обработчиков вместо их перезапуска — незаполненные данные в подсистемах
04
Отмена обновления без резервной копии — невозможность отката при проблемах
05
Игнорирование блокировки сеансов после завершения сеанса — пользователи не могут войти
Итог

Что важно запомнить

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

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

Можно ли отменить обновление, если реструктуризация уже началась?

Безопасно — нет. Прерывание реструктуризации оставляет таблицы в несогласованном состоянии. Если процесс реально завис (нет активности на диске и в СУБД продолжительное время), завершите сеанс и восстановите базу из резервной копии, сделанной до обновления.

База заблокирована после прерванного обновления. Как снять блокировку?

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

Отложенные обработчики выполняются очень долго. Можно ли их просто удалить?

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

Чем отличается «вернуться к конфигурации БД» от восстановления из копии?

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

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

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

Отключение регламентного задания обновления что-то сломает?

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