Эскалация блокировок в 1С: что это и как с ней бороться

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

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

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

Как устроен механизм эскалации блокировок

MS SQL Server поддерживает несколько уровней гранулярности блокировок: строка (RID/KEY), страница, экстент, таблица, база данных. Когда транзакция изменяет данные, сервер сначала накладывает мелкие блокировки — на конкретные строки или страницы. Это позволяет другим сессиям работать с остальными частями таблицы параллельно.

Однако каждая блокировка требует памяти в структуре lock manager. Когда число блокировок в одной транзакции достигает внутреннего порога (обычно порядка нескольких тысяч) или общий объём памяти под блокировки на сервере превышает допустимую долю, SQL Server выполняет эскалацию: снимает мелкие блокировки и ставит одну блокировку на всю таблицу или секцию.

Важный нюанс: эскалация никогда не происходит «вниз» до уровня страниц — только сразу до таблицы (или секции при партиционировании). Поэтому последствия для параллельности всегда заметные: таблица становится недоступной для конкурирующих операций на запись до завершения транзакции.

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

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

Результат предсказуем: пока идёт проведение такого документа, остальные пользователи не могут провести ни один документ, пишущий в тот же регистр. В журнале появляются ошибки «Конфликт блокировок при выполнении транзакции» и «Превышено время ожидания предоставления блокировки», а пользователи видят зависший интерфейс.

Дополнительный фактор — регламентные задания. Обмены данными, расчёт итогов, полнотекстовое индексирование и обработчики обновления часто выполняются массовыми пакетами в фоне, в самое неподходящее время накладывая табличные блокировки на рабочие часы.

Как диагностировать эскалацию блокировок

Первый источник информации — технологический журнал 1С. Включите сбор событий TLOCK, TTIMEOUT и TDEADLOCK: они покажут, какие таблицы блокировались, какие сеансы ждали и кто был держателем блокировки. В логе видны имена таблиц СУБД (например, _AccumRg12345), которые можно сопоставить с объектами метаданных через структуру базы данных.

Второй инструмент — динамические административные представления SQL Server. Запрос к sys.dm_tran_locks покажет текущие блокировки и их уровень: если видите resource_type = OBJECT с request_mode X или Sch-M, значит, таблица заблокирована целиком. Представление sys.dm_os_waiting_tasks покажет цепочку ожидающих сессий.

Третий способ — расширенные события (Extended Events) SQL Server: событие lock_escalation фиксирует сам факт эскалации, имя объекта и количество блокировок, которые её вызвали. Это самый прямой способ подтвердить диагноз и понять, какие именно запросы провоцируют проблему.

SELECT request_session_id, resource_type, request_mode, COUNT(*) AS cnt FROM sys.dm_tran_locks GROUP BY request_session_id, resource_type, request_mode ORDER BY cnt DESC;

Основные способы снизить эскалацию

Самый надёжный метод — уменьшать размер транзакций. Если обработка перепроводит 50 000 документов одной транзакцией, разбейте её на порции по 500–1000 документов с фиксацией после каждой порции. Количество удерживаемых блокировок упадёт ниже порога эскалации, и таблица останется доступной для других пользователей.

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

Третий рычаг — настройка на стороне SQL Server. Команда ALTER TABLE ... SET (LOCK_ESCALATION = DISABLE) отключает эскалацию для конкретной таблицы, а вариант AUTO при партиционировании ограничивает эскалацию уровнем секции. Это рабочий, но требующий осторожности приём: отключение эскалации увеличивает потребление памяти под блокировки, и при нехватке памяти запросы начнут завершаться с ошибкой.

Оптимизация запросов и индексов

Эскалация часто является симптомом, а не первопричиной. Если запрос сканирует всю таблицу из-за отсутствия подходящего индекса, он заблокирует огромное число строк — и эскалация неизбежна. Проанализируйте планы запросов самых тяжёлых операций: поиск Table Scan и Clustered Index Scan на больших таблицах — прямое указание на недостающие индексы.

Проверьте индексы, которые платформа создаёт автоматически, и при необходимости добавьте индексы в конфигураторе (через свойство «Индексировать» у реквизитов и измерений). Помните обратную сторону: каждый лишний индекс замедляет запись, поэтому добавляйте их точечно, под конкретные запросы.

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

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

Организационные меры и регламент

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

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

Отдельно проконтролируйте работу разработчиков: типичные источники проблем — циклы с записью внутри одной транзакции, запросы без отборов по индексированным полям, использование конструкции «ДЛЯ ИЗМЕНЕНИЯ» на больших выборках. Ревью кода по этим критериям предотвращает появление новых источников эскалации.

Когда обращаться за помощью и как проверить результат

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

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

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