← На главную

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

Понимание природы проблемы

Когда мы обновляем информационную базу, 1С помечает ряд процедур как «выполненные» в специальных регистрах и константах. Основная проблема возникает из-за того, что при обмене данными между узлами РИБ передаются не только документы, но и служебная информация о конфигурации. Если подчиненная база (ПБ) после обновления возвращает данные, которые главный узел интерпретирует как неактуальные или конфликтующие, система может счесть, что база находится в «недообновленном» состоянии. В результате запускается механизм Отложенное обновление, который пытается повторно обработать данные, что часто приводит к критическому росту потребления оперативной памяти и «аварийному завершению» процесса.

Шаг 1: Диагностика состояния системы

Первым делом проанализируем текущее состояние базы. Нам нужно понять, какой именно статус обновления зафиксирован в системе. Рассмотрим способы проверки:

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

Шаг 2: Управление обработчиками обновления

Если обновление постоянно падает из-за нехватки памяти (например, на обработчике РегистрыНакопления.ОстаткиАлкогольнойПродукцииЕГАИС.ОбработатьДанныеДляПереходаНаНовуюВерсию), попробуем изменить тактику выполнения:

Запуск через командную строку: Вместо использования интерфейса 1С, который потребляет много ресурсов для отрисовки форм, запустите процесс в фоновом режиме через командную строку сервера. Это позволит сэкономить значительный объем оперативной памяти. Используйте ключ запуска:

/СЗапуститьОбновлениеИнформационнойБазы

Этот метод позволяет системе выполнить тяжелые транзакции без нагрузки на графический интерфейс, что часто спасает при обработке больших массивов данных ЕГАИС.

Шаг 3: Исправление конфликтов в очереди

Если обработчик зависает на конкретном объекте, необходимо проверить Очередь отложенного обновления. Рассмотрим следующие действия:

• Проверьте, нет ли в очереди «битых» объектов, которые невозможно обработать из-за нарушенных ссылок или некорректных данных.
• Если задачи «висят» и не двигаются, попробуйте очистить очередь (в крайнем случае, если вы уверены в целостности данных) или локализовать проблемный документ, который вызывает переполнение памяти.
• Перед обменом отключайте регламентные задания. Часто бывает так, что фоновое задание по обмену конфликтует с регламентным заданием обновления, создавая взаимные блокировки, которые приводят к аварийному завершению.

Рекомендации по безопасному обновлению

Чтобы минимизировать риски, придерживайтесь стратегии постепенного обновления:

1. Обновляйте конфигурацию последовательно. Не пытайтесь прыгнуть сразу на несколько мажорных релизов.
2. Перед обменом убедитесь, что в обоих узлах (Центр и ПБ) выполнены все текущие обработчики обновления.
3. Очистите планы обмена от неактуальных сообщений. Убедитесь, что в момент обмена в очереди на отправку нет лишних объектов.
4. Если проблема сохраняется, проанализируйте константы, связанные с версией конфигурации. Иногда помогает принудительная установка флага завершения обновления, если вы уверены, что все структуры данных уже актуализированы, однако используйте этот метод с осторожностью.

Помните, что «откат» или «сброс» обработчиков — это защитная реакция системы. Главная задача — добиться того, чтобы метаданные и версии подсистем в обоих узлах соответствовали друг другу. Если после всех попыток проблема сохраняется, рекомендуем выполнить сверку ПланаОбмена и проверить, нет ли в нем неожиданных изменений, переданных из подчиненной базы.