← На главную

При работе с крупными информационными базами стандартный процесс обновления конфигурации базы данных (реструктуризация) может занимать часы или даже сутки. Это происходит из-за того, что классический механизм платформы часто прибегает к полному пересозданию таблиц. В современных версиях платформы 1С:Предприятие 8.3 (начиная с 8.3.11) реализован оптимизированный механизм реструктуризации (версия 2), который позволяет значительно ускорить этот процесс. Рассмотрим подробно, как он работает, как его настроить и какие риски следует учитывать.

Принципиальные отличия механизмов реструктуризации

Для начала разберем, чем отличаются первая и вторая версии механизма, чтобы понимать причину ускорения:

1. Версия 1 (Классическая): При внесении изменений в структуру объекта (например, добавлении реквизита в справочник) платформа создает временную таблицу с новой структурой. После этого данные из старой таблицы построчно копируются в новую, старая таблица удаляется, а новая переименовывается. Это требует двойного объема свободного места в СУБД и огромного количества операций записи.
2. Версия 2 (Оптимизированная): Этот механизм старается выполнить модификацию "на месте". Вместо копирования данных он генерирует команды ALTER TABLE для СУБД. Например, добавление новой колонки в MS SQL Server или PostgreSQL происходит практически мгновенно, так как СУБД просто обновляет метаданные таблицы, не трогая существующие строки данных.

Проанализируем практический пример: при обновлении конфигурации со снятием режима совместимости, когда в регистр бухгалтерии добавляется множество новых полей, обычная реструктуризация может выполняться более 24 часов, в то время как механизм v2 справляется за 20-30 минут.

Лицензионные требования: КОРП или ПРОФ

Существует распространенное заблуждение, что оптимизированная реструктуризация доступна только для лицензий уровня КОРП. Выясним реальное положение дел:

Оптимизированный механизм реструктуризации (v2) доступен на лицензиях уровня ПРОФ. Его можно включить через файл конфигурации сервера 1С.

Фоновая реструктуризация (возможность обновлять базу без выгона пользователей) — это отдельная функциональность, и вот она действительно требует лицензий уровня КОРП.

Таким образом, если у вас ПРОФ-версия, вы можете легально ускорить процесс обновления, но вам все равно потребуется монопольный доступ к базе данных.

Подготовка окружения и системные требования

Механизм версии 2 реализован с использованием языка Java, что накладывает определенные требования к серверу 1С:

• Установка Java: На сервере, где запущен процесс rphost, должна быть установлена среда выполнения Java (JRE) или пакет разработки (JDK). Рекомендуется использовать 64-битные версии (например, BellSoft Liberica, AdoptOpenJDK или Oracle JRE).
• Протоколы сетевого взаимодействия: Если вы используете Microsoft SQL Server, крайне важно, чтобы соединение осуществлялось по протоколу TCP/IP. Механизм v2 не поддерживает работу через Shared Memory (Разделяемая память) или Named Pipes (Именованные каналы). Для PostgreSQL необходимо обеспечить доступность через сетевой сокет.
• Права пользователя СУБД: Пользователь, под которым сервер 1С подключается к базе данных, должен иметь расширенные права на изменение схемы (DDL-команды), так как скрипты версии 2 работают напрямую с объектами СУБД.

Настройка включения механизма v2

Рассмотрим пошагово процесс включения оптимизированной реструктуризации. Настройка выполняется путем редактирования файла conf.cfg, который обычно располагается в каталоге C:\Program Files\1cv8\conf (для Windows) или /opt/1cv8/x86_64/conf (для Linux).

Добавьте в файл conf.cfg следующую строку:

UpdateDBCfg=v2

После изменения файла перезапуск сервера 1С обычно не требуется для подхвата этой настройки при следующем обновлении конфигурации базы данных, но в некоторых случаях (в зависимости от релиза платформы) перезагрузка службы может быть полезна для инициализации Java-окружения.

Также можно управлять ресурсами, которые потребляет Java-процесс. Если база содержит десятки тысяч объектов метаданных, Java может потребоваться больше памяти. Это настраивается через переменные окружения, например:

_JAVA_OPTIONS="-Xmx2g"

Риски и особенности эксплуатации

Несмотря на высокую скорость, механизм версии 2 считается более агрессивным и менее "защищенным" от сбоев, чем классический. Разберем основные риски:

1. Отсутствие автоматического отката. Если классическая реструктуризация прерывается, СУБД просто не фиксирует транзакцию, и у вас остаются старые таблицы. В режиме v2 изменения вносятся в реальные рабочие таблицы. Если процесс упадет из-за ошибки в скрипте в середине транзакции, база может остаться в "битом" состоянии. Наличие свежего бэкапа перед использованием v2 обязательно!

2. Ошибка "зацикливания" при сортировке реквизитов. Известна проблема в некоторых релизах платформы: если вы добавили новый реквизит в объект и одновременно изменили порядок (сортировку) существующих реквизитов, Java-движок может уйти в бесконечный цикл или упасть с кодом возврата 1. В этом случае рекомендуется:

1. Сначала просто добавить реквизит и выполнить обновление по v2.
2. Затем изменить порядок реквизитов и выполнить обновление (возможно, переключившись временно на v1).

3. Логирование процесса. Пользователи часто жалуются, что в окне 1С не отображается прогресс выполнения. На самом деле детальные логи пишутся в каталог временных файлов пользователя, под которым работает сервер 1С (rphost). Ищите файлы с маской v8_..._restruct.log. Там можно увидеть все SQL-запросы, которые платформа отправляет в СУБД. Для расшифровки технических имен таблиц и полей из лога пригодится обработка для перевода SQL-запросов в термины метаданных 1С.

Выводы

Оптимизированный механизм реструктуризации — мощный инструмент для администраторов больших баз. Рассмотрим основные шаги для его внедрения:

1. Установите 64-битную Java на сервере.
2. Убедитесь, что СУБД настроена на работу по TCP/IP.
3. Добавьте UpdateDBCfg=v2 в conf.cfg.
4. Всегда делайте архивную копию перед обновлением! Для регулярного создания резервных копий перед проведением работ пригодится автоматическое архивирование и обновление баз 1С по расписанию.

Применение этого подхода позволит вам сократить технологические окна обслуживания баз с нескольких часов до считанных минут, что критично для бизнеса в условиях высокой нагрузки.