Монопольный режим в 1С: что это и когда он нужен

Монопольный режим в 1С — это особое состояние информационной базы, при котором с ней работает только один сеанс, а все остальные пользователи и фоновые соединения блокируются. Пока режим активен, никто другой не может войти в базу, изменить данные или запустить регламентные задания. Это защищает структуру базы от конфликтов в моменты, когда выполняются критичные операции.

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

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

Что такое монопольный режим простыми словами

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

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

Для каких операций обязателен монопольный доступ

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

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

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

Как включить монопольный режим в конфигураторе

Самый частый сценарий — обновление конфигурации. Порядок действий для файловой базы:

1. Предупредите пользователей и попросите их выйти из программы. Дайте им время завершить документы и сохранить работу.
2. Запустите конфигуратор. Если в базе есть активные сеансы, платформа выдаст ошибку разделённого доступа при попытке обновления.
3. Откройте меню «Администрирование» → «Активные пользователи» и проверьте, кто ещё подключён.
4. Установите блокировку сеансов: «Администрирование» → «Блокировка установки соединений с информационной базой». Задайте сообщение для пользователей и код разблокировки.
5. Дождитесь завершения активных сеансов или завершите их принудительно через консоль кластера (для клиент-серверного варианта).
6. Выполните обновление конфигурации базы данных (F7 или «Конфигурация» → «Обновить конфигурацию базы данных»).
7. После завершения снимите блокировку соединений и сообщите пользователям о возобновлении работы.

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

Монопольный режим в клиент-серверном варианте

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

Для блокировки подключений в кластере используются свойства информационной базы: параметры «Блокировка начала сеансов включена», дата начала и окончания блокировки, сообщение и код разрешения. Это надёжнее, чем просьбы к пользователям выйти: новые сеансы просто не создаются, а существующие можно завершить по расписанию через дату начала блокировки.

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

Что делать, если монопольный режим не устанавливается

Типичная ситуация: все пользователи вышли, а конфигуратор всё равно сообщает об ошибке разделённого доступа. Причины обычно такие:

• Зависший сеанс — программа на чьём-то компьютере закрылась некорректно, но соединение осталось активным. В клиент-серверном варианте завершите его через консоль кластера.
• Фоновые или регламентные задания — они тоже создают сеансы. Отключите их на время обслуживания.
• Открытый второй конфигуратор или сеанс предприятия на самом компьютере администратора.
• Подключения через веб-сервисы, COM-соединения, планировщики обмена — внешние системы могут держать соединение с базой.
• Для файловой базы — файл базы открыт по сети другим процессом или антивирус блокирует корректное снятие блокировок.

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

Как проверить, что режим установлен и работа завершена корректно

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

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

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

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

Список активных пользователей

Норма

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

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

Есть чужие сеансы или фоновые задания

Запуск базы после обновления

Норма

Предприятие открывается, версия конфигурации новая

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

Ошибки при запуске, сообщения о несоответствии конфигураций

Блокировка соединений

Норма

Снята, пользователи входят штатно

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

Пользователи видят сообщение о блокировке после завершения работ

Частые вопросы о монопольном режиме

Можно ли обновить конфигурацию без монопольного режима?

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

Что будет, если завершить сеанс пользователя принудительно?

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

Почему база остаётся заблокированной после обновления?

Блокировка соединений не снимается автоматически. Администратор должен зайти в конфигуратор и отключить её в разделе «Блокировка установки соединений» или в свойствах базы в консоли кластера. Если задан код разблокировки, пользователи могут войти с ним, но штатно блокировку лучше снять.

Как выгнать зависший сеанс в файловой базе без консоли кластера?

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

Мешает ли монопольный режим обменам с другими системами?

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

Нужна ли резервная копия перед монопольными операциями?

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