Как устранить ошибку получения монопольного доступа и зависшие соединения при обновлении базы 1С?

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

Выясним причину расхождения сеансов и соединений

Проанализируем внутренние механизмы взаимодействия клиентских приложений, сервера 1С и СУБД:

1. Разделение логических сеансов и физических соединений: В консоли кластера в ветке «Сеансы» отображаются пользовательские сеансы и фоновые задания, а в ветке «Соединения» — реальные соединения рабочего процесса rphost с сервером СУБД. Платформа активно использует механизм пула соединений (connection pooling). Даже когда пользователь завершил работу или фоновое задание отработало, физическое подключение к СУБД может удерживаться процессом rphost еще некоторое время.
2. Распределение нескольких баз на один процесс: Если в свойствах кластера разрешено обслуживание нескольких информационных баз одним рабочим процессом rphost, пул соединений становится общим для них. В этом случае соединения других баз могут учитываться сервером при попытке монопольной блокировки рабочей базы.
3. Автоматический перезапуск фоновых заданий: Если в базе активен планировщик регламентных заданий, после принудительного удаления сеанса из консоли кластер тут же инициирует запуск нового фонового задания, что препятствует установке монопольного режима.
4. Зависшие транзакции в СУБД: На уровне сервера 1С сессия может выглядеть закрытой, но на стороне SQL-сервера транзакция может находиться в состоянии отката или ожидания снятия блокировок системных таблиц.

Основное решение: изоляция информационных баз по рабочим процессам

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

1. Откроем консоль администрирования серверов 1С:Предприятия.
2. Перейдем в свойства нужного кластера серверов.
3. Найдем параметр «Количество ИБ на один процесс» (в старых версиях платформы или расширенных свойствах сервера) и установим его значение равным 1.
4. Применим изменения. В результате кластер выделит под каждую информационную базу отдельные процессы rphost, что исключит конфликт пулов соединений и удерживание блокировок соседними базами данных.

Правильная подготовка базы к обновлению без перезапуска службы

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

1. В консоли кластера откроем свойства целевой информационной базы.
2. Установим флаг «Блокировка регламентных заданий включена», чтобы фоновые задачи не создавались заново.
3. Установим флаг «Блокировка начала сеансов включена», укажем понятное пользователям текстовое сообщение и зададим «Код разрешения» (например, AdminUpdate).
4. Завершим оставшиеся пользовательские сеансы через ветку «Сеансы».
5. Запустим конфигуратор информационной базы с ключом разрешения запуска в командной строке или свойствах ярлыка: 1cv8.exe DESIGNER /IBConnectionString "..." /UC "AdminUpdate"
6. Выполним обновление конфигурации базы данных.

Сброс зависших подключений на стороне СУБД

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

В среде Microsoft SQL Server выявим блокирующие сессии системной процедурой sp_who2 или через системные представления, после чего завершим зависший процесс командой:

-- Завершение зависшей сессии по ее SPID
KILL 58;

В среде PostgreSQL найдем идентификаторы процессов (PID) и принудительно разорвем их соединение с целевой базой:

-- Принудительное завершение всех сессий к указанной базе
SELECT pg_terminate_backend(pid) 
FROM pg_stat_activity 
WHERE datname = 'TradeManagement' 
  AND pid <> pg_backend_pid();

Профилактические настройки кластера 1С

Для предотвращения накопления утечек памяти и зависания неактивных пулов соединений в процессе регулярной эксплуатации настроим параметры кластера 1С:

1. Интервал перезапуска рабочих процессов: Зададим периодичность автоматического мягкого перезапуска процессов rphost (например, 86400 секунд — раз в сутки в нерабочее время). Кластер запустит новые процессы для свежих сеансов и плавно остановит старые по мере завершения текущих задач.
2. Ограничения по памяти: Настроим параметры «Допустимый объем памяти» и «Интервал превышения допустимого объема памяти», что защитит сервер от падения при некорректных ресурсоемких запросах.
3. Таймауты пассивных сеансов: Зададим параметры «Время засыпания пассивного сеанса» и «Время завершения спящего сеанса», чтобы брошенные клиентские приложения автоматически отключались от сервера баз данных.