← На главную

При переходе между редакциями конфигураций, например при обновлении с 1С:Управление торговлей 11.1 на 11.2, специалисты часто сталкиваются с ситуацией, когда после запуска информационной базы процесс обновления длится многие часы. В журнале регистрации при этом регулярно фиксируются однотипные записи, например: Выполняется процедура обновления "УчетНДСУТ.ЗаполнитьРеквизитыПервичныхДокументов". Разберем по шагам, почему это происходит, как диагностировать реальное состояние системы и как избежать сбоев в учете.

Причины длительной работы процедур обновления

Проанализируем внутренние механизмы Библиотеки стандартных подсистем (БСП), которые отвечают за обновление данных:

1. Массовая перезапись исторических документов. В редакции 11.2 произошли масштабные изменения в подсистемах учета НДС, взаиморасчетов и расчета себестоимости. Процедура УчетНДСУТ.ЗаполнитьРеквизитыПервичныхДокументов последовательно выбирает выборками все первичные документы (поступления, реализации, счета-фактуры) за всю историю базы и перезаписывает их для заполнения новых служебных реквизитов.
2. Иллюзия зацикливания в журнале регистрации. Обработчики БСП работают порциями (пакетами). После успешной обработки очередной пачки документов в журнал регистрации записывается очередное служебное сообщение с тем же наименованием процедуры. Это свидетельствует не о зацикливании, а об успешном переходе к следующей выборке данных. На базах с большим объемом документов нормальное время выполнения таких процедур может составлять от нескольких часов до суток.
3. Влияние подписок на события и версионирования. При перезаписи каждого объекта платформа инициирует выполнение стандартных обработчиков событий ПередЗаписью и ПриЗаписи. Если в базе включена история версионирования объектов, создание новых версий на каждый исторический документ многократно увеличивает время выполнения.

Как проверить: зависла процедура или выполняется

Выясним, какими инструментами можно точно определить текущий статус выполнения фонового обновления:

1. Штатный монитор обновления данных. Перейдем в раздел НСИ и администрирование → Обслуживание → Результаты обновления и дополнительная обработка данных. В открывшейся форме отображается детальный список всех отложенных процедур обновления, их текущее состояние, процент выполнения, а также текст критической ошибки, если обработка завершилась аварийно.
2. Проверка регистра сведений. Через меню «Функции для технического специалиста» откроем регистр сведений ОбработчикиОбновления (или ОбновлениеИнформационнойБазы). В нем можно увидеть статус выполнения конкретной процедуры (например, «Выполняется», «Завершена» или «Ошибка») и дату/время последнего изменения состояния.
3. Мониторинг активности СУБД. В клиент-серверном варианте проанализируем активность процессов рабочего процесса rphost и СУБД (через системный монитор MS SQL Server Management Studio или представление pg_stat_activity в PostgreSQL). Если процесс активно выполняет операции чтения/записи (высокий Disk I/O, загрузка CPU) и в запросах меняются границы диапазонов ссылок, обработка выполняется штатно.
4. Анализ журнала регистрации на ошибки. Установим отбор в журнале регистрации по уровню важности «Ошибка» и «Предупреждение». Если процедура не может записать конкретный документ из-за блокировки или программного исключения, транзакция порции будет откатываться, что приведет к бесконечным повторным попыткам с фиксацией ошибки.

Рекомендации по ускорению обновления и предотвращению сбоев

Рассмотрим комплекс мер, позволяющий сократить время простоя базы данных и снизить риски искажения данных:

1. Подготовка базы перед переходом. Перед накатыванием релиза 11.2 обязательно выполним полное закрытие прошлых месяцев, удаление помеченных объектов и стандартную процедуру «Тестирование и исправление информационной базы» в конфигураторе с переиндексацией таблиц.
2. Временное отключение версионирования. На период проведения миграции данных отключим версионирование документов, чтобы исключить накладные расходы дисковой подсистемы на сохранение версий при массовой перезаписи.
3. Перенос процесса на высокопроизводительный стенд. Для крупных баз данных оптимально выполнять конвертацию на отдельном мощном сервере с быстрыми накопителями NVMe и достаточным запасом оперативной памяти, после чего готовую сконвертированную базу возвращать в рабочий контур.
4. Строгое соблюдение цепочки релизов. Переход между редакциями необходимо осуществлять строго по рекомендованной фирмой «1С» последовательности релизов (указанной в файле поставки). Перед накатыванием следующего релиза убедимся, что все отложенные обработчики предыдущего обновления завершились на 100%.
5. Обязательное предварительное тестирование на копии. Перевод рабочей базы нельзя выполнять без предварительного прогона на тестовой копии. После завершения всех процедур обновления необходимо перезакрыть тестовые месяцы и сопоставить ключевые управленческие отчеты (ведомости по расчетам с клиентами и поставщиками, отчеты по валовой прибыли и остаткам товаров на складах) до и после миграции.