В процессе эксплуатации крупных информационных баз на платформе 1С:Предприятие 8.3 администраторы часто сталкиваются с проблемой критически долгого времени обновления конфигурации. Традиционный механизм реструктуризации (v1) работает путем полного пересоздания таблиц, что на базах объемом в сотни гигабайт может занимать десятки часов. Для решения этой проблемы компания 1С представила оптимизированный механизм реструктуризации второго поколения (v2). В этой статье мы подробно разберем, как работает этот механизм, как его правильно настроить и с какими трудностями можно столкнуться при его использовании.
Разберем, почему старый метод работает медленно. В режиме v1 платформа при любом изменении структуры таблицы (например, добавлении нового реквизита) выполняет следующие действия:
Этот процесс требует двойного объема дискового пространства (оценить которое поможет SQL Базомер) и генерирует колоссальную нагрузку на дисковую подсистему и логи транзакций СУБД. Проанализируем, что предлагает механизм v2. Он максимально использует нативные команды СУБД, такие как ALTER TABLE. Если операция позволяет (например, добавление колонки, допускающей значение NULL), СУБД выполняет ее почти мгновенно на уровне метаданных, не переписывая физически гигабайты данных.
Механизм v2 не включен по умолчанию и требует определенного окружения. Рассмотрим шаги по подготовке сервера:
1. Установка Java. Для работы механизма на сервере 1С должна быть установлена среда Java Runtime Environment (JRE) или JDK версии 11 или выше (обязательно 64-битная). Это связано с тем, что логика планирования реструктуризации в новом режиме вынесена в отдельный Java-процесс.
2. Настройка переменных окружения. Необходимо убедиться, что путь к исполняемому файлу Java добавлен в системную переменную PATH, либо явно указать его в файле конфигурации сервера conf.cfg.
3. Включение механизма. Для активации режима v2 в файле conf.cfg (который обычно находится в каталоге установленной платформы в папке conf) необходимо добавить следующую строку:
UpdateMode=v2
JavaRoot=C:\Program Files\Java\jdk-11
Также этот параметр можно передать в строке соединения с информационной базой или указать в дополнительных параметрах запуска в консоли кластера серверов 1С.
На основе опыта участников обсуждения выясним, в каких ситуациях v2 дает наибольший прирост производительности:
1C:Бухгалтерия и 1С:ERP) скорость возрастает в разы. Известны случаи, когда обновление, длившееся ранее 12 часов, завершалось за 2 часа.v1 часто «вылетает» с ошибкой, в то время как v2 проходит успешно за счет меньшего объема операций копирования.Однако стоит учитывать, что при изменении типов данных (например, если вы меняете Число на Строку), механизм все равно может прибегнуть к полному копированию таблицы, и выигрыш будет минимальным. Также важно понимать, что пересчет индексов в v2 все равно остается длительной операцией, сильно зависящей от частоты процессора.
Несмотря на технологичность, использование v2 сопряжено с серьезными рисками. Рассмотрим их подробнее, чтобы вы могли обезопасить свои данные.
Выясним важный нюанс: если база данных подвергалась ручной обрезке или манипуляциям на уровне таблиц СУБД (например, системными администраторами для экономии места), механизм v2 может выдать критическую ошибку. Это происходит из-за несоответствия ожидаемой платформой логики и физического состояния таблиц.
Проанализируем ситуацию сбоя. В режиме v2 во время реструктуризации создаются служебные таблицы с префиксом _t_. Если процесс обновления будет принудительно прерван (отключение питания, kill процесса Java или rphost), эти таблицы останутся в базе данных. Попытка запустить обновление повторно или вернуться к механизму v1 может закончиться неудачей из-за конфликта имен и «мусора» в метаданных. В таких случаях базу иногда приходится «вычищать» вручную на уровне SQL-запросов, что требует высокой квалификации.
Рассмотрим редкий, но неприятный баг, упомянутый пользователями: после успешного завершения реструктуризации v2 база может начать вести себя нестабильно. Например, попытка записи в ПланСчетов может вызывать бесконечное ожидание со стороны СУБД. Это указывает на возможные скрытые проблемы с блокировками или неконсистентность структуры, возникшую в процессе оптимизированного обновления.
Для того чтобы минимизировать риски при использовании нового механизма, рекомендуем придерживаться следующего алгоритма:
v2 наличие свежего бэкапа — это не рекомендация, а закон. Откатиться штатными средствами 1С после неудачной реструктуризации этого типа крайне сложно.TempDB (которая в режиме v2 возрастает).logs внутри каталога данных сервера 1С. Там находятся детальные логи Java-процесса, которые дадут гораздо больше информации, чем обычный журнал регистрации.v2 активно использует многопоточность, и неправильные настройки Max Degree of Parallelism могут привести к деградации производительности.Подводя итог, можно сказать, что механизм v2 — это мощный инструмент для «ультрадолгих» обновлений, который позволяет значительно сократить технологическое окно. Однако из-за меньшей надежности по сравнению с проверенным десятилетиями v1, его стоит использовать осознанно и только тогда, когда это действительно необходимо.