При администрировании высоконагруженных систем на базе «1С:Предприятие» специалисты часто сталкиваются с аппаратными и программными сбоями. Одним из самых неприятных и труднораспутываемых инцидентов является конфликт блокировок при выполнении транзакций. Ситуация осложняется тем, что под одной и той же формулировкой «ошибка блокировки» могут скрываться два абсолютно разных технических механизма. Проанализируем природу этих ошибок, выясним причины их возникновения и разберем по шагам методы детальной диагностики с помощью Технологического журнала (ТЖ) и встроенных средств MS SQL Server.
Для начала разберем ситуацию, с которой часто сталкиваются администраторы при анализе технологического журнала. В ТЖ могут фиксироваться два различных исключения:
Microsoft SQL Server Native Client 10.0: Превышено время ожидания запроса на блокировку. HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=38, Severity=10, native=1222, line=1.Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки.Рассмотрим подробнее их принципиальные различия. Во втором случае конфликт происходит на уровне встроенного менеджера блокировок 1С. Это так называемые управляемые блокировки. Менеджер блокировок платформы «1С:Предприятие» сам отслеживает бесконфликтность доступа к ресурсам базы данных. Если одна транзакция пытается заблокировать, например, определенный набор записей регистра, а вторая транзакция уже удерживает на него блокировку, то вторая транзакция ожидает освобождения ресурса. Если ожидание превышает время, заданное в конфигураторе (по умолчанию 20 секунд), платформа генерирует исключение. В ТЖ при этом фиксируются стандартные события TTIMEOUT и TLOCK, по которым легко определить виновника и жертву.
В первом же случае мы имеем дело с таймаутом на уровне СУБД (ошибка с кодом native=1222). Этот конфликт происходит непосредственно внутри MS SQL Server. СУБД не смогла предоставить блокировку на уровне физических таблиц, страниц или строк данных в отведенное время. Менеджер управляемых блокировок 1С со своей стороны этот конфликт не видит, так как запросы просто «зависают» на выполнении внутри базы данных. Именно поэтому в технологическом журнале при стандартных настройках отсутствуют события TTIMEOUT и TLOCK — для 1С эта транзакция выглядит как долго выполняющийся запрос СУБД, завершившийся аварийным исключением.
Если анализ логов показал, что вы столкнулись с классическим таймаутом управляемых блокировок, расследовать его относительно просто. Для этого настроим Технологический журнал на сбор событий TTIMEOUT, TLOCK, а также на фиксацию начала, окончания и отката транзакций.
Посмотрим на пример конфигурационного файла logcfg.xml для сбора управляемых блокировок:
<config xmlns="http://v8.1c.ru/8.1/xdto">
<log location="C:\v8\logs\locks" history="24">
<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. В свойствах этого события будет четко указано имя заблокированного пространства, описание заблокированных полей, а также идентификатор транзакции-жертвы и транзакции-виновника. Сопоставив эти данные с событиями TLOCK, мы сможем построить полную цепочку и увидеть, какой именно программный код удерживал блокировку слишком долго.
Для расследования блокировок на уровне СУБД стандартных событий TLOCK недостаточно. Однако, начиная с версии платформы 8.3.8, разработчики добавили мощный встроенный механизм мониторинга физических блокировок. Для его активации используется специальный тег <dbmslocks/>.
Разберем по шагам, как настроить сбор логов ТЖ для выявления виновников СУБД-блокировок. Мы должны включить отслеживание событий DBMSSQL, длительность которых превышает критический порог (например, более 20000 миллисекунд или 20 секунд), и добавить тег детального анализа СУБД-блокировок.
Применим следующую структуру файла logcfg.xml:
<config xmlns="http://v8.1c.ru/8.1/xdto">
<dbmslocks/>
<log location="C:\v8\logs\dbms_locks" history="24">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="20000000"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Важное примечание: Использование тега <dbmslocks/> задействует системную службу кластера AuxiliaryService, которая с периодичностью раз в несколько секунд опрашивает системные таблицы СУБД на предмет взаимных блокировок сессий. Это создает дополнительную нагрузку на сервер, поэтому активируйте этот режим только на время расследования инцидентов.
После включения данного флага в логах ТЖ для событий СУБД начнут заполняться уникальные свойства:
lkp='1' — указывает, что данная сессия является жертвой блокировки СУБД.lka='1' — указывает, что данная сессия является источником (виновником) блокировки.lkpid — уникальный идентификатор заблокированного запроса.lkaid — список идентификаторов запросов, которые были заблокированы этой сессией.Благодаря сопоставлению этих свойств мы можем без использования сторонних утилит определить, какой именно фоновый процесс или пользовательский сеанс заблокировал таблицы на уровне MS SQL Server.
Если мы хотим провести максимально точный анализ непосредственно на стороне базы данных без дополнительной нагрузки на кластер 1С, отличным решением станет использование встроенного механизма СУБД — Blocked Process Report (BPR). Этот инструмент позволяет автоматически фиксировать подробные XML-отчеты о блокировках, превысивших заданный временной лимит.
Выясним, как активировать этот отчет. По умолчанию в MS SQL Server сбор отчетов о заблокированных процессах отключен. Включим его с помощью следующего T-SQL скрипта в среде SQL Server Management Studio (SSMS):
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'blocked process threshold', 5; -- Порог в секундах (например, 5 секунд)
RECONFIGURE;
GO
После выполнения этого скрипта SQL Server начнет генерировать события при обнаружении блокировок, длящихся более 5 секунд. Для сбора этих событий рекомендуется настроить сессию Extended Events (Расширенные события). Это современная альтернатива устаревшему SQL Profiler, которая практически не оказывает влияния на производительность сервера.
В собранном XML-файле отчета (Blocked Process Report) мы увидим две ключевые секции:
<blocked-process> — содержит подробную информацию о заблокированном запросе-жертве, включая текст SQL-запроса, контекст выполнения, уровень изоляции транзакции и дескриптор соединения.<blocking-process> — содержит информацию о запросе-источнике, который удерживал монопольную блокировку и не давал выполниться первой транзакции.По именам таблиц в тексте SQL-запросов (например, таблицы вида _InfoRg1234 или _Document56) мы легко сможем сопоставить физические объекты СУБД с метаданными в конфигураторе 1С.
Если в вашей системе регулярно возникают таймауты СУБД (ошибки native=1222), это свидетельствует об архитектурных проблемах или неоптимальных запросах. Проанализируем самые распространенные причины:
Table Scan). При этом SQL Server вынужден блокировать огромные диапазоны данных, включая строки, которые текущему пользователю не нужны. Это мгновенно парализует параллельную работу других пользователей. Решение: добавление недостающих индексов.TAB). В этот момент любое параллельное обращение к таблице вызывает таймаут. Решение: оптимизация кода, обработка данных небольшими порциями (пакетами).Serializable или Repeatable Read), что приводит к наложению избыточных S-блокировок (блокировок чтения). Перевод конфигурации или отдельных объектов в режим управляемых блокировок переводит работу СУБД на уровень Read Committed (с использованием механизма версионности строк RCSI), что сводит конфликты на уровне СУБД к минимуму.Систематический мониторинг с использованием предложенных инструментов позволит вам быстро локализовать узкие места конфигурации, устранить избыточные блокировки и обеспечить стабильную и быструю работу информационной системы.