Многие разработчики, перешедшие на платформу 1С:Предприятие версии 8.3.25 (например, 8.3.25.1445), столкнулись с непривычным поведением системы при обновлении конфигурации базы данных. Процесс реструктуризации таблиц стал проходить значительно быстрее, а привычный счетчик обрабатываемых строк, который позволял визуально контролировать процесс, перестал появляться. Попытки принудительно включить старый механизм через параметр UpdateDBCfg=v1 в файле conf.cfg не приносят результата. Давайте разберемся, что происходит, почему так себя ведет платформа и является ли это штатным поведением.
Чтобы понять суть изменений, проанализируем, как работали оба механизма реструктуризации.
Механизм v1 (старый)
Этот способ можно описать как потабличное копирование данных. Когда в структуру таблицы вносились изменения (например, добавлялся новый реквизит), платформа выполняла следующую последовательность действий:
Этот метод считался надежным, так как до самого конца операции исходные данные оставались нетронутыми. Однако у него были серьезные недостатки: высокая нагрузка на диск и сеть, медленная работа на больших таблицах и значительное разрастание лога транзакций СУБД.
Механизм v2 (новый)
Начиная с версии 8.3.25, платформа внедряет новый, более эффективный механизм. Его главная идея — перенести максимум операций на сторону сервера СУБД, избегая перекачки больших объемов данных на сервер 1С и обратно. Вместо копирования данных платформа теперь стремится выполнить одну или несколько команд языка SQL, которые напрямую меняют структуру таблицы. Например, для добавления новой колонки используется команда ALTER TABLE ... ADD COLUMN ....
Ключевые преимущества нового подхода:
Отсутствие счетчика строк — прямое следствие работы этого механизма. Раз данные не копируются построчно, то и считать нечего. Процесс происходит "под капотом" на уровне СУБД.
Проанализировав поведение системы, можно сделать вывод, что платформа стала "умнее". Она сама анализирует характер изменений в конфигурации и выбирает наиболее оптимальный способ реструктуризации.
Для простых и безопасных операций, таких как добавление нового реквизита простого типа (Строка, Число, Дата и т.д.), платформа определяет, что можно безопасно использовать команду ALTER TABLE. В этом случае она отдает приоритет новому, быстрому механизму v2, даже если в конфигурационном файле принудительно указан UpdateDBCfg=v1.
Однако старый механизм v1 никуда не делся. Платформа автоматически переключается на него в сложных случаях, когда простого изменения структуры таблицы недостаточно. Характерный пример, подмеченный в обсуждении на форуме, — изменение составного типа данных (например, удаление одного из типов в реквизите). Такая операция требует анализа и преобразования данных в каждой строке, поэтому платформа использует старый, надежный метод с построчным копированием, и в этот момент вы снова увидите знакомый счетчик строк.
Важный технический нюанс, без которого новый механизм реструктуризации не будет работать, — это наличие на сервере 1С:Предприятия установленной и доступной Java Runtime Environment (JRE). Управляющий код нового механизма использует Java для взаимодействия с СУБД.
Если сервер 1С (процесс rphost.exe) при попытке реструктуризации не сможет найти подходящую среду выполнения Java, он автоматически переключится на старый механизм v1. Это объясняет, почему у некоторых пользователей даже на новой платформе все еще может появляться счетчик строк при простых операциях.
Как проверить, используется ли Java?
java.exe, запущенный от имени пользователя, под которым работает сервер 1С, значит, новый механизм v2 успешно задействован.Основная причина, по которой разработчики хотят вернуть старый режим, — это ощущение большей безопасности. Процесс копирования был прозрачным и оставлял исходные данные нетронутыми до последнего шага. Новый механизм, работающий через ALTER TABLE, изменяет "живую" таблицу, что вызывает опасения.
На практике, для тех операций, для которых платформа его применяет, он является атомарным и безопасным на уровне СУБД. Фирма "1С" не стала бы делать его поведением по умолчанию, если бы он нес существенные риски. Преимущества в скорости для современных высоконагруженных систем перевешивают мнимые риски.
UpdateDBCfg=v1 в conf.cfg больше не является гарантией использования старого метода для всех случаев.Таким образом, беспокоиться не о чем. Система стала работать эффективнее, и к этому новому поведению просто нужно привыкнуть, понимая его внутреннюю логику.