Как правильно перевести УПП 1.3 с платформы 8.2 на 8.3

Системный администратор 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

Перевод производственной системы масштаба «1С:Управление производственным предприятием 1.3» с платформы 8.2 на 8.3 — ответственная административная задача. Хотя конфигурация УПП 1.3 функционирует на платформе 8.3 в режиме совместимости с версией 8.2 и использует обычные формы, сама смена серверного окружения и формата хранения служебных данных требует четкого соблюдения регламента. Разберем подробно способы переноса, нюансы параллельной работы платформ, а также технические риски и способы их минимизации.

Критически важное предупреждение: необратимость конвертации

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

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

Способ 1. Переподключение базы в консоли серверов (рекомендуемый для клиент-серверных баз)

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

  1. Создаем резервную копию базы данных: штатными средствами СУБД (например, средствами Microsoft SQL Server) создаем полную резервную копию (Full Backup) базы УПП. Дополнительно можно выгрузить информационную базу в файл с расширением .dt.
  2. Останавливаем регламентные задания и завершаем сеансы: в консоли кластера серверов 8.2 блокируем начало сеансов и отключаем всех активных пользователей.
  3. Удаляем регистрацию базы из консоли 8.2: открываем консоль кластера 8.2, находим нашу базу УПП и удаляем ее из списка. При удалении выбираем вариант «Оставить базу данных без изменений», чтобы физическая база на SQL-сервере осталась нетронутой.
  4. Регистрируем базу в кластере 8.3: открываем консоль администрирования серверов 1С 8.3, создаем новую информационную базу, указываем точное имя сервера баз данных и имя существующей базы на SQL-сервере.
  5. Включаем блокировку регламентных заданий: в свойствах базы в консоли 8.3 временно устанавливаем флаг «Блокировка регламентных заданий включена». Это предотвратит запуск тяжелых фоновых процедур и регламентных обменов до окончания проверки работоспособности системы.

Способ 2. Миграция через файл выгрузки (.dt)

Разберем альтернативный вариант, который отлично подходит для тестовых переносов или баз относительно небольшого объема:

  1. Открываем базу в Конфигураторе платформы 8.2 и выполняем команду «Администрирование» — «Выгрузить информационную базу» в файл формата .dt.
  2. В консоли серверов 8.3 создаем новую пустую информационную базу (с созданием новой пустой базы данных на SQL-сервере).
  3. Запускаем Конфигуратор новой базы под платформой 8.3 и загружаем данные через меню «Администрирование» — «Загрузить информационную базу».

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

Особенности параллельной работы служб 8.2 и 8.3 на одном сервере

Если на одном сервере одновременно развернуты службы 1C:Enterprise 8.2 Server Agent и 1C:Enterprise 8.3 Server Agent, выясним причину возможных конфликтов. По умолчанию обе службы претендуют на одни и те же сетевые порты: 1540, 1541 и диапазон 1560:1591.

Чтобы службы не конфликтовали, для платформы 8.3 при установке или в параметрах запуска службы Windows задают смещенные порты (например, 2540, 2541, 2560:2591). В этом случае в диалоге запуска 1С у пользователей в поле сервера обязательно прописывается порт кластера, например: server_name:2541.

Взаимодействие через COM-соединения и внешние компоненты

Проанализируем интеграционные сценарии, которые могут нарушиться после перевода базы:

  1. Перерегистрация COM-коннектора: если сторонние конфигурации или внешние скрипты подключались к УПП через V82.COMConnector, их код потребуется скорректировать на использование V83.COMConnector. На самом сервере необходимо зарегистрировать библиотеку comcntr.dll из каталога bin новой платформы 8.3 с помощью команды: regsvr32 "C:\Program Files\1cv8\8.3.X.XXXX\bin\comcntr.dll"
  2. Разрядность платформы: если сервер 8.2 был 32-разрядным, а новый сервер 8.3 установлен как 64-разрядный, все 32-битные внешние компоненты (криптография, генераторы штрихкодов, драйверы весов и сканеров), запускаемые в серверном контексте, перестанут загружаться. Их необходимо обновить до 64-битных версий или перенести их вызов на клиентские рабочие места.

Обязательные действия после первого запуска

После того как информационная база подключена к кластеру 8.3, выполним финальные технические процедуры:

  1. Первый запуск строго через Конфигуратор: открываем базу в режиме «Конфигуратор» под платформой 8.3. Если программа запросит подтверждение реструктуризации метаданных, применяем изменения (нажимаем F7).
  2. Очистка кэша: обязательно очищаем временные каталоги сеансовых данных на сервере и локальный кэш конфигураций на пользовательских компьютерах (каталоги 1C\1cv8 в AppData\Local и AppData\Roaming), чтобы избежать странных графических артефактов и ошибок метаданных обычных форм.
  3. Тестирование и исправление: различия в оптимизаторах запросов версий 8.2 и 8.3 могут приводить к замедлению выборки данных. Рекомендуется запустить процедуру «Тестирование и исправление» (минимум — реиндексацию таблиц и пересчет итогов регистров) либо средствами СУБД выполнить дефрагментацию индексов и процедуру UPDATE STATISTICS.
  4. Снятие блокировки: после проверки основных документов и отчетов возвращаемся в консоль серверов 8.3 и снимаем флаг блокировки регламентных заданий.
← На главную