← На главную

Механизм реструктуризации версии 2 (V2) — это одно из наиболее значимых технологических обновлений платформы «1С:Предприятие», начиная с версии 8.3.11. Основная цель этого механизма — кардинальное сокращение времени простоя системы при обновлении конфигурации базы данных. В отличие от старого метода (V1), который блокировал таблицы на все время преобразования данных, версия V2 позволяет выполнять большую часть работы в фоновом режиме.

Однако на практике системные администраторы и разработчики часто сталкиваются с тем, что даже после внесения необходимых настроек система продолжает использовать старый механизм. Разберем по шагам, как правильно активировать V2, какие требования предъявляются к среде и как устранить типичные ошибки настройки.

Основные требования для работы механизма V2

Перед тем как приступать к правке конфигурационных файлов, нам необходимо убедиться, что серверная среда соответствует минимальным системным требованиям. Механизм V2 не является «простой надстройкой», это сложный программный комплекс, использующий внешние компоненты.

1. Версия платформы и режим совместимости: Механизм доступен в платформе, начиная с версии 8.3.11. Важно понимать, что режим совместимости конфигурации также должен быть установлен не ниже 8.3.11. Если ваша конфигурация работает в режиме совместимости 8.3.10 или ниже, платформа автоматически откатится к использованию старого механизма (V1), даже если в настройках прописано обратное.
2. Наличие Java Runtime Environment (JRE): Новый механизм реализован в виде Java-приложения (db-restruct-v2.jar). Для его работы на сервере «1С:Предприятие» должна быть установлена JRE версии 8 или выше. Разрядность Java должна строго соответствовать разрядности сервера 1С (как правило, это x64).
3. Протоколы сетевого взаимодействия: Это критический момент, на котором спотыкаются многие. Механизм V2 подключается к SQL-серверу через JDBC-драйвер. JDBC не умеет работать через протокол Shared Memory. Для успешной работы обязательно должен быть включен протокол TCP/IP.

Шаг 1. Настройка файла conf.cfg

Первым делом нам нужно явно указать платформе, что мы хотим использовать вторую версию механизма. Для этого найдем файл conf.cfg. Обычно он располагается в каталоге установленной платформы (например, C:\Program Files\1cv8\conf).

Добавим в него следующую строку:

UpdateDBCfg=v2

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

Шаг 2. Настройка протоколов SQL Server

Проанализируем ситуацию, описанную в обращении: если сервер 1С и SQL Server установлены на одной физической машине, платформа по умолчанию пытается использовать наиболее быстрый протокол — Shared Memory. Однако, как мы выяснили ранее, JDBC-компонента механизма V2 требует TCP/IP.

Рассмотрим порядок действий в SQL Server Configuration Manager:

1. Перейдем в раздел SQL Server Network Configuration -> Protocols for [Имя_Экземпляра].
2. Убедимся, что TCP/IP находится в статусе Enabled.
3. Проверим настройки Shared Memory. Если система упорно игнорирует V2, попробуем временно отключить (Disable) Shared Memory, оставив только TCP/IP. Это принудит все соединения, включая внутренние вызовы Java, использовать сетевой стек.
4. После изменения протоколов необходимо обязательно перезапустить службу SQL Server.

Шаг 3. Права доступа в SQL Server

Выясним причину, по которой Java-процесс может завершаться с ошибкой, даже если протоколы настроены верно. Пользователь, под которым сервер 1С авторизуется на SQL-сервере, должен обладать расширенными правами. Для управления процессом фоновой реструктуризации JDBC-драйверу требуются права:

• VIEW SERVER STATE — для мониторинга процессов.
• ALTER ANY CONNECTION — для возможности управления блокирующими сессиями в процессе финализации обновления.

Без этих прав механизм может стартовать, но упасть в процессе миграции данных, что приведет к откату на версию V1.

Шаг 4. Проверка работоспособности механизма

Как понять, что мы все сделали правильно и реструктуризация действительно идет по новому сценарию? Рассмотрим основные признаки:

1. Процесс в ОС: Во время обновления конфигурации базы данных в диспетчере задач сервера должен появиться процесс java.exe, запущенный от имени пользователя службы 1С.
2. Технологический журнал: Если настроен сбор ТЖ, мы увидим события, относящиеся к db-restruct-v2. В логах будет зафиксирован запуск jar-архива и параметры подключения к БД.
3. Мониторинг SQL: В списке активных соединений (через sp_who2 или Activity Monitor) вы увидите подключения, где в колонке Program Name будет фигурировать что-то вроде Microsoft JDBC Driver for SQL Server.

Особенности фонового режима и риски

Рассмотрим подробнее, как именно V2 ускоряет процесс. В отличие от V1, новый механизм создает временные таблицы с новой структурой и начинает переливать в них данные из старых таблиц, пока пользователи работают. Для предварительной оценки объемов данных перед реструктуризацией подойдёт обработка для анализа размера таблиц 1С в MS SQL.

Важные моменты, которые нужно учитывать:

• Место на диске: Поскольку создаются копии таблиц, база данных во время реструктуризации может вырасти в объеме почти в два раза. Убедитесь, что на дисках с данными и логами достаточно свободного пространства.
• Нагрузка на TempDB: Механизм V2 очень активно использует временную базу TempDB. Рекомендуется размещать файлы TempDB на максимально быстрых дисках (NVMe/SSD).
• Транзакционный лог: Объем транзакций при массовом переносе данных будет огромным. Если ваша база находится в модели восстановления Full, приготовьтесь к стремительному росту файла .ldf.

Проанализируем ситуацию с режимом совместимости. В примере автора использовалась версия 8.3.12. Это стабильная версия для V2, однако стоит помнить, что в ранних релизах (8.3.11-8.3.13) механизм считался экспериментальным. Если вы планируете использовать фоновую реструктуризацию в промышленной среде, рекомендуется использовать платформу версии 8.3.14 и выше, где большинство детских болезней JDBC-драйвера было исправлено.

Таким образом, для запуска V2 недостаточно просто прописать параметр в conf.cfg. Необходимо обеспечить связку "Совместимая платформа + JRE + Работающий TCP/IP на SQL + Достаточные права пользователя SQL". Только при соблюдении всех этих условий вы получите преимущество в виде минимального времени простоя системы при обновлении тяжелых конфигураций, таких как ERP или Комплексная автоматизация. Для автоматизации всего процесса накатывания релизов можно использовать скрипт обновления конфигурации 1С с помощью PowerShell.