Рассмотрим распространенную и крайне болезненную проблему, с которой сталкиваются администраторы и разработчики при попытке свернуть распределенную информационную базу (РИБ) в конфигурации «1С:Розница 2.2». При ведении учета в течение нескольких лет объем базы данных на торговых точках разрастается до критических размеров. Назревает необходимость проведения свертки.
Однако стандартный механизм свертки в связке с активным РИБ часто преподносит неприятный сюрприз: при первой же попытке синхронизации после установки даты свертки центральная база намертво зависает, а через некоторое время аварийно завершает работу с системным сообщением «Недостаточно памяти» (Out of memory). Выясним причину этого поведения платформы и разберем по шагам полностью безопасный, эффективный алгоритм решения этой проблемы.
Проанализируем техническую сторону процесса. Когда мы запускаем штатную свертку в центральной базе (ЦБ), система производит колоссальный объем вычислений:
Поскольку в розничной торговле за несколько лет накапливаются миллионы чеков, отчетов о розничных продажах и складских документов, количество зарегистрированных изменений на узлах РИБ моментально возрастает до сотен тысяч или миллионов записей. При попытке выполнить очередной сеанс обмена файловая база данных (или даже серверный процесс при нехватке выделенных ресурсов) пытается упаковать весь этот гигантский массив удалений в один-единственный XML-файл сообщения обмена. Платформе банально не хватает адресного пространства для обработки такого объема данных в оперативной памяти (особенно если используется 32-разрядный клиент или сервер), что и приводит к падению системы с ошибкой памяти.
Некоторые специалисты на форумах предлагают отказаться от штатной свертки и пойти по пути создания «чистой» базы данных, куда вручную или с помощью обработок (например, через загрузку/выгрузку в Excel) переносятся остатки и справочники. Проанализируем риски такого подхода:
Поэтому мы настоятельно рекомендуем использовать правильный, системный метод свертки РИБ, который сохраняет целостность всех идентификаторов, но при этом избавляет систему от критических нагрузок при обменах.
Рассмотрим детальный пошаговый алгоритм, который позволяет успешно выполнить свертку без зависаний обмена и ручного переноса данных.
Перед началом любых глобальных операций необходимо зафиксировать учетное состояние всей сети:
Запускаем процедуру свертки в центральной базе на выбранную дату (например, 01.07.2019) через стандартную обработку «Свертка информационной базы». После успешного завершения процедуры в ЦБ появятся документы ввода остатков, а старые документы будут помечены на удаление.
Внимание! После завершения свертки в ЦБ ни в коем случае не запускайте синхронизацию данных! Если запустить обмен сейчас, база зависнет из-за регистрации миллионов удалений.
Чтобы избежать передачи миллионов документов на удаление в подчиненные узлы, мы должны очистить регистрацию обмена. Разберем, как это сделать:
Для гарантированной очистки регистрации изменений программным путем можно выполнить следующий код в консоли кода или внешней обработке:
Процедура ОчиститьРегистрациюДляВсехУзловРИБ() Экспорт
ВыборкаУзлов = ПланыОбмена.ПоМагазинам.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
// Пропускаем предопределенный узел (этот узел - ЦБ)
Если ВыборкаУзлов.Ссылка = ПланыОбмена.ПоМагазинам.ЭтотУзел() Тогда
Продолжить;
КонецЕсли;
// Очищаем всю регистрацию изменений по выбранному узлу
ПланыОбмена.УдалитьРегистрациюИзменений(ВыборкаУзлов.Ссылка);
// Сбрасываем номера принятых и отправленных сообщений для избежания рассинхронизации номеров пакетов
ОбъектУзла = ВыборкаУзлов.Ссылка.ПолучитьОбъект();
ОбъектУзла.НомерОтправленного = 0;
ОбъектУзла.НомерПринятого = 0;
ОбъектУзла.Записать();
КонецЦикла;
КонецПроцедуры
После выполнения этой операции центральная база больше не хранит информацию о том, что она "должна" отправить на точки миллионы помеченных на удаление документов. Обмен теперь чист.
Теперь наша задача — обновить базы данных на торговых точках так, чтобы они стали "легкими", содержали свернутые остатки и не имели в своей истории старых документов. Для этого мы создадим новые начальные образы:
Совет по оптимизации: Процесс создания начального образа РИБ крайне требователен к дисковой подсистеме и процессору. Если ваша ЦБ работает в файловом режиме, скопируйте ее временно на компьютер со скоростным NVMe SSD-накопителем и мощным процессором, сформируйте все образы там, а затем верните базу назад.
После генерации начальных образов выполняем физическую замену баз на местах:
1Cv8.1CD для файловых баз) на торговые точки.Рассмотрим специфические нюансы работы конфигурации «1С:Розница», о которых необходимо помнить при свертке:
Решение: Рекомендуется делать свертку со смещением назад относительно текущей даты. Например, если свертка проводится в августе, дату свертки лучше назначить на 1 июля текущего года, оставив "хвост" документов за последние 30-45 дней нетронутым. Также помните, что в «1С:Розница» предусмотрен штатный механизм оформления возврата без чека, при котором кассир выбирает товар и указывает его цену вручную.
ЦеныНоменклатуры, из-за чего в новой базе перестают действовать скидки или не определяются розничные цены. Наш метод с генерацией нового начального образа полностью решает эту проблему: платформа 1С автоматически рассчитывает срез последних цен на дату создания образа и корректно переносит действующие цены в подчиненный узел в виде виртуальных документов ввода остатков цен.Проанализировав данную методику, мы видим, что использование штатных механизмов платформы в сочетании с ручным контролем планов обмена позволяет быстро, безопасно и без колоссальных затрат времени развернуть обновленную и быструю систему РИБ на базе «1С:Розница 2.2».