В процессе эксплуатации систем на базе 1С, использующих Библиотеку стандартных подсистем (БСП), администраторы и разработчики часто сталкиваются с ситуацией, когда объем зарегистрированных изменений в служебном регистре СоответствияОбъектовИнформационныхБаз (СОИБ) начинает лавинообразно расти. Это приводит к существенному замедлению обмена данными, а сами записи «висят» без номера сообщения, что означает — система их видит, но по какой-то причине не включает в пакет выгрузки. Рассмотрим детально, почему это происходит и как навести порядок в синхронизации.
Регистр сведений СоответствияОбъектовИнформационныхБаз является ключевым элементом подсистемы «Обмен данными» в БСП. В нем хранится информация о том, какому объекту в текущей базе соответствует объект в другой (приемнике), основываясь на их уникальных идентификаторах (GUID). Это позволяет избегать дублей при повторных обменах.
Проблема: Если записи в этом регистре зарегистрированы для выгрузки (в плане обмена), но им не присваивается номер сообщения при очередном сеансе обмена, это верный признак того, что механизм выгрузки «пропускает» этот объект. При этом количество записей может исчисляться десятками тысяч (в обсуждаемом случае — 40 000), что создает дополнительную нагрузку на базу данных при каждой попытке обмена.
Проанализируем ситуацию, когда объект включен в состав ПланаОбмена, но отсутствует в правилах выгрузки. Система 1С работает следующим образом: механизм регистрации изменений фиксирует правку в регистре, но когда дело доходит до формирования XML-пакета или COM-передачи, подсистема обмена обращается к правилам конвертации данных (ПВД). Если в ПВД нет правила для выгрузки регистра СоответствияОбъектовИнформационныхБаз, система просто игнорирует эти записи. Но так как выгрузка формально не произошла, номер сообщения этим записям не присваивается, и они не удаляются из очереди на регистрацию.
Разберем настройки метаданных. Часто в Плане обмена для этого регистра установлено свойство Авторегистрация в значение Разрешить. В норме БСП управляет регистрацией в этом регистре программно. Если же включена автоматическая регистрация, то при каждом изменении или создании соответствия запись попадает в очередь. В некоторых случаях это создает «циклическую» регистрацию: при загрузке данных создается соответствие, оно автоматически регистрируется на выгрузку, при следующей выгрузке оно «якобы» отправляется, и так по кругу.
При использовании COM-обмена весь процесс передачи данных происходит в рамках одной длительной транзакции. Если объем данных (включая те самые 40 000 записей соответствий) слишком велик, COM-соединение может прерываться по таймауту или из-за нехватки памяти на стороне сервера до того, как будет получено подтверждение от базы-приемника. В результате база-источник не получает сигнал о том, что данные приняты, и не проставляет номера сообщений, оставляя регистрацию активной.
Для исправления ситуации выполним последовательность действий, которая поможет локализовать и устранить ошибку.
Чтобы исключить проблемы именно COM-соединения, попробуем выполнить обмен в ручном режиме через файл. Для этого воспользуемся стандартной обработкой Выгрузка и загрузка данных XML или встроенным в синхронизацию механизмом выгрузки в файл. Если через файл записи регистра успешно выгружаются и очищаются, значит, проблема в стабильности COM-канала или правах доступа пользователя, под которым устанавливается соединение.
Нам необходимо убедиться, что для регистра СОИБ существуют инструкции по выгрузке. Проанализируем правила в конфигурации «Конвертация данных»:
СоответствияОбъектовИнформационныхБаз.Выясним, стоит ли у регистра Авторегистрация. Если ваша цель — остановить бесконтрольный рост записей, выполним следующее:
Конфигуратор.ПланОбмена.РегистрСведений.СоответствияОбъектовИнформационныхБаз.Запретить.Важно: Это не сломает обмен, так как БСП регистрирует нужные записи программно при записи сопоставленных объектов.
Поскольку у нас уже накопилось 40 000 «мертвых» записей, их нужно удалить вручную, так как сами они не уйдут. Воспользуемся обработкой Регистрация изменений для обмена:
Соответствия объектов информационных баз.Это абсолютно безопасная операция. Если объекты уже сопоставлены в обеих базах, записи в самом регистре сведений сохранятся, удалятся только «заявки» на их передачу в следующий раз. При реальном изменении объекта или при его первой синхронизации БСП сама зарегистрирует то, что нужно.
Если вы заметили странное поведение счетчиков (как упоминалось в Сообщении 2 про «прибавление 2 к номеру сообщения»), проанализируем модуль менеджера плана обмена или обработку ОбменДаннымиСервер. Рассмотрим пример кода, который может отвечать за инкремент номеров сообщений:
// Пример логики в недрах БСП
Если ЕстьИзмененияВРегистреСоответствий Тогда
// Если логика нарушена, номер сообщения может инкрементироваться некорректно
УзелОбменаОбъект.НомерОтправленного = УзелОбменаОбъект.НомерОтправленного + 1;
КонецЕсли;
Проанализируем журнал регистрации в момент обмена. БСП довольно подробно пишет об ошибках синхронизации. Если там встречаются записи вида «Ошибка при выгрузке данных: [ИмяОбъекта]», это укажет на конкретную причину сбоя в правилах.
Подведем итог. В 90% случаев «зависание» регистра соответствий связано с тем, что он включен в состав плана обмена с разрешенной авторегистрацией, но в правилах конвертации (ПВД) для него не прописана логика выгрузки.
Решение в три клика:
После этих действий скорость обмена восстановится, а лишний «хвост» из записей перестанет тормозить вашу систему.