Администрирование · 11 мин
Как выкинуть пользователей из базы 1С на сервере
Способы отключить пользователей от серверной базы 1С: консоль кластера, блокировка сеансов, принудительное завершение соединений. Риски и порядок действий.
Отключить пользователей от серверной базы 1С нужно при обновлении конфигурации, регламентных операциях с СУБД, восстановлении из резервной копии или когда зависший сеанс блокирует работу других. В клиент-серверном варианте соединениями управляет агент сервера 1С:Предприятия, поэтому все основные действия выполняются через консоль кластера серверов, а не через файловую систему и не через саму СУБД.
Есть три рабочих подхода: штатное завершение сеансов через консоль кластера, установка блокировки сеансов с принудительным отключением и «тяжёлые» способы вроде перезапуска службы агента сервера или отключения соединений средствами MS SQL / PostgreSQL. Правильный выбор зависит от ситуации: плановое обновление требует мягкого сценария с предупреждением пользователей, а зависший фоновый процесс иногда приходится снимать принудительно.
Главный риск любого принудительного отключения — потеря несохранённых данных у пользователей и «оборванные» транзакции в СУБД. Поэтому перед жёсткими действиями всегда стоит убедиться, что резервная копия свежая, а пользователи предупреждены.
Как устроены сеансы и соединения в клиент-серверной 1С
Пользователь, запустивший клиент 1С, создаёт сеанс — логическую сессию, зарегистрированную в кластере серверов. Сеанс обслуживается рабочим процессом (rphost), который, в свою очередь, держит соединение с сервером СУБД. Это важно понимать: удаление сеанса в консоли кластера разрывает всю цепочку, а удаление соединения только на стороне SQL-сервера оставляет «осиротевший» сеанс, который 1С может переподключить.
Кроме пользовательских сеансов в базе висят системные: фоновые задания, сеансы веб-сервисов, COM-соединения, сеанс самой консоли кластера. Перед массовым отключением проверьте колонки «Приложение» и «Пользователь» в списке сеансов, чтобы случайно не снять регламентное задание или интеграционный обмен.
Способ 1. Завершение сеансов через консоль кластера серверов
Это основной и самый управляемый способ. Консоль кластера доступна на сервере, где установлен агент 1С:Предприятия: «Пуск → 1С:Предприятие → Администрирование серверов 1С Предприятия», либо через оснастку MMC. Также её можно запустить с машины администратора, подключившись к серверу по сети.
- 1Откройте консоль «Администрирование серверов 1С Предприятия» и разверните нужный кластер.
- 2Перейдите в ветку «Информационные базы» → ваша база → «Сеансы».
- 3Отсортируйте список по пользователю или приложению, выделите нужные сеансы (Ctrl или Shift для группы).
- 4Нажмите «Удалить» в контекстном меню или на панели инструментов.
- 5Обновите список и убедитесь, что сеансы исчезли, а новые не появляются.
У пользователя при этом клиент закрывается с сообщением о разрыве соединения с сервером. Несохранённые данные форм теряются, поэтому перед массовым удалением разошлите предупреждение — хотя бы через корпоративный мессенджер или встроенный механизм сообщений блокировки сеансов.
Если сеанс после удаления появляется снова, значит, пользователь (или автоматика) тут же переподключается. В этом случае сначала включите блокировку сеансов — о ней ниже.
Способ 2. Блокировка сеансов в свойствах информационной базы
Блокировка не выкидывает уже подключённых, но запрещает новые входы — это обязательный элемент планового сценария. Откройте свойства информационной базы в консоли кластера (правый клик → «Свойства») и установите флажок «Блокировка регламентных заданий включена» и «Блокировка начала сеансов включена».
В параметрах блокировки можно задать время начала и окончания, код разрешения и сообщение пользователям. Код разрешения позволяет администратору зайти в базу во время блокировки: при входе его указывают в параметре запуска /UC КодРазрешения. Сообщение увидят те, кто попытается войти в период блокировки.
Способ 3. Программное отключение через административный интерфейс и скрипты
Для регулярных операций удобнее автоматизировать отключение. Есть несколько вариантов:
- Консольная утилита RAC — штатный инструмент из каталога сервера 1С, позволяет получить список сеансов и завершить их из командной строки или скрипта.
- Административный веб-сервер (RAS) — даёт те же возможности по HTTP, удобен для интеграции с системами оркестрации.
- Обработки на встроенном языке — через COM-объект V83.COMConnector можно подключиться к агенту сервера и программно удалить сеансы.
Пример получения списка сеансов и их завершения через RAC:
rac session --cluster=<ID_кластера> list --infobase=<ID_базы>
rac session --cluster=<ID_кластера> terminate --infobase=<ID_базы> --session=<ID_сеанса>Автоматизация особенно оправдана, когда обновление выполняется ночью по расписанию: скрипт включает блокировку, ждёт заданный интервал, снимает оставшиеся сеансы, запускает обновление и снимает блокировку. Тестируйте такой сценарий на копии базы — ошибка в идентификаторах кластера или базы может снять сеансы не там.
Способ 4. Жёсткие варианты: перезапуск службы и отключение на стороне СУБД
Когда консоль кластера недоступна или сеансы «зависли» и не удаляются, остаются грубые методы. Перезапуск службы «Агент сервера 1С:Предприятия» обрывает все сеансы всех баз кластера разом. Это допустимо в нерабочее время или при полном зависании сервера, но не подходит, если на том же кластере работают другие продуктивные базы.
Отключение соединений на стороне СУБД (например, через Activity Monitor в MS SQL Server или запросом к pg_stat_activity с pg_terminate_backend в PostgreSQL) — крайняя мера. Сеанс в кластере 1С при этом может остаться «живым» и порождать ошибки у клиента, а оборванная транзакция будет откатываться, что на больших базах занимает заметное время.
Как выбрать подходящий способ
Как выбрать действие
Сравнение способов
Точечно и безопасно, видно всех пользователей. Требует ручной работы и прав администратора кластера.
Идеальна для плановых работ, предупреждает пользователей. Не отключает уже вошедших.
Подходят для автоматизации. Требуют настройки и проверки идентификаторов.
Быстро и гарантированно, но рвёт все базы кластера и теряет несохранённые данные.
Крайняя мера при зависании. Оставляет осиротевшие сеансы и риск долгого отката транзакций.
Проверка результата и типичные ошибки
После отключения обновите список сеансов в консоли кластера: он должен быть пустым либо содержать только ваш административный сеанс и разрешённые системные. Дополнительно проверьте соединения на стороне СУБД — после удаления сеансов они должны закрыться в течение короткого времени. Если соединения висят, а сеансов нет, это признак «залипших» процессов rphost, которые иногда приходится завершать вручную.
Как проверить результат
Пусто или только разрешённые системные сеансы
Сеансы появляются снова — блокировка не включена или работает автоматика
Закрываются вскоре после удаления сеансов
Десятки висящих соединений без сеансов — зависшие rphost
Появляется заданное сообщение о блокировке
Пользователь входит свободно — блокировка не применилась или снята
Не выполняются в период блокировки
Задания продолжают работать — блокировка регламентных заданий не включена
Держите под рукой заранее записанные идентификаторы кластера и информационных баз для RAC-скриптов: в аварийной ситуации искать их в консоли некогда. Идентификаторы можно один раз выгрузить командами rac cluster list и rac infobase summary list.
Частые вопросы
Можно ли выкинуть пользователей, не имея доступа к консоли кластера?
Да, если настроен RAC на сервере или поднят RAS — обе утилиты работают удалённо. Также можно попросить администратора СУБД завершить соединения, но это менее чистый способ. Без доступа ни к одному из этих инструментов отключить пользователей серверной базы штатно нельзя.
Что увидит пользователь при принудительном завершении сеанса?
Клиентское приложение закроется с сообщением о разрыве соединения с сервером. Все несохранённые данные в открытых формах будут потеряны, отменить это нельзя. Поэтому перед массовым отключением пользователей стоит предупредить заранее.
Как зайти в базу, пока действует блокировка сеансов?
Запустите клиент с параметром /UC и кодом разрешения, заданным в свойствах блокировки, например: /UC Админ2026. Без кода войти сможет только тот, кто снимет блокировку через консоль кластера или RAC.
Удалил сеансы, а они появляются снова. Что делать?
Значит, пользователи или автоматика переподключаются. Включите блокировку начала сеансов в свойствах базы, затем снова удалите сеансы. Проверьте также внешние подключения: обмены, веб-сервисы и планировщики могут создавать сеансы без участия людей.
Опасно ли перезапускать службу агента сервера 1С?
Сама операция штатная, но она обрывает все сеансы всех баз кластера с потерей несохранённых данных. Выполняйте её в нерабочее время и убедитесь, что никакие длительные процессы (обновление, загрузка данных) не выполняются.
Нужно ли отключать пользователей файловой базы так же?
Нет, файловая база не использует кластер серверов. Там применяют блокировку через параметр запуска, механизм «Завершение работы пользователей» из БСП или простое закрытие общего доступа к каталогу базы — но это отдельная тема со своими ограничениями.
Что важно запомнить
Основной инструмент — консоль кластера серверов: блокировка сеансов для плановых работ и удаление сеансов для отключения. Перед принудительными действиями проверьте активные транзакции и наличие свежей резервной копии, а отключения на стороне СУБД оставьте как крайнюю меру.