Работа с распределенными информационными базами (РИБ) требует особого внимания к объему передаваемых данных. Одной из самых коварных проблем в конфигурации 1С:Управление торговлей 11.4 (и других на базе БСП) является внезапный отказ узла принимать пакеты обмена от центральной базы. Ситуация часто выглядит так: обмен стабильно работал месяцами, но после того как менеджер или администратор провел «генеральную уборку» (удаление помеченных объектов), периферийная база начинает «зависать», выдавать ошибки типов или просто перестает увеличивать номер принятого сообщения. Рассмотрим детально, почему это происходит и как реанимировать обмен.
Когда мы запускаем процедуру Удаление помеченных объектов в центральной базе, система физически удаляет записи из таблиц базы данных. Согласно механизму РИБ, информация об этом должна быть передана во все подчиненные узлы. Однако здесь кроется важный технический нюанс: в таблицу регистрации изменений записывается не само удаление как действие, а специальная бинарная ссылка на удаленный объект с пометкой об удалении.
Проанализируем ситуацию: если в базе удаляются тысячи заказов, накладных и их движений, файл обмена раздувается до гигантских размеров. Он содержит не данные, а бесконечный список инструкций типа «Удали объект с таким-то внутренним идентификатором». Попытка загрузить такой файл на стороне узла (особенно если это обычный ноутбук) приводит к следующим последствиям:
1cv8.exe просто завершается или «зависает» без записи в журнал регистрации.ПередУдалением или ПриЗаписи, которые некорректно обращаются к уже удаленным данным в контексте обмена, возникают трудночитаемые ошибки.Чтобы предотвратить «смерть» РИБ, выработаем правило: перед запуском массового удаления объектов необходимо временно управлять регистрацией изменений. Если удаляемые данные (например, старые заказы пятилетней давности) уже давно есть в узлах и их удаление в периферии не критично для текущей работы, можно воспользоваться обработкой Регистрация изменений для обмена данными.
Рассмотрим алгоритм действий:
ПланыОбмена).В этом случае информация об удалении просто не попадет в файл обмена, и пакет останется легким. Однако помните, что в этом случае объекты останутся в периферийной базе «навсегда» или до тех пор, пока вы не удалите их там вручную.
Если «тяжелый» файл уже сформирован и узел не может его принять, попробуем заставить систему обрабатывать данные порциями. В типовых конфигурациях на БСП есть возможность настройки ограничения количества объектов в одном сообщении. Рассмотрим, как это можно реализовать через код, если стандартных настроек недостаточно:
// Пример настройки параметров обмена для уменьшения размера транзакции
Прокси = Последовательность.ПолучитьОбъект();
ПараметрыЗагрузки = ОбменДаннымиСервер.ПараметрыЗагрузкиДанных();
ПараметрыЗагрузки.МаксимальноеКоличествоОбъектовВТранзакции = 1000;
ОбменДаннымиСервер.ВыполнитьЗагрузкуДанных(ПараметрыЗагрузки);
Уменьшение количества объектов в одной транзакции позволит базе фиксировать изменения поэтапно. Даже если произойдет сбой, часть данных уже будет записана, и в следующий раз система начнет не с самого начала.
Часто после неудачных попыток обмена счетчики сообщений «рассинхронизируются». Если вы видите, что номер принятого сообщения в узле не увеличивается, несмотря на успешную (как вам кажется) загрузку, выполните следующие действия:
Регистрация изменений вручную установите Номер принятого сообщения на единицу меньше того, который прислала центральная база.Важно помнить: если вы «обнуляете» номера сообщений (ставите 0), система попытается выгрузить все зарегистрированные изменения с самого начала. Для большой базы УТ 11.4 это может привести к созданию файла размером в несколько гигабайт, который гарантированно «уложит» базу-приемник.
Проанализируем ситуацию, когда удаление блокируется из-за ссылочной целостности. Если в узле объект используется в документе, который еще не был изменен в центре, попытка удаления этого объекта через обмен может вызвать конфликт. Выясним причину через Журнал регистрации. Ищите записи с событием Данные.ОбменДанными.Загрузка.
Если вы видите ошибки преобразования типов (например, Ошибка при установке значения атрибута контекста (ПометкаУдаления): Несоответствие типов (Boolean)), это часто означает, что объект, который база пытается пометить на удаление или физически удалить, заблокирован другим процессом или его структура в памяти искажена из-за прерванной ранее транзакции.
Подведем итог: проблема РИБ в УТ 11.4 — это не столько «глюк» программы, сколько архитектурная особенность обработки больших объемов данных. Чтобы обмен не «валился», придерживайтесь следующих правил:
message_ЦБ_РБ.xml весит более 200–300 Мб, у стандартного ноутбука могут возникнуть проблемы с его обработкой в одной транзакции.Совместное использование инструментов мониторинга регистрации изменений и грамотное планирование регламентных операций позволит вам избежать «трупов» в РИБ и обеспечит стабильную работу распределенной системы.