Конфликт блокировок при выполнении транзакции 1С: как найти виновника

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

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

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

Что делать сразу после сообщения об ошибке

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

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

Узнайте, работают ли остальные пользователи. Если база отвечает, а один документ не проводится, ищите локальный конфликт. Если соединения оборвались у всех, причина может быть не в блокировках. Тогда переходите к отдельной проверке связи с сервером 1С.

До завершения сеанса снимите резервную копию средствами вашей СУБД. Просмотр сеансов и сбор записей TLOCK данные не меняют. Принудительное завершение соединения уже вмешивается в работу: СУБД откатит незавершённую транзакцию.

Сообщение пользователя задаёт время поиска. Виновника подтверждает только связка из TLOCK, соединения и границ транзакции.

Как найти блокирующее соединение по TLOCK

Откройте консоль администрирования кластера. Найдите активные сеансы нужной информационной базы и сопоставьте их со временем ошибки. Набор и расположение колонок зависят от версии консоли, поэтому ориентируйтесь на данные, а не на конкретную кнопку.

Затем откройте технологический журнал. Официальная методика расследования ошибок блокировок на портале 1С:ИТС указывает на события TLOCK. Поля Regions и Locks описывают занятый ресурс и режим блокировки.

Смотрите на WaitConnections. Поле ссылается на t:connectID соединения, которое удерживает блокировку. Долгий сеанс без такой связи ещё не виновник.

Одна запись TLOCK не показывает, сколько длилась транзакция. Найдите рядом события SDBL и сопоставьте функции начала и завершения:

• BeginTransaction — транзакция началась;
• CommitTransaction — изменения зафиксированы;
• RollbackTransaction — платформа откатила изменения.

Полную расшифровку полей TDEADLOCK здесь дать нельзя. Доступная официальная методика 1С не описывает все поля этой записи для рассматриваемого сценария. Считайте TDEADLOCK отметкой события, а участников определяйте по TLOCK, t:connectID и границам SDBL.

Если до ошибки журнал не собирал нужные события, включите их и дождитесь следующего воспроизведения. Тайм-аут увеличивать не надо. Он лишь продлит ожидание и ничего не расскажет о соединении, которое держит данные.

Четыре причины повторяющихся конфликтов

Блокирующее соединение отвечает на вопрос «кто». Теперь нужно понять, почему оно удерживает ресурс дольше, чем требуется.

Длинная транзакция при проведении документа

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

Сравните время BeginTransaction и CommitTransaction. Затем свяжите этот интервал с действием пользователя. Если документ открывает транзакцию, выполняет несколько запросов и лишь затем записывает движения, конфликт затрагивает больше операций.

Проверьте и порядок работы с регистрами. Первая транзакция может занять ресурс А и ждать Б. Вторая — занять Б и ждать А. Технические материалы OTUS советуют захватывать общие ресурсы в одинаковом порядке.

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

Запрос отчёта читает больше строк, чем требуется

Долгий отчёт ещё не виновник. Подтвердите, что его запрос пересекается с ресурсом из TLOCK.

Fast1C описывает такой сценарий для SQL Server: без подходящего индекса СУБД сканирует таблицу и удерживает блокировки на прочитанных строках. Если в это время документы пишут в тот же регистр, чтение начинает мешать записи.

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

Проведение документов захватывает слишком широкую область

В автоматическом режиме блокировками управляет СУБД. По материалу OTUS, она может блокировать строки, страницы или таблицы. СУБД видит SQL-операции, но не знает, что документы относятся к разным складам или организациям.

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

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

Фоновое задание пересекается с работой пользователей

Планировщик заданий 1С создаёт отдельные сеансы. Fast1C описывает сценарий, при котором блокировка базы мешает планировщику создать новый сеанс. Возникает взаимное ожидание.

Сверьте время ошибки с расписанием фоновых заданий. Совпадение даёт направление для проверки, но не доказывает причину. Найдите соединение задания через WaitConnections.

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

Завершайте подтверждённое блокирующее соединение. Первый долгий сеанс в списке может не иметь отношения к ошибке.

Когда можно завершить блокирующий сеанс

Завершать соединение можно, когда WaitConnections подтвердил его роль и вы понимаете, какую операцию прервёте. СУБД откатит незавершённую транзакцию. Пользователь потеряет несохранённый результат этой операции.

Предупредите владельца сеанса. Проверьте, что резервная копия снята и разворачивается в отдельной базе. После этого завершайте соединение средствами кластера или СУБД.

Не перезапускайте весь сервер из-за одного сеанса. Перезапуск оборвёт работу остальных пользователей и уничтожит часть оперативных следов. Запрос или длинная транзакция останутся прежними, поэтому конфликт вернётся.

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

Что меняют управляемые и автоматические блокировки

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

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

Метод Заблокировать() вызывают внутри транзакции. По описанию OTUS, вне транзакции ресурс освобождается сразу. Платформа может не показать ошибку, поэтому дефект проявится только под параллельной нагрузкой.

Подготовьте все элементы блокировки до вызова метода. Заблокировать() установит их одним действием. Порядок ресурсов должен совпадать во всех транзакциях.

Для SQL Server проверьте RCSI — режим чтения зафиксированных версий строк. Читающие запросы получают версии из TempDB и реже мешают записи. Но если две транзакции одновременно меняют одну запись, конфликт сохранится.

Для включения RCSI нужен монопольный доступ к базе. Режим также увеличивает нагрузку на TempDB. До работ проверьте резервную копию и устройство TempDB, затем назначьте окно обслуживания. Подготовку разбираем в материале о настройке SQL Server для 1С.

Режим определяет место и ширину блокировки. Конкуренцию за одни данные он не отменяет.

Что проверять при 55P03 в PostgreSQL

Если рядом с конфликтом появился код 55P03, не расшифровывайте его по догадке. Среди предоставленных материалов нет документа PostgreSQL, который официально задаёт значение кода для этой ситуации.

Ищите блокирующую транзакцию по методике 1С:ИТС. Представление pg_locks показывает блокировки. Через pg_stat_activity можно связать идентификатор транзакции backend_xid с активным запросом.

Рабочий порядок:

1. Если планируете завершать соединение, снимите резервную копию средствами PostgreSQL.
2. Запишите время ошибки и сеанс 1С.
3. Найдите ожидающую и блокирующую транзакции через pg_locks.
4. Сопоставьте идентификатор с backend_xid в pg_stat_activity.
5. Проверьте текст запроса и время начала транзакции.
6. После подтверждения завершите блокирующий сеанс или дождитесь штатного окончания операции.

Для повторяющихся ожиданий методика 1С:ИТС предлагает включить log_lock_waits = on в postgresql.conf. PostgreSQL начнёт записывать сведения об ожиданиях блокировок в журнал.

Параметр lock_timeout управляет только длительностью ожидания. После его увеличения пользователь позже увидит ошибку, но блокирующая транзакция останется. Настройка тайм-аута не заменяет поиск соединения.

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

Сохраните технологический журнал и журналы СУБД, если TLOCK не связывается с активным сеансом. То же относится к случаям без границ транзакции и конфликтам, которые возникают лишь под нагрузкой. Зафиксируйте общий временной интервал, имя базы и действие пользователя.

Не запускайте «Тестирование и исправление». Конфликт блокировок не подтверждает повреждение базы. Эта операция меняет данные, но не сокращает транзакции и не создаёт недостающие индексы.

Если рабочие операции остаются заблокированными, передайте собранные журналы специалисту по аварийному разбору 1С и SQL. Остальные сценарии остановки собраны на карте неисправностей 1С.

Чтобы не повторилось

Настройте сбор TLOCK и границ SDBL до нового инцидента. Без этих событий у администратора остаётся жалоба пользователя, но нет связи с соединением и транзакцией.

Проверьте четыре места:

• длинные транзакции при проведении документов;
• порядок захвата общих регистров;
• запросы без подходящих индексов;
• фоновые задания в период массовой работы.

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

Запомните короткое правило. Тайм-аут отвечает на вопрос «сколько ждать». TLOCK — на вопрос «кто держит ресурс». Исправлять нужно причину из второго ответа.