СУБД под 1С:Предприятие: роль, выбор между PostgreSQL и MS SQL, обслуживание

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

Сама 1С с данными на диске не работает . Её сервер (кластер с рабочими процессами rphost) получает запросы от пользователей, переводит их на язык SQL и отправляет в СУБД. Хранение, индексы, блокировки на уровне записей, журнал транзакций и бэкап — зона ответственности сервера баз данных.

Как СУБД встроена в клиент-серверную 1С

В клиент-серверной схеме три звена. Путать их — главная причина неправильных настроек и долгих поисков ошибок.

Порядок подключения такой:

1. Клиент обращается к агенту сервера 1С (по умолчанию порт 1540).
2. Агент направляет его к менеджеру кластера (1541) и в рабочий процесс (диапазон портов задаётся в свойствах рабочего сервера, по умолчанию 1560–1591).
3. Рабочий процесс подключается к СУБД: PostgreSQL слушает 5432, MS SQL Server — 1433.

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

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

Чем сервер СУБД отличается от сервера 1С

• 🗄️ Сервер СУБД знает только таблицы и SQL. Он понятия не имеет, что такое «документ Реализация» или «регистр накоплений».
• ⚙️ Сервер 1С знает метаданные конфигурации, права пользователей, управляемые блокировки, регламентные задания и лицензии.
• 🔑 Лицензия на сервер 1С покупается у 1С. Лицензия на СУБД — отдельно у её производителя (у PostgreSQL она не нужна).

Таблицы в базе называются вроде _Document123 или _AccumRg456. Смотреть их можно, а вот писать в них SQL-запросами в обход 1С нельзя: платформа ничего не узнает об изменениях, итоги регистров и ссылочная целостность поедут.

PostgreSQL или MS SQL Server: что выбрать

Платформа 8.3 работает с четырьмя СУБД: Microsoft SQL Server, PostgreSQL, IBM Db2 и Oracle Database. На практике в России выбирают между первыми двумя.

Когда брать PostgreSQL

• 🐘 Новая инсталляция, где нет купленных лицензий Microsoft.
• 🐧 Сервер планируется на Linux: там PostgreSQL — естественный выбор.
• 🏛️ Организации с требованиями импортозамещения: выбирают сертифицированные российские сборки.

⚠️ Ванильный PostgreSQL с сайта проекта для 1С не подойдёт. Нужна сборка с патчами для 1С: в ней доработаны типы данных и поведение планировщика под запросы платформы. Берите дистрибутив, совместимость которого с вашей версией платформы заявлена производителем.

Когда оставаться на MS SQL Server

• 💼 Лицензии Standard или Enterprise уже куплены и действуют.
• 🧑‍💻 Администратор привык к Windows и SSMS, опыта с Linux нет.
• 📊 Есть внешние отчёты и интеграции, завязанные на T-SQL.

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

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

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

Цифры примерные. Узкое место почти всегда одно из трёх.

• 💾 Диск. Журнал транзакций пишется синхронно при каждом проведении. Медленный диск даёт тормоза, даже если процессор отдыхает. HDD под рабочую базу не годится вообще.
• 🧠 Память. Чем больше горячих данных помещается в кеш СУБД, тем меньше чтений с диска. Хорошо, когда в ОЗУ входит хотя бы треть базы.
• ⚡ Частота ядра. Многие запросы 1С выполняются в один поток. Высокая частота важнее числа ядер.

💡 Виртуализация допустима. Следите только, чтобы гипервизор не делил диск базы с другими нагруженными машинами и не отбирал память через балансировку.

Настройка СУБД и индексы

Начальные параметры по умолчанию рассчитаны на скромные машины. После установки их нужно поднять под реальный объём памяти.

MS SQL Server

1. Максимальная память сервера (max server memory). Без ограничения SQL Server забирает почти всю ОЗУ и вытесняет процессы rphost. Оставьте операционной системе 4–6 ГБ, а если сервер 1С на той же машине — ещё по 1–2 ГБ на каждый рабочий процесс.
2. Степень параллелизма (max degree of parallelism). Для 1С обычно ставят 1: параллельные планы на коротких запросах платформы чаще мешают, чем помогают.
3. Модель восстановления. Full — если нужен откат на любую минуту, Simple — если хватает ночной копии. Подробнее в разделе про резервные копии.
4. tempdb. Платформа активно использует временные таблицы. Вынесите tempdb на быстрый диск и разбейте на несколько файлов одинакового размера (по числу ядер, но не больше 8).

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 49152;  -- 48 ГБ из 64
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;

PostgreSQL

Основные параметры лежат в файле postgresql.conf. Для сервера с 64 ГБ памяти, где работает и 1С:

shared_buffers = 16GB            # около 25% ОЗУ
effective_cache_size = 40GB      # сколько ОС и СУБД реально держат в кеше
work_mem = 64MB                  # на одну операцию сортировки
maintenance_work_mem = 2GB       # для VACUUM и построения индексов
autovacuum = on

После правки параметра shared_buffers нужен перезапуск службы PostgreSQL. Перезапуск обрывает все сеансы 1С в этой базе — делайте его вне рабочего времени и предупредите пользователей.

Что с индексами

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

⚠️ Индекс, созданный в обход 1С, исчезнет при следующей реструктуризации базы после обновления конфигурации. Нужен дополнительный индекс — пусть разработчик включит индексирование реквизита в Конфигураторе.

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

В SQL Server всё это удобно собрать в план обслуживания через SQL Server Agent (его нет в редакции Express — там задания запускают через планировщик Windows).

Резервное копирование базы на сервере СУБД

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

MS SQL Server

При модели Full схема такая: полная копия раз в сутки и копия журнала каждые 15–60 минут.

-- Полная копия, ночью
BACKUP DATABASE [buh] TO DISK = N'D:\Backup\buh_full.bak'
  WITH COMPRESSION, CHECKSUM, INIT;

-- Журнал транзакций, каждые 30 минут
BACKUP LOG [buh] TO DISK = N'D:\Backup\buh_log.trn'
  WITH COMPRESSION, CHECKSUM;

Без регулярного бэкапа журнала при модели Full файл журнала растёт, пока не займёт весь диск. Если копии журнала не нужны, переключите базу на Simple.

PostgreSQL

Простой вариант — ночной дамп в сжатом формате:

pg_dump -U postgres -Fc -f /backup/buh_$(date +%F).dump buh

Восстановление в новую пустую базу:

createdb -U postgres buh_test
pg_restore -U postgres -d buh_test /backup/buh_2026-10-07.dump

Для восстановления на любой момент времени настраивают архивирование WAL-журналов (archive_mode, archive_command) или используют утилиты вроде pg_probackup.

💡 Восстановленную базу подключают к кластеру 1С как новую информационную базу: в консоли администрирования серверов Информационные базы → Создать, указываете имя базы в СУБД и снимаете флажок создания базы, если она уже существует.

Создание информационной базы на сервере СУБД

Базу в СУБД обычно создаёт сама 1С. Так правильнее: платформа выставит нужную кодировку и параметры сортировки.

1. Откройте консоль администрирования серверов 1С:Предприятия и разверните кластер.
2. Правой кнопкой по ветке Информационные базы → Создать → Информационная база.
3. Заполните поля: имя в кластере, защищённое соединение, сервер баз данных (имя или адрес машины с СУБД), тип СУБД, имя базы в СУБД, пользователь и пароль СУБД.
4. Отметьте флажок создания базы данных в случае её отсутствия.
5. Укажите смещение дат: для MS SQL Server обычно 2000, для PostgreSQL — 0.
6. Для копии рабочей базы включите блокировку регламентных заданий — иначе тестовая копия начнёт обмениваться данными и отправлять отчёты вместо рабочей.

Пользователь СУБД для 1С на MS SQL обычно получает роль dbcreator (чтобы создавать базы) или права владельца нужной базы. Давать sysadmin без нужды не стоит.

Ошибки сервера баз данных и как их разбирать

Большинство сбоев видно по тексту ошибки: 1С пересылает сообщение СУБД почти дословно, после слов Ошибка СУБД:. Читайте его до конца — там обычно и написана причина.

Чего не делать

• 🚫 Не правьте данные таблиц 1С прямыми SQL-запросами UPDATE и DELETE.
• 🚫 Не сжимайте базу MS SQL (SHRINK) по расписанию: после этого индексы фрагментируются, а файл снова растёт.
• 🚫 Не отключайте autovacuum в PostgreSQL: таблицы распухнут, запросы замедлятся.
• 🚫 Не обновляйте основную версию СУБД, не проверив, что она поддерживается вашей версией платформы.

Частые вопросы