Короткий ответ

Зависший сеанс снимайте точечно: консоль кластера или rac session terminate по UUID сеанса базы Accounting. Перед этим посмотрите, не идёт ли запись: лучше сохранить документ у пользователя, если UI ещё жив. Не убивайте все rphost, не останавливайте ragent и не делайте KILL всех подключений Accounting на SQL01. Цель — разорвать один сеанс и его транзакцию, оставив кластер и остальных живыми.

Если зависли все сразу — это уже кластер или диск/SQL, не «убить сеанс».

Симптомы и как отличить

Типичная картина:

  • у одного пользователя 1С не рисует, в Диспетчере задач 1cv8c.exe 0–5% CPU;
  • коллеги на том же документе/регистре ждут;
  • в кластере сеанс есть, «время вызова» растёт;
  • на SQL01: blocking_session_id указывает на SPID этого сеанса.

Отличия:

НаблюдениеДействие
UI жив, «идёт проведение 5 минут»подождать или смотреть запрос, не terminate сразу
Клиент мёртв, сеанс в кластере живterminate сеанса
Сеанса в кластере нет, SQL SPID естьточечный KILL SPID после проверки
Все сеансы мертвы, ragent Downне сеанс, кластер
База Suspectsuspect

Возможные причины

  1. Открытая транзакция: отладка, конструктор запроса, обмен, «форма зависла на сервере».
  2. Блокировка 1С (управляемые блокировки) + SQL lock.
  3. Сеть оборвала клиент, сеанс остался.
  4. Тяжёлый запрос, пользователь думает, что «зависло».
  5. Взаимоблокировка 1205.
  6. Редко: завивший rphost только этого рабочего процесса — тогда точечный разбор, не kill all.

Диагностика

1. Кластер

Консоль: инфобаза Accounting → сеансы. Зафиксируйте пользователя, приложение, время начала, «захвачено СУБД», номер сеанса.

& 'C:\Program Files\1cv8\8.3.23.1782\bin\rac.exe' session list --cluster=<cluster-uuid> --infobase=<infobase-uuid>

2. SQL01, база Accounting

SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time, r.status, r.command,
       t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.database_id = DB_ID(N'Accounting');

SELECT s.session_id, s.login_name, s.host_name, s.program_name, s.status
FROM sys.dm_exec_sessions s
WHERE s.database_id = DB_ID(N'Accounting') OR s.session_id IN (
  SELECT session_id FROM sys.dm_exec_requests WHERE database_id = DB_ID(N'Accounting')
);

program_name 1С обычно содержит имя инфобазы/кластера. Сопоставьте с сеансом кластера, не гадайте SPID.

3. Не путать с медленной работой

Если wait меняется и CPU SQL есть — это медленно, terminate оборвёт проведение. Смотрите запросы.

Решение

Сценарий A. Клиент ещё на экране

Попросите сохранить / закрыть форму. Если проведение идёт и SQL активен — не terminate.

Сценарий B. Клиент мёртв, сеанс в кластере есть

В консоли: завершить сеанс. Либо:

& 'C:\Program Files\1cv8\8.3.23.1782\bin\rac.exe' session terminate --cluster=<cluster-uuid> --session=<session-uuid>

Дождитесь исчезновения сеанса и что blocker на SQL пропал. Пользователь открывает 1С заново.

Сценарий C. Сеанса 1С нет, SPID остался

Тогда на SQL01 один KILL <spid> после подтверждения, что это тот самый коннект 1С к Accounting. Не трогайте SPID backup, CheckDB, Agent.

-- только после идентификации
-- KILL 136;

Проверьте sys.dm_tran_database_transactions: rollback может идти минуты на большом документе — это нормально, не рестартуйте SQL.

Сценарий D. Нужен рестарт рабочего процесса

Если один rphost не отвечает и консоль не завершает сеансы: в кластере перезапуск этого рабочего процесса, не всего агента. Окно согласовать.

Контур SRV-1C / SQL01: как не развалить остальных

На живом кластере сначала отделите «один сеанс» от «все ждут диск». Если rphost всех баз на SRV-1C стоит на 100% CPU, terminate одного бухгалтера не поможет: снимите замер, как в статье про производительность. Если SQL01 показывает один blocking_session_id, а в кластере этому SPID соответствует сеанс Accounting — работайте с этим UUID.

Практика на терминальном сервере: пользователь закрыл RDP крестиком, 1cv8c.exe мог остаться, серверный сеанс жив. Не reboot RDS. В консоли кластера найдите сеанс по имени пользователя RDS и завершите. Если сеансов несколько (предприятие + конфигуратор + обмен) — не снимайте конфигуратор, если в нём идёт штатная операция; сначала поговорите с консультантом.

После terminate подождите rollback на SQL01. В sys.dm_exec_requests статус KILLED/ROLLBACK — не рестартуйте MSSQLSERVER «чтобы быстрее». На большой таблице регистров 1С rollback может идти дольше, чем само проведение. Сообщите складу, что документ может откатиться полностью — пусть не вводят повторно, пока не увидят отсутствие номера в журнале.

Если после снятия сеанса коллеги всё ещё ждут, повторите запрос blocking: возможно, второй сеанс (регламент РегламентныеЗадания / обмен) держит ту же таблицу. Его тоже завершают штатно, не KILL 1 (это не Oracle). Для 1С никогда не используйте SHUTDOWN SQL как способ снять блокировку.

Запишите в заявку: пользователь, номер сеанса 1С, SPID, wait_type, длительность rollback, что стало с документом (проведён / отсутствует / частично — последнее недопустимо, разбирайте с консультантом на копии).

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

  • Пользователь вошёл снова, документ не задвоен (проверьте номер).
  • У коллег проведение проходит.
  • blocking_session_id пустой.
  • Число сеансов в кластере = реально работающие люди + регламент.

Если не помогло

  • Сразу новый завис — ищите обмен/регламент, который держит таблицу.
  • KILL не завершается — rollback, ждите; смотрите kill_rollback.
  • После terminate база в сомнительном состоянии — не EMERGENCY; смотрите журнал SQL, не чините файлы.
  • Пользователь снова в отладке на проде — запретите отладку на боевом кластере.

Профилактика

  • Запрет отладки на прод-SRV-1C.
  • Таймауты блокировок 1С осознанно, не 0 «ждать вечно» без политики.
  • Мониторинг blocking на SQL01.
  • Регламентные задания не в рабочий пик склада.
  • Обучение: не уходить на обед в транзакции.

FAQ

Пользователь просит «просто перезагрузить сервер 1С».

Сначала terminate его сеанса. Ребут SRV-1C бьёт всех и SQL-транзакции.

Terminate vs удаление сеанса в разных пунктах меню.

Цель одна: штатный сброс сеанса кластером. Не параллельте с KILL, если сеанс ещё уходит сам.

Можно ли снять сеанс, если идёт закрытие месяца?

Оборвёте расчёт. Сначала статус операции и SQL CPU/IO. Лучше дождаться или согласовать повтор закрытия.

Почему после снятия сеанса лицензия всё ещё занята?

Подождите обновления счётчика; если слот завис — см. лицензия, иногда нужен повторный terminate хвоста.

Task Manager на ПК пользователя помогает?

Убийство 1cv8c.exe на ПК не всегда убивает серверный сеанс. Смотрите кластер, не только клиент.