Ошибка блокировки данных в 1С:УТ 11: причины и решение

Автор: Михаил С., Архитектор 1С · Опубликовано: 08.09.2026

📅 Опубликовано 8 сентября 2026 г.

Коротко: сообщение «Ошибка блокировки данных: превышено максимальное время ожидания предоставления блокировки» в 1С:Управление торговлей 11 означает, что транзакция ждала освобождения управляемой блокировки дольше таймаута (по умолчанию 20 секунд) и была аварийно прервана платформой. Данные при этом не портятся — документ просто не проводится. Причина почти всегда одна: рядом работает другая длинная транзакция — групповое проведение, обмен данными, регламентное задание или неоптимальный запрос без индекса.

Таймаут по умолчанию — 20 секунд. Он задаётся платформой и меняется методом УстановитьВремяОжиданияБлокировкиДанных() на уровне сеанса, а не галочкой в конфигураторе.
Ошибка не равна взаимоблокировке. Deadlock срабатывает за доли секунды и звучит иначе; увеличение таймаута его не лечит, а таймаут — иногда лечит.
Главные «горячие точки» УТ 11 — регистры ТоварыНаСкладах, СвободныеОстатки, ЗаказыКлиентов, РасчетыСКлиентами и автонумерация документов.
Диагностика занимает 1–2 часа: технологический журнал с событиями TLOCK, TTIMEOUT, TDEADLOCK показывает конкретный регистр, гранулы блокировки и номер сеанса-виновника.
Дешёвые меры дают 60–80 % эффекта: перенос обменов и регламентных заданий на ночь, разделение итогов у регистров, дробление пакетного проведения на порции по 50–200 документов.

Что означает «превышено максимальное время ожидания предоставления блокировки»?

1С:УТ 11 работает в управляемом режиме блокировок. Это значит, что за конкурентный доступ к данным отвечает не СУБД, а менеджер блокировок сервера «1С:Предприятия». Когда документ проводится и контролирует остатки, конфигурация ставит управляемую блокировку на комбинации измерений регистра — например, на пары «номенклатура + склад» в регистре накопления ТоварыНаСкладах. Пока транзакция не завершена, другой сеанс, который пытается заблокировать те же комбинации, встаёт в очередь.

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

Отдельно различайте два источника таймаута. Если в тексте фигурируют имена объектов метаданных на русском (РегистрНакопления.СвободныеОстатки, Справочник.Номенклатура) — сработал менеджер блокировок 1С. Если в тексте есть фрагменты вида «Lock request time out period exceeded» и имена таблиц _AccumRgT… — таймаут пришёл со стороны Microsoft SQL Server, куда платформа тоже транслирует ограничение в 20 секунд. Второй вариант чаще указывает на проблемы СУБД: устаревшую статистику, отсутствующие индексы, эскалацию блокировок.

Чем таймаут блокировки отличается от взаимоблокировки (deadlock)?

Это две разные ошибки, и их постоянно путают, из-за чего лечат не то. Взаимоблокировка возникает, когда две транзакции захватывают ресурсы в противоположном порядке и обе ждут друг друга; сервер обнаруживает цикл и принудительно «убивает» одну из них почти мгновенно. Таймаут — это простое ожидание, когда никакого цикла нет, просто кто-то очень долго держит ресурс.

Признак	Таймаут блокировки	Взаимоблокировка (deadlock)
Текст ошибки	«Превышено максимальное время ожидания предоставления блокировки»	«Конфликт блокировок при выполнении транзакции», «Обнаружена взаимоблокировка»
Событие технологического журнала	TTIMEOUT	TDEADLOCK
Через сколько срабатывает	20 секунд (по умолчанию)	Доли секунды, практически сразу
Кто виноват	Одна долгая транзакция держит ресурс	Две транзакции берут ресурсы в разном порядке
Помогает ли увеличение таймаута	Да, но как временная мера	Нет, не помогает совсем
Типичный сценарий в УТ 11	Проведение реализации во время обмена с бухгалтерией	Два документа пишут одни и те же регистры в разной последовательности
Что чинить	Длительность транзакции	Порядок наложения блокировок в коде

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

Почему в 1С:УТ 11 блокировки возникают чаще всего?

1. Групповое проведение и обработки в одной транзакции

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

2. Обмены данными и РИБ в рабочее время

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

3. Регламентные задания днём

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

4. Автонумерация документов

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

5. Отсутствие индексов и неоптимальные доработки

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

6. Избыточные блокировки в коде

Разработчик пишет Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах") и не задаёт условия по измерениям. Формально всё корректно, фактически блокируется весь регистр — и вся компания стоит.

7. Эскалация блокировок на уровне СУБД

Microsoft SQL Server при накоплении большого числа блокировок строк на одном объекте переводит их на уровень таблицы. Один «тяжёлый» документ с тысячами строк способен заблокировать таблицу движений целиком. Симптом — таймауты у всех сразу, включая пользователей с совершенно другой номенклатурой.

8. Оперативное проведение и контроль остатков в пике

Если в УТ 11 включён жёсткий контроль остатков и складом одновременно работают десятки пользователей по одной ходовой позиции, конкуренция за одну и ту же гранулу блокировки неизбежна. Здесь помогает не код, а организация: резервирование по заказам, разнесение отгрузок, дробление партий.

Как найти, кто именно держит блокировку?

Гадать бессмысленно — нужна фактура. Порядок действий такой.

Журнал регистрации. Отбор по уровню «Ошибка» и точному времени инцидента. Смотрим, какие сеансы работали параллельно и какое регламентное задание стартовало за минуту до ошибки.
Технологический журнал. Включаем сбор событий TLOCK, TTIMEOUT и TDEADLOCK на 1–2 рабочих дня — это даёт имя регистра, гранулу блокировки, номера конкурирующих соединений и стек контекста.
Консоль кластера. В момент проблемы смотрим активные сеансы и их длительность — «висящий» сеанс с временем вызова в десятки секунд обычно и есть виновник.
Замер производительности. Если ошибка воспроизводится, включаем замер и находим строку кода, внутри которой открыта транзакция.

Минимальный logcfg.xml для сбора блокировок кладётся в каталог conf сервера 1С:

<config xmlns="http://v8.1c.ru/v8/tech-log">
	<log location="C:\logs\tj" history="48">
		<event>
			<eq property="name" value="TLOCK"/>
		</event>
		<event>
			<eq property="name" value="TTIMEOUT"/>
		</event>
		<event>
			<eq property="name" value="TDEADLOCK"/>
		</event>
		<property name="all"/>
	</log>
</config>

В событии TTIMEOUT ищите свойство WaitConnections — там перечислены номера соединений, которые держали ресурс. Дальше по этим номерам в событиях TLOCK находится контекст: имя регистра, режим блокировки (Shared/Exclusive) и гранулы. Это и есть точный адрес проблемы.

Программно быстро отобрать ошибки за день можно средствами самой платформы:

// Выгружаем ошибки журнала регистрации за текущий день в XML для анализа
Процедура ВыгрузитьОшибкиБлокировокЗаДень(ИмяФайла) Экспорт
	
	Отбор = Новый Структура;
	Отбор.Вставить("ДатаНачала", НачалоДня(ТекущаяДатаСеанса()));
	Отбор.Вставить("ДатаОкончания", КонецДня(ТекущаяДатаСеанса()));
	Отбор.Вставить("Уровень", УровеньЖурналаРегистрации.Ошибка);
	
	// Файл затем открывается любым XML-редактором или загружается в обработку анализа
	ВыгрузитьЖурналРегистрации(ИмяФайла, Отбор);
	
	ЗаписьЖурналаРегистрации("Диагностика.Блокировки",
		УровеньЖурналаРегистрации.Информация, , ,
		"Выгрузка ошибок завершена: " + ИмяФайла);
	
 КонецПроцедуры

Что делать прямо сейчас: быстрые меры

Если производство встало и нужно снять остроту за 30 минут, действуйте по этому списку. Он не устраняет корень проблемы, но возвращает работоспособность.

Мера	Эффект	Трудоёмкость	Риск
Остановить обмен данными и «тяжёлые» регламентные задания на время пика	Высокий	10 минут	Отставание данных в приёмнике
Завершить зависшие сеансы в консоли кластера	Высокий	5 минут	Откат незавершённой операции пользователя
Запретить групповое проведение больше N документов	Средний	1–2 часа доработки	Недовольство операторов
Увеличить время ожидания блокировки до 45–60 секунд	Средний	1 час	Маскирует проблему, растут очереди
Обновить статистику и перестроить индексы в СУБД	Высокий при деградации плана	30 минут	Нагрузка на время обслуживания
Перезапустить рабочие процессы кластера	Разовый	5 минут	Обрыв сеансов пользователей

Увеличение таймаута — легальный, но осознанный шаг. Меняйте его не глобально, а точечно, вокруг конкретной длительной операции:

// Локально увеличиваем ожидание только для длительной сервисной операции
Процедура ВыполнитьДлительнуюОперацию(МассивДокументов) Экспорт
	
	ПредыдущийТаймаут = ПолучитьВремяОжиданияБлокировкиДанных();
	УстановитьВремяОжиданияБлокировкиДанных(60); // секунд вместо 20 по умолчанию
	
	Попытка
		ПровестиДокументыПорциями(МассивДокументов);
	Исключение
		// Обязательно возвращаем исходное значение даже при ошибке
		УстановитьВремяОжиданияБлокировкиДанных(ПредыдущийТаймаут);
		ВызватьИсключение;
	КонецПопытки;
	
	УстановитьВремяОжиданияБлокировкиДанных(ПредыдущийТаймаут);
	
КонецПроцедуры

Найдите специалиста для решения этой задачи на koderion.ru

Автоматизацию торговли и склада доверьте специалистам по 1С:УТ с биржи.