Обновление базы 1С не двигается: как понять, что идёт работа, и как безопасно её прервать

Если 1С зависла при обновлении, сначала не трогайте процесс 5–10 минут и откройте «Диспетчер задач»: если 1cv8.exe (или rphost.exe на сервере, sqlservr.exe/postgres.exe у СУБД) грузит процессор или диск — обновление идёт, просто медленно. Если нагрузка нулевая 15–20 минут и полоса прогресса стоит, это настоящее зависание: снимите процесс, проверьте блокировки и запустите обновление заново из резервной копии или с той же точки.

Чаще всего «зависает» не сама загрузка конфигурации, а реструктуризация таблиц, обработчики обновления при первом запуске или ожидание монопольного доступа, пока в базе висит чужой сеанс. Для каждого случая действия разные.

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

Реструктуризация в большой базе может идти часами: платформа пересоздаёт таблицы и переносит в них данные. База на 50 ГБ с изменённым регистром бухгалтерии на обычном диске легко занимает 1–3 часа. Прерывать такую работу — значит потерять время и рискнуть целостностью.

Признаки того, что процесс жив:

• 🟢 1cv8.exe в «Диспетчере задач» стабильно использует 5–25 % процессора (одно ядро);
• 🟢 на вкладке «Производительность» → «Монитор ресурсов» → «Диск» видна запись в файл 1Cv8.1CD (файловая база) или в файлы данных СУБД;
• 🟢 растёт размер файла базы или журнала транзакций;
• 🟢 у сервера СУБД есть активный запрос от рабочего процесса 1С.

Признаки зависания:

• 🔴 процессор 0 %, диск 0 % дольше 15–20 минут;
• 🔴 окно Конфигуратора «Не отвечает», а процесс не потребляет ресурсов;
• 🔴 появилось и висит окно со списком активных пользователей или запрос на завершение сеансов;
• 🔴 память процесса упёрлась в потолок и не меняется (типично для 32-разрядного клиента на крупной конфигурации).

На каком этапе остановилось

Экстренная остановка зависшего процесса обновления

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

Файловая база

1. Откройте «Диспетчер задач» → вкладка «Подробности».
2. Найдите все 1cv8.exe, 1cv8c.exe и 1cv8s.exe, связанные с этой базой. На терминальном сервере включите колонку «Имя пользователя», чтобы не снять чужие сеансы в других базах.
3. Завершите их через «Снять задачу».
4. Убедитесь, что в каталоге базы не осталось открытого файла: откройте Монитор ресурсов → «ЦП» → «Связанные дескрипторы», введите в поиск 1Cv8.1CD.

Клиент-серверная база

1. Откройте «Администрирование серверов 1С Предприятия» (консоль кластера).
2. Перейдите в кластер → «Информационные базы» → нужная база → «Сеансы».
3. Найдите сеанс Конфигуратора (приложение «Конфигуратор») и фоновые задания, завершите их через контекстное меню.
4. Если сеанс не завершается, посмотрите «Соединения» этой базы и разорвите соединение.
5. Крайняя мера — перезапуск рабочего процесса или службы «Агент сервера 1С:Предприятия». Это оборвёт все сеансы всех баз кластера, поэтому только вне рабочего времени.

Для проверки из командной строки подойдут rac cluster list и rac session list; параметры остальных подкоманд смотрите в rac help.

Если в СУБД после этого остался «висящий» запрос от 1С, его снимают средствами самой СУБД: в MS SQL — через «Монитор активности» в Management Studio, в PostgreSQL — по pg_stat_activity и pg_terminate_backend. Откат большой транзакции на стороне СУБД сам по себе может занять столько же времени, сколько она шла: не перезапускайте сервер СУБД посреди отката.

Диагностика причин, из-за которых зависает обновление

После остановки найдите причину, иначе вторая попытка встанет там же.

Где смотреть подробности

• 📄 Журнал регистрации. В Конфигураторе: Администрирование → Журнал регистрации. Отберите интервал попытки и события с ошибками.
• 📄 Протокол пакетного запуска. Если обновлять через командную строку с параметром /Out, всё, что платформа сообщает, попадёт в текстовый файл (пример команды ниже).
• 📄 Технологический журнал на сервере. Включается файлом logcfg.xml; полезен, когда нужно увидеть, какой запрос к СУБД длится часами.
• 📄 Счётчики Windows: загрузка диска, очередь диска, свободная память на сервере 1С и СУБД.

Монопольный режим и блокировки: как освободить базу для обновления

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

Блокировка входа пользователей

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) есть штатная обработка: Администрирование → Обслуживание → Блокировка работы пользователей. В ней задают время начала блокировки, сообщение пользователям и код разрешения. Пользователей предупредят и выведут из базы автоматически.

Для клиент-серверной базы то же можно включить в консоли кластера: свойства информационной базы → флаг «Блокировка начала сеансов включена», время, сообщение и «Код разрешения». Там же есть флаг блокировки регламентных заданий — включите его на время обновления.

Чтобы войти самому при включённой блокировке, добавьте к строке запуска параметр /UC с кодом:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /S"srv1c\buh" /N"Администратор" /P"пароль" /UC"Обновление"

Номер версии в пути подставьте свой.

Файловая база и «чужой» сеанс

В файловом режиме сеанс держит открытым файл 1Cv8.1CD. Если пользователь ушёл домой с открытой 1С на другом компьютере, монопольный режим не установится. Найдите, кто держит файл: на сервере, где лежит база, Управление компьютером → Общие папки → Открытые файлы. Оттуда же файл можно закрыть — но это оборвёт работу того пользователя.

Очистка кэша и временных файлов после сбоя

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

Кэш клиента

Самый безопасный способ — запуск с параметром /ClearCache:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" ENTERPRISE /F"D:\Bases\Buh" /ClearCache

Вручную кэш лежит в двух местах (при закрытой 1С):

• %APPDATA%\1C\1cv8\ — папки с именами вида GUID;
• %LOCALAPPDATA%\1C\1cv8\ — тоже папки-GUID.

Удаляйте только папки с длинными GUID-именами. Файлы *.pfl в корне папки не трогайте: в них общие настройки пользователя. Список баз хранится отдельно, в %APPDATA%\1C\1CEStart\ibases.v8i, его чистка кэша не затрагивает.

Сеансовые данные сервера

На сервере 1С временные данные сеансов лежат в каталоге кластера, обычно C:\Program Files\1cv8\srvinfo\reg_1541\ — внутри папки с GUID баз и подпапки вида snccntx…. Их чистят только при остановленной службе агента.

Временные файлы

Обновление через Конфигуратор пишет временные файлы в %TEMP%. Если на системном диске меньше 2–3 ГБ, большая реструктуризация упирается в нехватку места и «зависает». Очистите %TEMP% при закрытой 1С и освободите место.

Параметры сервера и СУБД, которые решают судьбу обновления

На клиент-серверной базе большая часть «зависаний» — это медленные операции на стороне СУБД.

Что проверить в СУБД

Что проверить на сервере 1С

• 🛡 Антивирус. Исключите из проверки каталог srvinfo, каталоги файловых баз и файлы данных СУБД. Проверка на лету каждого записываемого блока превращает час реструктуризации в пять.
• 🧠 Память. Если рабочий процесс упирается в ограничения, заданные в свойствах рабочего сервера, процесс перезапускается посреди операции. Перед крупным обновлением проверьте эти лимиты.
• ⏱ Регламентные задания. Заблокируйте их на время обновления, иначе обмен или загрузка курсов захватит базу посередине.

Пакетное обновление вместо интерактивного

Для крупных баз удобнее обновлять из командной строки: нет окон, которые «зависают», и есть протокол.

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /S"srv1c\buh" /N"Администратор" /P"пароль" /UC"Обновление" /UpdateDBCfg /Out"D:\Logs\update_buh.txt" /DisableStartupDialogs

Параметр /UpdateDBCfg применяет основную конфигурацию к конфигурации базы данных, /Out пишет протокол. Пока команда работает, следите за размером лог-файла и нагрузкой на СУБД.

Если обновление прервано: как вернуть базу в рабочее состояние

После снятия процесса откройте базу в Конфигураторе и оцените состояние.

1. Конфигурация не применена. Основная конфигурация уже новая, а конфигурация БД — старая. Можно повторить «Обновить конфигурацию базы данных» (Конфигурация → Обновить конфигурацию базы данных или F7) или отказаться от изменений: Конфигурация → Конфигурация базы данных → Вернуться к конфигурации БД.
2. Ошибки при открытии. Сделайте копию и запустите Администрирование → Тестирование и исправление с проверкой логической и ссылочной целостности. Для файловой базы есть отдельная утилита chdbfl.exe в каталоге bin платформы — она проверяет физическую целостность файла при закрытой базе.
3. Зависание на обработчиках при первом запуске. Войдите в режиме «Предприятие» под администратором. В БСП-конфигурациях при сбое обработчика выводится форма с описанием ошибки и возможностью повторить. Подробности пишутся в журнал регистрации.
4. Ничего не помогает. Восстановите копию, сделанную до обновления, устраните найденную причину (место, память, сеансы) и повторите.

Профилактика: как обновлять, чтобы не зависало

Порядок, который снимает почти все причины из предыдущих разделов:

Пробный прогон на копии — главный приём. Он показывает реальное время реструктуризации: если на копии обновление шло 2 часа, вы не снимете процесс на 40-й минуте с мыслью «всё зависло».

Ещё несколько правил из практики:

• 📅 Не пропускайте релизы надолго. Переход через 10–15 релизов сразу даёт огромную реструктуризацию и много обработчиков; обновляйтесь по цепочке, как предписывает описание обновления.
• 🧹 Раз в квартал выполняйте «Тестирование и исправление» на копии и чистку кэша клиентов — битые данные всплывают именно при обновлении.
• 🗂 Для MS SQL держите в порядке статистики и индексы плановым обслуживанием, но в другое время, чем обновление.
• 🧾 Ведите простую запись: дата, релиз, сколько длилось обновление. Через пару месяцев у вас будет ориентир, когда пора тревожиться.

Чего не делать при зависшем обновлении

• ❌ Перезагружать компьютер через 10 минут ожидания. Реструктуризация прерывается в худший момент, а время потрачено впустую.
• ❌ Удалять файл базы или папки в srvinfo целиком. Это ломает реестр кластера; удаляются только сеансовые данные и только при остановленной службе.
• ❌ Обновлять рабочую базу без пробы на копии. Неизвестно, сколько ждать, и нечем сравнить.
• ❌ Забыть про регламентные задания. Монопольный режим не устанавливается, хотя все пользователи вышли.
• ❌ Оставить блокировку входа после обновления. Утром база недоступна всем.

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