«Конфликт блокировок при выполнении транзакции» в 1С — как снять

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

Что означает эта ошибка

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

Причины конфликтов делятся на две группы: проблемы конфигурации (длинные транзакции, отсутствие индексов, автоматические блокировки) и проблемы СУБД (эскалация блокировок, фрагментация, неактуальная статистика). Лечение — комбинированное.

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

Причины появления

• Одновременная работа множества пользователей с одним документом или объектом.
• Длинные транзакции — например, обработка обновления цен с тысячами строк в одной транзакции.
• Режим автоматических блокировок (вместо управляемых) с эскалацией до уровня таблицы.
• Отсутствие нужных индексов в SQL — блокировки берутся на лишние строки или страницы.
• Неактуальная статистика — оптимизатор выбирает неэффективный план с большим количеством блокировок.
• Фоновое задание перестроения индексов или обновления статистики во время рабочего дня.
• Зависший сеанс пользователя, не отпустивший блокировку.
• Регламентное задание, конфликтующее с пользовательскими операциями.

Способ 1: Перевод на управляемые блокировки

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

1. Конфигуратор → корневой узел конфигурации → свойства → «Режим управления блокировкой данных».
2. Возможные значения: «Автоматический», «Управляемый», «Автоматический и управляемый».

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

1. Сделайте бэкап.
2. Откройте свойство конфигурации, измените на «Управляемый».
3. Проверьте у всех объектов (документы, регистры) свойство «Режим управления блокировкой» — должно быть «Управляемый».
4. Сохраните конфигурацию, выполните обновление с реструктуризацией.

Типовые конфигурации (БП 3.0, ЗУП 3.1, ERP 2.5, УТ 11) уже работают в управляемом режиме. Если у вас унаследованная самописная конфигурация на автоматических — нужен анализ кода: использование НачатьТранзакцию без управляемых блокировок может потребовать доработки.

Способ 2: Оптимизация запросов в транзакциях

Длинные транзакции — главный враг производительности. Проверьте:

1. Через журнал регистрации найдите проблемные сеансы (поиск по «Конфликт блокировок»).
2. Включите технологический журнал (ТЖ) на 1-2 часа с фильтром по событиям TLOCK, TDEADLOCK, EXCP.
3. Анализируйте, на каких объектах висят блокировки.

Типовые ошибки в коде:

• Открытие транзакции до интерактивных действий пользователя.
• Запросы внутри циклов записи (1000 документов = 1000 запросов в одной транзакции).
• Чтение справочников внутри транзакции без необходимости.

Перенесите подготовку данных за пределы транзакции. Внутри — только сами операции записи. Используйте «Для каждого … Из» по предварительно подготовленной выборке, а не запрос внутри цикла.

Способ 3: Реиндексация и обновление статистики SQL

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

1. В SQL Server Management Studio создайте план обслуживания (Maintenance Plan).
2. Добавьте задачи: Rebuild Index, Update Statistics, Reorganize Index.
3. Расписание — ежедневно ночью.

Разовый запуск для всех таблиц проблемной базы:

USE [имя_базы_1С];
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (ONLINE = OFF)';
EXEC sp_updatestats;

В типовых конфигурациях рекомендуется использовать встроенную обработку «Регламентное обслуживание СУБД» из БСП или ИТС-обработку — она знает таблицы 1С и обходит их корректно. Подробности на its.1c.ru, раздел «Эксплуатация прикладных решений».

Способ 4: Увеличение таймаута блокировок

Это не лечение, а компромисс — даёт время на нормальное завершение операций. По умолчанию 20 секунд. В клиент-серверной базе можно поднять до 60–120.

1. В консоли администрирования сервера 1С откройте свойства информационной базы.
2. Параметр «Таймаут блокировок данных» = 60 (или больше).
3. Сохраните, перезапустите рабочие процессы.

Минус — пользователь будет дольше ждать при настоящих конфликтах. Применяйте только как временное смягчение, пока не оптимизирована логика.

Способ 5: Диагностика и снятие зависших сеансов

Если конфликт длится бесконечно — кто-то держит блокировку и не отпускает.

1. Консоль администрирования сервера 1С → Кластер → ваша база → Сеансы.
2. Колонка «Заблокировано» показывает, кого ждёт сеанс.
3. «Текущая блокировка» — какой объект держит сеанс.
4. Найдите сеанс с большим временем активности и нулевым CPU — кандидат на завершение.
5. ПКМ на сеансе → «Удалить». Перед этим предупредите пользователя.

На стороне SQL посмотреть блокировки:

SELECT request_session_id, resource_type, resource_database_id, request_status
FROM sys.dm_tran_locks
WHERE request_status = 'WAIT';

Заблокированные процессы покажет sp_who2 active в колонке BlkBy.

Профилактика

Регулярно (раз в квартал) запускайте Центр Управления Производительностью (ЦУП) или анализатор технологического журнала — они показывают топ-запросов по блокировкам. Не запускайте обработки массовых изменений в рабочее время — выносите в ночные регламентные задания. Документируйте, какие операции должны быть монопольными (свёртка, обновление, обмен большими порциями). Следите за фрагментацией индексов — раз в неделю rebuild, ежедневно reorganize и updatestats. Не превышайте рекомендуемое количество пользователей на один рабочий процесс — настройте лимит «Количество соединений на процесс» в кластере.

FAQ

Чем управляемые блокировки лучше автоматических?

Управляемые работают на уровне платформы 1С: блокируются конкретные значения измерений регистров и реквизитов, а не целые таблицы. Автоматические передаются в СУБД через подсказки и часто эскалируются до уровня страниц или таблиц, вызывая лишние конфликты.

Можно ли просто увеличить таймаут до 600 секунд?

Технически можно, но это маскирует проблему: пользователи будут ждать по 10 минут на каждой операции. Лучше потратить время на оптимизацию: управляемые блокировки + индексы + переписать долгие транзакции.

В типовой БП 3.0 появились конфликты — что делать первым делом?

Проверить регламентные операции SQL (давно ли rebuild и updatestats), посмотреть журнал регистрации на конкретные объекты конфликтов, посмотреть фоновые задания — возможно одно из них идёт долго и блокирует пользователей.

Как найти, какой именно код вызывает конфликт?

Включите технологический журнал с фильтром EXCP и текстом «Конфликт блокировок». В выгрузке будет стек вызова с указанием модуля и строки. Анализируйте через утилиту logcfg или собственные скрипты.

Deadlock и конфликт блокировок — это одно и то же?

Нет. Deadlock — взаимная блокировка двух сеансов, СУБД сама убивает одного из них (событие TDEADLOCK). Конфликт блокировок — превышение таймаута ожидания одной блокировки. Лечатся разными подходами, но оба связаны с одними и теми же причинами.

Помогает ли увеличение количества рабочих процессов rphost?

Косвенно — распределяет нагрузку по CPU. На сами блокировки не влияет. Если конфликты на одном документе — увеличение rphost не поможет, нужна оптимизация кода.

Что делать, если конфликты появились после миграции с MS SQL на PostgreSQL?

Проверьте версию PostgreSQL и патчи 1С (используйте сборку от Postgres Pro 1C). Перенастройте autovacuum, work_mem, shared_buffers под нагрузку 1С. Запустите ANALYZE по всем таблицам и REINDEX крупным таблицам.