Миграция 1С с файловой базы на SQL: инструкция, риски и выгоды
Файловая база 1С — удобный способ начать. Поставил платформу, открыл 1cv8.1cd в сетевой папке — и пять человек уже работают. Через год эта схема превращается в источник ежедневной боли: бухгалтерия ждет, пока коллега «отпустит документ», файл растет, а в один момент одна из таблиц упирается в жесткий лимит четыре гигабайта, и система просто перестает открываться. Решение известно — миграция на клиент-серверный режим, где с данными работает полноценная СУБД, а не клиент платформы напрямую.
Ниже мы спокойно разберем, чем 1С 8.3 файловая база отличается от клиент-серверной архитектурно, как понять, что пора переходить, какую СУБД выбрать под свои задачи и как провести саму миграцию.
Чем отличается файловая база 1С от клиент-серверной
В файловом варианте вся информационная база хранится в одном файле 1cv8.1cd на сетевой шаре. Каждый клиент платформы открывает его напрямую — это «общая тетрадь на пятерых», где сотрудники занимают страницы по очереди. Платформа сама управляет блокировками: пока один редактирует документ, второй ждёт. До пяти-шести активных пользователей схема работает приемлемо, дальше ожидания становятся заметными.
Архитектура клиент-серверного варианта
Клиент-серверная база 1С устроена иначе. Между пользователями и данными встают два слоя: сервер 1С:Предприятие (службы rphost, rmngr, ragent) и сервер СУБД. Клиент общается только с сервером 1С, тот переводит запросы в команды базы данных, а блокировки разруливаются уже на уровне строк и страниц. Это не общая тетрадь, а банковский операционный зал — каждому клиенту достается собственный рабочий процесс, и сотрудники не мешают друг другу.
Где находится «движок» базы
В файловом варианте движок — сам клиент платформы, который пишет в общий файл. В клиент-серверной архитектуре 1С — это полноценная OLTP-СУБД (MS SQL Server, PostgreSQL или Postgres Pro). Она параллельно держит десятки соединений, ведёт журнал транзакций, кэширует горячие данные и оптимизирует запросы. Поэтому SQL-вариант тянет в три-десять раз больше пользователей на том же железе.
Когда пора уходить с файловой базы на SQL
Самый жесткий сигнал — лимит файловой базы 1С в четыре гигабайта на таблицу. Когда регистр накопления упирается в этот предел, система перестает открываться. До этого момента есть месяцы предупреждений: документы проводятся всё медленнее, отчеты строятся дольше, периодически появляются ошибки целостности. После лимита маневрировать поздно — миграция превращается в авральный проект.
Второй сигнал — блокировка базы 1С файловая. На пятом-шестом активном пользователе появляются заметные ожидания: «Ваша операция будет выполнена, как только освободится коллега». На десяти это превращается в постоянное ожидание, на пятнадцати — в катастрофу. SQL снимает проблему: блокировки переезжают с уровня файла на уровень строки или страницы.
Третий сигнал — внешние требования. Если компания работает с персональными данными по 152-ФЗ, должна вести журнал событий, иметь сертифицированный сервер баз данных, держать репликацию и горячие бэкапы — все это реализуется только в SQL. Файловый вариант ничего из перечисленного не умеет.
Какую СУБД выбрать: MS SQL, PostgreSQL или Postgres Pro
Под клиент-серверный режим 1С сегодня используют три варианта. MS SQL Server в редакциях 2019 или 2022 — зрелый продукт с инструментами диагностики (Query Store, Resource Governor, мониторинг блокировок). Под него за годы накопилась масса готовых сценариев настройки. Минус — лицензии и санкционные ограничения, из-за которых легально купить и обновить продукт в России затруднительно.
PostgreSQL — бесплатный движок, который под платформу ставится только сборкой с патчами 1С (с портала 1c.postgres.ru). Поднимается быстро, ресурсы экономятся. Postgres Pro — российский форк с теми же патчами плюс корпоративные возможности (CFS-сжатие, ptrack), реестром российского ПО и сертификатом ФСТЭК. Для госсектора это основной выбор, и такие проекты обычно идут вместе с импортозамещением серверов.
Лицензирование и стоимость владения
При переходе на клиент-серверный режим обязательной становится серверная лицензия 1С — программная или MIN_LICS на двенадцать одновременных соединений. У компании появляются две статьи расходов: лицензия платформы и лицензия СУБД. PostgreSQL здесь выгоднее: первый бесплатный, второй (Postgres Pro) дешевле зарубежного аналога и проходит по полной российской процедуре.
Подготовка к миграции
Любой проект начинается с аудита. Считается размер текущей информационной базы, фиксируется список регламентных заданий, выявляются интеграции по COM-соединениям, описываются доработки. Чем меньше неучтенного всплывет после переключения, тем меньше будет хвост откатов.
Подбор сервера под целевую нагрузку
Под десять пользователей разумный минимум — 4-6 vCPU, 8-16 ГБ RAM, 100 ГБ NVMe. Для пятидесяти-ста — восемь-шестнадцать vCPU, тридцать два — шестьдесят четыре ГБ RAM и NVMe с раздельными томами под данные, журнал транзакций и tempdb. Под рост числа сотрудников разумно сразу взять сервер для 1С с запасом по памяти. Для крупных проектов СУБД выносят на отдельный сервер баз данных — это снимает конкуренцию между платформой и движком за процессор и память.
После выбора железа ставится платформа 1С версии 8.3.20+, выбранная СУБД и проверяются обязательные параметры. Для PostgreSQL — max_locks_per_transaction = 256 (актуально для всех версий) и параметры строкового экранирования согласно текущей сборке с патчами 1С с портала 1c.postgres.ru.
Старые рекомендации из методичек 2018–2020 годов про standard_conforming_strings = off и escape_string_warning = off сегодня не нужны: на PostgreSQL 9.1+ значение standard_conforming_strings по умолчанию равно on, и сборки под платформу 8.3.20+ адаптированы под это поведение.
Перед запуском продакшена сверяйтесь с актуальной документацией на 1c.postgres.ru под свою версию PostgreSQL. Для MS SQL — MAXDOP = 1 и Max Server Memory в 60–80% от оперативной памяти. Без этих настроек платформа либо не запустится, либо будет работать медленнее.
Пошаговая инструкция миграции
CHDBFL
Утилита chdbfl.exe из папки bin платформы 1С (например, C:\Program Files\1cv8\8.3.x\bin\chdbfl.exe) проверяет файловую базу на ошибки индексов и при необходимости их чинит. Запускается она напрямую, а не через конфигуратор. Шаг обязательный до выгрузки: пропущенные сейчас ошибки перенесутся в SQL и всплывут уже в продакшене.
Закрытие сеансов и остановка регламентов
Перед выгрузкой обязательно закрыть все активные сеансы пользователей и убедиться, что нет запущенных регламентных и фоновых заданий. Если в момент выгрузки кто-то работает в базе или фоновое задание пишет данные, DT окажется «грязным» — с незафиксированными транзакциями и незавершенными операциями. Проверяется это в консоли администрирования: список сеансов должен быть пустой, регламентные задания — отключены через свойства информационной базы.
Выгрузка в DT
В конфигураторе открывается «Администрирование → Выгрузить информационную базу», результат сохраняется в файл с расширением .dt. Для базы пятьдесят гигабайт DT обычно весит два-шесть, для ста — четыре-двенадцать. Архив переносится на новый сервер.
Создание пустой клиент-серверной базы
В консоли кластера 1С администратор создает новую информационную базу с типом «MS SQL» или «PostgreSQL», прописывает параметры подключения и при необходимости MIN_LICS.
Загрузка DT и реструктуризация
В новой пустой базе через тот же пункт меню запускается загрузка файла. Платформа разворачивает структуру таблиц, переносит данные и запускает реструктуризацию — самый долгий этап на крупных объемах.
Проверка и переключение
Сверяются число документов, регистры, остатки на ключевых счетах, запускаются тестовые проведения и отчёты. Только после этого пользователей пускают в новую систему. Старая копия остается «только для чтения» как страховка.
Риски миграции
Несовместимость самописных доработок с клиент-серверным режимом
Файловый вариант прощает многое: код может обращаться к 1cv8.1cd напрямую, использовать однопоточные операции, игнорировать транзакции. В SQL такие места ломаются. Перед миграцией код проходит через ревью с упором на режим работы.
Большие DT-файлы и тайм-ауты загрузки
Если исходная база подходит к четырем гигабайтам, DT получится огромным, а реструктуризация может занять сутки или просто упасть. В таких случаях разумнее свернуть старые периоды или сразу переходить на прямое копирование между серверами уже после первой миграции.
Простой бизнеса в окне обслуживания
Окно согласуется с заказчиком, пользователи оповещаются заранее, готовится подробный план отката. Без этой бюрократии даже технически успешная миграция оставляет шрамы в отношениях между ИТ и бизнесом.
Выгоды от перехода
Главная — снятие лимита в четыре гигабайта. В SQL объемы спокойно живут на сотнях гигабайт и терабайтах, единственное ограничение — мощность железа. Вторая выгода — кратное ускорение проведения документов и закрытия месяца. На практике переход с файловой схемы на SQL для 1С Бухгалтерии на пятнадцать пользователей сокращает закрытие месяца с шести часов до полутора. На крупных объемах разница доходит до десятикратной.
Третья выгода — кластеризация и резервирование. Клиент-серверный режим легко включается в отказоустойчивую схему, реплицируется на резервный узел, бэкапится без остановки. Под рост числа сотрудников можно сразу планировать сервер для 1С на 30 пользователей или мощнее.
Сравнительная таблица
Из таблицы видно: при росте свыше пяти-десяти пользователей файловый режим перестает быть жизнеспособным. Производительность, масштабирование и надёжность работают только в клиент-серверной схеме.
Ответы на частые вопросы
Когда файловая база перестаёт справляться?
Признаков три: число активных пользователей подбирается к десяти, размер файла к трём гигабайтам, документы проводятся дольше нескольких секунд. При любом из этих сигналов пора планировать переход.
Сколько занимает миграция 100 ГБ?
DT-выгрузка крупной базы — двенадцать-двадцать четыре часа, загрузка с реструктуризацией — столько же. Для больших объёмов окно обслуживания планируется на выходные.
Что выбрать: MS SQL, PostgreSQL или Postgres Pro?
MS SQL — если есть лицензии и команда умеет с ним работать. PostgreSQL community — бюджетный вариант для коммерческого сектора. Postgres Pro — для госсектора и компаний с импортозамещением и ФСТЭК.
Сколько пользователей выдержит SQL-вариант?
Практический потолок — несколько тысяч на одном кластере при правильно подобранном железе и оптимизированной СУБД. Перед масштабным внедрением имеет смысл провести аудит ИТ-инфраструктуры и обкатать конфигурацию на пилоте.
Заключение
Переход с файловой схемы на SQL — естественный шаг для растущего бизнеса. Файловый режим хорош для команды до пяти человек, дальше он становится узким местом: лимит, блокировки, потеря скорости. Клиент-серверный вариант на MS SQL, PostgreSQL или Postgres Pro снимает эти ограничения и открывает дорогу к отказоустойчивости и масштабированию. Следующий шаг — снять текущие показатели и под них собрать чек-лист: сервер, СУБД, окно миграции, тесты и план отката.
