кейсы клиентов
Ошибки при проведении
Анамнез
Конфигурация ERP.
Жалобы на ошибки при проведении документов, часто появлялось сообщение о таймауте на блокировках СУБД.
Жалобы на ошибки при проведении документов, часто появлялось сообщение о таймауте на блокировках СУБД.
Ошибка о таймауте на блокировках СУБД
На первый взгляд проблема очевидная, и для анализа был включен показатель Ожидания на блокировках с флагом Анализировать блокировки СУБД.
Но чтобы получить более полную картину, также были включены показатели: Долгий запрос, Взаимоблокировка и Ошибка ТЖ.
Но чтобы получить более полную картину, также были включены показатели: Долгий запрос, Взаимоблокировка и Ошибка ТЖ.
Список показателей
С помощью показателя Ошибка ТЖ определили критичность проблемы, сколько ошибок по таймауту возникает за день и есть ли пользователи, у которых ошибка возникает чаще всего.
По анализу ошибок видно, что повторяется она довольно часто - 39 таймаутов на блокировках СУБД за неделю, т.е. примерно 8 ошибок в день или по одной ошибке каждый час.
По анализу ошибок видно, что повторяется она довольно часто - 39 таймаутов на блокировках СУБД за неделю, т.е. примерно 8 ошибок в день или по одной ошибке каждый час.
Ошибки по таймауту на блокировках СУБД
Стали смотреть ожидания на блокировках СУБД: видно, что ожидания происходят при удалении, но, судя по данным журнала регистрации и значениям параметров, данные не пересекались. Получалось, что пользователи работали с разными данными, но ожидания все же были, при этом эскалации не было, так как поле "Гранулярность" имеет значение "Строка".
Детали ожидания на блокировке
Текст запроса SQL, приводящий к блокировке
Решили посмотреть план выполнения запроса, так как запрос с Delete выполнялся медленно - он фиксировался показателем Долгий запрос, для которого был включен сбор планов запроса.
План запроса со сканированием при удалении
В плане запроса видно, что происходило сканирование индекса, хотя все условия для поиска по индексу в запросе указаны, ведь это служебный запрос, формируемый платформой.
С помощью показателя Данные СУБД проверили дату обновления статистики по данному индексу и выяснилось, что она очень давно не обновлялась.
С помощью показателя Данные СУБД проверили дату обновления статистики по данному индексу и выяснилось, что она очень давно не обновлялась.
Дата обновления статистики давно не менялась
Задание по обновлению статистики выполнялось скриптом, в котором не были учтены некоторые особенности данного регистра, из-за чего статистика по нему в определенный момент перестала обновляться.
Доработали скрипт, обновили статистику, сканирование прекратилось, и, как следствие, ушли излишние ожидания и ошибки по таймауту.
На первый взгляд кейс кажется простым, но самым сложным здесь было понять, что данные пользователей не пересекаются, а ожидание все равно происходит. Благодаря тому, что почти все данные для анализа были в одном месте, удалось решить проблему относительно быстро.
Доработали скрипт, обновили статистику, сканирование прекратилось, и, как следствие, ушли излишние ожидания и ошибки по таймауту.
На первый взгляд кейс кажется простым, но самым сложным здесь было понять, что данные пользователей не пересекаются, а ожидание все равно происходит. Благодаря тому, что почти все данные для анализа были в одном месте, удалось решить проблему относительно быстро.
Подпишитесь на наш канал в Telegram чтобы не пропускать новые материалы
Если вы хотите поделиться своим кейсом, напишите нам на support@1smonitor.ru