К статье
Практический материал

Администрирование · 12 мин

Как перейти на SQL в 1С: перевод базы на клиент-серверный режим

Как перевести базу 1С с файлового режима на SQL Server или PostgreSQL: выбор СУБД, выгрузка, настройка сервера 1С, проверка результата и типичные ошибки.

Переход на SQL в 1С означает перевод информационной базы из файлового режима в клиент-серверный, где данные хранятся в СУБД — Microsoft SQL Server или PostgreSQL. Такой шаг обычно продиктован ростом базы: при объёме свыше нескольких гигабайт и одновременной работе более 10–15 пользователей файловый режим начинает давать блокировки, замедление проведения документов и сбои при регламентных операциях.

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

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

Когда файловый режим пора менять на SQL

Файловый режим хранит всю базу в одном файле 1Cv8.1CD, и доступ к нему организован через механизм блокировок на уровне файла. Пока пользователей мало и объём умеренный, это работает стабильно. Проблемы начинаются, когда возрастает конкуренция за данные.

Характерные признаки того, что пора переходить на SQL: документы проводятся заметно дольше в часы пик, пользователи получают ошибки «Конфликт блокировок при выполнении транзакции», регламентные задания мешают интерактивной работе, а восстановление после сбоя электропитания превращается в длительное тестирование и исправление базы.

Число пользователейБолее 10–15 одновременно

Файловый режим плохо переносит конкурентную работу — блокировки растут лавинообразно

Размер файла 1Cv8.1CDНесколько гигабайт и растёт

Большие файловые базы медленнее обслуживаются и рискованнее при сбоях

Ошибки блокировокРегулярные конфликты транзакций

Признак того, что механизм блокировок файлового режима исчерпал себя

Фоновые задачиОбмены и регламентные задания тормозят работу

В клиент-серверном режиме фоновые процессы изолированы от пользователей

Важно понимать, что переход на SQL сам по себе не ускоряет медленные запросы и не лечит ошибки конфигурации. Если база тормозит из-за неоптимального кода или слабого сервера, клиент-серверный режим лишь частично сгладит проблему, но добавит надёжности и управляемости.

Выбор СУБД: MS SQL Server или PostgreSQL

1С:Предприятие поддерживает несколько СУБД, но практический выбор почти всегда сводится к двум вариантам: Microsoft SQL Server и PostgreSQL. Оба варианта полностью поддерживаются платформой, различия — в стоимости лицензий, требованиях к администрированию и экосистеме.

Сравнение вариантов

Microsoft SQL Server

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

PostgreSQL (сборка для 1С)

Бесплатная СУБД, для 1С нужна специально собранная версия. Экономия на лицензиях, но настройка и обслуживание требуют более внимательного подхода

Оставить файловый режим

Оправдано при малом числе пользователей и небольшой базе: нет затрат на сервер и лицензии, но есть потолок по нагрузке

Для PostgreSQL нужна специальная сборка, адаптированная для работы с 1С, — ванильный дистрибутив с официального сайта PostgreSQL платформа не поддерживает корректно. Сборки публикуются в том числе на портале 1С для зарегистрированных пользователей.

Отдельная статья расходов — лицензии на сервер 1С:Предприятия. Клиент-серверный режим требует отдельной лицензии на сервер помимо клиентских. Это нужно заложить в бюджет до начала работ, иначе миграция остановится на этапе запуска.

Подготовка: резервная копия и проверка конфигурации

Первое и безусловное правило — полная резервная копия до любых действий. Для файловой базы достаточно выгрузки в .dt из конфигуратора плюс копии самого файла 1Cv8.1CD. Проверьте, что выгрузка прошла без ошибок и файл читается: протестируйте загрузку копии в пустую файловую базу.

Второй шаг — проверка конфигурации на совместимость. В конфигураторе есть режим проверки с включённым флагом «Клиент-сервер»: он выявляет код, который в клиент-серверном режиме работать не будет. Типичные проблемы — обращения к локальным файлам с сервера, модальные вызовы, использование методов, недоступных на сервере.

Подготовительные действия
  1. 1
    Сделайте выгрузку базы в файл .dt через конфигуратор и скопируйте файл 1Cv8.1CD
  2. 2
    Проверьте восстановление копии в тестовую файловую базу
  3. 3
    Запустите проверку конфигурации с флагом совместимости клиент-серверного режима
  4. 4
    Устраните выявленные ошибки или запланируйте их исправление
  5. 5
    Убедитесь, что есть лицензия на сервер 1С и выбрана СУБД
  6. 6
    Спланируйте окно миграции — время, когда пользователи не работают

Также оцените оборудование. Сервер 1С и СУБД требовательны к оперативной памяти и скорости дисковой подсистемы. Размещение СУБД на том же диске, что и операционная система, на медленных HDD — частая причина разочарования после миграции: нагрузка выросла, а производительность не изменилась.

Установка сервера 1С и СУБД

Порядок установки: сначала СУБД, затем сервер 1С:Предприятия, затем создание базы. Для MS SQL Server достаточно стандартной установки экземпляра с аутентификацией Windows или смешанной. Для PostgreSQL устанавливается специальная сборка, после чего обычно требуется настройка параметров памяти в конфигурационном файле — значения по умолчанию рассчитаны на слабые машины и для 1С не подходят.

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

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

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

Когда инфраструктура работает, создаётся новая информационная база. Это делается либо через диалог добавления базы в списке (выбор «Создание новой информационной базы» → «на сервере 1С:Предприятия»), либо через консоль кластера серверов. Указываются тип СУБД, имя сервера баз данных, имя создаваемой базы и учётные данные администратора СУБД.

После создания пустой базы откройте её в конфигураторе и выполните загрузку из ранее выгруженного файла .dt (Загрузить информационную базу). Время загрузки зависит от объёма данных и скорости дисков — для больших баз это часы, поэтому миграцию планируют на ночь или выходные.

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

Проверка результата после миграции

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

Контрольные точки

Как проверить результат

Вход пользователей
Норма

База открывается через сервер, список пользователей полный

Тревожный признак

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

Проведение документов
Норма

Документы проводятся без ошибок блокировок

Тревожный признак

Конфликты транзакций или ошибки SQL при проведении

Регламентные задания
Норма

Задания выполняются по расписанию на сервере

Тревожный признак

Задания не стартуют — проверьте, что их выполнение разрешено в свойствах базы

Отчёты и обмены
Норма

Формируются за приемлемое время, обмены проходят

Тревожный признак

Обмены падают из-за путей к локальным файлам на сервере

Отдельно проверьте всё, что связано с файловыми операциями: обмены через каталоги, печать во внешние файлы, выгрузки. В клиент-серверном режиме код выполняется на сервере, и пути вроде C:\Обмен теперь указывают на диски сервера, а не компьютера пользователя. Это самый частый источник «поломок» после миграции.

Первые дни после перехода наблюдайте за нагрузкой на СУБД: размер логов транзакций, заполнение tempdb, свободная память. Настройте регламентное обслуживание на стороне СУБД — резервное копирование средствами самой СУБД, обновление статистики, контроль роста логов.

Типичные ошибки и ограничения

Типичные ошибки
01
Миграция без тестового прогона — ошибки совместимости всплывают в рабочей базе, откат занимает часы
02
Отсутствие резервной копии перед выгрузкой — при сбое .dt остаётся единственная копия данных без гарантии целостности
03
Установка обычного PostgreSQL вместо сборки для 1С — база не создаётся или работает некорректно
04
Слабый сервер: мало памяти, медленные диски — после перехода производительность не растёт, а иногда падает
05
Забытые регламентные задания — в свойствах базы в кластере не разрешено их выполнение, обмены молча останавливаются
06
Продолжение работы в старой файловой копии частью сотрудников — данные расходятся, свести их потом крайне трудно

Есть и принципиальные ограничения. Режим совместимости конфигурации с очень старыми версиями платформы может препятствовать работе в клиент-серверном варианте — сначала потребуется обновление. Некоторые узкоспециализированные решения сторонних разработчиков содержат компоненты, рассчитанные только на файловый режим; это нужно уточнять у поставщика до миграции.

Опыт показывает, что самая трудоёмкая часть перехода — не сама выгрузка-загрузка, а поиск и исправление мест в конфигурации, где используются локальные пути и клиентские вызовы. Выделите на этот этап отдельное время и привлеките разработчика, если конфигурация сильно доработана.
ПЗ
Практическое замечание

Если объём базы очень большой и загрузка .dt занимает неприемлемо много времени, рассмотрите альтернативу: миграцию средствами самой СУБД через сторонние инструменты или поэтапный перенос с предварительной свёрткой базы. Такие сценарии сложнее и требуют участия опытного администратора 1С.

Итог

Что важно запомнить

Переход на SQL — это выгрузка .dt, создание базы на сервере 1С с MS SQL или PostgreSQL и загрузка данных обратно. Критичны три вещи: резервная копия, проверка конфигурации на совместимость с клиент-серверным режимом и тестовый прогон до миграции рабочей базы.

Частые вопросы о переходе на SQL в 1С

Можно ли перейти на SQL без остановки работы пользователей?

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

Что делать со старой файловой базой после перехода?

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

Ускорит ли переход на SQL медленные отчёты?

Не гарантированно. SQL-сервер лучше справляется с параллельной работой и большими объёмами, но неоптимальные запросы в конфигурации останутся медленными. Если отчёт тормозит из-за плохого кода, его нужно оптимизировать отдельно — миграция этого не исправит.

Нужны ли отдельные лицензии для клиент-серверного режима?

Да. Помимо клиентских лицензий требуется лицензия на сервер 1С:Предприятия, а при использовании MS SQL Server — лицензии на саму СУБД по её модели лицензирования. PostgreSQL в сборке для 1С лицензионных платежей за СУБД не требует, но лицензия на сервер 1С нужна в любом случае.

Можно ли вернуться с SQL обратно на файловый режим?

Технически да: база выгружается в .dt из конфигуратора и загружается в файловый вариант. Однако для больших баз это долго, а сам возврат обычно означает отказ от преимуществ клиент-серверного режима. Оставляйте такой откат как аварийный вариант, а не как плановый сценарий.

Кто должен выполнять миграцию — бухгалтер, программист или администратор?

Миграция — задача администратора 1С или специалиста с опытом установки сервера 1С и СУБД. Бухгалтеру и рядовому программисту без практики администрирования доверять её не стоит: цена ошибки — работоспособность учётной системы всей организации.