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

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

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

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

Когда переход на SQL действительно необходим

Не каждой базе нужен клиент-серверный вариант. Если с базой работают 3–5 человек и её размер не превышает нескольких гигабайт, файловый режим справляется, а переход на SQL добавит лишь затраты на лицензии и администрирование. Решение принимают по конкретным признакам, а не «для надёжности на будущее».

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

Выбор СУБД и подготовка сервера

Платформа 1С:Предприятие поддерживает несколько СУБД. Наиболее распространённый вариант — Microsoft SQL Server; бесплатная альтернатива — PostgreSQL в специальной сборке, адаптированной для 1С. Также поддерживаются Oracle Database и IBM Db2, но в типовых внедрениях они встречаются редко.

Выбор зависит от бюджета и компетенций. MS SQL проще в сопровождении для администраторов Windows-инфраструктуры, но требует лицензий (бесплатный Express-выпуск имеет ограничения по памяти и размеру базы, что для рабочих баз обычно недостаточно). PostgreSQL бесплатен, но требует отдельной сборки и большей аккуратности при настройке.

Сравнение СУБД для 1С

Microsoft SQL Server

Подходит большинству организаций на Windows; простая настройка, но нужны лицензии. Express-выпуск ограничен и подходит только для малых баз.

PostgreSQL (сборка для 1С)

Бесплатный вариант; требует установки специальной сборки и более внимательной настройки параметров.

Oracle / Db2

Оправданы при наличии корпоративных лицензий и опыта сопровождения; для типовых задач избыточны.

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

Подготовка файловой базы к выгрузке

Перед выгрузкой базу нужно привести в порядок. Первый шаг — полная резервная копия: скопируйте файл 1Cv8.1CD целиком при закрытых сеансах либо сделайте выгрузку через конфигуратор. Это единственная страховка на случай повреждения данных в процессе.

Затем выполните тестирование и исправление информационной базы (конфигуратор → Администрирование → Тестирование и исправление) с проверками логической и ссылочной целостности. Ошибки, которые в файловом режиме не мешали работе, при загрузке на SQL могут привести к сбою. Также завершите все непроведённые или помеченные на удаление объекты по регламенту вашей организации — переносить «мусор» на новую платформу нет смысла.

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

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

Создание серверной базы и загрузка данных

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

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

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

Проверка результата и первые настройки

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

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

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

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

Открытие справочников и документов

Норма

Списки открываются, записи на месте, количество совпадает с файловой копией

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

Пустые списки, ошибки при открытии объектов

Проведение документа

Норма

Документ проводится без ошибок блокировок и ссылочной целостности

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

Ошибки СУБД, битые ссылки, зависания

Сверка отчётов

Норма

ОСВ и остатки совпадают с данными файловой базы до копейки

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

Расхождения в итогах — признак неполной загрузки

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

Норма

Задания выполняются по расписанию на сервере

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

Задания не стартуют или падают с ошибками подключения

Типичные ошибки и ограничения

Большинство проблем миграции связано не с самой загрузкой, а с окружением. Частая ошибка — разные версии платформы: выгрузка сделана на одной версии, а сервер развёрнут на другой, более старой. Второй типовой сценарий — недостаток места на дисках SQL Server: при загрузке журнал транзакций может вырасти в разы, и диск переполняется на середине процесса.

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

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

Частые вопросы о переходе с файловой 1С на SQL

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

Нет, штатный способ миграции между файловым и клиент-серверным режимом — только через выгрузку и загрузку файла .dt в конфигураторе. Прямого преобразования файла 1Cv8.1CD в базу SQL Server не существует. Сторонние инструменты ускорения переноса существуют, но требуют отдельной проверки и опыта.

Потеряются ли данные, настройки и пользователи при переходе?

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

Какая СУБД лучше для небольшой организации — MS SQL или PostgreSQL?

Если бюджет ограничен и есть специалист, готовый сопровождать PostgreSQL, разумно выбрать бесплатную сборку PostgreSQL для 1С. Если в инфраструктуре уже есть лицензии MS SQL и администратор Windows — проще и предсказуемее MS SQL. По производительности для типовых нагрузок оба варианта при корректной настройке сопоставимы.

Сколько времени занимает миграция?

Выгрузка и загрузка базы объёмом в несколько гигабайт обычно укладывается в несколько часов; базы в десятки гигабайт могут загружаться сутки и дольше. К этому добавьте время на тестирование, настройку сервера и проверку данных. Планируйте переход на выходные или праздники с запасом времени.

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

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

Ускорит ли переход на SQL работу отчётов и проведение документов?

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