Ситуация, когда процесс обмена в распределенной информационной базе (РИБ) доходит до отметки 95–99% и «замирает» без видимых ошибок, является одной из самых сложных для диагностики. В конфигурации 1С:Управление торговлей 11.4 это часто связано не с передачей самих файлов, а с пост-процессинговыми механизмами, которые запускаются сразу после загрузки данных. Разберем детально, почему это происходит и какие шаги необходимо предпринять для локализации проблемы.
Первым делом нам необходимо исключить ситуацию, при которой программа на самом деле работает, но делает это очень медленно. Зачастую «зависание» — это лишь длительное выполнение тяжелой транзакции. Проанализируем Журнал регистрации. Для этого откроем его в принимающем узле и установим фильтр по событию ОбменДанными.
Если в журнале зафиксированы записи о начале загрузки, но нет записи о завершении или ошибке, это подтверждает, что транзакция все еще открыта. Рассмотрим, какие сообщения могут указывать на проблему: ошибки блокировок, превышение времени ожидания запроса или конфликты прав доступа. Оставим обмен запущенным на длительное время (например, на ночь) — в конечном итоге система либо завершит процесс, либо выдаст критическую ошибку, которая будет зафиксирована в журнале.
Одной из наиболее эффективных техник диагностики является изменение параметров загрузки данных. Если стандартный обмен «валится» или виснет на большом пакете данных, нам нужно понять, на каком именно объекте происходит сбой. Проанализируем метод изменения размера транзакции.
В настройках синхронизации данных (или через программное изменение узла плана обмена) установим параметр Количество элементов в транзакции равным 1. По умолчанию 1С загружает объекты большими порциями (по 200–500 штук), и если в одном из них есть ошибка в коде (например, в обработчике ПередЗаписью или ПриЗаписи), откатывается вся порция, либо процесс зацикливается.
Установив значение 1, мы заставим систему записывать каждый объект по отдельности. Это позволит:
В современных конфигурациях на базе БСП, таких как УТ 11.4, после фактического приема данных система инициирует процедуры отложенного обновления. Это необходимо для актуализации регистров, пересчета итогов или заполнения новых реквизитов, которые появились в результате обновления версии программы. Выясним причину, проверив этот раздел.
Перейдем в раздел НСИ и администрирование — Обслуживание — Обновление программы — Результаты обновления. Если в списке есть невыполненные дополнительные процедуры обработки данных, обмен может блокироваться ими. Попробуем дождаться их завершения или запустить их принудительно. Пока эти процедуры не завершены, попытки проведения документов в рамках обмена могут приводить к бесконечным ожиданиям блокировок.
Часто проблема кроется в некорректном состоянии конфигурации на конкретном рабочем месте или сервере. Рассмотрим ситуацию с «Динамическим обновлением». Если в центральной базе изменения вносились без монопольного захвата, конфигурация базы данных может разойтись с основной конфигурацией. РИБ крайне чувствителен к таким расхождениям.
Для решения этой проблемы выполним следующие действия:
F7) в монопольном режиме.%AppData%\Local\1C\1Cv8 и %AppData%\Roaming\1C\1Cv8.Если визуально обмен стоит на 95%, мы можем программно посмотреть, чем занят процесс. Запустим базу в режиме отладки и откроем Замер производительности. Начнем замер в момент, когда полоска прогресса дошла до критической отметки. Спустя минуту остановим замер и проанализируем таблицу.
Мы увидим, какая функция или процедура занимает больше всего времени. Часто виновником оказывается бесконечный цикл в коде или тяжелый запрос к регистрам накопления. Например, если в документе реализована сложная логика в модуле объекта:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
// Проверим, не заходит ли сюда управление при обмене
// Иногда разработчики забывают ставить эту проверку,
// и тяжелые расчеты выполняются при каждой загрузке объекта
Возврат;
КонецЕсли;
КонецПроцедуры
Проанализируем наличие конструкции ОбменДанными.Загрузка во всех подписках на события и модулях объектов. Если её нет, то при загрузке 1500 документов система будет пытаться выполнить их полную проверку и пересчет, что и создает эффект «зависания».
На финальном этапе записи транзакции 1С выполняет пересчет итогов. Если база большая, а таблицы регистров «раздуты», этот процесс может занимать часы. Посмотрим на состояние итогов: попробуем временно отключить использование итогов для регистров через Управление итогами и повторить обмен. Если загрузка пройдет успешно — значит, база требует оптимизации (свертки или пересчета итогов на актуальную дату).
Также стоит обратить внимание на Полнотекстовый поиск (ППС). При массовой загрузке данных система пытается их проиндексировать. Рекомендуем полностью отключить ППС в настройках администрирования перед началом обмена, чтобы высвободить ресурсы системы.
Если база файловая, проанализируем размер файла 1Cv8.1cd. При достижении одной из внутренних таблиц (например, ENTRY или DOCUMENT) размера в 4 ГБ, база перестает принимать данные. В этом случае внешне все выглядит как зависание. Обязательно воспользуемся утилитой chdbfl.exe для проверки физической целостности таблиц базы данных. Иногда повреждение индекса таблицы планов обмена мешает зафиксировать номер принятого сообщения, что приводит к невозможности завершить транзакцию.
Резюмируя: последовательно проверяйте Журнал регистрации, отключайте тяжелые фоновые процессы, используйте отладку с замером производительности и обязательно ограничивайте размер транзакции до одного объекта для поиска «битых» данных.