Эскалация блокировок в 1С: причины, признаки и способы устранения

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

Проблема актуальна только для клиент-серверного режима работы (MS SQL Server, PostgreSQL, Oracle, IBM Db2). В файловом варианте эскалации в классическом понимании нет, поскольку механизм блокировок там устроен иначе. Если база работает на SQL Server и пользователи жалуются на конфликты блокировок при массовых проведениях, эскалация — одна из первых причин, которую стоит проверить.

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

Как работает механизм блокировок в 1С и СУБД

При записи данных 1С накладывает блокировки на два уровнях: прикладном (блокировки данных платформы) и на уровне СУБД (транзакционные блокировки). СУБД блокирует те строки и страницы, которые транзакция читает или изменяет, чтобы другие транзакции не получили несогласованные данные. Каждая такая блокировка требует памяти и накладных расходов на учёт.

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

В MS SQL Server порог эскалации внутренне привязан к количеству блокировок (типично порядка нескольких тысяч на инструкцию) и к объёму памяти, занятой менеджером блокировок. Точные значения Microsoft не гарантирует как фиксированные, поэтому рассчитывать на конкретную цифру нельзя — нужно проектировать обработку данных так, чтобы эскалация в принципе не требовалась.

Признаки эскалации блокировок в работающей системе

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

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

Третий признак виден администратору: в технологическом журнале 1С фиксируются события TLOCK и TTIMEOUT с большим числом ожиданий на одной таблице, а в мониторе MS SQL Server (Activity Monitor, представления sys.dm_tran_locks) видна блокировка уровня TAB (таблица) вместо ожидаемых KEY или PAGE.

Почему эскалация возникает в 1С

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

Вторая причина — запросы без достаточно узких условий отбора. Если запрос сканирует значительную часть таблицы регистра накопления (например, из-за отсутствия подходящего индекса), СУБД блокирует всё прочитанное, и эскалация становится почти неизбежной. Особенно этим страдают таблицы итогов и регистры с большим числом движений.

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

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

Диагностика: как подтвердить эскалацию

Первый шаг — включить сбор технологического журнала с событиями TLOCK, TDEADLOCK, TTIMEOUT и контекстами. По содержимому событий видно, какие таблицы участвуют в конфликтах и какие запросы их вызывают. Если в ожиданиях постоянно фигурирует одна и та же таблица (например, регистр накопления «ТоварыНаСкладах»), это сильный аргумент в пользу эскалации.

Второй инструмент — динамические административные представления MS SQL Server. Запрос к sys.dm_tran_locks в момент зависания покажет тип удерживаемых блокировок: если видны блокировки ресурса OBJECT (таблица) со статусом GRANT, а параллельно масса ожиданий (WAIT) на том же объекте — эскалация подтверждена.

SELECT request_session_id, resource_type, request_mode, request_status FROM sys.dm_tran_locks WHERE resource_type IN ('OBJECT','PAGE','KEY') ORDER BY resource_type;

Третий способ — счётчики производительности SQL Server: объект SQLServer:Locks, счётчик Lock Waits/sec, а также трассировка события Lock:Escalation через Extended Events. Событие эскалации прямо покажет, какая инструкция и на какой таблице её вызвала. Это самый точный метод, но требует аккуратной настройки, чтобы не нагружать сервер.

Способы устранения и профилактики

Основная мера — перевод конфигурации в управляемый режим блокировок. В свойствах конфигурации параметр «Режим управления блокировкой данных» должен быть установлен в «Управляемый» (или «Управляемый и автоматический» на переходный период). Для регистров, дающих основную нагрузку, режим задаётся индивидуально в свойствах объекта. После перевода разработчик обязан явно устанавливать управляемые блокировки в коде перед изменением данных.

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

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

На уровне MS SQL Server существует возможность отключить эскалацию для конкретной таблицы командой ALTER TABLE ... SET (LOCK_ESCALATION = DISABLE). Это допустимый, но вспомогательный приём: он не устраняет причину (массовые блокировки), а лишь запрещает СУБД их объединять, что при нехватке памяти может привести к ошибке нехватки ресурсов блокировок. Применять его стоит осознанно и только после анализа.

Порядок действий при массовых конфликтах блокировок

Когда пользователи жалуются на зависания, действовать нужно последовательно: сначала локализовать источник, потом снимать острый симптом и только затем устранять причину. Хаотичные перезапуски сервера 1С или СУБД снимают блокировки на минуты, но транзакция-виновник при следующем запуске воспроизведёт ситуацию снова.

1. 1
   Включите технологический журнал с событиями TLOCK, TTIMEOUT, TDEADLOCK и контекстами
2. 2
   В момент зависания снимите снимок блокировок через sys.dm_tran_locks и найдите сессию с табличной блокировкой
3. 3
   Определите запрос и процедуру конфигурации, породившие эскалацию
4. 4
   Проверьте режим управления блокировками конфигурации и проблемного регистра
5. 5
   Оптимизируйте запрос: добавьте отборы, проверьте индексы, сократите транзакцию
6. 6
   Проведите нагрузочную проверку на копии базы и убедитесь, что эскалация не повторяется

После внесения изменений обязательно проверьте результат под нагрузкой на тестовой копии. Признак успеха — отсутствие события Lock:Escalation по проблемной таблице и отсутствие ожиданий уровня OBJECT в sys.dm_tran_locks при типовой рабочей нагрузке.

Типичные ошибки и ограничения

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

Вторая ошибка — бороться с симптомом через увеличение таймаута ожидания блокировок. Пользователи перестают получать ошибку, но начинают просто дольше ждать: очередь блокировок никуда не девается. Таймаут можно корректировать только как временную меру, параллельно устраняя причину.

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

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

Частые вопросы