Администрирование · 10 мин
Для чего делать SQL-базу 1С и когда это оправдано
Зачем переводить 1С на SQL-базу: отличия от файлового режима, условия выбора, настройка MS SQL и PostgreSQL, типичные ошибки и проверка результата.
1С:Предприятие умеет хранить данные двумя способами: в файловом варианте (один файл 1Cv8.1CD в папке) и в клиент-серверном — через СУБД, чаще всего Microsoft SQL Server или PostgreSQL. Файловый режим прост в запуске, но у него есть жёсткие ограничения по числу одновременных пользователей, размеру базы и устойчивости к сбоям. SQL-база снимает эти ограничения: данными управляет полноценная СУБД, а платформа 1С обращается к ней через сервер приложений или напрямую.
Практический смысл перехода на SQL — не «модная технология», а конкретные задачи: работа десятков пользователей одновременно без блокировок, базы объёмом в десятки и сотни гигабайт, регламентное резервное копирование без остановки работы, защита от потери данных при обрыве питания или сети. Если в файловой базе при отключении электричества можно получить повреждённый файл, то СУБД ведёт журнал транзакций и после сбоя откатывает незавершённые операции.
При этом SQL-режим требует отдельного сервера (или выделенной машины), лицензий на СУБД (кроме бесплатных сборок PostgreSQL) и администратора, который будет следить за обслуживанием базы. Для маленькой компании на 1–3 пользователя переход может быть избыточным. Ниже разобраны критерии выбора, порядок развёртывания и типичные ошибки.
Чем SQL-база отличается от файловой
В файловом режиме вся база — это один файл, к которому платформа обращается по сети или локально. Одновременная запись жёстко блокируется: пока один пользователь проводит документ, другие ждут. При росте базы заметно замедляются отчёты и проведение, а риск повреждения файла при сбое сети или питания остаётся высоким.
В клиент-серверном режиме данные лежат в СУБД, которая умеет параллельно выполнять запросы, кэшировать данные в оперативной памяти и гарантировать целостность транзакций. Платформа 1С формирует SQL-запросы, а СУБД оптимизирует их выполнение. Блокировки становятся более гранулярными — на уровне записей, а не всей таблицы.
Файловый и SQL-режимы
1–5 пользователей, база до нескольких гигабайт, нет выделенного сервера и администратора. Ограничение: блокировки при параллельной записи и риск повреждения файла.
Средние и крупные внедрения, инфраструктура Windows. Ограничение: стоимость лицензий на сервер и подключения.
Те же задачи без затрат на лицензии СУБД. Ограничение: требует более внимательной настройки и опыта администрирования.
Когда переход на SQL действительно нужен
Главные признаки того, что файловый режим исчерпал себя: пользователи жалуются на ожидание при проведении документов, отчёты строятся минутами, база регулярно «падает» с ошибками, резервная копия занимает часы и мешает работе. Дополнительный сигнал — необходимость организовать работу филиалов через веб-сервер или тонкий клиент по сети с нестабильным каналом.
Есть и организационные причины: требования безопасности (разграничение доступа на уровне СУБД, аудит), регламент резервного копирования без остановки работы, интеграция с другими системами напрямую через SQL-запросы. В этих сценариях файловый режим просто не предоставляет нужных инструментов.
Как выбрать действие
Что даёт SQL-база на практике
Первое — параллельная работа. СУБД обрабатывает запросы пользователей одновременно, используя несколько ядер процессора и кэш в памяти. Проведение документа одним менеджером перестаёт останавливать работу остальных.
Второе — надёжность. Журнал транзакций позволяет восстановить базу на момент времени, а не только на момент последней копии. При аварийном завершении СУБД сама откатывает незавершённые транзакции, и база остаётся согласованной.
Третье — обслуживание без простоя. Резервное копирование средствами СУБД выполняется «на горячую», пользователи продолжают работать. Переиндексация и обновление статистики планируются по расписанию.
Четвёртое — масштабируемость. При росте нагрузки можно добавить память, перенести СУБД на более мощный сервер или настроить кластер серверов 1С, не меняя саму конфигурацию.
Как развернуть SQL-базу: порядок действий
Общая схема одинакова для MS SQL и PostgreSQL: установить СУБД, установить сервер 1С:Предприятия, создать пустую базу через консоль кластера, загрузить в неё выгрузку (.dt) из файловой базы. Прямого «преобразования» файла 1Cv8.1CD в SQL не существует — данные переносятся именно через выгрузку/загрузку.
Перед началом проверьте совместимость версий: платформа 1С поддерживает определённые версии СУБД, указанные в системных требованиях. Для PostgreSQL нужна специальная сборка с патчами для 1С, стандартная версия с официального сайта не подойдёт.
- 1Сделайте полную выгрузку файловой базы в файл .dt и проверьте, что она загружается в тестовую копию
- 2Установите СУБД (MS SQL Server или сборку PostgreSQL для 1С) на выделенный сервер
- 3Установите сервер 1С:Предприятия и запустите агент кластера
- 4В консоли кластера создайте новую информационную базу, указав параметры подключения к СУБД
- 5Загрузите в новую базу выгрузку .dt через конфигуратор
- 6Настройте план обслуживания: резервное копирование, переиндексацию, обновление статистики
- 7Переведите пользователей на новую базу и неделю наблюдайте за производительностью и журналом ошибок
Особенности MS SQL Server
Для баз 1С рекомендуется задавать модель восстановления Full с регулярным копированием журнала транзакций, иначе журнал разрастётся и займёт весь диск. TempDB выносят на быстрый диск, а максимальный объём памяти сервера ограничивают, оставляя ресурс операционной системе.
Особенности PostgreSQL
Используйте сборку, адаптированную для 1С. После установки обязательно настройте параметры памяти (shared_buffers, work_mem) под объём оперативной памяти сервера — значения по умолчанию рассчитаны на слабые машины и не используют ресурсы сервера.
Риски и типичные ошибки
Самая частая ошибка — развёрнуть СУБД и забыть про обслуживание. Без регламентного копирования, переиндексации и обновления статистики база через несколько месяцев начинает тормозить сильнее, чем файловая. Вторая ошибка — ставить СУБД и сервер 1С на одну слабую машину с малым объёмом памяти: оба процесса конкурируют за ресурсы.
Третья группа ошибок — безопасность: пароль sa или postgres хранится в открытом виде, порт СУБД доступен из локальной сети всем, резервные копии лежат на том же диске, что и база. При выходе диска из строя теряется и база, и копия.
Как проверить, что переход удался
После загрузки базы сверьте контрольные показатели: остатки по основным регистрам (товары, взаиморасчёты, денежные средства) должны совпадать с файловой копией до копейки. Затем проверьте восстановление из резервной копии на тестовом сервере — копия, которую нельзя восстановить, не считается копией.
В течение первых недель наблюдайте за длительностью типовых операций и журналом регистрации. Рост времени проведения документов или ошибки взаимоблокировок — сигнал проверить настройки СУБД и индексы.
Как проверить результат
Совпадают с файловой копией до копейки
Расхождения в остатках или оборотах
Копия разворачивается на тестовом сервере без ошибок
Восстановление не проверялось или завершается ошибкой
Нет заметных ожиданий и ошибок блокировок
Взаимоблокировки, таймауты в журнале регистрации
Стабилен, копируется по расписанию
Непрерывно растёт и заполняет диск
FAQ
Можно ли просто скопировать файл 1Cv8.1CD в SQL Server?
Нет. Файловый и клиент-серверный форматы хранения несовместимы. Перенос выполняется только через выгрузку базы в файл .dt в конфигураторе и последующую загрузку в пустую SQL-базу, созданную через консоль кластера серверов 1С.
Сколько пользователей выдерживает файловая база?
Точного порога нет — он зависит от интенсивности записи. На практике комфортная работа обычно сохраняется до 3–5 одновременно работающих пользователей. При 10 и более активных пользователях блокировки и замедление становятся заметными, и стоит рассматривать клиент-серверный режим.
Что выбрать: MS SQL или PostgreSQL?
Если бюджет позволяет и инфраструктура построена на Windows, чаще выбирают MS SQL Server — он проще в сопровождении для типового администратора. PostgreSQL (специальная сборка для 1С) исключает затраты на лицензии СУБД, но требует более тщательной настройки и опыта администрирования Linux или Windows-сборок.
Нужно ли менять конфигурацию при переходе на SQL?
Обычно нет: типовые конфигурации работают в обоих режимах без доработки. Исключение — самописные решения с прямыми обращениями к файловой структуре или внешние обработки, рассчитанные на файловый режим. Их проверяют на тестовой копии до миграции.
Можно ли вернуться с SQL обратно на файловый режим?
Да, тем же способом: выгрузить базу в .dt из конфигуратора и загрузить в новую файловую базу. Учтите, что при большом объёме данных выгрузка и загрузка могут занять часы, а файловый режим снова вернёт ограничения по пользователям и надёжности.
Ускорит ли SQL медленные отчёты?
Только частично — за счёт кэширования данных в памяти и параллельного выполнения запросов. Если отчёт построен на неоптимальном запросе или обходе больших таблиц в коде, проблему решит доработка запроса и индексов, а не сам переход на SQL.
Что важно запомнить
SQL-база 1С нужна для параллельной работы десятков пользователей, больших объёмов данных, надёжного резервного копирования и защиты от сбоев. Переход выполняется через выгрузку .dt, требует выделенного сервера, правильной настройки СУБД и регламентного обслуживания. Без плана обслуживания и проверки восстановления копий SQL-режим создаёт больше рисков, чем решает.