Как посмотреть блокировки в 1С и найти их источник

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

Инструмент зависит от режима работы. В файловой базе доступен ограниченный набор средств: список активных пользователей и журнал регистрации. В клиент-серверном варианте картина полнее: консоль кластера серверов показывает сеансы и соединения, технологический журнал фиксирует события блокировок, а СУБД (MS SQL Server, PostgreSQL) позволяет увидеть блокировки на уровне самой базы данных.

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

Где смотреть блокировки: выбор инструмента под ситуацию

Первый вопрос — какой у вас режим работы и что именно нужно узнать. Если задача просто понять, кто сидит в базе и мешает провести документ, достаточно списка активных пользователей. Если нужно найти причину взаимоблокировки или хронических конфликтов — потребуется технологический журнал и средства СУБД.

Ориентируйтесь по таблице ниже: она сопоставляет инструменты с задачами и ограничениями.

Просмотр активных сеансов и блокировок в консоли кластера

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

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

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

Как найти виновника по ошибке пользователя

Когда пользователь присылает текст ошибки «Конфликт блокировок при выполнении транзакции», действуйте так. Откройте консоль кластера, отсортируйте сеансы по времени последней активности и найдите сеансы с длительными транзакциями. Часто виновник — это сеанс, в котором открыта форма документа в режиме редактирования, фоновое задание обмена или регламентная операция.

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

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

Технологический журнал: события блокировок TLOCK, TTIMEOUT, TDEADLOCK

Технологический журнал — текстовый лог платформы, который фиксирует низкоуровневые события, включая установку и ожидание блокировок. По умолчанию он выключен: его нужно включить конфигурационным файлом logcfg.xml, размещённым в каталоге conf сервера 1С (или в каталоге, заданном параметром службы).

Для диагностики блокировок настраивают события: TLOCK (установка и ожидание управляемых блокировок), TTIMEOUT (превышение времени ожидания), TDEADLOCK (взаимоблокировка), а также DBMSSQL или DBPOSTGRS с длительностью — чтобы видеть запросы, внутри которых возник конфликт. В свойствах события укажите свойство Context, чтобы в лог попадал контекст исполняемого кода — без него найти место в конфигурации будет сложно.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="Context"/>
  </log>
</config>

Читая лог, ищите пары событий: один сеанс установил блокировку (TLOCK с результатом), другой ждёт ту же область и завершается по TTIMEOUT. В событии TDEADLOCK платформа записывает жертву взаимоблокировки и участников цикла — по этим данным определяют, какие два процесса захватывают ресурсы в разном порядке.

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

Управляемые блокировки 1С видны платформе, но транзакционные конфликты происходят внутри СУБД. Если консоль кластера не даёт ответа, смотрите блокировки непосредственно в базе данных. Для MS SQL Server используйте Activity Monitor в Management Studio (раздел Processes показывает ожидающие процессы и колонку Blocked By) или запросы к системным представлениям sys.dm_tran_locks и sys.dm_os_waiting_tasks.

Запрос к представлениям покажет цепочку ожидания: идентификатор сессии, которую блокируют, идентификатор блокирующей сессии и тип ресурса. По идентификатору сессии через sys.dm_exec_sessions можно выйти на имя пользователя 1С и компьютер — этого достаточно, чтобы связать блокировку СУБД с конкретным сеансом в консоли кластера.

В PostgreSQL аналогичную информацию дают представления pg_locks и pg_stat_activity: запрос с соединением этих таблиц покажет, какой процесс удерживает блокировку и какой ждёт. Учтите, что для выполнения таких запросов нужны права администратора СУБД, а интерпретация результатов требует понимания типов блокировок конкретной СУБД.

Журнал регистрации и файловая база: что доступно без сервера

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

В файловой базе консоли кластера нет, поэтому инструментарий уже. Основное — список активных пользователей (Администрирование → Активные пользователи) и программный метод ПолучитьСеансыИнформационнойБазы(), который возвращает массив сеансов с пользователями и приложениями. Если блокировка возникает из-за монопольного режима или фонового задания, в списке сеансов это будет видно.

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

Как снять блокировку и не навредить данным

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

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

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

FAQ: частые вопросы о блокировках в 1С