Конфликты блокировок — одна из самых частых и неприятных проблем в многопользовательской работе 1С:Предприятие. Пользователи жалуются на сообщения типа «Ошибка при выполнении транзакции: Конфликт блокировок при выполнении операции», а администраторы часто не видят проблем на уровне SQL-сервера. В этой статье мы подробно разберем, как вычислить «виновника» блокировки, используя стандартную консоль кластера серверов, Технологический журнал и встроенные средства платформы.
Первым делом проанализируем возможности штатной консоли кластера 1С. Многие администраторы ограничиваются просмотром списка активных пользователей, однако консоль предоставляет гораздо больше информации, если знать, где искать. Разберем шаги по поиску блокирующего сеанса:
Блокирующий сеанс, Время ожидания на управляемых блокировках и Захвачено СУБД.Проанализируем полученные данные. Если пользователь сообщает об ошибке блокировки в данный момент, в колонке Блокирующий сеанс у него отобразится номер сеанса того пользователя (или регламентного задания), который удерживает нужный ресурс. Это самый быстрый способ найти «виновника» в режиме реального времени.
Выясним причину, по которой MS SQL Server часто не показывает блокировок, в то время как 1С выдает ошибку. В современных конфигурациях используется Управляемый режим блокировок (Managed Locks). Рассмотрим, как это работает:
В управляемом режиме за очередь транзакций отвечает менеджер блокировок самого кластера 1С, а не СУБД. Когда один процесс пытается изменить данные, заблокированные другим процессом, 1С просто не отправляет запрос к SQL-серверу, заставляя сеанс ждать на уровне платформы. Именно поэтому системные представления SQL, такие как sys.dm_tran_locks, могут быть пусты. Если же ваша конфигурация работает в «Автоматическом режиме», блокировки накладываются на уровне таблиц и страниц в СУБД, и их нужно анализировать средствами SQL Profiler или мониторинга блокировок SQL.
Если блокировки кратковременные и их сложно «поймать» в консоли вручную, нам поможет Технологический журнал. Это мощный инструмент, который фиксирует все события платформы в текстовые файлы. Для расследования конфликтов блокировок нам нужно настроить сбор конкретных событий. Для упрощения сбора логов и анализа задержек можно использовать инструмент для сбора технологического журнала и поиска узких мест.
Разберем основные события, которые необходимо отслеживать:
WaitConnections — там будет указан номер блокирующего сеанса.Пример настройки файла logcfg.xml для отслеживания таймаутов блокировок:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\Logs\Locks" history="168">
<event>
<eq property="Name" value="TTIMEOUT"/>
</event>
<event>
<eq property="Name" value="TDEADLOCK"/>
</event>
<property name="All"/>
</log>
</config>
Проанализируем поле Context в логах ТЖ. Оно содержит стек вызова функций 1С, что позволяет точно определить строку кода в модуле (например, в модуле набора записей регистра или в обработке проведения), где произошла задержка.
Если вы работаете в современной конфигурации (ERP, УТ 11, БП 3.0), в ней уже есть встроенный механизм анализа. Перейдем в раздел Обслуживание — Анализ клиент-серверных блокировок. Рассмотрим преимущества этого инструмента:
Этот монитор автоматически собирает данные и представляет их в удобном графическом виде. Он позволяет увидеть «жертву» и «виновника», а также детализировать информацию до конкретного объекта метаданных. Это избавляет от необходимости вручную парсить файлы Технологического журнала.
Выясним, почему блокировки вообще возникают, даже если код кажется правильным. Рассмотрим типичные ошибки при разработке:
ОбработкаПроведения разработчик делает запрос к большой таблице для проверки остатков. Платформа может наложить S-блокировку (Shared) на читаемые данные, что запретит другим пользователям записывать данные в эти же таблицы до конца транзакции.РегистрНакопления.Запасы, а затем РегистрНакопления.Продажи, а другой делает это в обратном порядке — возникнет Deadlock.Для оптимизации работы с регистрами накопления рекомендуется включать режим Разделение итогов. Это позволяет системе записывать движения в разные «слои» итогов, существенно снижая вероятность конфликтов при массовом проведении документов несколькими пользователями одновременно.
Для профессионального анализа производительности и блокировок часто применяются специализированные решения, такие как сервисы Гилева или Центр управления производительностью (ЦУП) из состава КИП. Эти инструменты позволяют строить граф блокировок в реальном времени, наглядно показывая дерево зависимостей сеансов. Если стандартных средств консоли недостаточно, использование таких систем становится производственной необходимостью для крупных внедрений. В качестве более доступной альтернативы можно использовать готовое решение для мониторинга и расследования технологических инцидентов.
Подводя итог, отметим, что решение проблем блокировок — это всегда комплексный процесс: от оперативного выявления виновника в консоли до глубокого анализа кода через Технологический журнал и последующей оптимизации тяжелых запросов.