Обновление конфигурации 1С не заканчивается: как понять, что она встала, и вернуть базу в строй

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

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

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

Долгое обновление и зависание снаружи неотличимы. Отличает их нагрузка.

Что смотреть на компьютере или сервере

Откройте диспетчер задач (Ctrl+Shift+Esc) и найдите процесс 1cv8.exe (конфигуратор или клиент). Для клиент-серверной базы смотрите ещё процессы rphost.exe на сервере и процесс СУБД.

• 📈 Процессор или диск у процесса заметно загружены и меняются, значит, идёт работа. Ждите.
• 📉 Нагрузка 0-1% и не меняется 20-30 минут, значит, процесс, скорее всего, стоит.
• 💾 В файловой базе следите за размером и временем изменения файла 1Cv8.1CD: растёт или меняется, значит, идёт запись.
• 🧠 Память процесса растёт без остановки до упора, значит, дело в нехватке ресурсов, а не в блокировке.

Сколько обновление занимает обычно

Ориентиры очень приблизительные и зависят от диска и размера базы.

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

Первая проверка: журнал регистрации и логи

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

Журнал регистрации в конфигураторе

Откройте второй экземпляр конфигуратора или базу в режиме «1С:Предприятие» (если она ещё пускает) и вызовите журнал: в конфигураторе пункт меню «Администрирование», далее «Журнал регистрации». В Предприятии он открывается из раздела администрирования.

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

1. Уровень «Ошибка» и «Предупреждение» за последние минуты.
2. События, связанные с конфигурацией и обновлением информационной базы.
3. Сообщения о таймаутах блокировок и об ошибках СУБД.

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

Логи платформы и СУБД

На сервере 1С логи кластера лежат в каталоге данных кластера, а для разбора тяжёлых случаев включается технологический журнал (настраивается файлом logcfg.xml в каталоге conf платформы). Это путь для администратора: он даёт запросы, ожидания и взаимные блокировки.

Для СУБД смотрите её собственные средства:

• Microsoft SQL Server: процедура sp_who2 показывает, кто кого блокирует (колонка BlkBy).
• PostgreSQL: представление pg_stat_activity со статусом ожидания.

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

Что делать с сеансами и блокировками

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

Закройте пользователей

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

На сервере удобнее консоль администрирования серверов 1С: найдите кластер, затем информационную базу, затем «Сеансы». Там видны время последней активности, приложение и компьютер пользователя.

Блокировка новых входов на время работ

В консоли администрирования в свойствах информационной базы включите запрет начала сеансов с указанием кода разрешения. Тогда никто, кроме вас, не зайдёт, пока вы не снимете флажок. Свой сеанс запускайте с ключом /UC и этим кодом.

Если сеанс не завершается

Бывает, что клиент «умер», а сеанс остаётся. Тогда его удаляют из консоли серверов. В файловой базе нет консоли, поэтому остаётся закрыть процесс 1cv8.exe на компьютере пользователя через диспетчер задач или ждать перезагрузки машины.

⚠️ Зависшие транзакции в СУБД иногда держат блокировку даже после завершения сеанса. Это видно в sp_who2 или pg_stat_activity и лечится завершением процесса в СУБД, но делать это нужно, понимая последствия.

Запуск в монопольном режиме и отладка

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

Пошагово в конфигураторе

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

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

Что даёт запуск с отладкой

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

Очистка кэша клиента

Иногда зависает не база, а локальный клиент. Закройте 1С, удалите содержимое папок кэша и запустите заново.

Папки обычно лежат здесь:

%APPDATA%\1C\1cv8
%LOCALAPPDATA%\1C\1cv8

Либо запустите клиент с параметром очистки кэша:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /ClearCache

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

Что делать, если процесс не оживает: прерывание и откат

Решение «прервать» принимают, когда нагрузка нулевая, сеансы закрыты, а сообщений нет в течение разумного времени (ориентир: 30-60 минут для средней базы).

Мягкое прерывание

В конфигураторе и клиенте иногда помогает сочетание Ctrl+Break: оно прерывает текущую операцию. Если окно отзывается, подождите несколько минут, прежде чем делать что-то ещё.

Жёсткое завершение

Только если мягкое не сработало:

1. В диспетчере задач завершите процесс 1cv8.exe.
2. На сервере при необходимости перезапустите службу «Агент сервера 1С:Предприятие 8.3». Все пользователи вылетят из всех баз кластера, поэтому делайте это ночью.
3. В файловой базе после жёсткого закрытия проверьте, нет ли оставшегося файла блокировки 1Cv8.cdn рядом с базой. Удаляйте его, только когда уверены, что в базе никого нет.

Восстановление из копии

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

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

Не удаляйте повреждённую базу, пока не убедились, что копия открывается и данные на месте.

Тестирование и исправление

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

Типичные ошибки платформы при обновлении и как их убрать

Ниже самые частые сообщения. Формулировки могут слегка отличаться в разных релизах, ищите по смыслу.

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

Как не получить зависание в следующий раз

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

Что ещё стоит сделать:

• 🔧 Обновлять платформу и конфигурацию по очереди, не одновременно: так проще найти виновника.
• 🧹 Раз в квартал сворачивать лишние данные и чистить журнал регистрации, если он разросся.
• 🗂 На сервере держать базу и журнал транзакций СУБД на быстрых дисках.
• 🧪 Крупные релизы сначала проверять на тестовой копии и замерять время. Если копия обновилась за 40 минут, на боевой закладывайте с запасом час-полтора.
• 📝 Вести короткий журнал обновлений: версия до, версия после, время, проблемы. Через пару раз это даёт точную картину.

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