Администрирование · 11 мин
Конфликт блокировок при выполнении транзакции в 1С 8.3: причины и способы исправления
Разбираем ошибку «Конфликт блокировок при выполнении транзакции» в 1С 8.3: причины, диагностика, управляемые блокировки, настройка MS SQL и профилактика конфликтов.
Ошибка «Конфликт блокировок при выполнении транзакции» возникает, когда два сеанса 1С одновременно пытаются изменить одни и те же данные — например, провести документы по одному контрагенту, списать один товар со склада или записать один регистр. Платформа не позволяет второй транзакции перезаписать результат первой и прерывает её с этим сообщением.
Сама по себе ошибка — не сбой программы, а штатный механизм защиты целостности данных. Проблемой она становится, когда возникает массово: пользователи не могут провести документы, обмены падают, фоновые задания завершаются с ошибкой. В таких случаях нужно искать системную причину: режим блокировок, длительные транзакции, нагрузку на СУБД или ошибки в коде конфигурации.
Ниже разобраны типовые причины конфликтов, способы диагностики, настройка управляемых блокировок, работа с SQL-сервером и профилактика. Материал ориентирован на администраторов и разработчиков 1С, работающих с клиент-серверными базами, но часть рекомендаций применима и к файловому режиму.
Что означает ошибка и почему она возникает
При проведении документа или записи объекта 1С открывает транзакцию и накладывает блокировки на затрагиваемые данные: записи регистров, таблицы документов, справочники. Если другой сеанс уже удерживает блокировку на те же данные, вторая транзакция либо ждёт, либо прерывается с ошибкой конфликта — поведение зависит от режима блокировок и таймаутов.
Типичные источники конфликтов:
- автоматический режим управления блокировками в клиент-серверной базе — СУБД блокирует избыточно широкие диапазоны, вплоть до целых таблиц;
- длительные транзакции: массовые перепроведения, тяжёлые отчёты с записью, загрузки данных без разбиения на порции;
- одновременная работа пользователей с одними документами, складами или кассами;
- фоновые задания и обмены данными, пересекающиеся по времени с работой пользователей;
- взаимоблокировки (deadlock): две транзакции блокируют ресурсы в разном порядке и ждут друг друга.
Как диагностировать источник конфликта
Прежде чем менять настройки, нужно понять, какие объекты конфликтуют. Откройте журнал регистрации (Администрирование → Обслуживание → Журнал регистрации), отфильтруйте по ошибкам с текстом «Конфликт блокировок» и посмотрите, какой пользователь, документ или фоновое задание указаны в событии. Часто картина видна сразу: конфликты идут по одному регистру или в одно время суток.
Для глубокой диагностики используйте технологический журнал. Включите сбор событий DBMSSQL, TLOCK, TDEADLOCK, TTIMEOUT в конфигурационном файле logcfg.xml на сервере 1С. События TDEADLOCK покажут участников взаимоблокировки, TLOCK — ожидания на блокировках.
На стороне MS SQL Server полезны динамические представления sys.dm_tran_locks и sys.dm_os_waiting_tasks — они показывают, какие сессии кого блокируют в реальном времени. Также проверьте, не выполняются ли в момент ошибок регламентные операции СУБД: перестроение индексов, обновление статистики, бэкап.
Достаточно повторить операцию и развести пользователей по времени
Проверить режим блокировок и длительные транзакции
Смотреть TDEADLOCK в техножурнале и активные сессии СУБД
Перевод базы в управляемый режим блокировок
Главная системная мера для клиент-серверной базы — переход с автоматического режима на управляемый. В автоматическом режиме блокировками управляет СУБД, и при чтении регистров она может блокировать тысячи строк или целые страницы таблиц, провоцируя конфликты там, где реального пересечения данных нет.
Порядок действий: откройте конфигуратор, перейдите в свойства конфигурации (корень дерева конфигурации → Свойства) и установите параметр «Режим управления блокировкой данных» в значение «Управляемый». Для отдельных объектов можно задать смешанный режим: у документов и регистров в свойствах есть аналогичный параметр.
После смены режима проверьте код: в управляемом режиме разработчик обязан явно устанавливать блокировки через объект БлокировкаДанных перед изменением данных в транзакции. Запросы вне транзакции читают «грязные» данные без блокировок — это нормально для отчётов, но критично учитывать при проверках остатков перед записью.
Сокращение длительных транзакций и нагрузки
Даже в управляемом режиме длинная транзакция удерживает блокировки всё время своего выполнения. Типовой антипаттерн — обработка, которая в одной транзакции перепроводит тысячи документов. Правильный подход: транзакция на один документ или на небольшую порцию, с фиксацией между порциями.
Разведите конкурирующие процессы по времени: перенесите обмены данными, загрузку заказов и тяжёлые регламентные задания на нерабочие часы. Если пользователи массово проводят документы по одному складу — рассмотрите разделение складского учёта или доработку движений, чтобы уменьшить пересечение по измерениям регистров.
Проверьте запросы внутри транзакций: соединения с виртуальными таблицами без отборов, сканирование регистров целиком, чтение «для изменения» лишних данных. Чем меньше строк затрагивает транзакция и чем быстрее она завершается, тем реже конфликты.
Частый источник конфликтов — проведение документов по регистру с отключенными итогами или тяжёлая запись в регистр сведений, который одновременно читает популярный отчёт. Если ошибки идут по одному регистру, начните оптимизацию именно с него: индексы, итоги, состав измерений.
Настройка СУБД и сервера 1С
На MS SQL Server убедитесь, что для базы включён режим ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT — типовые конфигурации 1С рассчитаны на версионность, она снижает конфликты чтения с записью. Проверьте, что tempdb расположена на быстром диске и имеет достаточный размер: версионные строки хранятся там.
Регулярно выполняйте обновление статистики и реорганизацию индексов — устаревшие планы выполнения приводят к сканированиям таблиц и избыточным блокировкам. Следите, чтобы регламентные операции СУБД не пересекались с пиковой нагрузкой пользователей.
На стороне сервера 1С проверьте настройки кластера: достаточное число рабочих процессов, отсутствие ошибок в консоли кластера. Зависшие сеансы, удерживающие блокировки, можно завершить через консоль кластера (Сеансы → Удалить) — но сначала убедитесь, что сеанс действительно завис, а не выполняет длительную операцию.
Работа с взаимоблокировками и повторение операций
Взаимоблокировка (deadlock) — частный случай конфликта: транзакция А держит ресурс 1 и ждёт ресурс 2, транзакция Б — наоборот. СУБД принудительно завершает одну из них. Если TDEADLOCK в техножурнале повторяется по одним и тем же объектам, нужно унифицировать порядок обращения к данным в коде: например, всегда блокировать сначала шапку документа, затем регистры в фиксированной последовательности.
Для пользовательских операций, где конфликт возможен штатно (проведение по общему складу, запись курсов валют), в прикладном коде применяют повтор попытки: перехват исключения, короткая пауза и повторное выполнение транзакции. Это допустимо для фоновых загрузок, но не заменяет устранение системной причины.
Как проверить, что проблема решена
После внесения изменений наблюдайте систему минимум несколько рабочих дней под реальной нагрузкой. Ключевые признаки результата: исчезновение ошибок из журнала регистрации, сокращение событий TLOCK и TDEADLOCK в техножурнале, стабильное время проведения документов в часы пик.
Как проверить результат
Единичные ошибки или их нет, повтор операции успешен
Десятки конфликтов по одним объектам в одно время
События редки, участники разные
Повторяющиеся взаимоблокировки по одной паре таблиц
Сопоставимо с временем вне пика
Кратный рост времени и таймауты
Если конфликты сохраняются после перевода в управляемый режим и оптимизации транзакций, проблема почти наверняка в конкретном коде конфигурации или в доработках. В этом случае нужен анализ запросов и планов выполнения по «горячим» таблицам — это работа для разработчика с доступом к конфигуратору и SQL Profiler или Extended Events.
Что важно запомнить
Конфликт блокировок — следствие конкуренции транзакций, а не поломка. Системное решение: управляемый режим блокировок, короткие транзакции, разнесение нагрузки по времени, здоровая СУБД и диагностика через техножурнал. Единичные ошибки достаточно повторить; массовые требуют анализа кода и инфраструктуры.
Частые вопросы
Ошибка возникла один раз — что делать?
Просто повторите операцию через несколько секунд. Единичный конфликт означает, что другой сеанс в этот момент менял те же данные. Если повтор прошёл успешно, никаких дополнительных действий не требуется.
Поможет ли увеличение таймаута ожидания блокировки?
Только частично: транзакция будет дольше ждать освобождения ресурса вместо немедленной ошибки. Это сглаживает редкие конфликты, но при системной проблеме превращает ошибки в «зависания» базы. Таймаут — не замена оптимизации.
Бывают ли конфликты блокировок в файловой базе?
Да, но там механизм проще: блокировки накладываются платформой на таблицы целиком, поэтому конфликты чаще и менее управляемы. Для многопользовательской работы с интенсивной записью рекомендуется переход на клиент-серверный вариант.
Можно ли совсем отключить блокировки, чтобы ошибок не было?
Нет. Блокировки защищают данные от одновременного изменения. Отключение или обход механизма приведёт к потере и рассогласованию данных — например, двойному списанию товара. Задача — сузить и ускорить блокировки, а не убрать их.
Кто виноват: пользователи, конфигурация или сервер?
Чаще всего сочетание факторов. Пользователи редко виноваты напрямую — массовые конфликты указывают на автоматический режим блокировок, длинные транзакции в коде или проблемы СУБД. Диагностику начинайте с журнала регистрации и техножурнала, а не с действий сотрудников.
Нужно ли останавливать работу базы для перевода в управляемый режим?
Изменение свойства конфигурации требует монопольного доступа при обновлении конфигурации базы данных, поэтому пользователей на это время придётся вывести. Само тестирование и правку кода следует выполнять заранее на копии базы.