Обновление 1С стоит на месте: как отличить долгую реструктуризацию от сбоя и выйти без потерь
Содержание
Если обновление 1С зависло, сначала не трогайте процесс 10–15 минут и посмотрите в диспетчере задач, нагружает ли 1cv8.exe (или служба СУБД) процессор и диск. Есть активность — идёт реструктуризация, её надо дождаться. Нагрузки ноль, а окно не реагирует — ищите спрятанный диалог, блокировку или ошибку, и только потом снимайте задачу.
Чаще всего «зависание» оказывается одним из трёх случаев: окно с вопросом ушло за другие окна, обновлению мешает чужой сеанс, или большая таблица перестраивается часами. Прерывать без последствий можно далеко не каждый этап, поэтому сначала определите, где именно встал процесс.
Проверяем, идёт ли процесс на самом деле
Полоса прогресса в Конфигураторе почти не двигается на крупных регистрах. Это нормально: платформа пишет данные в новые таблицы и обновляет индикатор редко. Поэтому судить по полосе нельзя — смотрите на ресурсы.
Файловая база
- Откройте диспетчер задач (
Ctrl+Shift+Esc), вкладка «Подробности». - Найдите
1cv8.exe— процесс Конфигуратора. Если открыто несколько, нужный обычно потребляет больше всего памяти. - Включите столбцы «ЦП», «Операции ввода-вывода (чтение/запись)». Растёт счётчик записи — работа идёт.
- На вкладке «Производительность» → «Открыть монитор ресурсов» → «Диск» видно, в какие файлы идёт запись. Активные
1Cv8.1CDи временные файлы в каталоге базы — признак реструктуризации.
Клиент-серверная база
Здесь основную работу делает не Конфигуратор, а рабочий процесс сервера rphost.exe и СУБД (sqlservr.exe для MS SQL, postgres для PostgreSQL). Проверяйте нагрузку на сервере, а не на своём компьютере. Конфигуратор у вас может показывать 0% ЦП и при этом всё будет в порядке.
Определите этап, на котором встало
От этапа зависит, насколько опасно прерывание.
| Этап | Что видно на экране | Что меняется в базе | Если прервать |
|---|---|---|---|
| Загрузка, сравнение, объединение | Окно сравнения конфигураций, загрузка .cfu/.cf | Только основная конфигурация, данные не трогаются | Относительно безопасно, конфигурацию можно загрузить заново |
| Обновление конфигурации БД (реструктуризация) | «Реорганизация информации», прогресс по объектам | Структура таблиц и данные | Рискованно: нужна проверка базы или откат из копии |
| Обработчики обновления | При первом запуске «Обновление версии программы» | Данные учёта | Обычно продолжаются при следующем входе |
| Отложенная обработка | Программа работает, в фоне идёт дообработка | Данные учёта, частями | Безопасно, задание продолжится |
Как безопасно завершить зависшее обновление
Прежде чем снимать задачу, убедитесь, что у вас есть резервная копия базы, сделанная до обновления. Без неё прерывание реструктуризации может закончиться восстановлением из старого архива.
Шаг 1. Исключите спрятанное окно
Сверните все окна (Win+D) и пройдитесь по Alt+Tab. Проверьте панель задач: у иконки Конфигуратора может быть второе окно. Если удалённый рабочий стол показывает чёрный экран, переподключитесь — диалог мог открыться в отключённом сеансе RDP.
Шаг 2. Освободите базу от чужих сеансов
Для файловой базы посмотрите, кто подключён: в Конфигураторе Администрирование → Активные пользователи. Попросите выйти или закройте их процессы 1cv8c.exe на тех компьютерах.
Для клиент-серверной базы откройте консоль администрирования кластера, раздел «Сеансы» информационной базы. Здесь же видно фоновые задания (приложение «Фоновое задание») и COM-соединения обменов. Удалите лишние сеансы.
Удаление сеанса обрывает работу пользователя: несохранённый документ пропадёт. Предупредите людей заранее, а лучше обновляйтесь вне рабочего времени.
Чтобы новые сеансы не появлялись, в свойствах информационной базы в консоли кластера включите «Блокировку начала сеансов» и задайте код разрешения. Себя впускайте с параметром запуска /UC<код>. Для фоновых заданий там же есть флажок блокировки регламентных заданий.
Шаг 3. Снимите процесс, если ожидание бесполезно
Если 30–40 минут нет ни ЦП, ни диска, а спрятанных окон нет — процесс завис.
- В диспетчере задач завершите
1cv8.exeКонфигуратора. - Для клиент-серверной базы проверьте в консоли кластера, не остался ли сеанс «Конфигуратор» — удалите его.
- Если сеанс не удаляется, а транзакция в СУБД продолжает висеть, перезапуск рабочего процесса
rphostоборвёт все сеансы этого процесса. Делайте это только при пустой базе или с согласия пользователей.
Если оборвать долгую операцию в MS SQL, сервер начнёт откат транзакции. Откат может длиться столько же, сколько шла работа. Не перезапускайте службу SQL Server в этот момент: после рестарта откат всё равно продолжится при восстановлении базы, только без возможности за ним следить.
Шаг 4. Поднимите базу после обрыва
Откройте Конфигуратор заново. Возможны три картины:
- ✅ Конфигурация БД совпадает с основной — реструктуризация успела завершиться. Проверьте базу и запускайте.
- 🔄 Основная конфигурация отличается от конфигурации БД (в дереве метка изменения) — запустите
Конфигурация → Обновить конфигурацию базы данных(F7) ещё раз. Платформа начнёт реструктуризацию заново. - ❌ Ошибка при открытии или сообщение о повреждении — сначала
Администрирование → Тестирование и исправлениена копии базы, при неудаче — восстановление из резервной копии.
Для файловой базы после аварийного снятия процесса бывает, что база считается занятой. Убедитесь, что ни одного 1cv8.exe с этой базой не запущено, и только тогда удалите в каталоге базы файл блокировки 1Cv8.1CL. Пока работает хоть один процесс, этого делать нельзя.
Почему обновление зависает: причины и что с ними делать
| Причина | Как проявляется | Что делать |
|---|---|---|
| 🙈 Скрытый диалог | Окно не отвечает, нагрузки нет | Alt+Tab, переподключение к RDP |
| 👥 Чужие сеансы, фоновые задания | Ожидание монопольного режима | Завершить сеансы, заблокировать начало сеансов и регламентные задания |
| 💾 Нет места на диске | Падение скорости, затем ошибка записи | Освободить место в каталоге базы, во временной папке, для MS SQL — под tempdb и журнал транзакций |
| 🛡️ Антивирус проверяет файлы базы | Процесс идёт, но в разы медленнее | Исключить из проверки каталог базы, папку временных файлов и каталоги данных СУБД |
| 🔒 Блокировка в СУБД | rphost ждёт, ЦП низкий | Найти блокирующий процесс в СУБД (см. ниже) |
| 🧩 Не та версия платформы | Обновление отказывается начинаться или падает | Поставить версию платформы, указанную в описании релиза как минимальная |
| 📈 Крупные регистры | Этап реструктуризации идёт часами | Ждать, на будущее — замерить время на копии |
Отдельно — перепрыгивание через релизы. Типовые конфигурации обновляются по цепочке: файл обновления .cfu принимает только определённые предыдущие версии. Если поставить «через голову» полным .cf, сравнение-объединение может затянуться, а обработчики промежуточных версий не выполнятся. Проверяйте в описании обновления, с каких версий оно ставится.
Ещё одна частая история — сетевая файловая база. Реструктуризация по сети через SMB идёт заметно медленнее, чем локально, и обрывается при кратковременном пропадании связи. Крупную файловую базу обновляйте, запустив Конфигуратор прямо на компьютере, где лежит каталог базы.
Что искать в журнале регистрации и логах СУБД
Журнал регистрации
Откройте Администрирование → Журнал регистрации в Конфигураторе или в пользовательском режиме. Поставьте отбор по интервалу времени обновления и важности «Ошибка». Типовые конфигурации на БСП пишут события обработчиков обновления с текстом, в котором есть слово «Обновление», — по нему удобно отфильтровать.
Смотрите на последнее событие перед остановкой: в нём обычно указан объект или обработчик, на котором встала работа.
В типовых конфигурациях ход отложенной обработки виден в пользовательском режиме: Администрирование → Обслуживание, ссылка о результатах обновления программы. Там показано, какие обработчики выполнены и какие завершились с ошибкой.
Технологический журнал платформы
Если журнал регистрации пуст, включите технологический журнал. В каталоге conf установленной платформы (например, C:\Program Files\1cv8\conf) создайте файл logcfg.xml:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\1c_techlog" history="24">
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Платформа начнёт писать исключения в C:\1c_techlog. Параметр history — сколько часов хранить логи. После диагностики файл удалите: журнал растёт быстро и сам замедляет работу.
Логи и блокировки в MS SQL
В SQL Server Management Studio выполните запрос — он покажет, чем заняты активные сеансы и кто кого блокирует:
SELECT session_id, blocking_session_id, status, command,
wait_type, wait_time, percent_complete
FROM sys.dm_exec_requests
WHERE session_id > 50;
Ненулевой blocking_session_id — номер сеанса, который держит блокировку. Если идёт откат после прерывания, ход отката покажет KILL <номер> WITH STATUSONLY.
Логи и блокировки в PostgreSQL
SELECT pid, state, wait_event_type, wait_event,
now() - query_start AS duration,
left(query, 80) AS query
FROM pg_stat_activity
WHERE datname = 'имя_базы';
Значение Lock в wait_event_type значит, что запрос ждёт чужую блокировку. Ошибки сервера смотрите в каталоге журналов PostgreSQL — там бывают сообщения о нехватке места и обрывах соединений.
Как обновлять 1С, чтобы не зависало
Главный приём практиков — генеральная репетиция. Разверните копию рабочей базы из .dt или бэкапа СУБД и проведите обновление на ней с замером времени. Так вы узнаете, сколько длится реструктуризация, и спокойно дождётесь её в рабочей базе, а не сорвётесь на 40-й минуте.
Ещё несколько правил:
- 📅 Обновляйтесь регулярно. Между соседними релизами изменений мало, реструктуризация короткая. Набор из восьми пропущенных релизов — это восемь реструктуризаций подряд.
- 🧹 Перед большим обновлением имеет смысл свернуть или почистить данные, которые не нужны: например, старые записи журнала регистрации и версии объектов, если их хранение включено.
- 🖥️ Файловую базу обновляйте локально на том компьютере, где лежат её файлы.
- 📝 Записывайте, сколько длился каждый этап. Через пару обновлений у вас будет своя норма, и вопрос «зависло или нет» отпадёт.
Если не помогло: когда звать специалиста
Самостоятельно разбираться дальше не стоит, если:
- 🚫 после прерывания Конфигуратор сообщает о повреждении базы, а тестирование и исправление не проходит;
- 🗄️ резервной копии нет или она не разворачивается;
- 🔁 обновление повторно встаёт на одном и том же объекте, а в журнале — ошибка уникальности индекса или нарушение ссылочной целостности;
- ⚙️ в конфигурации есть доработки, и при объединении нужно решать, какие изменения поставщика принимать;
- 🧮 клиент-серверная база весит сотни гигабайт, и простой больше нескольких часов недопустим.
Специалисту передайте: версию платформы и конфигурации до и после, тип базы (файловая, MS SQL, PostgreSQL), этап, на котором остановилось, последние записи журнала регистрации и, если включали, файлы технологического журнала. Это сокращает диагностику с часов до минут.