Как удалить блокировки на сервере 1С

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

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

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

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

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

Находим источник блокировки через консоль кластера

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

Дополнительно полезен раздел «Соединения»: он показывает связь сеансов с рабочими процессами кластера и соединениями с СУБД. По колонке «Заблокировано СУБД» и связанным признакам можно понять, какой процесс держит ресурс. Если в консоли видно, что один сеанс выполняет длительный вызов, а остальные жалуются на блокировки — почти наверняка источник найден.

Когда консоль недоступна (например, нет прав администратора кластера), источник ищут на стороне СУБД. В MS SQL Server откройте Activity Monitor или выполните запрос к sys.dm_tran_locks и sys.dm_exec_sessions, отсортируйте по времени транзакции. В PostgreSQL помогает представление pg_stat_activity в связке с pg_locks — по полю query_start находят самый старый активный запрос.

SELECT session_id, login_name, host_name, status, last_request_start_time FROM sys.dm_exec_sessions WHERE database_id = DB_ID('ИмяБазы') AND status = 'running';

Снимаем блокировку завершением сеанса

Самый безопасный способ — завершить проблемный сеанс в консоли кластера. Найдите сеанс в списке, кликните правой кнопкой и выберите «Удалить» (в зависимости от версии консоли — «Завершить сеанс»). Платформа принудительно закроет соединение, незавершённая транзакция откатится, и блокировки будут сняты. Другие пользователи смогут продолжить работу сразу, без перезапуска служб.

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

1. 1
   Откройте консоль кластера и раздел «Сеансы»
2. 2
   Найдите сеанс с аномально долгим временем вызова или сеанс пользователя, указанного в сообщении о блокировке
3. 3
   Убедитесь, что сеанс не выполняет важную регламентную операцию
4. 4
   Завершите сеанс через контекстное меню
5. 5
   Попросите пострадавших пользователей повторить операцию и убедитесь, что ошибка блокировки исчезла

Снятие блокировок на уровне СУБД

Если завершение сеанса в консоли не помогло или блокировка осталась «висеть» на уровне СУБД, действуют средствами самой СУБД. В MS SQL Server находят блокирующую сессию командой sp_who2 (колонка BlkBy показывает, кто кого блокирует) и завершают её командой KILL с номером сессии. В PostgreSQL используют pg_terminate_backend с идентификатором процесса из pg_stat_activity.

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

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'ИмяБазы' AND state = 'active' AND now() - query_start > interval '30 minutes';

Взаимоблокировки и длительные транзакции

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

Для диагностики включите сбор событий TLOCK, TDEADLOCK и TTIMEOUT в технологическом журнале. По логам видно, какие объекты и в каком порядке блокируются. Устранение системных взаимоблокировок — задача разработчика: выравнивается порядок наложения управляемых блокировок, сокращается длительность транзакций, тяжёлые операции выносятся в фоновые задания с последовательным выполнением.

Блокировки регламентными заданиями и режимом конфигуратора

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

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

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

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

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

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