Найти в Дзене
1SMonitor.ru

Ошибки при проведении документов 1С

Конфигурация ERP.
Жалобы на ошибки при проведении документов, часто появлялось сообщение о таймауте на блокировках СУБД. На первый взгляд проблема очевидная, и для анализа был включен показатель Ожидания на блокировках с флагом Анализировать блокировки СУБД.
Но чтобы получить более полную картину, также были включены показатели: Долгий запрос, Взаимоблокировка и Ошибка ТЖ. С помощью показателя Ошибка ТЖ определили критичность проблемы, сколько ошибок по таймауту возникает за день и есть ли пользователи, у которых ошибка возникает чаще всего.
По анализу ошибок видно, что повторяется она довольно часто - 39 таймаутов на блокировках СУБД за неделю, т.е. примерно 8 ошибок в день или по одной ошибке каждый час. Стали смотреть ожидания на блокировках СУБД: видно, что ожидания происходят при удалении, но, судя по данным журнала регистрации и значениям параметров, данные не пересекались. Получалось, что пользователи работали с разными данными, но ожидания все же были, при этом эскалации
Конфигурация ERP.
Жалобы на ошибки при проведении документов, часто появлялось сообщение о таймауте на блокировках СУБД.

Ошибка о таймауте на блокировках СУБД
Ошибка о таймауте на блокировках СУБД

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

Список показателей Монитора
Список показателей Монитора

С помощью показателя Ошибка ТЖ определили критичность проблемы, сколько ошибок по таймауту возникает за день и есть ли пользователи, у которых ошибка возникает чаще всего.
По анализу ошибок видно, что повторяется она довольно часто - 39 таймаутов на блокировках СУБД за неделю, т.е. примерно 8 ошибок в день или по одной ошибке каждый час.

Ошибки по таймауту на блокировках СУБД
Ошибки по таймауту на блокировках СУБД

Стали смотреть ожидания на блокировках СУБД: видно, что ожидания происходят при удалении, но, судя по данным журнала регистрации и значениям параметров, данные не пересекались. Получалось, что пользователи работали с разными данными, но ожидания все же были, при этом эскалации не было, так как поле "Гранулярность" имеет значение "Строка".

Детали ожидания на блокировке
Детали ожидания на блокировке
Текст запроса SQL, приводящий к блокировке
Текст запроса SQL, приводящий к блокировке

Решили посмотреть план выполнения запроса, так как запрос с Delete выполнялся медленно - он фиксировался показателем Долгий запрос, для которого был включен сбор планов запроса.

План запроса со сканированием при удалении
План запроса со сканированием при удалении

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

Дата обновления статистики давно не менялась
Дата обновления статистики давно не менялась

Задание по обновлению статистики выполнялось скриптом, в котором не были учтены некоторые особенности данного регистра, из-за чего статистика по нему в определенный момент перестала обновляться.
Доработали скрипт, обновили статистику, сканирование прекратилось, и как следствие ушли излишние ожидания и ошибки по таймауту.
На первый взгляд кейс кажется простым, но самым сложным здесь было понять, что данные пользователей не пересекаются, а ожидание все равно происходит. Благодаря тому, что почти все данные для анализа были в одном месте, удалось решить проблему относительно быстро.

Показатели: "Долгий запрос", "Ошибка ТЖ" и "Данные СУБД", описанные в данном кейсе, доступны в бесплатной версии Монитора.
Показатель
"Ожидание на блокировке" является платным.