MS SQL, PostgreSQL или Oracle под 1С 8.3: как устроен сервер СУБД и на чём его собрать

Сервер базы данных 1С — это СУБД (Microsoft SQL Server, PostgreSQL, Oracle Database или IBM Db2), в которой физически лежат таблицы информационной базы при клиент-серверном варианте работы. Сама 1С в ней ничего не «хранит» напрямую: запросы пользователей обрабатывает сервер 1С:Предприятия, а он уже обращается к СУБД. Для большинства компаний выбор сводится к двум вариантам — MS SQL Server или PostgreSQL в сборке для 1С.

Переходить с файловой базы на сервер СУБД имеет смысл, когда одновременно работают 10–15 человек и больше, база перевалила за несколько гигабайт или нужны регламентные задания, которые идут без открытого клиента. Ниже — как выбрать СУБД, на каком железе её поднять, что настроить в первый день и как не потерять данные.

Где сервер СУБД стоит в схеме клиент-серверной 1С

В клиент-серверном варианте участвуют три звена:

1. 💻 Клиент — тонкий клиент, толстый клиент или браузер. Он не видит СУБД вообще.
2. ⚙️ Сервер 1С:Предприятия — служба ragent (агент), менеджер кластера rmngr и рабочие процессы rphost. Клиент подключается к агенту по порту 1540, затем к менеджеру кластера (1541) и к рабочим процессам из диапазона портов, который задаётся в свойствах рабочего сервера.
3. 🗄️ Сервер СУБД — принимает SQL-запросы от рабочих процессов 1С и возвращает данные. У MS SQL стандартный порт 1433, у PostgreSQL — 5432.

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

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

Какие СУБД поддерживает 1С 8.3 и чем они отличаются

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

Microsoft SQL Server

Исторически самый распространённый вариант. Хорошо отлаженный оптимизатор, удобная графическая утилита SQL Server Management Studio, понятные планы обслуживания. Минус — стоимость: для рабочей базы нужна лицензия SQL Server (Standard или Enterprise), а с 2022 года купить её в России официально стало сложно. Бесплатная редакция Express для 1С годится только на тест: у неё ограничение на размер базы (10 ГБ) и на используемую память.

PostgreSQL в сборке для 1С

Бесплатная СУБД, но не «чистая»: для 1С нужна сборка с патчами, которые добавляют типы и функции, нужные платформе (например, тип mchar). Такие сборки распространяют фирма 1С и компания Postgres Professional (Postgres Pro, в том числе редакции, сертифицированные для госсектора). Обычный PostgreSQL из репозитория дистрибутива Linux 1С не подойдёт.

PostgreSQL отлично живёт на Linux, что убирает ещё и затраты на Windows Server. На некоторых тяжёлых отчётах и запросах он может уступать MS SQL, но в свежих версиях платформы и сборок разница заметно сократилась.

Oracle Database и IBM Db2

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

Сравнение СУБД для 1С в одной таблице

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

Требования к железу сервера базы данных

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

На что смотреть в первую очередь:

• 🚀 Частота ядра важнее числа ядер. Многие операции 1С идут в один поток, и 3,5 ГГц дадут больше, чем 2,2 ГГц при вдвое большем числе ядер.
• 🧠 Память под кэш СУБД. Хорошо, когда активная часть базы помещается в память целиком. База 40 ГБ на сервере с 16 ГБ будет постоянно читать с диска.
• 💾 Только SSD. На обычных HDD сервер СУБД под 1С сегодня не ставят: время отклика диска сразу ограничивает всё остальное.
• 🔌 Сеть 1 Гбит/с и выше между сервером 1С и СУБД, если они на разных машинах. Задержка важнее пропускной способности.
• 🖥️ Виртуализация допустима, но СУБД лучше выделить фиксированные ядра и память без переподписки.

Первичная настройка СУБД под 1С

Установить СУБД «по умолчанию» и забыть — частая причина жалоб на медленную 1С. Несколько параметров нужно поправить сразу.

MS SQL Server

1. Ограничьте память. В свойствах сервера в SSMS (Properties → Memory) задайте Maximum server memory. Если 1С и SQL на одной машине с 64 ГБ, оставьте SQL около 40–44 ГБ, остальное — системе и рабочим процессам 1С. Без ограничения SQL заберёт почти всю память.
2. Выставьте Max Degree of Parallelism = 1. Для нагрузки 1С (много коротких запросов) параллельные планы чаще мешают, чем помогают. Это давняя рекомендация для 1С на MS SQL.
3. Выберите модель восстановления. Full — если нужна точка восстановления на любой момент и вы делаете бэкапы журнала транзакций. Simple — если хватает ночной полной копии. Модель Full без бэкапов журнала приводит к бесконечному росту файла .ldf.
4. Вынесите tempdb на быстрый диск и сделайте несколько файлов данных одинакового размера (обычно по числу ядер, но не больше 8).

PostgreSQL

Основные параметры задаются в postgresql.conf. Пример для сервера с 32 ГБ памяти, где PostgreSQL делит машину с сервером 1С:

shared_buffers = 8GB
effective_cache_size = 20GB
work_mem = 64MB
maintenance_work_mem = 1GB
max_connections = 500
random_page_cost = 1.1
checkpoint_timeout = 15min
max_wal_size = 8GB

• shared_buffers — около 25% памяти машины.
• effective_cache_size — подсказка планировщику, сколько данных реально в кэше ОС; ставят 50–75% памяти.
• random_page_cost = 1.1 — для SSD, иначе планировщик считает случайное чтение дорогим и выбирает плохие планы.
• max_connections — с запасом: каждый рабочий процесс 1С открывает несколько соединений.

Регламентное обслуживание

Устаревшие статистики — одна из самых частых причин внезапной «тормозящей» 1С при неизменной нагрузке: оптимизатор строит план по старым данным и выбирает полный просмотр таблицы вместо поиска по индексу.

Резервное копирование на уровне СУБД

В клиент-серверной базе выгрузка .dt из Конфигуратора — это не основной бэкап. Она требует монопольного доступа, долго идёт на больших базах и не даёт восстановиться на конкретный момент. Основной инструмент — средства самой СУБД.

MS SQL Server:

• полная копия (Full) — раз в сутки ночью;
• разностная (Differential) — днём, если база большая;
• копии журнала транзакций — каждые 15–60 минут при модели Full.

BACKUP DATABASE [buh] TO DISK = N'D:\Backup\buh_full.bak' WITH COMPRESSION, CHECKSUM;
BACKUP LOG [buh] TO DISK = N'D:\Backup\buh_log.trn' WITH COMPRESSION, CHECKSUM;

PostgreSQL:

• логическая копия pg_dump в формате custom — для баз до нескольких десятков гигабайт;
• физическая копия pg_basebackup плюс архив WAL — когда нужна точка восстановления на любой момент.

pg_dump -U postgres -Fc -f /backup/buh_$(date +%F).dump buh
pg_restore -U postgres -d buh_test /backup/buh_2026-10-07.dump

Правила, без которых бэкап ничего не стоит:

1. 📦 Копии хранятся не на том же диске и не на том же сервере, что база.
2. 🔁 Есть хотя бы одна копия вне офиса или вне основного дата-центра.
3. 🧪 Восстановление проверяется: раз в месяц разверните копию в тестовую базу, опубликуйте её в кластере и откройте в 1С.

Бэкап, который ни разу не восстанавливали, считайте несуществующим.

Типичные проблемы сервера БД 1С и что с ними делать

Частые вопросы о сервере базы данных для 1С