Миграция 1С с файлового режима на SQL Server

Перевод на SQL — это переход с файлового режима (папка с файлом 1Cv8.1CD) на клиент-серверный, где данные хранит отдельная СУБД: Microsoft SQL Server или PostgreSQL. Сам файл базы при этом не «конвертируется» — вы выгружаете данные в файл .dt и загружаете их в новую, уже серверную базу .

Схема миграции одинакова для Бухгалтерии, ЗУП, Управления торговлей и любой другой конфигурации на платформе 8.3: подготовить сервер СУБД и сервер 1С:Предприятия, завести учётную запись в СУБД, выгрузить файловую базу в .dt, создать серверную базу в кластере и загрузить в неё данные. Разберём каждый шаг с точными путями.

Когда файловую базу пора переводить на SQL и какую СУБД выбрать

Файловый режим упирается в потолок по числу активных пользователей (практический предел — около 5–10 одновременно работающих) и по размеру базы. Признаки, что пора на сервер:

• 🐢 база «подтормаживает» при одновременной работе нескольких человек;
• 📦 файл 1Cv8.1CD разросся до десятков гигабайт;
• 🔒 частые конфликты блокировок и сообщения о занятости объектов;
• 🌐 нужен веб-клиент, регламентные задания на сервере или публикация базы.

Платформа 8.3 работает с MS SQL Server, PostgreSQL, IBM DB2 и Oracle Database. На практике выбор почти всегда между двумя:

Про редакции MS SQL: бесплатная Express имеет ограничения по объёму одной базы (порядка 10 ГБ) и по используемой памяти и ядрам. Для боевой базы 1С, которая легко перерастёт этот лимит, берите редакцию Standard; Express годится разве что для теста миграции или совсем небольшой базы. PostgreSQL таких искусственных лимитов не ставит.

Клиент-серверный режим требует серверной лицензии 1С:Предприятия — она платная и покупается отдельно от клиентских. Базовые версии конфигураций (например, «Бухгалтерия предприятия. Базовая») клиент-серверный режим не поддерживают в принципе — для них миграция на SQL невозможна.

Что подготовить до перехода

Миграция затрагивает нескольких людей и несколько программ, поэтому собранный заранее список экономит время и нервы на самом переносе.

Отдельно про версии: разрядность и версия платформы на сервере 1С должны быть совместимы с клиентскими. Ставьте на сервер версию платформы с номером не ниже, чем на рабочих местах, и ту же разрядность (как правило, x86-64). Разнобой версий — частая причина, по которой клиент потом не подключается.

Права и учётная запись на сервере СУБД

Серверу 1С нужна учётная запись в СУБД, под которой он создаёт базу и работает с ней. Права должны позволять создавать базы данных.

Для MS SQL Server. В SQL Server Management Studio создайте логин с проверкой подлинности SQL Server (SQL authentication, не доменную). Разделы в дереве — Security → Logins → New Login. Задайте пароль, снимите требование сменить пароль при первом входе. Назначьте серверные роли:

• public — базовая, стоит по умолчанию;
• dbcreator — право создавать базы данных;
• processadmin — управление процессами.

Эта же учётная запись потом указывается при создании информационной базы в кластере 1С.

Для PostgreSQL. Нужна роль с правом создавать базы (атрибут CREATEDB) или суперпользователь. При установке сборки от 1С создаётся суперпользователь postgres — его пароль вы задаёте сами и используете при регистрации базы. Создать отдельную роль можно командой в psql:

CREATE ROLE usr1cv8 WITH LOGIN CREATEDB CREATEROLE PASSWORD 'надёжный_пароль';

Выгрузка файловой базы в файл dt

Данные из файловой базы переносятся через выгрузку в файл .dt — это полный слепок конфигурации и всех данных.

1. Убедитесь, что из базы вышли все пользователи. Выгрузка снимает согласованный слепок только при монопольном доступе — пока кто-то работает, корректно выгрузить не получится.
2. Запустите базу в режиме Конфигуратор.
3. Меню Администрирование → Выгрузить информационную базу.
4. Укажите имя и папку для файла .dt, дождитесь завершения.

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

Создание серверной базы и загрузка данных

Теперь создаём пустую серверную базу в кластере 1С и заливаем в неё .dt.

1. Добавьте базу на сервере. В окне запуска 1С нажмите Добавить → Создание новой информационной базы → Создание базы без конфигурации (пустую — данные придут из .dt). На шаге расположения выберите На сервере 1С:Предприятия.

2. Заполните параметры кластера и СУБД:

• Кластер серверов — имя или адрес сервера 1С (по умолчанию порт агента 1540);
• Имя информационной базы в кластере — латиницей, например buh_sql;
• Тип СУБД — MS SQL Server или PostgreSQL;
• Сервер баз данных — адрес сервера СУБД (для MS SQL часто вид SERVER\SQLEXPRESS);
• Имя базы данных — как будет называться база в СУБД;
• Пользователь базы данных и пароль — та самая учётка из прошлого шага;
• ✅ отметьте Создать базу данных в случае её отсутствия — 1С сама создаст базу в СУБД.

Нажмите Готово. Если прав у учётной записи СУБД хватает, в списке баз появится новая серверная база — пока пустая.

3. Загрузите данные. Откройте новую базу в Конфигураторе, затем Администрирование → Загрузить информационную базу и выберите ваш .dt.

После загрузки платформа предложит перезапустить — согласитесь. Серверная база готова.

Подключение пользователей к новой базе

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

1. В окне запуска Добавить → Добавление в список существующей информационной базы.
2. Тип расположения — На сервере 1С:Предприятия.
3. Укажите адрес кластера (имя сервера 1С) и имя базы в кластере — то самое buh_sql.

Чтобы клиент достучался до сервера, между рабочим местом и сервером 1С должны быть открыты порты:

• 1540 — агент сервера (ragent);
• 1541 — главный менеджер кластера (rmngr);
• 1560–1591 — диапазон рабочих процессов (по умолчанию).

А между сервером 1С и сервером СУБД — порт СУБД: 1433 для MS SQL, 5432 для PostgreSQL.

Настройка производительности после миграции

Серверная база из коробки работает, но несколько настроек СУБД заметно влияют на скорость 1С.

Для MS SQL Server:

• Модель восстановления базы — Simple, если не ведёте журнал транзакций для point-in-time восстановления. Full без регулярного бэкапа лога раздувает .ldf до потери места на диске.
• Автоувеличение файлов (autogrowth) задайте фиксированными мегабайтами (например, 512 МБ), а не процентами.
• Max degree of parallelism (MAXDOP) для 1С традиционно ограничивают — распараллеливание одного запроса редко помогает учётной нагрузке. Начните с небольшого значения и проверьте на своей нагрузке.
• tempdb вынесите на быстрый диск; число файлов данных tempdb — по числу ядер (разумный максимум — 8).

Для PostgreSQL ключевые параметры в postgresql.conf зависят от объёма ОЗУ сервера: shared_buffers, work_mem, effective_cache_size, max_connections. Сборка от 1С обычно идёт с уже адаптированными под 1С значениями — радикально менять их без замеров не стоит.

Отдельный шаг, который часто забывают, — режим управления блокировкой данных. В Конфигураторе откройте свойства конфигурации (корень дерева) и проверьте параметр Режим управления блокировкой данных. Для серверной базы правильное значение — Управляемый: он снижает число эскалаций блокировок и конфликтов при одновременной работе, тогда как «Автоматический» режим на SQL-базе может давать избыточные блокировки. Типовые конфигурации уже идут в управляемом режиме, но после миграции это стоит проверить явно.

Общие правила для любой СУБД:

• 💾 настройте регулярное резервное копирование средствами СУБД — это надёжнее, чем выгрузка .dt вручную;
• 🧹 заведите регламент обслуживания: обновление статистики и дефрагментацию индексов (для MS SQL), VACUUM/ANALYZE (для PostgreSQL);
• 🗓 запланируйте обслуживание на ночь или выходные — тяжёлые операции СУБД конкурируют с работой пользователей за диск и память;
• 🧪 нагрузочное тестирование лучше проводить на копии, а не на боевой базе.

Если планируете веб-клиент или мобильный доступ, после миграции базу публикуют на веб-сервере (IIS или Apache) — это отдельная настройка поверх уже работающего клиент-серверного режима, а не часть самой миграции.

Типичные ошибки при переходе на SQL

Большинство сбоев при миграции — не в самих данных, а в правах, версиях и сети. Вот что встречается чаще всего.

Частые вопросы