В процессе эксплуатации крупных информационных систем на платформе 1С:Предприятие 8.3 администраторы и разработчики часто сталкиваются с проблемой длительной реструктуризации базы данных. Традиционный механизм (версия 1) при внесении изменений в структуру таблиц часто прибегает к созданию временных таблиц, переливанию в них всех данных, удалению старых объектов и переименованию новых. Это требует двойного объема дискового пространства и занимает огромное количество времени. Начиная с версии платформы 8.3.11, появился оптимизированный механизм реструктуризации (v2). Разберем подробно, как его активировать и убедиться, что он действительно работает.
Прежде чем переходить к настройке, проанализируем, в чем заключается профит от версии 2. Основная идея «нового» механизма заключается в минимизации использования временных таблиц. Система старается максимально использовать нативные команды СУБД, такие как ALTER TABLE. Рассмотрим ситуацию: нам нужно добавить новый реквизит в документ, в котором уже накоплено несколько миллионов записей.
В режиме v1 платформа создаст полную копию таблицы документа, что приведет к росту файла базы данных и длительному ожиданию завершения транзакции. В режиме v2 платформа выполнит прямую SQL-команду добавления колонки, что в современных СУБД (MS SQL Server, PostgreSQL) происходит практически мгновенно, если не задано значение по умолчанию.
Для активации механизма нам необходимо внести изменения в файл conf.cfg. Важно помнить, что этот файл находится в каталоге установленной платформы. Рассмотрим стандартный путь для 64-битной версии Windows:
C:\Program Files\1cv8\conf\conf.cfg
В этот файл необходимо добавить следующую строку:
UpdateDBCfg=v2
Обратите внимание, что если у вас установлено несколько версий платформы, настройку следует вносить либо в общий файл в папке conf, либо проверять настройки для конкретной версии. Если параметр не указан, система по умолчанию использует старый метод (v1), что подтверждается официальной документацией «Руководство администратора».
Выясним важную техническую деталь: механизм v2 не является частью бинарного кода самого сервера 1С в чистом виде. Для расчета плана реструктуризации используется отдельный модуль, написанный на Java. Рассмотрим требования к окружению:
rphost, должна быть установлена среда выполнения Java (JRE) или Java Development Kit (JDK) версии 8 или выше.PATH, либо платформа должна иметь возможность найти его автоматически.Если Java отсутствует, система при попытке обновления конфигурации БД может либо выдать ошибку, либо (что чаще) молча «откатиться» к использованию старого механизма v1, и вы не получите ожидаемого ускорения.
Теперь разберем, как правильно инициировать процесс. Механизм v2 предназначен в первую очередь для работы в клиент-серверном варианте. Чтобы задействовать оптимизацию, недостаточно просто нажать клавишу F7 в Конфигураторе. Необходимо выполнить следующие действия:
Именно этот режим запускает серверный процесс анализа изменений, который использует Java-модуль и настройки UpdateDBCfg=v2.
Проанализируем ситуацию: вы внесли изменения в конфиг, поставили Java и запустили обновление. Как понять, что магия сработала? Существует три основных способа проверки.
Способ 1. Окно сообщений в Конфигураторе
Это самый простой визуальный метод. При запуске обновления на сервере внимательно следите за выводом в окне сообщений (внизу экрана). Если все настроено верно, первой строкой вы увидите:
«Применяется новый механизм реструктуризации»
Если этой фразы нет, значит, система по какой-то причине (отсутствие Java, ошибка в conf.cfg, локальный запуск) вернулась к старому методу.
Способ 2. Технологический журнал (ТЖ)
Для детального анализа мы можем настроить сбор событий технологического журнала. Нас интересует событие DBV2. Рассмотрим пример настройки logcfg.xml:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<log location="C:\LOGS\DBV2" history="24">
<event>
<eq property="name" value="DBV2"/>
</event>
<property name="all"/>
</log>
</config>
Если после обновления в указанном каталоге появились логи, значит, механизм v2 активен. В логах будет подробно описано, какие изменения метаданных были обнаружены и какие SQL-запросы сформированы.
Способ 3. SQL Profiler (для MS SQL Server)
Если мы хотим убедиться «на уровне железа», запустим профайлер СУБД. При использовании механизма v1 мы увидим создание таблиц типа #v8_tmp_... и массовые операции INSERT INTO ... SELECT FROM. При использовании v2 мы увидим прямые команды ALTER TABLE. Это окончательное доказательство работы оптимизации.
Посмотрим на ситуацию реалистично: v2 — это не панацея, и у него есть свои особенности:
Число в Строка), платформа все равно может создать временную таблицу, так как простая конвертация на уровне СУБД может привести к потере данных или ошибкам.Рассмотрим пример того, как система ведет себя при изменении длины строки. Предположим, у нас есть реквизит НаименованиеПолное с длиной 150 символов, и мы увеличиваем её до 250.
В режиме v1: Платформа создаст копию всей таблицы справочника, перенесет данные, удалит старую таблицу. Время выполнения на таблице в 100 Гб может составить часы.
В режиме v2: Платформа выполнит ALTER TABLE ... ALTER COLUMN. Время выполнения — секунды, так как СУБД просто обновит описание колонки в системном каталоге, не трогая сами данные на диске.
Таким образом, использование механизма реструктуризации v2 является критически важным для администраторов крупных баз данных. Правильная настройка conf.cfg, наличие Java и контроль через окно сообщений позволят значительно сократить время технологических окон при обновлении информационных систем.