На чём хранит данные 1С:Предприятие 8.3 и какую СУБД выбрать

1С:Предприятие 8.3 работает с базой данных в одном из двух режимов. Файловый — все данные лежат в одном файле 1Cv8.1CD, СУБД встроена в платформу. Клиент-серверный — данные хранятся во внешней СУБД: Microsoft SQL Server, PostgreSQL, IBM Db2 или Oracle Database, а между пользователями и СУБД стоит сервер 1С.

Чаще всего на практике встречаются два варианта: файловая база у небольших фирм и связка «сервер 1С + MS SQL или PostgreSQL» у всех, кто вырос из 5–10 одновременных пользователей. Конфигурация (БП, ЗУП, УТ) при этом одна и та же: прикладной код не зависит от того, где физически лежат таблицы.

Файловая база 1С: что внутри и когда её хватает

Файловая база — это каталог, в котором лежит файл 1Cv8.1CD. В нём хранятся и данные, и конфигурация, и служебные таблицы. Рядом платформа создаёт файлы блокировок и временные файлы, а журнал регистрации пишет в подкаталог 1Cv8Log.

Отдельной СУБД ставить не нужно. Достаточно установить платформу и указать путь к каталогу при добавлении базы в список.

Сильные стороны файлового режима:

• 🟢 ноль затрат на сервер и лицензии СУБД;
• 🟢 база переносится простым копированием каталога;
• 🟢 развернуть новую базу из шаблона — пара минут;
• 🟢 удобно для разработки, тестовых копий, учёта одного ИП.

Слабые стороны:

• 🔴 блокировки грубые: пока один пользователь проводит документ, другие ждут — при 8–10 активных пользователях это уже заметно;
• 🔴 работа по сети через общую папку медленная и чувствительна к обрывам — обрыв во время записи может повредить файл;
• 🔴 крупные базы (десятки гигабайт) открываются и обрабатываются долго;
• 🔴 нет штатных средств СУБД: журнала транзакций, восстановления на момент времени, тонкой настройки.

Ориентир по выбору простой. До 3–5 одновременных пользователей и база до 5–10 ГБ — файлового режима обычно хватает. Если пользователей больше, идут регламентные обмены и тяжёлые закрытия месяца — пора думать о клиент-серверном варианте.

Как устроен клиент-серверный вариант 1С

В клиент-серверной схеме три звена:

1. Клиент — тонкий, толстый или веб-клиент на рабочем месте.
2. Кластер серверов 1С — служба «Агент сервера 1С:Предприятия» (ragent), менеджер кластера (rmngr) и рабочие процессы (rphost), которые выполняют код конфигурации.
3. СУБД — хранит таблицы, индексы, выполняет запросы.

Клиент сначала обращается к агенту сервера (по умолчанию порт 1540), затем к менеджеру кластера (1541) и дальше работает с рабочими процессами. Их порты берутся из диапазона, который задаётся в свойствах рабочего сервера (по умолчанию 1560–1591). Если между клиентами и сервером стоит брандмауэр, открывать нужно все три группы.

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

Главный выигрыш — блокировки. В клиент-серверном режиме современные конфигурации используют управляемые блокировки на уровне записей. Два бухгалтера проводят документы по разным контрагентам и не мешают друг другу.

Сравнение СУБД для 1С: MS SQL Server, PostgreSQL, Db2, Oracle

Платформа 8.3 поддерживает четыре внешние СУБД. Конкретные поддерживаемые версии зависят от релиза платформы, их перечень публикуется в системных требованиях к каждому релизу.

Для 1С используют не любой PostgreSQL «из репозитория», а сборки с патчами под 1С. Их распространяет сама фирма 1С (на портале обновлений для владельцев лицензий) и Postgres Professional. Ванильный PostgreSQL без патчей с 1С работать не будет или будет работать с ошибками.

Как выбрать на практике:

• 🧮 Уже есть Windows-инфраструктура и лицензии MS SQL — оставайтесь на MS SQL, переход ради перехода не окупится.
• 🐧 Новый сервер, бюджет ограничен или требование отечественного ПО — PostgreSQL с патчами для 1С на Linux.
• 🏢 Db2 или Oracle — только если эта СУБД уже стоит в компании и есть администратор под неё.

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

Перенос базы 1С из файлового режима в SQL

Универсальный способ — через файл выгрузки .dt. Он не зависит от СУБД: так же переносят базу и обратно, из SQL в файл.

Шаг 1. Выгрузите файловую базу

1. Попросите пользователей выйти из базы.
2. Откройте базу в Конфигураторе.
3. Выберите Администрирование → Выгрузить информационную базу и сохраните файл .dt.

Отдельно сохраните копию каталога с 1Cv8.1CD — это откат, если что-то пойдёт не так.

Шаг 2. Создайте базу на сервере 1С

В окне запуска 1С нажмите Добавить → Создание новой информационной базы → Создание информационной базы без конфигурации и выберите вариант «На сервере 1С:Предприятия». Заполните поля:

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

Шаг 3. Загрузите данные

1. Откройте новую пустую базу в Конфигураторе.
2. Выберите Администрирование → Загрузить информационную базу и укажите файл .dt.
3. Подтвердите замену данных и дождитесь окончания загрузки.

Для базы на 5–10 ГБ загрузка занимает от получаса до нескольких часов — зависит от дисков и СУБД.

Шаг 4. Проверьте и переключите пользователей

• ✅ откройте базу в режиме предприятия, сверьте ОСВ и остатки с файловой копией;
• ✅ проверьте, что пользователи и права перенеслись (они входят в .dt);
• ✅ удалите из списка баз на рабочих местах старую файловую базу или переименуйте её в «Архив», чтобы никто не продолжил работу в ней.

Обслуживание и скорость: на что смотреть в каждом режиме

Каждый режим требует своего регламента. Файловая база «сама в себе», в клиент-серверной обслуживать нужно и сервер 1С, и СУБД.

Файловая база

• 🔧 Раз в месяц–квартал — Администрирование → Тестирование и исправление в Конфигураторе. Режим требует монопольного доступа.
• 🔧 Для запуска без Конфигуратора есть утилита chdbfl.exe в каталоге bin платформы — проверка физической целостности файла.
• 🔧 Держите базу на локальном SSD, а не на сетевом хранилище с нестабильным соединением.
• 🔧 Исключите каталог базы из проверки антивирусом «на лету» — сканирование 1Cv8.1CD при каждой записи тормозит работу.

MS SQL Server

• 📈 Регулярно обновляйте статистику и перестраивайте индексы — через план обслуживания SQL Server, ночью.
• 📈 Ограничьте максимальную память SQL Server (max server memory), если на той же машине работает сервер 1С: иначе SQL заберёт почти всё ОЗУ.
• 📈 Следите за размером журнала транзакций: в модели восстановления Full без резервного копирования журнала он растёт бесконечно.
• 📈 Вынесите tempdb на быстрый диск.

PostgreSQL

• 🐘 Настройте shared_buffers, effective_cache_size, work_mem под объём памяти — с настройками по умолчанию СУБД рассчитана на очень скромное железо.
• 🐘 Проверьте, что работает autovacuum, и периодически запускайте VACUUM ANALYZE для крупных таблиц.
• 🐘 Ставьте ту сборку и версию PostgreSQL, которая указана как поддерживаемая для вашего релиза платформы.

Со стороны сервера 1С

• 🖥️ Сеансы, блокировки и рабочие процессы смотрят в консоли кластера или утилитой rac. Список сеансов выводит rac session list, параметры остальных команд — в rac help.
• 🖥️ Технологический журнал включают файлом logcfg.xml — он нужен при разборе медленных запросов и взаимоблокировок.

Резервные копии базы 1С: файл, .dt и средства СУБД

Способ копирования зависит от режима. Ниже — что реально работает и чем каждый вариант опасен.

Для MS SQL полный бэкап выглядит так:

BACKUP DATABASE [buh_main]
TO DISK = N'D:\Backup\buh_main_full.bak'
WITH COMPRESSION, CHECKSUM, INIT;

Для PostgreSQL — выгрузка одной базы в сжатый формат:

pg_dump -U postgres -h localhost -F c -f D:\Backup\buh_main.backup buh_main

Восстанавливают такую копию утилитой pg_restore в пустую базу.

Чтобы бэкап действительно спас, соблюдайте три правила:

1. Храните копии не на том же диске, где база. Отказ диска уносит и базу, и копии.
2. Держите несколько поколений — например, 7 ежедневных и 4 еженедельных. Ошибку в данных часто замечают через неделю.
3. Раз в квартал проверяйте восстановление на тестовом сервере. Копия, которую ни разу не разворачивали, — это надежда, а не бэкап.

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