← На главную
Переход на новую редакцию или установка комплексного релиза в крупных бажах 1С, таких как 1С:Управление торговлей или 1С:ERP, нередко занимает десятки часов. Если регламентного окна в 12 часов недостаточно для выполнения всех постобработчиков обновления, предприятие рискует столкнуться с простоем. Проанализируем ключевые факторы, замедляющие процесс конвертации данных, и разберем по шагам, как оптимизировать процедуру обновления.
Анализ узких мест и отключение фоновой нагрузки
Перед началом процедуры важно максимально разгрузить систему от паразитных операций записи и фоновых вычислений. Рассмотрим первоочередные действия:
- Остановка регламентных и фоновых заданий. Во время выполнения обработчиков обновления типовые фоновые задания (обмен данными, рассылка отчетов, расчеты) создают избыточные блокировки таблиц и конкурируют за ресурсы диска и процессора. Регламентные задания необходимо заблокировать через консоль администрирования кластера 1С или параметры базы.
- Отключение или сокращение журнала регистрации. При массовой модификации справочников (например,
Справочник.Партнеры) и документов (Документ.РеализацияТоваровУслуг) запись каждого события в журнал регистрации существенно нагружает дисковую подсистему. На период обновления рекомендуется временно перевести регистрацию событий в режим Регистрировать только ошибки или полностью отключить ведение журнала. - Отключение полнотекстового поиска данных (ППС). Массовая перезапись объектов приводит к постоянной переиндексации полнотекстового поиска. Отключение регламентного задания индексации и очистка индекса ППС перед стартом обновления заметно ускоряют запись данных.
Очистка и вынос избыточных служебных данных
Разберем ситуацию, когда таблицы метаданных содержат миллионы устаревших записей, обрабатываемых механизмами БСП при переходе между редакциями.
Один из самых тяжелых объектов — регистр сведений ВерсииОбъектов (история версионирования). Если регистр содержит большой объем данных, механизмы обновления тратят часы на проверку ссылочной целостности и конвертацию.
На практике применяют следующую схему оптимизации средствами СУБД:
- Таблица регистра
ВерсииОбъектов копируется во временную таблицу на уровне MS SQL Server. - Основная таблица регистра очищается командой
TRUNCATE TABLE. - Выполняется обновление конфигурации и обработка данных на пустом регистре.
- После завершения всех процедур данные переносятся обратно из временной таблицы в рабочий регистр.
Настройка механизмов БСП и отложенного обновления
В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) процедуры обновления разделены на обязательные (выполняемые монопольно до запуска пользователей) и отложенные (выполняемые в фоновом режиме).
Рассмотрим, как управлять этим процессом:
- Многопоточность обработчиков. В обработке
Результаты обновления программы проверьте количество назначенных потоков. Увеличение числа параллельных фоновых заданий позволяет загрузить свободные ядра сервера и ускорить обработку независимых процедур. - Приоритет обновления. Если требуется быстрее предоставить доступ сотрудникам, отложенные обработчики можно перевести в режим работы
С приоритетом работы пользователей, запустив систему в продуктив сразу после завершения монопольной фазы. - Контроль зависших процедур. Если конкретный шаг обновления зависает из-за некорректных данных, через интерфейс администратора БСП можно перезапустить или принудительно завершить проблемную процедуру для детального ручного разбора.
Оптимизация СУБД и перенос на производительный контур
Выясним причину аппаратных задержек и параметры сервера СУБД, критичные для скорости перезаписи таблиц:
- Модель восстановления (Recovery Model). На время массовых обновлений в MS SQL Server рекомендуется переключить базу данных в режим
Simple (Простая модель восстановления). Это предотвращает взрывной рост файла транзакций .ldf и ускоряет фиксацию изменений. - Настройка базы TempDB. Процедуры БСП активно используют временные таблицы. Файлы
TempDB должны быть размещены на высокоскоростных NVMe-накопителях и разделены на несколько файлов данных по числу процессорных ядер сервера. - Актуализация статистик. Перед запуском обновления выполните полную реиндексацию и обновление статистик базы данных, чтобы оптимизатор СУБД строил эффективные планы запросов без лишних сканирований таблиц (Table Scan).
- Обновление на отдельном стенде. Если сервер предприятия не справляется с объемом за отведенное время, базу выгружают на выделенный мощный сервер с быстрой дисковой подсистемой и высокочастотным процессором. После завершения обновления база возвращается в рабочий контур.
Альтернативный сценарий: выгрузка и догрузка изменений
Когда объем данных не позволяет уложиться в выходные, применяют схему с переносом дельты:
- Создается копия рабочей базы данных, на которой процесс обновления выполняется заранее без жестких ограничений по времени.
- В момент технического перерыва на исходной базе фиксируются новые и измененные документы, созданные пользователями за время выполнения тестового обновления.
- С помощью планов обмена или механизмов универсальной выгрузки данных дельта переносится в обновленную базу, после чего обновленная база вводится в эксплуатацию с минимальным временем простоя.