При обновлении конфигураций 1С, особенно при переходе между мажорными редакциями (например, с 1С:Управление торговлей 11.1 на 11.2), разработчики и администраторы часто сталкиваются с ситуацией, когда процесс обновления в пользовательском режиме зависает на определенном проценте (например, 31%) и не продвигается часами. При этом журнал регистрации может не показывать новых событий, а попытки вручную скорректировать метаданные приводят к новым ошибкам. Разберем детально, почему это происходит, как правильно диагностировать причину зависания и как корректно завершить процесс обновления.
Причины долгого обновления и отсутствия записей в журнале регистрации
Рассмотрим основные факторы, которые приводят к многочасовому зависанию и кажущемуся отсутствию активности программы:
Масштабная миграция структур данных: При смене редакций разработчики типовых решений коренным образом перерабатывают учетные механизмы — изменяется учет серий, политика характеристик, взаиморасчеты и партионный учет. Алгоритмам Библиотеки стандартных подсистем (БСП) требуется пересчитать и перенести миллионы записей в новые структуры регистров.
Ограничения файлового формата базы данных: Если база данных имеет размер от 5–7 ГБ и работает в файловом режиме (.1CD), все обработчики выполняются монопольно в один поток. Таблицы блокируются целиком, что многократно замедляет обработку по сравнению с клиент-серверным вариантом на СУБД.
Буферизация журнала регистрации: Если процедура обновления выполняет тяжелую выборку или пакетную запись данных внутри длительного цикла либо единой неделимой транзакции, платформа 1С не сбрасывает буфер журнала регистрации на диск моментально. Записи в журнале появятся только после фиксации порции данных или завершения текущей транзакции.
Блокировка регламентных заданий: Если на копии информационной базы или в основной базе включена блокировка работы фоновых и регламентных заданий, отложенные обработчики обновления не могут запуститься в фоновом режиме, из-за чего система либо зависает, либо останавливается на начальном этапе.
Инструменты детальной диагностики: как понять, что происходит
Выясним, какие штатные механизмы позволяют отследить состояние процесса и локализовать ошибку, если прогресс остановился:
Форма результатов обновления программы: Перейдем в раздел НСИ и администрирование — Обслуживание — Обновление программы — Результаты обновления и дополнительная обработка данных. В открывшейся форме отображается детальный список всех выполняемых процедур БСП, текущий процент их завершения, а также стек ошибок в случае сбоя конкретного обработчика.
Регистры состояния обновления БСП: Через меню Функции для технического специалиста (или Все функции) откроем регистры сведений:
ОбновлениеИнформационнойБазы
ОбработкаДанныхДляПереходаНаНовуюВерсию (или ПотокиОбновленияИнформационнойБазы)
В этих регистрах в реальном времени фиксируется статус каждого обработчика (выполняется, ошибка, завершен) и объем обработанных порций.
Технологический журнал: Для низкоуровневого анализа настроим технологический журнал (файл logcfg.xml), включив отслеживание событий EXCP (исключения) и DBV8DBENG (обращения к файловой СУБД). Это позволит увидеть, выполняет ли процесс реальные запросы к базе или находится в мертвом цикле.
Ошибки с объектами с префиксом Удалить и пропуск релизов
Проанализируем распространенную ошибку, когда администратор или программист пытается пропустить один или несколько промежуточных релизов и обновиться сразу на финальный доступный дистрибутив.
В типовых конфигурациях 1С вывод объектов из эксплуатации происходит поэтапно:
В первом переходном релизе устаревший объект (регистр, последовательность, реквизит) переименовывается с добавлением префикса Удалить, создается новая структура, и запускаются обработчики переноса данных из старого объекта в новый.
В последующих релизах старый объект с префиксом Удалить полностью удаляется из метаданных.
Важное предупреждение: Ни в коем случае нельзя вручную убирать префикс Удалить в дереве метаданных конфигуратора. Это нарушает внутренние соответствия в коде процедур БСП. Если переименовать объект обратно, следующий обработчик попытается обратиться к уже удаленному связанному регистру или реквизиту, что вызовет фатальное падение обновления.
Единственное правильное решение в такой ситуации — строгое соблюдение цепочки последовательных обновлений.
Пошаговый алгоритм правильного обновления тяжелых и доработанных баз
Разберем по шагам регламент, который гарантирует корректный переход между сложными версиями конфигураций:
Подготовка базы:
Создадим резервную копию информационной базы.
Выполним тестирование и исправление (ТИИ) информационной базы через меню Администрирование — Тестирование и исправление... с проверкой логической и ссылочной целостности.
Выполним сжатие таблиц базы данных в конфигураторе (Администрирование — Сжатие таблиц информационной базы).
Проверим наличие свободного места на диске (для временных файлов требуется не менее двух объемов самой базы).
Использование промежуточного релиза:
Сверимся с официальной матрицей обновлений в файле UpdInfo.txt из комплекта поставки.
Если между текущей и целевой версией есть обязательный промежуточный релиз, накатываем конфигурацию строго на промежуточный релиз.
Выполняем обновление конфигурации через механизм Конфигурация — Поддержка — Обновить конфигурацию, а не через прямое объединение с файлом .cf.
Завершение отложенных обработчиков:
После обновления метаданных обязательно запускаем базу в пользовательском режиме 1С:Предприятие.
Дожидаемся 100% выполнения всех основных и отложенных процедур обновления данных БСП на промежуточном релизе.
Убеждаемся в отсутствии незавершенных заданий в форме Результаты обновления и дополнительная обработка данных.
Только после полной обработки данных переходим к накатыванию следующего релиза.
Ускорение процедуры через СУБД (клиент-сервер):
Если файловая база превышает 4–5 ГБ, выгружаем данные в файл .dt.
Загружаем базу на временный сервер СУБД (PostgreSQL или MS SQL).
Выполняем реструктуризацию и пользовательские обработчики на сервере — в клиент-серверном режиме БСП запускает параллельные фоновые потоки, что сокращает время обновления с 5–8 часов до 30–60 минут.
После завершения всех процедур выгружаем базу обратно в .dt и загружаем в файловый режим.
Принудительный запуск обновления через командную строку
Посмотрим на пример пакетного запуска процедуры обновления, который помогает форсировать выполнение обработчиков БСП до входа пользователей:
Параметр /C ЗапуститьОбновлениеИнформационнойБазы передает указание подсистеме БСП выполнить все базовые процедуры инициализации и реструктуризации данных без ожидания действий пользователя в интерфейсе.