Добрый день.

Вчера тестовый сервер был обновлен с 2016 SP1 CU1 до 2016 SP1 CU7.
Обновление прошло нормально, но сегодня начались проблемы с дедлоками.

В текущий транзакциях на сервере две сессии взаимоблокируют друг друга, следующие висят на них.
Обычно sql server автоматом убивает одну из транзакций, но тут продолжают висеть, если не убрать руками.

С чем может быть связано и что можно сделать?

invm,

Запросы я отловил, разбираться почему вообще начались блокировки тоже нужно.

Это обновление таблицы и селект в неё же, обычно в похожих случаях отстреливает селект.

update [TABLE] set [sync_with_lc_status] = @P1 where [AID] = @P2

select top 1500 * from [TABLE] where [sync_with_lc_status] in (@P1, @P2) and [TABLE].[Status] in (@P3, @P4, @P5, @P6) order by [cito] desc, [AID] desc

По ссылке посмотрел, но решения проблемы я там не вижу(

Эти запросы с разных серверов.
3 столбец - время выполнения, на скриншоте макс 3 минуты, но висело и 20+

Сейчас сессии
87 и 75
87 - селект

Владислав Колосов,

Хорошее определение, но к чему оно?

Пока оставив в сторону вопрос почему автоматически не отстреливает одну из транзакций начали разбираться, что за сервера с которых идут запросы.
Выяснилось, что второй сервер был создан копированием с первого и они похоже пытаются выполнить одно и тоже.
При этом никто не сообщил, что отвечает за второй сервер и он кому-то нужен, так что пока погасили его.

Текущую проблему конечно решило, но вопрос почему sql сервер похоже не считал это взаимоблокировокой и не убирал, хотя они именно что блокировали выполнение друг друга, остаётся открытым.

Поддерживаю invm.

На таблице РК + не кластерные индексы.

Для данного запроса пожалуй не самые оптимальные, но обычно нормально отрабатывают.
По плану селект делает через Key Lookup (99% стоимости) + Index seek, дальше nested loops и последующая обработка.

Запрос выполняется меньше секунды, тогда висело и 30+ минут. Такая конкуренция по результату от дедлока не отличается, только сервер сам не решает проблему.

TaPaK,

Флаги 1211, 1224 на этом сервер выключены. Скорее всего укрупнение включено.

Можно включать\выключать с помощью для таблицы
ALTER TABLE SET (LOCK_ESCALATION = DISABLE)
Но что-то не понял, где текущий статус пишет.

TaPaK,

На уровне сервера включено.
Для проверки на уровне таблицы просьба подсказать как проверить.

TaPaK,

Спасибо за ответ.
На таблице тоже включено. При этом на проде включен флаг 1224, подобной проблемы не встречал, хотя на тесте кроме этих двух запросов тоже подобного нет.

invm,

Выше в теме всё есть.
21869655

Гавриленко Сергей Алексеевич,

А чем не устраивают поля last_wait_type, wait_resource из sys.dm_exec_requests?

Сейчас то проблемы больше нет и смотреть не на что больше.

invm,
На скриншоте оставил
select session_id, wait_resource, last_wait_type from sys.dm_exec_requests
Смотрел сначала просто через *, у обоих столбцов значение для сессий было одинаковым.
Через sp_who выглядело: селект в несколько потоков и один из них поймал блокировку от апдейт. Апдейт в один поток блокирован сессий селекта.

Ладно, сейчас проблема решена, смотреть больше не на что. Всем спасибо.

Гавриленко Сергей Алексеевич,

Хорошо, если опять будет похожая проблема, то понял что смотреть.