При работе с распределенными информационными базами (УРИБ) в конфигурации «Управление торговлей 10.3» системные администраторы и программисты часто сталкиваются с ситуацией, когда после свертки базы или создания нового начального образа периферийного узла обмен данными начинает вести себя некорректно. Основная жалоба заключается в том, что центральная база (ЦБ) при каждом сеансе обмена пытается выгрузить огромный массив данных (например, 700 Мб и более), даже если в периферийной базе (ПБ) эти данные уже присутствуют. Рассмотрим подробно причины этого поведения и разберем пошаговые алгоритмы решения проблемы.
Для начала проанализируем, как 1С понимает, какие данные нужно отправлять, а какие уже получены другой стороной. В основе этого механизма лежат два реквизита каждого узла в плане обмена: НомерОтправленного и НомерПринятого.
Когда мы создаем «Начальный образ» для периферийного узла, в новой базе счетчики обнуляются. Однако в центральной базе запись об этом узле сохраняет старые значения счетчиков. Например, до свертки ЦБ отправила 500 сообщений. В ЦБ для этого узла НомерОтправленного равен 500. Когда свежесозданная ПБ присылает свой первый файл обмена с номером 1, ЦБ видит, что она ждет сообщение с номером, следующим за последним полученным. Если в ЦБ НомерПринятого все еще значится как 499, то сообщение с номером 1 будет проигнорировано или вызовет ошибку в логике подтверждения.
Проанализируем ситуацию: пока центральная база не получит от периферийной базы подтверждение (квитанцию), что сообщение с определенным номером принято, ЦБ не снимет регистрацию с объектов. В результате при каждом следующем обмене ЦБ будет пытаться снова и снова выгрузить все те данные, которые «висят» в регистрации.
Свертка базы — это процесс удаления старых документов и создания новых документов ВводОстатков. С точки зрения системы обмена, это колоссальное изменение данных. Все созданные документы остатков автоматически регистрируются к выгрузке на все узлы.
Если объем этих данных велик (сотни мегабайт в XML), то при обмене может возникнуть таймаут или нехватка оперативной памяти. Если процесс обмена прерывается до того, как база-приемник отправит ответное сообщение с подтверждением получения, регистрация в базе-источнике не очищается. В следующий раз система опять начнет упаковывать те же 700 Мб, что создает бесконечный цикл бесполезной нагрузки на сервер.
Самый эффективный способ синхронизировать узлы «с нуля» — это принудительно обнулить номера сообщений в обеих базах. Выполним это с помощью небольшого фрагмента кода. В центральной базе нам нужно найти соответствующий узел плана обмена и выполнить следующую операцию:
УзелОбъект = ПланыОбмена.ПоОрганизациям.НайтиПоКоду("КодВашегоУзла").ПолучитьОбъект();
УзелОбъект.НомерОтправленного = 0;
УзелОбъект.НомерПринятого = 0;
УзелОбъект.Записать();
Аналогичную процедуру рекомендуется провести и в периферийной базе. После того как в обеих базах счетчики станут равны 0, первый же успешный обмен установит их в значение 1, и механизм подтверждения регистрации заработает корректно. Важно помнить, что НомерПринятого в ЦБ должен соответствовать НомеруОтправленного в ПБ (и наоборот) после завершения цикла приема-передачи.
В типовой конфигурации «Управление торговлей 10.3» предусмотрена встроенная обработка для управления регистрацией. Рассмотрим подробнее, как с ней работать, чтобы остановить бесконечную выгрузку:
Ввод остатков), это и есть причина тяжелого файла обмена.Важный нюанс: как отметил автор в сообщении №3, часто путают кнопки «Зарегистрировать все» и «Удалить регистрацию». Если нажать «Зарегистрировать все», то база попытается выгрузить вообще всю свою конфигурацию и все данные, что только усугубит проблему.
Если данные действительно нужно передать, но файл слишком велик для одного сеанса, проанализируем ситуацию и предпримем следующие шаги:
1. Тестирование и исправление: Перед созданием образа или проведением масштабного обмена обязательно выполним ТестированиеИИсправление (ТиИ) в конфигураторе. Особое внимание уделим пунктам «Проверка логической целостности» и «Очистка ссылок на несуществующие объекты». Битые ссылки после свертки могут приводить к ошибкам при сериализации данных в XML.
2. Отключение регламентных заданий: На время первого тяжелого обмена в платформе 8.3 рекомендуется временно отключить фоновые задания (такие как полнотекстовый поиск или автоматическое обновление индексов). Это освободит ресурсы сервера и исключит блокировки таблиц регистрации _DataExchange_....
3. Пошаговая регистрация: Вместо выгрузки всех 700 Мб за один раз, можно удалять регистрацию всех объектов и регистрировать их частями (например, сначала справочники, затем документы по годам). Это позволит сообщениям успешно проходить через транспортные каналы и получать подтверждения в ЦБ.
В исключительных случаях, когда стандартная обработка зависает из-за огромного количества записей в таблицах регистрации, можно прибегнуть к очистке на уровне базы данных SQL. Таблицы регистрации изменений в 1С имеют префикс _DataExchange_.
Выясним причину долгого удаления: при стандартном методе 1С удаляет записи транзакционно, что порождает огромный лог транзакций в SQL. Прямая очистка таблиц через TRUNCATE TABLE в SQL Management Studio (только для таблиц регистрации конкретного узла!) мгновенно очищает очередь выгрузки. Внимание: этот метод требует глубокого понимания структуры базы данных 1С и должен выполняться только после создания резервной копии.
Для исправления проблемы бесконечного обмена в УТ 10.3 выполним следующую последовательность действий: обнулим счетчики в ЦБ программным кодом, удалим лишнюю регистрацию изменений через типовую обработку и убедимся, что номера сообщений синхронизировались после первого успешного цикла «Выгрузка-Загрузка». Помните, что залог стабильного обмена — это получение центральной базой подтверждения от периферийной, что позволяет системе очистить таблицу изменений.