1С: сервер захвачен пользователем СУБД — что это значит и как устранить

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

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

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

Что означает сообщение о захвате сервера

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

Вторая распространённая ситуация — администратор баз данных подключился к базе напрячую через Management Studio, pgAdmin или консольную утилиту и выполняет операции, которые удерживают монопольные блокировки. С точки зрения кластера 1С это выглядит как постороннее вмешательство.

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

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

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

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

Как диагностировать источник захвата

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

Далее перейдите на уровень СУБД. Для MS SQL Server выполните запрос к системным представлениям, чтобы увидеть активные соединения с конкретной базой. Для PostgreSQL используйте представление pg_stat_activity. Цель — найти процессы, которые подключены к базе, но не принадлежат рабочим процессам кластера 1С, либо зависшие транзакции в состоянии idle in transaction.

-- MS SQL: кто подключён к базе
SELECT session_id, login_name, host_name, program_name, status, last_request_start_time
FROM sys.dm_exec_sessions
WHERE database_id = DB_ID('ИмяБазы');

-- PostgreSQL: активные и зависшие соединения
SELECT pid, usename, application_name, state, query_start, state_change
FROM pg_stat_activity
WHERE datname = 'ИмяБазы';

Обратите внимание на поле program_name (MS SQL) или application_name (PostgreSQL): рабочие процессы 1С обычно идентифицируются как rphost. Соединения от Management Studio, sqlcmd, pgAdmin, psql или неизвестных приложений — кандидаты на источник захвата.

Пошаговое устранение проблемы

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

1. 1
   В консоли кластера 1С проверьте сеансы: завершите зависшие сеансы пользователей штатно через кнопку «Удалить»
2. 2
   Проверьте свойства информационной базы: снимите блокировку соединений, если она осталась после регламентных работ
3. 3
   В СУБД найдите посторонние или зависшие соединения с базой и завершите их (KILL в MS SQL, pg_terminate_backend в PostgreSQL)
4. 4
   Если соединения завершить не удаётся или ошибка повторяется — перезапустите службу агента сервера 1С, предупредив пользователей
5. 5
   После восстановления доступа проверьте журнал регистрации и технологический журнал на предмет повторения ситуации

Завершение процесса в MS SQL выполняется командой KILL с номером session_id, в PostgreSQL — функцией pg_terminate_backend(pid). Перед завершением убедитесь, что процесс действительно завис, а не выполняет важную операцию: посмотрите время последнего запроса и текст текущей команды.

Профилактика повторения ошибки

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

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

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

Когда привлекать специалиста

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

Частые вопросы