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

При работе в клиент-серверном варианте информационной базы пользователи нередко сталкиваются с ситуацией, когда при попытке открыть документ, отредактировать элемент справочника или сформировать отчет система выдает сообщение вида: «Ошибка блокировки объекта. Объект уже заблокирован: компьютер: PC7, пользователь: Иван, сеанс: 7, начат: ... приложение: Толстый клиент». Выясним причину такого поведения платформы и разберем по шагам, как снять блокировку без перезагрузки всего сервера.

Почему возникает ошибка блокировки объекта

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

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

Основное решение: завершение сеанса через консоль администрирования серверов 1С

Рассмотрим самый быстрый и надежный способ устранения проблемы, не требующий перезагрузки физического сервера или остановки службы кластера. Разберем по шагам порядок действий:

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

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

Альтернативные способы снятия зависших сеансов

Бывают ситуации, когда графическая консоль администрирования недоступна или доступ к серверу ограничен только командной строкой. Рассмотрим альтернативные методы управления сеансами кластера.

1. Использование утилиты командной строки RAC

В составе платформы 1С поставляется утилита rac, работающая в связке со службой администрирования ras. С ее помощью можно найти и удалить зависший сеанс скриптом:

# Получение списка сеансов базы
rac session --cluster=<ИдентификаторКластера> list --ibase=<ИдентификаторБазы>

# Принудительное завершение конкретного сеанса по его UUID
rac session --cluster=<ИдентификаторКластера> terminate --session=<UUID_Сеанса>

2. Завершение зависших транзакций на уровне СУБД

Если сеанс уже удален из кластера 1С, но ошибка блокировки сохраняется на уровне СУБД (например, в MS SQL Server или PostgreSQL), транзакция может удерживать эксклюзивные блокировки таблиц. В таком случае администратор СУБД может найти блокирующий процесс через системные представления и принудительно завершить его командой KILL <SPID> в среде управления базой данных.

3. Перезапуск рабочего процесса кластера

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

Настройка кластера для автоматического предотвращения подобных сбоев

Чтобы минимизировать появление «мертвых» блокировок при регулярных скачках сети или питания, настроим параметры самой информационной базы в консоли кластера 1С:

1. Откроем свойства нужной информационной базы в консоли администрирования.
2. Установим параметр «Время засыпания пассивных сеансов» (например, 1200 секунд). По истечении этого времени неактивный сеанс будет переведен платформой в спящий режим.
3. Установим параметр «Время завершения спящих сеансов» (например, 600 секунд). Если от спящего клиента не поступит запросов, кластер автоматически закроет сессию и освободит ресурсы.

Также рекомендуется скорректировать сетевые таймауты операционной системы сервера: параметр KeepAliveTime в реестре сетевого стека Windows по умолчанию составляет 2 часа. Уменьшение этого интервала (например, до 5–10 минут) заставляет операционную систему сервера быстрее отправлять проверочные пакеты и разрывать аварийно оборванные соединения.

Действия по проверке базы данных после сбоев питания

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

1. Создадим резервную копию базы данных средствами СУБД или конфигуратора.
2. Запустим конфигуратор 1С, откроем меню «Администрирование» -> «Тестирование и исправление...».
3. Выберем проверки логической и ссылочной целостности, а также реиндексацию таблиц информационной базы, чтобы исключить повреждение внутренних структур после аварийного отключения.