Блокировки в 1С: где увидеть и как разобрать причины зависаний

Активные блокировки в клиент-серверной базе видно в оснастке Администрирование серверов 1С Предприятия — узел «Блокировки» под нужной информационной базой. То же самое показывает команда rac lock list. Чтобы потом сделать анализ — кто кого держал и почему, — подключают технологический журнал (события TTIMEOUT и TDEADLOCK) и смотрят блокировки на уровне СУБД.

Отдельного «журнала блокировок» для рядового пользователя в режиме «Предприятие» нет. Увидеть, разобрать и устранить блокировки может администратор кластера. Ниже — все рабочие способы посмотреть блокировки в 1С по порядку: от быстрого взгляда на активные ожидания до разбора повторяющихся конфликтов.

Какие бывают блокировки в 1С и почему база начинает тормозить

В платформе 8.3 одновременно работают три разных механизма, и путать их не стоит.

• 🔒 Объектные блокировки. Пользователь открыл документ или элемент справочника на редактирование — остальные получают Объект заблокирован или Не удалось заблокировать объект. Живёт такая блокировка, пока форма открыта.
• 🔁 Транзакционные блокировки. Ставятся на время проведения документа или записи в регистры. Именно из-за них возникают массовые ожидания в рабочее время.
• 🗄 Блокировки СУБД. Их накладывает сам SQL Server или PostgreSQL на строки и страницы таблиц под транзакцией 1С.

Транзакционные блокировки работают в одном из режимов. Он задаётся в корне конфигурации: Конфигурация → свойства → Режим управления блокировкой данных, значения — Автоматический, Управляемый или Автоматический и управляемый.

В управляемом режиме платформа ставит собственные блокировки в менеджере блокировок кластера, а СУБД работает на низком уровне изоляции READ COMMITTED. Это точечно и быстро. В автоматическом режиме контроль отдан СУБД с высоким уровнем изоляции — блокируется больше данных, конфликты возникают чаще. Современные типовые (БП 3.0, ЗУП 3.1, УТ 11) идут в управляемом режиме.

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

Что можно увидеть из режима «Предприятие»

Сразу к делу: внутри самой программы отдельного окна со списком блокировок нет. Но признаки и косвенные данные доступны любому администратору без доступа к серверу.

Текст ошибки — первая подсказка. Когда пользователь жалуется на зависание, попросите скриншот. Формулировки говорят о типе проблемы:

Журнал регистрации. Открывается через Главное меню (значок ▾ слева вверху) → Все функции → Стандартные → Журнал регистрации. Чтобы пункт «Все функции» был доступен, включите его в Главное меню → Сервис → Параметры. В журнале отфильтруйте список по уровню «Ошибка» за нужный интервал — тексты конфликтов блокировок там фиксируются с указанием пользователя, компьютера и времени. Это даёт картину «когда и у кого», но не показывает, кто держал данные.

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

Для разбора причины этого недостаточно — нужен доступ к кластеру или к СУБД. Переходим к инструментам администратора.

Как посмотреть активные блокировки в консоли кластера и через rac

Это основной способ увидеть блокировки прямо сейчас в клиент-серверной базе.

Через оснастку администрирования серверов

1. Откройте Администрирование серверов 1С Предприятия (ярлык в меню «Пуск» в группе платформы; оснастка MMC).
2. Разверните дерево: Центральный сервер → Кластеры → ваш кластер → Информационные базы → нужная база.
3. Выберите узел «Блокировки».

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

Через консоль rac (без графики)

На сервере, где нет оснастки, те же данные берёт утилита rac из каталога bin платформы. Сначала узнайте идентификатор кластера, потом запросите блокировки:

rac cluster list
rac lock list --cluster=<uuid кластера>

Команда вернёт активные блокировки с номерами сеансов и соединений. Список сеансов — rac session list --cluster=<uuid>. Точные фильтры и параметры (в том числе отбор по информационной базе) смотрите в rac help и rac lock help — изобретать ключи не нужно, встроенная справка всегда актуальна версии платформы.

Если в кластере включена аутентификация администратора, к командам добавляют --cluster-user= и --cluster-pwd=.

Технологический журнал и уровень СУБД: детальный анализ

Активные блокировки вы увидели. Но если конфликты повторяются, нужен разбор постфактум: кто, когда и по каким данным сталкивался. Для этого собирают технологический журнал.

Настройка технологического журнала

Журнал включается файлом logcfg.xml, который кладут в каталог conf установленной платформы (например, C:\Program Files\1cv8\conf\). Минимальный конфиг под блокировки:

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

Что ловят эти события:

• TTIMEOUT — превышение времени ожидания блокировки. В записи видно, какой сеанс ждал, какие данные (пространство блокировок и диапазон) и кто эти данные держал.
• TDEADLOCK — взаимоблокировка. Содержит цепочку (кто кого ждёт по кругу) — по ней находят оба конфликтующих участка кода.
• TLOCK — установка и ожидание управляемых блокировок. Включают при детальном разборе, но он даёт много записей, поэтому надолго его не оставляют.

Разбирать текстовый журнал вручную тяжело. Для визуального анализа применяют Центр управления производительностью (ЦУП) из состава КИП — он собирает таймауты и взаимоблокировки из технологического журнала и показывает их наглядно, с топом проблемных операций.

Смотрим блокировки на стороне СУБД

Когда блокировки «сыпятся» на уровне базы данных, удобнее смотреть прямо в СУБД.

Для MS SQL Server:

EXEC sp_who2;

В выводе смотрите колонку BlkBy — это номер процесса, который блокирует. Детальнее по блокировкам:

SELECT * FROM sys.dm_tran_locks;

SELECT session_id, blocking_session_id, wait_type, wait_time
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Графически то же показывает Activity Monitor в SQL Server Management Studio, раздел Processes с колонкой блокирующего сеанса.

Для PostgreSQL блокировки и их ожидания смотрят так:

SELECT a.pid, a.wait_event_type, a.wait_event, a.query
FROM pg_stat_activity a
WHERE a.wait_event_type = 'Lock';

Связав номер процесса СУБД с сеансом 1С (его видно в узле «Соединения» оснастки), вы замыкаете картину: конкретный пользователь → его транзакция → заблокированные данные.

Из-за чего чаще всего возникают блокировки

Причины почти всегда сводятся к тому, что транзакция держит данные слишком долго или захватывает их слишком широко.

• ⏱ Долгое проведение. Документ пишет движения по многим регистрам, пересчитывает итоги — и всё это внутри одной транзакции. Пока она идёт, данные заблокированы.
• 📅 Проведение задним числом. Запись в закрытый или давний период заставляет пересчитывать остатки и итоги, расширяя область блокировки.
• 🧾 Групповые операции в рабочее время. Групповое перепроведение, массовая обработка, загрузка больших выгрузок конкурируют с обычными пользователями за одни и те же регистры.
• 🔍 Нет нужных индексов. Без подходящего индекса СУБД сканирует таблицу целиком и блокирует лишние строки, хотя нужны были единицы.
• ⬆️ Эскалация блокировок на СУБД. MS SQL при большом числе блокировок строк повышает их до блокировки всей таблицы — и тогда встают все, кто к ней обращается.
• ⚙️ Автоматический режим блокировок. На старых или нетиповых конфигурациях он даёт более широкие блокировки, чем управляемый.
• 🌙 Регламентные задания днём. Закрытие месяца , обновление агрегатов, обмены, запущенные в пик нагрузки, становятся источником очередей.
• 📊 Тяжёлые отчёты в транзакции. Длинный отчёт, читающий данные под блокировкой, держит их всё время построения.

Разберём типичные симптомы и первое, что проверить:

Как уменьшить блокировки и убрать зависания

Устранение идёт в двух направлениях: сократить длительность транзакций и сузить область блокировки. Начинайте с самого безопасного.

1. Разнесите тяжёлые операции по времени. Групповое перепроведение, закрытие периода, обмены и выгрузки переносите на ночь или обед. Это не требует изменений в коде и снимает большую часть жалоб.
2. Проверьте расписание регламентных заданий. В клиент-серверной базе ими управляют через оснастку или обработку настройки заданий. Уберите пересечение ресурсоёмких заданий с пиком пользователей.
3. Обновите статистику и перестройте индексы СУБД. Регламентное обслуживание MS SQL или PostgreSQL (обновление статистики, дефрагментация индексов) ускоряет запросы, а значит — сокращает время удержания блокировок.
4. Проверьте режим управления блокировками. Если конфигурация ещё в автоматическом режиме, перевод на управляемый сужает блокировки. Для нетиповых доработок это задача разработчика и требует тестирования.
5. Включите разделение итогов у нагруженных регистров накопления. Это снижает конкуренцию за строки итогов, когда много документов пишут в один регистр одновременно.
6. Рассмотрите RCSI на MS SQL. Режим READ COMMITTED SNAPSHOT убирает блокировки на чтение. Включать его стоит только после оценки нагрузки на tempdb — это решение уровня DBA, не делайте «на всякий случай».
7. Оптимизируйте проблемный код. По данным технологического журнала и ЦУП найдите самые долгие транзакции и уберите из них лишнее: вынесите чтение и отчёты за пределы транзакции, добавьте недостающие индексы, избегайте проведения задним числом.

Короткий чек-лист для разбора массовых блокировок:

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