Почему при выгрузке информационной базы 1С в файл dt через командную строку возникает ошибка монопольного доступа?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Разберем распространенную ситуацию: настроен скрипт резервного копирования или регулярной выгрузки базы данных в файл .dt с помощью параметров командной строки. Некоторое время сценарий отрабатывает корректно, однако в определенный момент процесс начинает прерываться. В лог-файле фиксируется сообщение: «Ошибка монопольного доступа. Запущен Конфигуратор», при этом в целевом каталоге создается пустой файл нулевого размера, который затем удаляется. Если запустить аналогичную строку для файловой базы данных, операция проходит без ошибок.

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

Анализ причин ошибки монопольного доступа

Выясним причину возникновения ошибки в журнале. Сообщение «Ошибка монопольного доступа. Запущен Конфигуратор» часто ошибочно воспринимается администраторами так, будто платформа конфликтует сама с собой при запуске фонового процесса. На самом деле платформа 1С сообщает о наличии реального препятствия на сервере:

  1. Зависший или сторонний сеанс Конфигуратора. Для выполнения операции выгрузки данных через параметр /DumpIB требуется исключительный монопольный доступ. Если в информационной базе активен хотя бы один сеанс с типом приложения «Конфигуратор» (забытая открытая сессия программиста или зависший процесс после сетевого сбоя), сервер 1С заблокирует выгрузку. В файловом варианте таких скрытых серверных сессий не остается, поэтому файловая база отрабатывает штатно.
  2. Синтаксические ошибки вызова командной строки. В строке запуска нередко дублируют режим (например, 1cv8 DESIGNER DESIGNER вместо одного 1cv8 DESIGNER или 1cv8 CONFIG). Также не рекомендуется использовать в путях спецсимволы командного интерпретатора (например, символ #), способные нарушить разбор параметров пакетного файла.

Пошаговое решение: корректная автоматизация выгрузки dt

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

  1. Установка блокировки соединений. Перед запуском Конфигуратора необходимо заблокировать начало новых сеансов пользователей и регламентных заданий на уровне кластера серверов 1С с указанием кода разрешения (ключа блокировки).
  2. Завершение активных сеансов. Принудительно завершаем все активные пользовательские и фоновые сеансы, а также зависшие сессии Конфигуратора с помощью консольной утилиты администрирования rac (команда rac session terminate) либо сценарием на базе v83.COMConnector.
  3. Запуск выгрузки с кодом разрешения. Передаем ключ доступа через параметр /UC, чтобы запущенный процесс Конфигуратора мог войти в заблокированную базу:

"C:\Program Files\1cv8\current\bin\1cv8.exe" DESIGNER /S"TSERV\Master" /N"autobackup" /P"123" /UC"BackupKey" /DumpIB "C:\autobackup\autobackup.dt" /DumpResult "C:\autobackup\result.txt" /Out "C:\autobackup\backup.log" -NoTruncate
  1. Проверка кода возврата и снятие блокировки. Параметр /DumpResult запишет в указанный файл числовой результат выполнения (0 свидетельствует об успешном завершении). После завершения выгрузки скрипт снимает блокировку информационной базы.

Ограничения формата dt для баз объемом от 30 Гб

Рассмотрим подробнее архитектурные особенности формата .dt, о которых важно помнить при работе с объемными базами:

  1. Разрядность платформы. При выгрузке базы размером 30 Гб и более стандартный 32-разрядный клиент может аварийно завершить работу из-за нехватки адресного пространства памяти. Всегда указывайте путь к 64-разрядной версии исполняемого файла 1cv8.exe (из каталога Program Files).
  2. Неприменимость для файловых копий. Если выгрузка .dt создается для разворачивания тестовой копии в файловом режиме (.1CD), информационная база объемом 30 Гб с высокой вероятностью не сможет загрузиться из-за внутреннего платформенного лимита: размер отдельной таблицы файловой базы не может превышать 4 Гб.

Альтернативные способы создания резервных копий и тестовых баз

Посмотрим на практические альтернативы, которые рекомендуются для промышленных баз данных на MS SQL Server или PostgreSQL:

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

BACKUP DATABASE [Master] 
TO DISK = N'C:\backup\Master.bak' 
WITH COMPRESSION, INIT, STATS = 10;

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

  1. Использование автономного сервера (ibcmd). В платформе 1С:Предприятие 8.3 доступна утилита ibcmd, позволяющая осуществлять дамп информационной базы командой ibcmd infobase dump напрямую на сервере без необходимости открывать графический Конфигуратор и перегружать сеансы кластера.
← На главную