Как перевести базы 1С на SQL-сервер и запустить две разные версии платформы на одном компьютере?

Переход с файлового режима работы на клиент-серверный (SQL) — это ответственный этап масштабирования информационной системы. Часто возникают ситуации, когда в организации сосуществуют старые конфигурации (например, сильно доработанная Управление торговлей 10.3) и современные решения (Бухгалтерия предприятия 3.0). Главная сложность здесь заключается в том, что разные базы могут требовать разных версий платформы 1С:Предприятие для стабильной работы. Разберем подробно, как реализовать такой переход и могут ли «ужиться» две версии платформы на одном сервере.

Анализ ситуации: когда пора уходить с файловой базы

Рассмотрим типовой сценарий: база УТ 10.3 весом 14–20 Гб работает в файловом режиме для 15 пользователей в терминальном доступе. Несмотря на то, что система кажется «шустрой», вы находитесь в зоне риска. Разберем почему:

1. Ограничение объема таблиц: В файловой базе .1CD размер одной внутренней таблицы не может превышать 4 Гб. Как только справочник или таблица итогов регистра достигнет этого предела, база перестанет принимать записи, что приведет к остановке работы.
2. Риск повреждения данных: При аварийном завершении сеанса в файловом режиме высока вероятность нарушения целостности базы.
3. Производительность при блокировках: При росте количества активных пользователей файловая база начинает страдать от избыточных блокировок всей базы при записи, тогда как SQL блокирует данные на уровне строк.

Вариант №1: Запуск двух экземпляров службы сервера 1С на одном хосте

Проанализируем техническую возможность запуска двух разных версий платформы (например, 8.3.6 и актуальной 8.3.22) на одной физической машине. Это вполне рабочая схема, если выполнить правильную настройку.

Разведение по портам и каталогам:

Для того чтобы два сервера 1С не конфликтовали, нам необходимо развести их по сетевым портам и путям хранения реестра кластера. Проделаем следующие шаги:

1. Установим обе версии платформы на сервер.
2. Первую службу (основную) оставим на стандартных портах (1540 — агент, 1541 — менеджер кластера, 1560-1591 — рабочие процессы).
3. Вторую службу зарегистрируем вручную через командную строку. Для этого воспользуемся утилитой sc create.

Пример регистрации второй службы (командная строка должна быть запущена от имени администратора):

sc create "1C:Enterprise 8.3.6 Server" binPath= "\"C:\Program Files\1cv8\8.3.6.2299\bin\ragent.exe\" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \"C:\Program Data\1C\server_8_3_6\"" displayname= "1C:Enterprise 8.3 Server (8.3.6)" depend= "Tcpip/dnscache/lanmanworkstation/lanmanserver" start= auto

Важные параметры:

• -regport: порт главного менеджера кластера (смещаем, например, на 1641).
• -port: порт агента сервера (смещаем на 1640).
• -range: диапазон портов для рабочих процессов.
• -d: отдельный каталог для данных кластера (обязательно создайте новую папку, чтобы реестры не перемешались).

Проблема COM-соединения и взаимодействия баз

Разберем важный нюанс, который упоминали эксперты: COM-коннектор может быть только одной версии. В реестре Windows библиотека comcntr.dll регистрируется глобально. Это означает, что если вы настроили обмен между базами через COM-соединение, возникнут сложности.

Проанализируем способы решения:

1. Использование универсальных методов обмена: Рекомендуем переходить с COM на HTTP-сервисы или Web-сервисы. Они работают через протокол HTTP и совершенно не зависят от версий установленных платформ.
2. Перерегистрация библиотек: Существуют методы программной перерегистрации нужной DLL перед выполнением обмена, но это решение считается нестабильным и «костыльным».

Вариант №2: Переход на единую актуальную платформу с режимом совместимости

Это самый правильный и стратегически верный вариант. Выясним, почему не стоит бояться запускать старую УТ 10.3 на новой платформе.

В свойствах конфигурации 1С существует параметр Режим совместимости. Если вы установите актуальную платформу, но оставите в конфигурации режим «8.3.6», платформа будет эмулировать поведение старого движка для этой конкретной базы. Рассмотрим преимущества этого подхода:

• Вам не нужно администрировать две разные службы сервера.
• У вас будет одна актуальная версия COM-коннектора.
• Новые версии платформы лучше работают с оперативной памятью и современными версиями SQL-сервера.

Внимание: Перед переводом рабочей базы обязательно проведите всестороннее тестирование на копии. Обратите внимание на работу внешних компонент (торговое оборудование, драйверы ККТ) и специфические запросы, которые могут по-разному обрабатываться в новых версиях платформы.

Вариант №3: Использование МИНИ-сервера для разделения нагрузки

Если бюджет ограничен, а бухгалтеров всего 2–3 человека, рассмотрим вариант с покупкой лицензии «1С:Предприятие 8.3. Сервер МИНИ на 5 подключений». Это позволит вам:

1. Вынести Бухгалтерию 3.0 на отдельный сервер (или отдельный экземпляр службы) с самой свежей платформой.
2. Оставить УТ 10.3 в файловом режиме (если свертка базы дает результат) или также перевести на сервер, используя основную серверную лицензию.

Настройка SQL Server при совместной работе баз

Независимо от выбранного варианта, при работе с SQL Server важно правильно настроить потребление ресурсов. По умолчанию SQL Server стремится занять всю доступную память. Проанализируем, как это настроить:

1. Зайдите в свойства экземпляра SQL Server через Management Studio.
2. В разделе Memory установите предел Maximum server memory. Оставьте ОС и процессам 1С (rphost) минимум 4–8 Гб памяти (в зависимости от общего объема ОЗУ).
3. Если вы запускаете два сервера 1С, обязательно мониторьте нагрузку через диспетчер задач: процессы rphost каждой версии платформы будут потреблять ресурсы независимо друг от друга.

Подведем итог: Самый стабильный и современный путь — перевод всех баз на одну актуальную платформу с использованием режима совместимости для старой УТ 10.3. Если же код конфигурации критически завязан на особенности старой платформы (что бывает редко), используйте вариант с двумя службами, разведенными по портам, и заменяйте COM-обмен на современные HTTP-технологии.