Администрирование · 14 мин
1С: когда переходить на SQL и как это сделать без потерь
Когда переходить с файловой базы 1С на SQL: признаки перегрузки, сравнение MS SQL и PostgreSQL, порядок миграции, типичные ошибки и проверка результата.
Файловый режим работы 1С:Предприятие — это не «плохой» вариант, а стартовый. Он прост в развёртывании, не требует отдельного сервера СУБД и лицензий на неё, и для небольшой компании с несколькими пользователями работает годами без проблем. Но у файловой базы есть жёсткие архитектурные ограничения: при росте числа пользователей, объёма данных и интенсивности операций она начинает «упираться» — и тогда вопрос перехода на клиент-серверный вариант с SQL становится вопросом времени.
Ошибка в обе стороны обходится дорого. Переход «на вырост» слишком рано — это лишние расходы на сервер, лицензии СУБД и администрирование, которое малой компании не нужно. Затягивание перехода — это падение производительности, блокировки, повреждения файловой базы и остановка учёта в самый неподходящий момент. Поэтому решение стоит принимать не по ощущениям, а по конкретным наблюдаемым признакам.
Ниже разобраны пороговые условия, при которых файловый режим перестаёт справляться, критерии выбора между MS SQL Server, PostgreSQL и другими СУБД, а также безопасный порядок миграции с проверкой результата.
Чем файловый режим принципиально отличается от клиент-серверного
В файловом режиме вся база — это один файл 1Cv8.1CD в сетевой папке. Каждый пользовательский компьютер сам читает и пишет в этот файл, а согласование доступа реализуется через механизм блокировок на уровне файловой системы. В клиент-серверном варианте добавляется промежуточное звено — сервер 1С:Предприятия, который обращается к СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2), а пользователи работают уже с сервером 1С, а не с файлом напрямую.
Разница проявляется в трёх ключевых моментах. Первый — блокировки: файловая база блокирует таблицы целиком, клиент-серверная умеет управлять блокировками на уровне записей, поэтому параллельная работа перестаёт мешать пользователям друг другу. Второй — надёжность: сетевой сбой при записи в файл .1CD может повредить базу, тогда как СУБД ведёт журнал транзакций и умеет откатывать незавершённые операции. Третий — масштабируемость: сервер приложений и СУБД можно разнести по разным машинам и наращивать их мощность независимо.
Признаки, что файловая база больше не справляется
Главный критерий — не возраст базы и не её «престижность», а наблюдаемые симптомы. Наиболее показательный — регулярные ошибки вида «Конфликт блокировок при выполнении транзакции» при обычной работе: проведении документов, запуске отчётов, обменах. Если пользователи вынуждены договариваться, кто когда проводит документы, чтобы не мешать друг другу, — это уже не удобство, а прямые потери рабочего времени.
Второй признак — деградация скорости при росте объёма данных. Отчёты, которые раньше строились за секунды, теперь выполняются минутами; проведение документов замедлилось; закрытие месяца превратилось в многочасовую процедуру. Если при этом сервер и сеть не менялись, причина почти наверняка в росте базы и ограничениях файлового механизма.
Третья группа признаков — организационная: выросло число одновременно работающих пользователей, появились филиалы с подключением по тонкому клиенту или веб-клиенту, потребовались регламентные задания в фоне (обмены, загрузка курсов, расчёты), которые в файловом режиме требуют отдельно запущенного сеанса и конфликтуют с работой пользователей.
Файловый режим начинает давать конфликты блокировок при интенсивной параллельной работе
Растёт время обновления, тестирования и резервного копирования, повышается риск повреждения файла
Пользователи мешают друг другу при проведении документов и запуске отчётов
В файловом режиме они требуют отдельного сеанса и работают нестабильно
Пороговые условия: когда переход оправдан, а когда преждевременен
Точных нормативов не существует — многое зависит от конфигурации, характера нагрузки и качества сети. Но на практике рабочими ориентирами считаются: до 5 одновременных пользователей и база до нескольких гигабайт — файловый режим вполне уместен; 5–15 пользователей — зона неопределённости, где всё решает интенсивность операций; свыше 10–15 активных пользователей или база заметно больше 5–10 ГБ — клиент-серверный вариант становится практической необходимостью.
Важно учитывать не только количество, но и характер работы. Пять пользователей, которые в основном вводят первичку, файловая база выдержит легко. Пять пользователей, которые одновременно проводят крупные документы, строят тяжёлые отчёты и запускают обмены, — уже нет. Также переход почти неизбежен, если требуется разграничение прав на уровне записей (RLS) в больших объёмах, работа через веб-сервер, интеграции через серверные механизмы или круглосуточная работа базы.
Как выбрать действие
Выбор СУБД: MS SQL Server, PostgreSQL или другое
1С:Предприятие поддерживает несколько СУБД, но на практике выбор почти всегда сводится к двум: Microsoft SQL Server и PostgreSQL. MS SQL Server исторически самый распространённый вариант в экосистеме 1С: под него больше всего документации, готовых практик настройки и специалистов на рынке. Его ограничение — стоимость лицензий при росте числа ядер и пользователей, хотя существует бесплатная редакция Express с жёсткими ограничениями по ресурсам, которая подходит лишь для небольших внедрений.
PostgreSQL — свободная СУБД, для работы с 1С используются сборки, адаптированные под платформу. Это существенно дешевле по лицензиям, что часто становится решающим фактором. Обратная сторона — тонкостей настройки больше, производительность сильнее зависит от корректной конфигурации, а специалистов с опытом именно связки «1С + PostgreSQL» меньше. Oracle и IBM DB2 встречаются в основном в крупных организациях, где эти СУБД уже являются корпоративным стандартом.
Сравнение вариантов
Максимум документации и специалистов, предсказуемая работа с 1С. Ограничение — стоимость лицензий при масштабировании
Без лицензионных платежей за СУБД, подходит для бюджетных внедрений. Ограничение — требует аккуратной настройки и опыта администрирования
Бесплатный старт для небольшой базы. Ограничение — жёсткие лимиты по памяти и размеру базы, быстро упирается в потолок
Оправданы, если уже являются корпоративным стандартом организации. Иначе — избыточная стоимость и сложность
Порядок миграции: от подготовки до переключения пользователей
Миграция выполняется штатными средствами платформы и не требует сторонних конвертеров. Технически это выгрузка базы в файл .dt и загрузка его в новую информационную базу, созданную на сервере 1С с указанием СУБД. Сложность не в самой выгрузке, а в подготовке инфраструктуры и минимизации простоя.
Перед миграцией нужно развернуть и настроить сервер 1С:Предприятия и выбранную СУБД (возможно, на разных машинах), убедиться, что версии платформы на сервере и у клиентов совместимы, а лицензии 1С покрывают клиент-серверный режим — для работы сервера требуется отдельная лицензия на сервер 1С:Предприятия. Также заранее проверьте, что используемая конфигурация поддерживает клиент-серверный режим: типовые конфигурации поддерживают, но сильно доработанные решения стоит проверить отдельно.
- 1Сделайте полную резервную копию файловой базы (копия файла 1Cv8.1CD при остановленной работе и выгрузка .dt)
- 2Разверните сервер 1С:Предприятия и СУБД, настройте их взаимодействие
- 3В консоли кластера серверов создайте новую информационную базу с указанием параметров СУБД
- 4Завершите работу всех пользователей файловой базы и выгрузите её в файл .dt через конфигуратор
- 5Загрузите .dt в новую серверную базу через конфигуратор
- 6Запустите тестирование и исправление, проверьте итоги, остатки и работу ключевых отчётов
- 7Пропишите пользователям новый путь подключения и проведите пробный рабочий день под наблюдением
Выгрузка и загрузка большой базы может занять часы, поэтому миграцию планируют на выходные или нерабочее время. До переключения пользователей обязательно сверьте контрольные точки: остатки по счетам, складские остатки, взаиморасчёты, итоги по регистрам. Старая файловая база после перехода сохраняется в архиве в режиме «только чтение» — она понадобится для сверки и как страховка.
Настройка после перехода и проверка результата
Сам по себе переход на SQL не ускоряет базу автоматически — без настройки СУБД можно получить даже замедление. Для MS SQL Server критичны: правильная модель восстановления базы, настройка tempdb (количество и размещение файлов), ограничение максимальной памяти сервера, чтобы СУБД не отбирала ресурсы у сервера 1С, если они на одной машине, а также регулярное обслуживание индексов и статистики. Для PostgreSQL ключевую роль играют параметры памяти и настройки планировщика под специфику запросов 1С.
После миграции нужно перенастроить регламентные операции: резервное копирование теперь делается средствами СУБД (а не копированием файла), регламентные задания 1С начинают выполняться на сервере автоматически. Проверьте, что фоновые задания реально запускаются и завершаются без ошибок — это одно из главных преимуществ перехода, и его нужно зафиксировать.
Как проверить результат
Остатки по счетам, складам и взаиморасчётам совпадают с файловой базой до копейки
Расхождения в итогах — загрузка прошла с ошибками, нужен анализ до запуска пользователей
Несколько пользователей одновременно проводят документы без конфликтов блокировок
Ошибки блокировок сохраняются — проверяйте настройки управляемых блокировок и СУБД
Фоновые задания выполняются по расписанию без запущенного сеанса
Задания не стартуют — проверьте настройки кластера и блокировки выполнения
Отчёты и проведение работают не медленнее, чем в файловом режиме
Замедление — СУБД требует настройки памяти, индексов и статистики
Типичные ошибки при переходе и как их избежать
Самая частая ошибка — экономия на оборудовании: сервер 1С и СУБД разворачивают на слабой машине или на том же диске, где лежат данные и журналы транзакций. В результате вместо ускорения компания получает стабильно медленную базу и разочарование в клиент-серверном режиме как таковом. Вторая типичная ошибка — миграция «вживую» без тестового прогона: первый опыт загрузки .dt происходит прямо в продуктив, и любая неожиданность (нехватка места, несовместимость версий) превращается в аварию.
Третья группа ошибок — организационные: не предупреждены пользователи о смене пути подключения, не перенастроены обмены и интеграции, которые обращались к файловой базе по старому пути, забыты внешние обработки и скрипты резервного копирования. Перед переключением составьте список всего, что взаимодействует с базой: обмены с сайтом, ЭДО, банк-клиенты, сторонние отчёты — и проверьте каждый пункт на новой базе.
Перед миграцией полезно выполнить тестирование и исправление файловой базы и удалить помеченные объекты: чем «чище» и компактнее исходная база, тем быстрее и надёжнее проходит выгрузка и загрузка .dt. Заодно это хороший повод провести ревизию неиспользуемых данных.
Частые вопросы о переходе 1С на SQL
Можно ли вернуться с SQL обратно на файловый режим?
Технически да: база выгружается в .dt и загружается в файловый вариант. На практике возврат почти никогда не оправдан, если причины перехода (число пользователей, объём) сохраняются. Именно поэтому решение о миграции стоит принимать осознанно, с запасом по ресурсам.
Нужна ли отдельная лицензия 1С для клиент-серверного режима?
Да. Помимо клиентских лицензий, требуется лицензия на сервер 1С:Предприятия соответствующего уровня. Плюс лицензия на саму СУБД, если используется коммерческий продукт вроде MS SQL Server в полной редакции. Эти затраты нужно заложить в бюджет перехода заранее.
Сколько времени занимает миграция?
Зависит от размера базы и оборудования. Выгрузка и загрузка .dt для базы в несколько гигабайт обычно укладывается в выходные, включая тестовый прогон. Основное время занимает не сама выгрузка, а подготовка серверов, проверка итогов и перенастройка интеграций.
Ускорит ли переход на SQL медленные отчёты?
Не гарантированно. Клиент-серверный режим устраняет проблему блокировок и параллельной работы, но конкретный медленный отчёт может быть следствием неоптимального запроса или нехватки индексов. Такие проблемы решаются анализом запросов и настройкой СУБД, а не самим фактом перехода.
Что лучше для небольшой компании: MS SQL или PostgreSQL?
Если бюджет ограничен и есть специалист, способный настроить PostgreSQL, — это рациональный выбор без лицензионных платежей. Если важнее предсказуемость, обилие документации и простота поиска администратора, чаще выбирают MS SQL Server. Для совсем небольших баз рассматривают бесплатную редакцию Express с учётом её ограничений.
Можно ли мигрировать без остановки работы пользователей?
Полностью без простоя обойтись нельзя: на время выгрузки .dt работу в базе нужно завершить, иначе данные будут несогласованными. Минимизировать простой помогает предварительный тестовый прогон, после которого финальная выгрузка делается быстро и по отработанному сценарию, обычно в нерабочее время.
Что важно запомнить
Переход на SQL оправдан при росте числа пользователей сверх 5–10, регулярных конфликтах блокировок, большом объёме базы и потребности в фоновых заданиях. Миграция выполняется выгрузкой и загрузкой .dt, но требует подготовки серверов, лицензий, тестового прогона и обязательной резервной копии. После перехода СУБД нужно настроить — сам по себе клиент-серверный режим скорость не гарантирует.