Обновление крупных баз данных, таких как 1С:Управление холдингом, часто становится серьезным испытанием для администраторов и программистов. При переходе с версии 3.0 на 3.2 происходит значительное изменение архитектуры подсистем бюджетирования, что влечет за собой запуск «тяжелых» обработчиков обновления. Часто стандартного технологического окна выходных не хватает для завершения всех операций. Рассмотрим комплекс мер, которые помогут нам уложиться в отведенные сроки.
Прежде всего, проанализируем, на чем именно спотыкается процесс. В 1С:УХ 3.2 основная нагрузка ложится на регистр накопления ОперацииБюджетов. Если мы перескакиваем через много релизов сразу, обработчики могут пытаться пересчитать данные за несколько лет. Разберем по шагам, что нужно сделать на копии базы перед основным обновлением:
ВерсииОбъектов. Каждая запись документа обработчиком обновления может порождать новую версию в истории, что колоссально замедляет процесс.Часто серверное оборудование, рассчитанное на многопоточную работу 100+ пользователей, оказывается неэффективным в монопольном режиме обновления. Выясним причину: 1С во многих операциях обновления использует одно ядро процессора. Поэтому для ускорения нам нужно не количество ядер, а их максимальная частота.
Рассмотрим настройки MS SQL Server, которые могут ускорить запись данных в 2–5 раз:
DELAYED_DURABILITY = FORCED. Это позволит системе не ждать подтверждения записи лога на диск для каждой мелкой транзакции. Важно: этот режим следует использовать только на время обновления.TempDB вынесены на самый быстрый NVMe-диск и их количество соответствует рекомендациям (обычно 8 файлов).Max Degree of Parallelism = 1 для базы на время реструктуризации, чтобы избежать избыточных блокировок.Проанализируем возможности самой платформы и конфигурации. Мы можем вмешаться в процесс обновления следующими способами:
Отключение итогов и индексов: Перед запуском массовой записи в регистр ОперацииБюджетов программно отключим использование итогов. Это исключит затраты ресурсов на их пересчет при каждой записи. После завершения обработчиков итоги нужно включить и пересчитать заново.
Управление многопоточностью: В настройках программы (раздел «Обслуживание» — «Результаты обновления») проверим количество потоков. Для мощных систем можно увеличить это значение (например, до 24 или даже 64 потоков), если обработчики поддерживают параллельное выполнение.
Группировка транзакций: Если мы правим код типовых обработчиков, разберем пример того, как втиснуть запись нескольких объектов в одну транзакцию. Вместо записи каждого документа по отдельности, будем фиксировать транзакцию каждые 1000 объектов:
НачатьТранзакцию();
Счетчик = 0;
Для Каждого ДокументОбъект Из МассивДокументов Цикл
ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);
Счетчик = Счетчик + 1;
Если Счетчик % 1000 = 0 Тогда
ЗафиксироватьТранзакцию();
НачатьТранзакцию();
КонецЕсли;
КонецЦикла;
ЗафиксироватьТранзакцию();
Если технические методы не помогают уложиться в 48 часов, рассмотрим более сложные, но эффективные стратегии:
Используем встроенную утилиту автономной реструктуризации (на базе Java), которая появилась в платформе 8.3.18+. Она позволяет выполнять изменение структуры таблиц более эффективно и иногда параллельно работе пользователей.
Посмотрим на стратегию «Клонирования»:
Наилучший результат дает сочетание быстрого железа (высокая частота ЦП + NVMe) и настроек SQL (Delayed Durability). Если и это не помогает, следует планировать переход на праздничные дни (например, новогодние каникулы), когда технологическое окно расширяется до нескольких дней, что позволит завершить все фоновые процессы без остановки бизнеса.