Что делать, если обновление 1С:Управление торговлей зависает на регистрации данных справочника Номенклатура?

← На главную

Обновление конфигурации 1С — это ответственный процесс, который не всегда проходит гладко. Одной из наиболее трудоемких версий в линейке 1С:Управление торговлей 11.3 стала версия 11.3.4.167. Многие технические специалисты сталкиваются с ситуацией, когда процесс обновления визуально «замирает» на этапе выполнения отложенных обработчиков. В этой статье мы подробно разберем, почему это происходит и как довести обновление до конца, не теряя данные.

Анализируем причину зависания

Проанализируем ситуацию: при переходе на новые версии системы часто меняется структура хранения данных. Для этого используются механизмы БСП (Библиотеки стандартных подсистем). Проблема, о которой пойдет речь, возникает в процедуре ЗарегистрироватьДанныеКОбработкеДляПереходаНаНовуюВерсию, которая относится к справочнику Номенклатура.

Разберем по шагам, что происходит внутри системы. В процессе обновления конфигурация запускает «отложенные обработчики». Первый этап их работы — регистрация данных. Система должна просканировать весь справочник Номенклатура и пометить объекты, которые требуют трансформации (например, при изменении логики учета характеристик или упаковок). Если в вашей базе данных сотни тысяч позиций номенклатуры, стандартный запрос, написанный разработчиками, может выполняться крайне медленно из-за неоптимального плана запроса на стороне СУБД (особенно часто это встречается на PostgreSQL или старых версиях MS SQL Server).

Решение 1: Оптимизация на уровне СУБД

Выясним причину, по которой запрос «висит». Часто это происходит не из-за ошибки в коде 1С, а из-за того, что СУБД не может быстро обработать огромный объем данных без актуальной статистики. Прежде чем приступать к радикальным мерам, выполним обслуживание базы данных:

Обновление статистик: В консоли управления SQL-сервером запустите процедуру обновления статистик. Это поможет оптимизатору SQL выбрать правильный путь к данным.
Очистка процедурного кэша: Иногда старые планы выполнения мешают работе новых запросов обновления.
Реиндексация: Полное перестроение индексов таблицы _ReferenceNode (соответствующей справочнику Номенклатура) и связанных с ней таблиц существенно ускоряет выборку.

Как показывает практика, после проведения этих регламентных операций процедура, которая висела часами, может завершиться за 15–20 минут.

Решение 2: Переход в файловый режим (Workaround)

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

Выполним выгрузку информационной базы в файл (.dt).
Развернем базу в файловом варианте на мощном локальном компьютере (желательно с SSD).
Запустим процесс обновления. В файловом режиме механизмы блокировок и работа с индексами реализованы иначе, что иногда позволяет избежать «зацикливания» запроса, характерного для серверных версий.
После успешного завершения регистрации и выполнения обработчиков, загрузим базу обратно на SQL-сервер.

Важно: этот метод подходит для баз среднего размера. Если ваша база весит несколько сотен гигабайт, выгрузка и загрузка .dt может занять больше времени, чем само обновление.

Решение 3: Использование инструментов управления обновлением

Посмотрим на стандартные возможности программы. В составе типовых конфигураций на базе БСП есть встроенная обработка для контроля процесса обновления. Найти ее можно через меню «Все функции» (или «Функции для технического специалиста»), введя в поиске Результаты обновления программы или Управление отложенным обновлением.

В этой обработке мы можем:

Увидеть реальный прогресс в процентах. Если процент растет (пусть даже на 1% в час), значит, процесс идет и прерывать его не стоит.
Остановить зависший поток и попробовать запустить его снова.
Посмотреть текст ошибки, если процедура завершилась аварийно.

Решение 4: Диагностика через Технологический журнал (ТЖ)

Если визуально ничего не происходит, проанализируем ситуацию с помощью Технологического журнала. Это самый надежный способ узнать, чем занят сервер 1С в данный момент. Настроим сбор событий DBMSSQL (или DBPOSTGRS) и EXCP. Мы сможем увидеть текст SQL-запроса, который выполняется в данный момент. Если в логах ТЖ мы видим один и тот же бесконечный запрос к таблице номенклатуры, значит, мы имеем дело с неоптимальным планом запроса или блокировкой.

Решение 5: Ручная регистрация данных (для опытных программистов)

Если вы понимаете, что типовой запрос в процедуре ЗарегистрироватьДанныеКОбработкеДляПереходаНаНовуюВерсию не может отработать на вашем объеме данных, мы можем временно изменить код. Рассмотрим, как выглядит структура такой процедуры в модуле менеджера справочника:


Процедура ЗарегистрироватьДанныеКОбработкеДляПереходаНаНовуюВерсию(Параметры) Экспорт
    // Типовой запрос может быть слишком тяжелым
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ ПЕРВЫЕ 10000
        |	Номенклатура.Ссылка КАК Ссылка
        |ИЗ
        |	Справочник.Номенклатура КАК Номенклатура
        |ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДанныеОчередиОбновления КАК Очередь
        |ПО Номенклатура.Ссылка = Очередь.Ссылка
        |ГДЕ
        |	Очередь.Ссылка ЕСТЬ NULL";
    
    РезультатЗапроса = Запрос.Выполнить();
    // Логика постановки в очередь порциями
КонецПроцедуры

Разберем этот пример. Если типовой механизм пытается зарегистрировать сразу 500 000 записей, это вызывает переполнение лога транзакций. Мы можем модифицировать код так, чтобы регистрация проходила порциями по 10 000 записей. После завершения обновления крайне важно вернуть объект на полную поддержку, чтобы не возникло проблем при следующих обновлениях.

Дополнительные рекомендации

Проанализируем еще несколько факторов, которые могут влиять на скорость:

Полнотекстовый поиск: Перед обновлением обязательно отключите индексирование полнотекстового поиска. Он создает дополнительную нагрузку на таблицы и может блокировать запись данных.
Регламентные задания: Отключите все фоновые задания, кроме тех, что относятся к обновлению. Особенно это касается синхронизации данных и извлечения текста из файлов.
Дубли в регистрах: Иногда причиной «зависания» являются битые ссылки или дубли в технических регистрах сведений (например, в регистре соответствия объектов информационных баз). Перед обновлением рекомендуется выполнить стандартное Тестирование и исправление.

Подведем итог: зависание на справочнике Номенклатура в версии 11.3.4.167 — это известная проблема, связанная с объемом данных и сложностью запросов регистрации. Используя комбинацию методов (обслуживание SQL, контроль через консоль обновлений и, в крайнем случае, порционную регистрацию), вы сможете успешно завершить переход на новую версию программы.