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

> Сайт: allerrorcodes.ru · Обновлено: 31.05.2026 · Адрес: https://allerrorcodes.ru/konflikt-blokirovok-pri-vypolnenii-tranzakcii-1s/

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

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

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

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

  **Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки по причине: Microsoft SQL Server Native Client: Lock request time out period exceeded.**

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

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

- Одновременная работа множества пользователей с одним документом или объектом.
- Длинные транзакции — например, обработка обновления цен с тысячами строк в одной транзакции.
- Режим автоматических блокировок (вместо управляемых) с эскалацией до уровня таблицы.
- Отсутствие нужных индексов в 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](https://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 крупным таблицам.

## Ещё по теме

- [Параметр сеанса отсутствует или удалён на сервере 1С](https://allerrorcodes.ru/parametr-seansa-otsutstvuet-ili-udalen-na-servere-1c-predpriyatie/): «Параметр сеанса отсутствует или удалён» — сервер 1С не нашёл сохранённые данные сеанса пользователя.
- [«Вход в программу временно невозможен» в 1С — причины и как исправить](https://allerrorcodes.ru/vhod-v-programmu-vremenno-nevozmozhen-v-svyazi-s-neobhodimostyu-obnovleniya-konfiguratsii/): «Вход в программу временно невозможен» — база 1С заблокирована после обновления конфигурации, блокировку не сняли явно.
- [Очистка истории лицензий 1С 8.3 на сервере — инструкция](https://allerrorcodes.ru/ochistka-istorii-litsenziy-informatsionnoy-bazy-8-3-server/): Длинный список лицензий в «О программе» — это накопленный кэш последних успешно полученных лицензий; официальной статьи 1С о его очистке на its.1c.ru нет, способ ниже — практика сообщества администраторов 1С (infostart.ru), а не рекомендация вендора.
- [HASP-ключ не определяется в 1С — причины и что делать](https://allerrorcodes.ru/hasp-klyuch-ne-opredelyaetsya-v-1s/): Разбираем, почему HASP-ключ не определяется в 1С: драйверы Sentinel, USB-порты, служба License Manager, порт 475 для сетевых ключей и переустановка.