К статье
Практический материал

Администрирование · 11 мин

Как перевести файловую базу 1С 8.3 на SQL

Подробная инструкция по переносу файловой базы 1С 8.3 на SQL Server: выгрузка через dt, настройка сервера, создание базы в кластере и проверка результата.

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

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

Ниже разобран полный цикл: от оценки готовности инфраструктуры до проверки работоспособности базы после миграции, с типичными ошибками и способами их избежать.

Когда переход на SQL оправдан и что потребуется

Файловый режим имеет жёсткие ограничения: одновременная запись возможна только одним пользователем на уровне таблицы, база хранится в одном файле 1Cv8.1CD, который чувствителен к обрывам сети при размещении на сетевом диске. Признаки того, что пора переходить на клиент-серверный вариант: база заметно выросла, работают одновременно больше нескольких пользователей, регулярно возникают ошибки блокировок или повреждения файла.

Для миграции потребуется: установленный сервер 1С:Предприятия той же версии платформы, что и на клиентских машинах; установленная и настроенная СУБД (Microsoft SQL Server, PostgreSQL со сборкой от 1С, Oracle или IBM DB2 — в зависимости от лицензий); учётная запись с правами на создание баз данных в СУБД. Также нужен достаточный объём диска: файл .dt и база в СУБД вместе могут занять заметно больше места, чем исходный файл 1Cv8.1CD.

Подготовка: резервная копия и установка серверных компонентов

Первое действие перед любыми манипуляциями — резервная копия. Для файловой базы достаточно скопировать каталог базы целиком (как минимум файл 1Cv8.1CD) при завершённых сеансах всех пользователей. Не полагайтесь только на выгрузку .dt как на единственную копию: если выгрузка прервётся или файл окажется повреждён, копия каталога останется страховкой.

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

Убедитесь, что служба агента сервера 1С запущена, а служба СУБД доступна с сервера 1С. Если сервер 1С и СУБД размещены на разных машинах, проверьте сетевую доступность портов и разрешения в брандмауэре.

Выгрузка файловой базы в файл .dt

Откройте базу в режиме «Конфигуратор» под пользователем с полными правами. Перед выгрузкой завершите все сеансы других пользователей — в файловом режиме конфигуратор требует монопольного доступа. Затем в меню выберите «Администрирование» → «Выгрузить информационную базу» и укажите путь и имя файла, например base_backup.dt.

Выгрузка большой базы может занять продолжительное время — это нормально, не прерывайте процесс. После завершения проверьте, что файл создан и его размер адекватен размеру базы (обычно .dt заметно меньше исходного файла благодаря сжатию, но не должен быть подозрительно маленьким, например несколько мегабайт при базе в десятки гигабайт).

Полезная дополнительная мера — перед выгрузкой выполнить «Тестирование и исправление» информационной базы, чтобы в SQL-версию не перенести накопившиеся ошибки файловой базы. Как минимум стоит запустить проверку логической целостности.

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

Создание пустой базы на сервере 1С и в СУБД

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

Флажок «Создать базу данных в случае её отсутствия» должен быть установлен — тогда база в СУБД будет создана автоматически. Опцию «Установить блокировку регламентных заданий» на время загрузки лучше включить, чтобы сразу после создания не запускались фоновые задачи.

Альтернативный путь — создать базу прямо из диалога запуска 1С (кнопка «Добавить» → «Создание новой информационной базы» → «На сервере 1С:Предприятия»), выбрав вариант без конфигурации. Результат тот же: пустая база в кластере, готовая к загрузке .dt.

Загрузка .dt и первичная проверка

Откройте созданную пустую базу в конфигураторе (при входе платформа запросит авторизацию — используйте администратора кластера, если он задан). Выберите «Администрирование» → «Загрузить информационную базу» и укажите ранее выгруженный файл .dt. На предложение перезапустить конфигуратор после загрузки ответьте согласием.

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

Не забудьте про пользователей: список пользователей переносится вместе с базой, но если в файловом режиме использовалась аутентификация операционной системы, на сервере она может потребовать перенастройки. Также снимите блокировку регламентных заданий, если устанавливали её при создании базы, и проверьте, что фоновые задачи выполняются.

Контрольные точки

Как проверить результат

Запуск в режиме Предприятие
Норма

База открывается без ошибок, списки документов отображаются

Тревожный признак

Ошибки доступа к СУБД или несовпадения версии платформы

Целостность данных
Норма

Оборотно-сальдовая ведомость и ключевые отчёты совпадают с файловой версией

Тревожный признак

Расхождения в итогах или пустые регистры

Регламентные задания
Норма

Фоновые задачи выполняются по расписанию

Тревожный признак

Задания заблокированы или завершаются с ошибкой

Работа пользователей
Норма

Несколько пользователей одновременно проводят документы без конфликтов

Тревожный признак

Ошибки блокировок или отсутствие прав у части пользователей

Типичные ошибки и как их избежать

Самая частая проблема — попытка загрузить .dt, выгруженный под одной версией платформы, в базу на сервере с другой версией. Платформа либо откажется загружать, либо потребует конвертацию. Решение простое: привести версии к одной до начала переноса.

Вторая группа ошибок связана с СУБД: недостаточные права учётной записи, нехватка места под файлы данных и журнал транзакций, неверные настройки сортировки (collation) в MS SQL Server при ручном создании базы. Рекомендуется позволять консоли кластера создавать базу автоматически — тогда параметры будут выставлены корректно.

Третья типичная ситуация — после успешного переноса пользователи продолжают заходить в старую файловую копию. Уберите старую базу из списка у пользователей или переместите каталог, чтобы исключить параллельную работу в двух версиях базы — это прямой путь к рассинхронизации данных.

Типичные ошибки
01
Перенос без резервной копии каталога файловой базы — при сбое загрузки восстановить данные нечем
02
Разные версии платформы на клиенте и сервере — ошибка загрузки .dt или невозможность запуска
03
Создание базы в СУБД вручную с неверными параметрами вместо автосоздания из консоли кластера
04
Продолжение работы пользователей в старой файловой копии после миграции — расхождение данных
05
Забытая блокировка регламентных заданий — фоновые обмены и задачи молча не выполняются

Альтернативы и ограничения метода

Выгрузка через .dt — универсальный, но не единственный способ. Если база очень большая и окно простоя ограничено, можно рассмотреть инструменты репликации или сторонние средства переноса, однако для типовых конфигураций .dt остаётся самым надёжным и поддерживаемым вариантом. Обратный переход (с SQL на файловый режим) выполняется тем же способом — выгрузкой и загрузкой .dt.

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

Выбор СУБД для 1С

Microsoft SQL Server

Самый распространённый вариант для 1С, хорошо документирован, но требует платных лицензий при промышленном использовании

PostgreSQL (сборка 1С)

Бесплатная альтернатива, требует специальной сборки и более внимательной настройки параметров

Oracle / IBM DB2

Подходят для крупных внедрений при наличии соответствующей инфраструктуры и лицензий

Часто задаваемые вопросы

Можно ли перевести базу на SQL без конфигуратора?

Нет, выгрузка и загрузка .dt выполняются именно через конфигуратор. Альтернатива — пакетный режим запуска конфигуратора из командной строки с параметрами DumpIB и RestoreIB, что удобно для автоматизации, но это тот же механизм.

Перенесутся ли пользователи и их пароли?

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

Сколько времени занимает перенос?

Зависит от размера базы и производительности оборудования: небольшая база переносится за десятки минут, большая — за несколько часов. Планируйте миграцию на нерабочее время с запасом на проверку результата.

Что делать, если загрузка .dt прервалась с ошибкой?

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

Нужно ли менять настройки СУБД после миграции?

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

Можно ли вернуться обратно к файловому режиму?

Да, обратный переход делается тем же способом: выгрузка базы из клиент-серверного режима в .dt и загрузка в файловую базу. Однако при большом объёме данных файловый режим может оказаться неработоспособным из-за ограничений формата.

Итог

Что важно запомнить

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