Требования: Существует множество причин, по которым базы данных SQL Server вызывают тупиковые блокировки: в производстве все могут столкнуться с проблемами тупиков, и конкретная причина может быть обнаружена не только на основе ненормальной информации о блокировках приложений, поэтому необходимо использовать события расширений в SQL Server для отслеживания проблем с тупиками и фиксации конкретных моментов их возникновения.
Расширенный обзор мероприятия
Extended Events — это лёгкая функция мониторинга производительности, позволяющая пользователям собирать необходимые данные для мониторинга и решения проблем. Эта функция позволяет просматривать детали внутренних операций движка данных для мониторинга производительности и решения задач.
С архитектурой Extended Events (XEvents) пользователи могут использовать столько или минимально данных, сколько им нужно для мониторинга, идентификации или устранения неполадок в SQL Server, Azure SQL Database и Azure SQL Managed Instance. Расширенные события очень настраиваемы, лёгкие и хорошо масштабируемы.
Ссылка:
Вход по гиперссылке виден.
Вход по гиперссылке виден.
Причины тупика
Тупиковые блокировки возникают из-за конкурирующих параллельных блокировок в базе данных, обычно в многоступенчатых транзакциях. Каждая пользовательская сессия может выполнять одну или несколько задач, при этом каждая задача может загружать или ждать для получения различных ресурсов. Следующие типы ресурсов могут вызвать блокировку и в конечном итоге привести к тупику.
- Блокировки: Блокировки, ожидающие загрузки ресурсов, таких как объекты, страницы, строки, метаданные и приложения, могут вызывать тупики. Например, транзакция T1 имеет общий замок (S lock) в строке r1 и ждёт получения эксклюзивного блокировки (X lock) для строки r2. Транзакция T2 имеет общий замок (S lock) в ряду r2 и ждёт получения эксклюзивного блокировки (X lock) для ряда r1. Это приводит к замкнению блокировки, где и T1, и T2 ждут друг друга, чтобы освободить заблокированный ресурс.
- Worker потоки: очередь задач для доступных рабочих потоков может привести к тупиков. Если в очереди есть ресурс, блокирующий все рабочие потоки, это приведёт к тупиковой блокировке. Например, после того как сессия S1 запускает транзакцию и получает общий замок (S-lock) для линии r1, она переходит в спящий режим. Активная сессия, работающая на всех доступных рабочих потоках, пытается получить эксклюзивную блокировку (X-lock) для строки r1. Поскольку сессия S1 не может получить рабочий поток, она не может коммитировать транзакцию и снять блокировку на линии r1. Это приведёт к тупику.
- Память: Тупиковая зависимость может возникнуть, когда одновременный запрос ждёт получения памяти, а доступной памяти недостаточно для его нужд. Например, два одновременных запроса (Q1 и Q2) выполняются как пользовательские функции, забирая соответственно 10 МБ и 20 МБ памяти. Если для каждого запроса требуется 30 МБ, а общая доступная память составляет 20 МБ, Q1 и Q2 должны ждать друг друга, чтобы освободить память, что приведёт к тупиковой блокировке.
- Параллельные запросы и ресурсы, связанные с выполнением: координаторы обработки, генераторы или потребительские потоки, обычно связанные с коммутируемыми портами, могут блокировать друг друга, если содержат хотя бы один процесс, не входящий в параллельный запрос, что приводит к тупиковым блокировкам. Кроме того, при начале выполнения параллельного запроса SQL Server определяет степень параллелизма или количество рабочих потоков на основе текущей нагрузки. Тупик может возникнуть при неожиданном изменении нагрузки системы, например, когда на сервере начинается новый запрос или когда в системе заканчиваются рабочие потоки.
- Ресурсы множественного набора результатов активности (MARS): Эти ресурсы используются для управления перекрёстным выполнением нескольких запросов на активность в рамках MARS.
Ссылка:
Вход по гиперссылке виден.
Логирование событий с расширенной зависимостью
Создайте событие расширения для записи информации о тупике с помощью следующей команды:
Запустите сессию событий с тупиком
Остановите сессию мероприятия
Удалить сессию события
Данные сессии запроса событий
Тестовые тупики
Создайте новую таблицу Tab1 для тестирования, создайте два новых окна выполнения и выполните следующие команды соответственно:
Тупиковая ситуация возникает следующим образом:
Транзакция (идентификатор процесса 68) с другим процессом заблокирована на заблокированном ресурсе и выбрана в качестве жертвы тупика. Пожалуйста, повторите транзакцию.
Транзакция (ID процесса 68) была заблокирована на ресурсах блокировки с другим процессом и выбрана жертвой тупиков. Повторите транзакцию. 
Просмотрите данные сессии события, как показано на следующем рисунке:
Подробные XML-данные следующие:
(Конец)
|
Опубликовано 02.03.2024 19:13:04
|
|
|
|
Хозяин|
Опубликовано 02.03.2024 19:14:35
|
