При обновлении распределенных информационных баз (РИБ) на базе конфигурации 1С:Зарплата и управление персоналом 3.1 технические специалисты часто сталкиваются со специфической проблемой. После успешного завершения обновления, выполнения всех процедур в режиме «Предприятие» и проведения синхронизации, в центральном узле (ЦУ) «зависает» регистрация изменений. Система продолжает бесконечно выгружать одни и те же объекты (их количество может исчисляться тысячами), подчиненный узел (ПУ) успешно их принимает, но при отправке квитанции подтверждения регистрация в центральной базе не снимается.
В этой статье мы подробно разберем, почему возникает данная коллизия на уровне платформы 1С и СУБД, как на этот процесс влияют отложенные обработчики обновления ЗУП 3.1 и какие практические шаги помогут полностью устранить эту проблему.
Для того чтобы понять, почему не снимается регистрация изменений, рассмотрим внутренний механизм работы планов обмена платформы «1С:Предприятие 8». Для каждого объекта метаданных, включенного в состав плана обмена, СУБД создает служебную таблицу регистрации изменений. В SQL-версии базы данных эта таблица имеет суффикс _Chng (например, _InfoRegChngXXXX для регистров сведений).
В этой таблице присутствуют две ключевые колонки:
_NodeRef — ссылка на узел плана обмена, для которого зарегистрировано изменение._SentNo — номер сообщения обмена, в котором данные были отправлены в подчиненный узел.Проанализируем стандартный жизненный цикл регистрации объекта при обмене:
_SentNo записывается значение NULL (или 0), что означает, что объект изменен, но еще не выгружался.ПланыОбмена.ВыбратьИзменения()) платформа формирует файл обмена, присваивает ему номер (например, 150) и записывает этот номер в колонку _SentNo для всех выгруженных записей.ПланыОбмена.УдалитьРегистрациюИзменений(). Платформа выполняет SQL-запрос на удаление записей из таблицы изменений, где номер отправленного сообщения меньше или равен подтвержденному (_SentNo <= 150).Суть проблемы: В некоторых релизах технологической платформы (особенно в ветках 8.3.12–8.3.15) при работе с независимыми регистрами сведений возникал баг: при выгрузке изменений колонка _SentNo для определенных записей не заполнялась и оставалась равной NULL. Из-за этого при получении подтверждения от подчиненного узла метод удаления регистрации просто игнорировал эти записи, так как их номер отправленного сообщения не соответствовал условию фильтрации. В результате объекты выгружались снова и снова, увеличивая трафик и время обмена.
В конфигурации «Зарплата и управление персоналом 3.1» при переходе на новые релизы (особенно при пропуске нескольких промежуточных версий) выполняется колоссальный объем изменений в структуре данных. В частности, задействуются механизмы БСП (Библиотеки Стандартных Подсистем) для выполнения отложенного обновления данных в фоновом режиме.
Эти обработчики массово перезаписывают данные в независимых регистрах сведений, таких как:
СоставДокументовЗарплатаКадрыФизическиеЛицаДокументовДанныеДляПодбораСотрудниковТекущиеКадровыеДанныеСотрудниковЕсли запустить цикл обмена данными до того, как все отложенные обработчики завершили свою работу на 100% в обоих узлах РИБ, возникает конфликт версий. Базы начинают циклически регистрировать изменения одних и тех же записей друг для друга, что накладывается на вышеописанный платформенный баг с незаполненным полем _SentNo. В результате база уходит в бесконечный цикл выгрузки «зависших» объектов.
---
Рассмотрим несколько практических способов устранения данной проблемы, начиная от превентивных мер и заканчивая программным вмешательством.
Категорически запрещается запускать синхронизацию данных РИБ во время выполнения процедур обновления в режиме «1С:Предприятие». Проанализируем правильный алгоритм действий при обновлении РИБ:
Если коллизия уже произошла, нет необходимости сбрасывать регистрацию для всей базы, так как это может привести к потере реальных изменений, внесенных пользователями. Мы можем удалить регистрацию выборочно для проблемных объектов:
СоставДокументовЗарплатаКадры или ДанныеДляПодбораСотрудников). Обратите внимание на показатели: если зарегистрировано много объектов, но в колонках отправки стоят нули или отсутствует актуальный номер сообщения, это наш случай.Для быстрого и гарантированного удаления регистрации изменений по конкретным объектам или регистрам без использования интерактивного интерфейса (который может зависнуть при больших объемах данных), мы можем применить встроенный язык 1С. Создадим простую внешнюю обработку и выполним следующий код:
// Определяем узел обмена, для которого нужно очистить регистрацию
УзелПолучатель = ПланыОбмена.ОбменЗарплатаПлатаКадры.НайтиПоКоду("ПУ"); // Укажите имя вашего плана обмена и код узла
Если Не УзелПолучатель.Пустая() Тогда
// Очищаем регистрацию для конкретного проблемного регистра сведений
ПланыОбмена.УдалитьРегистрациюИзменений(УзелПолучатель, РегистрыСведений.СоставДокументовЗарплатаКадры);
// При необходимости очищаем регистрацию для других проблемных таблиц
ПланыОбмена.УдалитьРегистрациюИзменений(УзелПолучатель, РегистрыСведений.ДанныеДляПодбораСотрудников);
ЗаписьЖурналаРегистрации("ОбменДанными.ОчисткаРегистрации",
УровеньЖурналаРегистрации.Информация,
,
,
"Регистрация изменений для узла " + УзелПолучатель + " успешно очищена.");
КонецЕсли;
Этот метод мгновенно очищает служебные таблицы регистрации изменений на уровне СУБД, освобождая оперативную память и дисковое пространство.
Если вы пропустили большое количество обновлений и уверены, что все отложенные обработчики успешно выполнились в обеих базах, а реальные пользовательские данные в этот момент в подчиненном узле не вводились, можно прибегнуть к радикальному, но эффективному методу, который использовал автор темы:
Поскольку проблема с заполнением колонки _SentNo носит платформенный характер, долгосрочным решением является переход на стабильные и актуальные релизы платформы «1С:Предприятие 8.3» (например, ветки 8.3.21, 8.3.22 и выше). В этих версиях разработчики «1С» исправили ошибки транзакционной записи номеров сообщений в таблицы изменений СУБД для независимых регистров сведений в РИБ.
Проанализировав описанные методы, вы сможете быстро локализовать проблему «неснимаемой регистрации» в ЗУП 3.1, сократить время выполнения обмена данными до нормальных показателей и обеспечить стабильную работу распределенной информационной системы.