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

Управляемая блокировка в 1С появляется, когда один сеанс захватывает объект (документ, элемент справочника, регистр) для изменения, а другой пытается обратиться к тем же данным. В норме такая блокировка живёт доли секунды и снимается автоматически при завершении транзакции. Проблема возникает, когда сеанс «завис», пользователь закрыл программу некорректно или транзакция оборвалась — тогда блокировка остаётся, и коллеги видят ошибку «Конфликт блокировок при выполнении транзакции».

Снять управляемую блокировку можно несколькими способами: завершить проблемный сеанс через консоль кластера серверов 1С, убить зависший процесс на СУБД, дождаться таймаута или принудительно перезапустить сервер. Выбор зависит от того, где именно «застряла» блокировка — на уровне сервера 1С или на уровне СУБД (MS SQL, PostgreSQL).

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

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

Признак управляемой блокировки — характерное сообщение об ошибке: «Конфликт блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки». В тексте ошибки обычно указано пространство блокировки (например, «Документ.РеализацияТоваровУслуг») и поля, по которым установлен захват.

Транзакционная блокировка СУБД выглядит иначе: ошибка приходит от самой СУБД (например, «Lock request time out period exceeded» в MS SQL). Различие важно, потому что инструменты диагностики разные: для управляемых блокировок анализируют сеансы 1С и технологический журнал, для транзакционных — мониторинг СУБД.

Способ 1. Завершить сеанс через консоль кластера

Самый безопасный и самый частый способ — найти и завершить сеанс, удерживающий блокировку. Для этого нужны права администратора кластера серверов 1С.

1. 1
   Откройте оснастку «Администрирование серверов 1С Предприятия» на сервере или на машине администратора.
2. 2
   Разверните нужный кластер → ветка «Сеансы».
3. 3
   Отсортируйте сеансы по времени начала или найдите пользователя, который сообщил о проблеме.
4. 4
   Обратите внимание на сеансы с длительным «временем вызова СУБД» или спящие сеансы, начавшиеся давно.
5. 5
   Выделите подозрительный сеанс, нажмите «Удалить» (или контекстное меню → «Завершить сеанс»).
6. 6
   Попросите пользователя повторить операцию — ошибка блокировки должна исчезнуть.

Если пользователей много и найти виновника сложно, ориентируйтесь на время появления ошибки у пострадавшего сеанса: блокирующий сеанс обычно стартовал чуть раньше и до сих пор активен. Также помогает колонка «Прочитано (текущее)» и «Записано (текущее)» — зависший в транзакции сеанс часто показывает ненулевую текущую активность без прогресса.

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

Способ 2. Снять зависшую блокировку на уровне СУБД

Если консоль кластера не помогает или блокировка удерживается на уровне СУБД (бывает при аварийном обрыве соединения, когда сеанс 1С уже умер, а процесс на SQL-сервере остался), работайте с мониторингом СУБД.

MS SQL Server

Откройте SQL Server Management Studio и выполните запрос, показывающий блокирующие процессы. Найдите SPID, который блокирует остальных (поле blocking_session_id у жертв указывает на него), проверьте, что это действительно зависший процесс 1С (по program_name и login_time), и завершите его командой KILL.

SELECT session_id, blocking_session_id, wait_type, wait_time, last_wait_type FROM sys.dm_exec_requests WHERE blocking_session_id <> 0; -- затем: KILL <session_id>;

PostgreSQL

В PostgreSQL зависшие блокировки видны в представлении pg_locks в связке с pg_stat_activity. Найдите процесс, удерживающий блокировку (granted = true), и завершите его функцией pg_terminate_backend(pid). Перед завершением убедитесь, что процесс действительно «мертвый», а не выполняет длинный регламентный запрос.

SELECT pid, state, query_start, wait_event FROM pg_stat_activity WHERE state <> 'idle'; SELECT pg_terminate_backend(<pid>);

Способ 3. Таймауты и автоматическое снятие

Платформа 1С по умолчанию ждёт предоставления блокировки ограниченное время (по умолчанию — порядка 20 секунд для ожидания в транзакции), после чего выдаёт ошибку ожидания. Но сама блокировка при этом не снимается — она живёт, пока жив блокирующий сеанс.

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

Диагностика: как найти виновника через технологический журнал

Когда ошибки блокировок повторяются регулярно, простого снятия недостаточно — нужно найти источник. Включите технологический журнал (файл logcfg.xml в каталоге conf сервера 1С) с событиями TLOCK, TTIMEOUT и TDEADLOCK. В логах будет видно, какой сеанс, в каком контексте и какое пространство блокировки захватил.

Также полезна обработка «Управление блокировками» или типовая консоль кода, позволяющая посмотреть активные сеансы программно. В файловом варианте базы управляемые блокировки снимаются проще: достаточно завершить сеанс через «Администрирование → Активные пользователи» в самой 1С.

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

Если конфликты управляемых блокировок — регулярная проблема, а не разовый случай, снимать их вручную бессмысленно: нужно устранять причину. Основные направления работы:

• Короткие транзакции. Чем дольше транзакция, тем дольше удерживаются блокировки. Не выполняйте внутри транзакции обмен данными, запросы к внешним сервисам и интерактивные диалоги с пользователем.
• Правильный порядок захвата. Если разный код блокирует одни и те же объекты в разном порядке, возникают взаимоблокировки. Унифицируйте порядок обращения к данным.
• Разнесение нагрузки. Регламентные задания (обмены, групповое перепроведение, расчёт себестоимости) не должны выполняться одновременно и в часы пиковой работы пользователей.
• Избыточные блокировки в коде. Проверьте, не устанавливаются ли исключительные блокировки там, где достаточно разделяемой, и не захватываются ли целые таблицы вместо конкретных записей.

Типичные ошибки при снятии блокировок

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

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