Переход с конфигурации «Комплексная автоматизация» редакции 2.4 на 2.5 — это не просто очередное обновление, а масштабная трансформация архитектуры данных. Изменения затрагивают фундаментальные механизмы учета: распределение запасов, расчет себестоимости и ведение взаиморасчетов. В связи с этим многие системные администраторы и программисты сталкиваются с тем, что отложенные обработчики обновления выполняются крайне долго — иногда более суток, а логи транзакций SQL-сервера разрастаются до невероятных размеров, съедая все свободное место на дисках.
В этой статье мы подробно разберем, как оптимизировать этот процесс, на какие настройки обратить внимание и как минимизировать время простоя системы. Рассмотрим пошагово все технические аспекты этой задачи.
Давайте разберем, почему процесс занимает так много времени. В редакции 2.5 полностью пересмотрена логика работы с регистрами накопления. Основным «узким местом» является регистр РаспределениеЗапасов. Система должна пересчитать все остатки и резервы по новой методике за весь период ведения учета в базе. Если база данных содержит информацию за несколько лет, количество записей, подлежащих обработке, может исчисляться миллионами.
Кроме того, в процессе обновления задействованы механизмы Библиотеки стандартных подсистем (БСП). Если параметры БСП не настроены под конкретное серверное оборудование, система может выполнять задачи в один поток, что крайне неэффективно для современных многоядерных процессоров.
Современные версии 1С позволяют регулировать количество потоков для выполнения отложенного обновления. Это один из самых действенных способов сократить время обработки. Давайте проанализируем, как это сделать:
Количество ядер процессора минус 1 или 2. Например, если на сервере 8 ядер, смело ставим 6 потоков.Важный нюанс: Не стоит выставлять слишком большое количество потоков (больше, чем ядер процессора), так как это может привести к блокировкам таблиц в SQL (так называемым deadlocks) и, наоборот, замедлить процесс из-за постоянных ожиданий доступа к данным.
Огромный рост лога транзакций (LDF-файла) — типичная проблема при выполнении сотен обработок. Чтобы база не «забила» всё свободное место (как в описанном случае с 70-80 ГБ), выполним следующие действия на стороне MS SQL Server:
TempDB. Поскольку обработки активно используют временные таблицы, диск, на котором расположен TempDB, должен быть максимально быстрым (желательно NVMe/SSD).Как мы уже выяснили, регистр РаспределениеЗапасов — главная причина задержек. Чтобы ускорить его заполнение, проанализируем следующие рекомендации:
Часто возникает вопрос: можно ли начинать работу, не дожидаясь окончания всех 500-600 заданий? Разберем ситуацию подробнее. Технически, система позволяет войти в базу после завершения монопольных обработчиков (которые выполняются при первом запуске программы или в конфигураторе). Однако работа пользователей при запущенных отложенных обработчиках несет риски:
Рекомендация: Если время поджимает, можно разрешить работу в ограниченном режиме (например, только просмотр или ввод документов, не связанных с блоками, которые сейчас обновляются). Статус выполнения каждой области можно отслеживать в форме Результаты обновления данных.
Для контроля процесса мы рекомендуем использовать внешнюю обработку ОбновлениеИнформационнойБазы.epf, которая обычно входит в состав дистрибутива БСП. С ее помощью можно:
Если вам необходимо программно проверить, остались ли незавершенные обработчики, можно воспользоваться методами БСП. Проанализируем пример кода, который возвращает количество невыполненных заданий:
Функция ПроверитьСтатусОбновления() Экспорт
Статус = ОбновлениеИнформационнойБазы.СтатусИнформационнойБазы();
Если Статус.Статус = "Выполняется" Тогда
КоличествоОставшихся = Статус.КоличествоОбработчиков - Статус.КоличествоВыполненныхОбработчиков;
Возврат СтрШаблон("Осталось выполнить %1 обработок", КоличествоОставшихся);
КонецЕсли;
Возврат "Обновление завершено";
КонецФункции
Использование подобных проверок помогает автоматизировать мониторинг процесса и вовремя реагировать на возникающие проблемы.
Чтобы успешно перейти с КА 2.4 на 2.5 за одну ночь, необходимо действовать комплексно: заранее подготовить SQL-сервер, настроить многопоточность в настройках БСП и обязательно использовать максимально свежий релиз целевой конфигурации с установленными патчами. Помните, что качественная подготовка и анализ инфраструктуры — залог быстрого обновления без потери данных и простоев в работе бизнеса.