В процессе сопровождения распределенных информационных баз (РИБ) администраторы и программисты часто сталкиваются с аномальным поведением: при запуске обмена один из узлов начинает регистрировать колоссальное количество объектов (справочники, документы, регистры), которые не должны передаваться в этот магазин или филиал. Попытки вручную снять объекты с регистрации не помогают — если обмен переполнен документами, система снова ставит их в очередь при следующем сеансе синхронизации. Проанализируем ситуацию и разберем по шагам, как выявить причину «бесконечной» регистрации и эффективно очистить таблицы обмена.
Если в очереди обмена накопилось около 10 миллионов объектов, стандартные инструменты будут работать крайне медленно. Рассмотрим подробнее, как выполнить максимально быструю очистку регистрации для конкретного узла, используя инструменты универсальной очистки базы.
Самый эффективный способ — использовать метод встроенного языка ПланыОбмена.УдалитьРегистрациюИзменений(). При передаче Неопределено в качестве второго параметра платформа очищает абсолютно все таблицы регистрации для данного узла за одну транзакцию.
// Пример быстрой очистки всей регистрации для конкретного узла
УзелОбмена = ПланыОбмена.ПоМагазину.НайтиПоКоду("М001"); // Замените на ваш план обмена и код узла
Если Не УзелОбмена.Пустая() Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, Неопределено);
Сообщить("Регистрация изменений для узла " + УзелОбмена + " успешно очищена.");
КонецЕсли;
Этот метод работает значительно быстрее, чем удаление по типам объектов, обеспечивая массовую очистку регистров через прямые команды платформы к базе данных для очистки таблиц с префиксом _ChngRec.
Если после полной очистки объекты снова появляются в очереди при нажатии кнопки «Синхронизировать», выясним причину в логике Библиотеки стандартных подсистем (БСП). В современных конфигурациях (таких как 1С:Розница, УТ 11, ERP) за регистрацию отвечают не только настройки метаданных, но и специальные «Правила регистрации объектов» (ПРО).
Разберем по шагам, как проверить правила:
НастройкиРегистрацииОбъектов для «проблемного» узла заданы некорректные параметры (например, пустой список магазинов, который интерпретируется как «выгружать всё»).Проанализируем ситуацию с обновлением метаданных. В 1С:Предприятии существует механизм, при котором динамическое изменение структуры объектов, входящих в состав плана обмена, может спровоцировать автоматическую перерегистрацию всех данных. Платформа делает это, чтобы гарантировать, что данные на узле будут соответствовать новой структуре центральной базы.
Если вы недавно выполняли «динамическое обновление» (без выгона пользователей), это могло стать триггером. Посмотрим на решение: в таких случаях помогает только полная очистка регистрации (см. Причину 1) и, при необходимости, выполнение обмена в монопольном режиме после полноценного принятия изменений конфигурации базы данных.
Часто объекты попадают в обмен не из-за собственных изменений, а из-за того, что на них ссылается другой, «важный» объект. Выясним причину на примере. Допустим, у вас есть документ «Установка цен номенклатуры», который ошибочно зарегистрировался к выгрузке. Этот документ ссылается на тысячи позиций номенклатуры. Платформа, пытаясь обеспечить целостность данных на узле, может начать регистрировать всю эту номенклатуру, а следом — её характеристики, цены и связанные регистры.
Чтобы пресечь это, проанализируем свойство метаданных Авторегистрация. Если оно установлено в значение Разрешить, любое изменение (в том числе программное) ставит объект в очередь. Для предотвращения массовых «выбросов» данных рекомендуется:
Авторегистрация в значение Запретить для крупных справочников и регистров.ПриЗаписи.Иногда проблема кроется не в самих данных, а в служебной информации плана обмена. Если в узле сбились номера принятых и отправленных сообщений (например, после восстановления из бэкапа), ЦБ может считать, что узел «не видел» огромный пласт данных за прошлые периоды. Рассмотрим, как это исправить:
НомерОтправленного и НомерПринятого.НомерПринятого равным НомеруОтправленного (это скажет системе, что узел подтвердил получение всех данных), а затем очистите регистрацию изменений.При работе с 10 миллионами записей стандартные методы 1С могут приводить к переполнению лога транзакций SQL-сервера. Если очистка через ПланыОбмена не помогает или вызывает ошибку Transaction log for database is full, системным администраторам рекомендуется проанализировать таблицы БД. Таблицы регистрации имеют имена вида _ChngRecXXXX. Очистка такой таблицы командой TRUNCATE (только для опытных специалистов!) позволяет моментально обнулить очередь, но делать это нужно крайне осторожно, предварительно сопоставив имена таблиц в SQL со структурами 1С через ПолучитьСтруктуруХраненияБазыДанных().
Подведем итог: при возникновении массовой неконтролируемой регистрации первым делом используйте программную очистку через ПланыОбмена.УдалитьРегистрациюИзменений(Узел, Неопределено). Если это не решило проблему «повторного появления» данных, переходите к анализу правил регистрации в БСП и проверке свойств Авторегистрация в конфигураторе. Совместный анализ этих факторов позволит вернуть обмен в штатный режим.