Сеанс без разделения данных и «висящие» подключения: разбор для администратора 1С

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

Частое заблуждение: «неразделенный сеанс» считают синонимом зависшего. Это разные вещи. Зависший сеанс — это подключение, от которого ушёл пользователь, а сервер его ещё держит. Но на практике оба случая лечат в одном месте — в консоли кластера, поэтому ниже разобраны оба.

Что такое неразделенный сеанс и как он возникает

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

Разработчик помечает общие реквизиты как разделители. Дальше в каждом сеансе платформа знает два значения:

• 🔹 используется ли разделитель в этом сеансе;
• 🔹 значение разделителя — номер области данных.

Если разделитель включён и значение задано, сеанс разделенный: он видит только свою область. Если разделитель выключен, сеанс неразделенный: он работает с общими данными и может обращаться ко всем областям.

Откуда берутся такие сеансы

• 🛠 Администратор сервиса зашёл в базу без указания области — так входят, чтобы обслуживать общие справочники и настройки.
• ⚙️ Регламентные и фоновые задания, которые запускаются от имени системы, а не от пользователя области.
• 🔌 Внешнее соединение или COM-подключение, в строке которого не указаны разделители.
• 🧩 Обычная база без разделения. В типовой Бухгалтерии на своём сервере все сеансы формально неразделенные — разделителей там просто не используют. Для такой базы это нормальное состояние, а не сбой.

Разделители при запуске задаются параметром командной строки /Z, а в строке соединения — отдельным параметром. Конкретные значения зависят от конфигурации, поэтому берите их у того, кто сопровождает решение в модели сервиса.

Когда это становится проблемой

Программа ругается на неразделенный сеанс в двух ситуациях:

1. Код, рассчитанный на работу внутри области, запустился без неё. Например, фоновое задание пытается записать документ, а область не выбрана.
2. Пользователь области зашёл в обход штатного входа, без разделителей. Типовые решения для модели сервиса такой вход блокируют или ограничивают.

В обоих случаях лечится не сеанс, а способ запуска: нужно указать область или запустить задание из правильного контекста.

Как найти проблемный сеанс в консоли кластера

Все сеансы клиент-серверной базы видны в консоли администрирования серверов 1С. Порядок такой:

1. Откройте консоль, разверните Центральные серверы 1С:Предприятия → <сервер> → Кластеры → <кластер>.
2. Откройте Информационные базы → <база> → Сеансы.
3. Отсортируйте список по колонке времени последней активности. Сеансы, где этот момент был часы назад, — первые кандидаты.

На что смотреть в строке сеанса:

То же самое через rac

Если консоль не открывается или серверов много, удобнее утилита rac. Перед ней должна работать служба ras (сервер администрирования).

rac cluster list
rac infobase summary list --cluster=<uuid-кластера>
rac session list --cluster=<uuid-кластера> --infobase=<uuid-базы>

В выводе rac session list у каждого сеанса есть поле data-separation. Пустое значение — сеанс без разделителей. Там же поля app-id, host, user-name, last-active-at и hibernate. По ним видно, кто, откуда и когда последний раз что-то делал.

Если на кластере задан администратор, добавьте к каждой команде --cluster-user и --cluster-pwd. Полный список параметров выдаёт rac help session.

Как завершить и очистить сеансы: от мягкого к жёсткому

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

Способ 1. Попросить пользователя выйти

Звучит банально, но решает половину вопросов без риска. В файловой базе этот способ вообще основной: список подключённых виден в Конфигураторе через Администрирование → Активные пользователи.

Способ 2. Завершить один сеанс в консоли

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

Через rac то же самое:

rac session terminate --cluster=<uuid-кластера> --session=<uuid-сеанса>

Способ 3. Запретить новые сеансы и выгнать всех

Нужен, когда предстоит обновление или когда сеансы плодятся быстрее, чем вы их удаляете. В свойствах информационной базы в консоли включите блокировку начала сеансов, задайте сообщение и код разрешения. Затем завершите оставшиеся сеансы. Сами вы сможете войти с параметром /UC<код>.

Способ 4. Перезапустить рабочий процесс

Если сеанс не удаляется или удаляется и тут же появляется снова, виноват рабочий процесс rphost. Его можно выключить в консоли в разделе Рабочие процессы.

Способ 5. Перезапуск службы с очисткой сеансовых данных

Крайняя мера, когда кластер «помнит» сеансы, которых уже нет. Порядок:

1. Остановите службу «Агент сервера 1С:Предприятия 8.3».
2. В каталоге кластера (по умолчанию srvinfo\reg_1541) удалите папки snccntx* — это кэш сеансовых данных.
3. Запустите службу.

Сеть и оборудование: почему сеансы отрываются

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

Типовые источники:

• 📶 Wi-Fi и VPN. Ноутбук ушёл в сон, VPN переподключился с новым адресом — старый сеанс остался на сервере.
• 🔥 Межсетевой экран и NAT. Простаивающие TCP-соединения обрываются по таймауту на маршрутизаторе, а сервер об этом не знает.
• 🖥 Терминальный сервер . Пользователь закрыл окно RDP крестиком, а не вышел из системы. Его сеанс Windows живёт, 1С внутри него тоже.
• 🔌 Аварийное выключение рабочей станции или зависание клиента.
• 🧱 Закрытые порты. Клиент обращается к агенту на порт 1540, затем к менеджеру кластера на 1541 и к рабочим процессам — диапазон портов задаётся в свойствах рабочего сервера, по умолчанию 1560–1591. Если часть диапазона перекрыта, подключения рвутся на ровном месте.

Что проверить

1. Для терминального сервера настройте в групповых политиках завершение отключённых сеансов Windows через разумное время, например 2–4 часа.
2. Проверьте, что на межсетевом экране открыт весь диапазон портов рабочих процессов, а не только 1540–1541.
3. Если пользователи ходят через VPN, посмотрите таймаут простоя на шлюзе. Слишком короткий таймаут — частая причина массовых обрывов.
4. Сверьте имена: сервер 1С должен находить клиентов и сам себя по имени. Ошибки разрешения имён дают обрывы, похожие на сетевые.

Профилактика: что настроить в кластере

Полностью избавиться от зависших сеансов нельзя — сеть иногда рвётся. Но можно сделать так, чтобы они не копились неделями.

Свойства кластера:

• ⏱ Интервал перезапуска — рабочие процессы перезапускаются по расписанию, и вместе с ними уходят накопившиеся «хвосты». Значение в секундах; 86 400 соответствует суткам.
• 💾 Допустимый объём памяти и интервал его превышения — процесс, раздувшийся из-за утечки, будет перезапущен до того, как начнёт тормозить всех.
• 🧹 Принудительно завершать проблемные процессы — кластер сам выключит процесс, который перестал отвечать.

Свойства информационной базы:

• 🔒 Блокировку регламентных заданий включайте на время обслуживания, чтобы фоновые сеансы не мешали.

Организационные меры:

• 📋 Правило для пользователей: закрывать 1С через меню, а не крестиком окна терминала.
• 📅 Обновления и обслуживание — в окно, когда в базе никого нет.
• 👀 Раз в неделю просматривать список сеансов, отсортированный по последней активности.

Блокировки на уровне СУБД: кто кого держит

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

В выводе rac session list полезны поля:

• blocked-by-dbms — номер соединения, которое блокирует этот сеанс в СУБД;
• blocked-by-ls — сеанс ждёт управляемую блокировку 1С;
• db-proc-info и db-proc-took — что сейчас выполняется в СУБД и сколько длится.

Список управляемых блокировок показывает команда:

rac lock list --cluster=<uuid-кластера> --infobase=<uuid-базы>

MS SQL Server

Посмотреть, кто кого блокирует:

SELECT session_id, blocking_session_id, wait_type, wait_time, status, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Цепочку разматывайте до сеанса, у которого blocking_session_id равен нулю, а сам он кого-то держит. Это голова блокировки.

PostgreSQL

SELECT pid, pg_blocking_pids(pid) AS blocked_by, state, wait_event_type, query_start, left(query, 80)
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Отдельно ищите соединения в состоянии idle in transaction с давним query_start — это и есть брошенные транзакции.

Частые ошибки

• ❌ Массово удалять все сеансы без разделителей. В обычной базе это все сеансы подряд, включая работающих бухгалтеров.
• ❌ Удалять фоновый сеанс посреди обмена или закрытия месяца. Задание прервётся, и его придётся перезапускать, а иногда — чистить частично записанные данные.
• ❌ Перезапускать службу днём ради одного зависшего сеанса, когда хватило бы rac session terminate.
• ❌ Удалять весь каталог reg_1541 вместо папок snccntx*. Вместе с ним пропадут настройки кластера и список баз.
• ❌ Лечить симптом. Если зависшие сеансы появляются каждый день у одних и тех же людей, ищите причину в сети или терминальном сервере, а не чистите консоль по утрам.

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