При обновлении конфигурации в современных версиях платформы 1С мы часто сталкиваемся с необходимостью ускорения процесса изменения структуры таблиц. Для этого был разработан механизм реструктуризации второй версии (v2). Однако его внедрение сопряжено с рядом технических сложностей. Одной из самых неприятных проблем является критическая ошибка с текстом: При работе механизма реструктуризации второй версии возникла ошибка. Код возврата: 1. Операция: prepare. В этой статье мы подробно разберем, почему возникает этот сбой и как настроить серверную среду для его устранения.
Для начала проанализируем, чем работа механизма второй версии отличается от классической схемы. В традиционном режиме платформа 1С самостоятельно формирует DDL-запросы (Data Definition Language) и отправляет их в СУБД. В режиме v2 (который активируется параметром UpdateDBCfg=v2 в файле conf.cfg) основную нагрузку по анализу метаданных и построению графа зависимостей берет на себя внешняя утилита, написанная на языке Java.
Операция prepare — это первый этап процесса, на котором система анализирует текущую структуру таблиц и готовит план трансформации данных. Код возврата 1 является универсальной ошибкой, сигнализирующей о том, что процесс Java завершился аварийно. Причиной может быть что угодно: от отсутствия прав в SQL до нехватки оперативной памяти или несовместимости версий Java.
Поскольку механизм реструктуризации v2 напрямую зависит от Java, начнем с проверки этой компоненты. Платформа 1С предъявляет строгие требования к окружению. Разберем основные моменты:
JRE или JDK обязательно должна быть 64-битной. Смешивание разрядностей гарантированно приведет к ошибке запуска процесса.JAVA_HOME. Она должна указывать на корневой каталог установленной Java. Также путь к папке bin должен быть прописан в переменной Path. Это критично, так как сервер 1С запускает процесс от имени системного пользователя, и он должен «видеть» исполняемые файлы.Рассмотрим ситуацию со стороны базы данных. В отличие от классического метода, реструктуризация v2 создает множество временных служебных таблиц с суффиксами _v2 и активно манипулирует схемами данных. Выясним, достаточно ли прав у пользователя, под которым сервер 1С подключается к SQL:
Необходимые права: Пользователь должен обладать ролью db_owner. Если политика безопасности вашей организации ограничивает использование этой роли, убедитесь, что предоставлено право ALTER ANY SCHEMA и права на создание/удаление индексов и таблиц. Часто ошибка prepare возникает именно в момент попытки создания служебной таблицы для хранения плана реструктуризации.
Также проанализируем протокол соединения. В настройках сервера 1С и SQL Server следует использовать протокол TCP/IP. Механизм v2 может нестабильно работать через Shared Memory, особенно если компоненты Java и СУБД пытаются взаимодействовать в условиях ограниченных ресурсов операционной системы.
Если конфигурация базы данных содержит тысячи объектов (документов, справочников, регистров), стандартного объема памяти, выделяемого Java-машине, может не хватить для построения плана обновления. В этом случае процесс «падает» по OutOfMemoryError, что транслируется в код возврата 1.
Для решения этой задачи создадим в каталоге с исполняемыми файлами платформы (например, C:\Program Files\1cv8\8.3.11.2954\bin\conf) файл с именем dbms.cfg. В этом файле мы можем прописать дополнительные аргументы запуска Java. Разберем пример конфигурации:
JavaCommandLine=-Xmx4g -Xms2g -Dfile.encoding=UTF-8
Здесь параметр -Xmx4g устанавливает максимальный размер кучи (heap) в 4 Гигабайта. Этого объема обычно достаточно даже для очень крупных ERP-систем. Параметр -Dfile.encoding=UTF-8 помогает избежать проблем с кодировкой при чтении имен метаданных.
Если стандартный Технологический Журнал (ТЖ) 1С не дает ответов, воспользуемся инструментами СУБД. Рассмотрим, как отловить проблемный запрос. Запустим MS SQL Server Profiler и настроим фильтры. Важно включить следующие события:
RPC:CompletedSQL:BatchCompletedExceptionUser Error MessageОсобое внимание уделим событиям Prepare SQL. Как показывает практика, ошибка часто происходит после выполнения запросов к таблице Config. Например, если в процессе подготовки система находит «висящие» записи с расширением .new, которые остались от предыдущих неудачных попыток обновления:
DELETE FROM Config WHERE FileName LIKE '%.new'
SELECT TOP 1 FileName FROM Config WHERE FileName LIKE '%.new'
Если вы видите, что SQL-запросы выполняются успешно, но после них процесс обрывается, значит, проблема локализована внутри Java-логики или в правах на временные папки Windows.
Проанализируем работу системы с файловой структурой. Java-процесс во время операции prepare активно использует временный каталог пользователя, от имени которого запущен процесс rphost. Выполним следующие действия:
C:\Users\username\AppData\Local\Temp).v2restruct_.hs_err_pid*.log. Если они есть, внутри можно найти подробное описание ошибки доступа к памяти или библиотекам.Важно помнить, что в релизах ветки 8.3.11 механизм реструктуризации v2 находился в стадии активной доработки. Существует несколько известных багов, связанных с уникальными индексами по полям неограниченной длины и специфическими именами объектов, содержащими зарезервированные слова SQL. Если ни один из вышеперечисленных шагов не помог, проанализируем возможность временного отключения механизма v2. Для этого в файле conf.cfg заменим строчку:
UpdateDBCfg=v2
на
UpdateDBCfg=v1
Это вернет систему к классическому алгоритму реструктуризации, который работает медленнее на больших объемах данных, но обладает гораздо более высокой стабильностью и предсказуемостью.
Подведем итог: ошибка prepare с кодом 1 — это комплексная проблема. Для её решения мы должны обеспечить корректную работу Java-машины, предоставить расширенные права пользователю СУБД и выделить достаточный объем памяти для обработки метаданных. Совместное использование логов SQL Profiler и настройки dbms.cfg позволяет успешно преодолеть этот этап и завершить обновление конфигурации.