Проблема мертвой блокировки в SQL Server 2008

Question

Я попал в тупиковую проблему, из-за которой я изо всех сил пытаюсь найти основную причину ... График тупиковой ситуации предполагает, что оператор UPDATE стал жертвой по сравнению с оператором SELECT ... Что меня озадачивает, так это то, что оператор UPDATE пытается получить индекс для какой-то другой таблицы, которая никогда не упоминается в операторе обновления ...

Вот так выглядит мой оператор UPDATE ...

UPDATE Table set col1 = @P1  where col2 = @P2 

Этот оператор получил X-блокировку для индекса col2, но также пытается получить индекс для столбца, определенного в некоторой другой таблице, которая никак не связана с оператором UPDATE ...

И оператор SELECT, который победил в ситуации взаимоблокировки, не имеет ничего общего с таблицей или индексом в операторе обновления, но попытался получить индекс для таблицы в операторе UPDATE. в конечном итоге вызывает DEADLOCK.

Answer 1

Обновление транзакции / блокировки будет включать в себя такие вещи, как:

• триггеры
• проверки внешнего ключа (col1 a fk?)
• проверка ограничений (для col1 с использованием udf)
• индексированных представлений (которые используют table.col1 или table.col2)

Любой из них может привести к блокировке явно несвязанной таблицы

Answer 2

В дополнение к другим отличным ответам, следует учитывать, что выборка обычно получает общую блокировку чтения, которая позволяет серии выборок поддерживать общую блокировку ресурса. Оператор обновления никогда не сможет получить эксклюзивную блокировку. Обычно, хотя движок хорошо справляется с предотвращением такого типа голодания, но если вы используете обновление в транзакции с другим оператором (ами), это может усложнить проблему. Если это так, предоставьте более подробную информацию о том, что происходит в транзакции.