← На главную

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

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

Симптоматика и диагностика проблемы

Проанализируем типичное поведение системы при рассматриваемом сбое:

1. Ручной режим работает: При нажатии кнопки «Выполнить обмен» в узле обмена данные выгружаются и загружаются без ошибок.
2. Запуск по расписанию отсутствует: В установленное время фоновый процесс не запускается, в Журнале регистрации подчиненной базы отсутствуют записи о старте регламентного задания.
3. Ошибки номеров сообщений: В центральной базе может появляться ошибка о том, что номер принятого сообщения меньше или равен ранее принятому (например, узел пытается передать пакет со старым номером).

Выясним главные технические причины, почему обновление конфигурации приводит к подобному поведению подсистемы обмена данными.

Причина 1. Битые ссылки в таблицах регистрации изменений

Механизм распределенных баз отслеживает все изменения с помощью специального регистра — таблицы регистрации изменений для узла обмена. При обновлении конфигурации через несколько десятков релизов меняются структуры метаданных и обработчики событий объектов.

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

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

Причина 2. Повреждение пользовательских настроек и кэша фонового обмена

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

В результате новый код конфигурации не может правильно прочитать старое хранилище настроек регламентного задания. Автоматический процесс запускается под учетной записью с поврежденными настройками и незаметно прерывается.

Решение: Пересоздать учетную запись пользователя, выделенного для выполнения обмена, и заново перенастроить параметры автообмена.

Причина 3. Специфика выполнения фоновых заданий в файловых базах

Если центральный узел работает в клиент-серверном режиме, а подчиненные узлы — файловые, крайне важно учитывать технические особенности платформы 1С:

1. Необходимость активного сеанса: В файловой базе отсутствует сервер приложений, который мог бы самостоятельно инициировать процессы по расписанию. Для работы автообмена в файловой базе должен быть постоянно запущен сеанс пользователя, указанного в настройках как Пользователь для выполнения регламентных заданий в файловом режиме.
2. Слишком частый интервал обмена: Настройка расписания с перезапуском каждые 100 секунд (и повтором через 50 секунд) создает слишком высокую нагрузку на файловую базу. Во время обмена платформа накладывает блокировки на таблицы. Если предыдущий сеанс обмена не успел завершиться за 100 секунд, новый запуск блокируется платформами, из-за чего регламентный обмен регулярно «пропускает» свои циклы.

Причина 4. Ошибка «Номер сообщения меньше ранее принятого»

Проанализируем ситуацию, когда в центральной базе возникает сообщение о несовпадении номеров пакетов. Это защитный механизм платформы 1С, предотвращающий перезапись актуальных данных устаревшими пакетами.

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

Номер отправленного сообщения на стороне узла-источника должен быть строго равен или на единицу больше параметра Номер принятого на стороне узла-приемника.

Пошаговый алгоритм решения проблемы

Разберем по шагам последовательность действий, которая позволяет полностью восстановить автоматический обмен РИБ:

1. Очистка базы от помеченных объектов:

   Перейдем в меню Операции — Удаление помеченных объектов. Выполним полное удаление всех помеченных элементов в подчиненном и центральном узлах.

2. Пересоздание пользователя для обмена:

   Зайдем в список пользователей (Конфигуратор или Администрирование — Пользователи). Удалим текущего пользователя, под которым выполнялся обмен, и создадим нового с полными правами. Убедимся, что у пользователя установлены необходимые административные роли и сняты ограничения на уровне записей (RLS).

3. Настройка пользователя файлового режима:

   Откроем Сервис — Настройки учета — Настройки параметров учета. На вкладке выполнения регламентных заданий укажем вновь созданного пользователя.

4. Перенастройка расписания:

   Откроем настройки узла обмена. Увеличим интервал запуска обмена (например, установим запуск каждые 300–600 секунд вместо 100 секунд), чтобы исключить наложение фоновых процессов друг на друга. Снимем и повторно установим флаг Использовать расписание, после чего сохраним настройки.

5. Синхронизация номеров сообщений (при необходимости):

   Если центральная база выдает ошибку номера сообщения, откроем обработку РегистрацияИзмененийДляОбмена, перейдем на вкладку настройки номеров сообщений и синхронизируем значения отправленных и принятых номеров пакетов между ЦО и подчиненным узлом.

6. Очистка кэша платформы:

   Завершим все процессы 1cv8.exe через Диспетчер задач и очистим локальный кэш платформы 1С на рабочем столе, где запущен сеанс файловой базы.

Выполнение описанного комплекса мер позволяет устранить повреждения настроек после обновления конфигурации и полностью восстановить стабильную работу автоматического обмена РИБ по расписанию.