Deadlocks - блокировка и ожидание одного и того же индекса

Question

У меня возникла тупиковая ситуация в приложении SQL Server. Я запустил SQL Profiler и поднял "граф взаимоблокировок", и это, кажется, говорит мне, что оба процесса удерживают и ожидают блокировки для одного и того же индекса первичного ключа.

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

то есть ОБНОВЛЕНИЕ xxx SET yyy = yyy + zzz ГДЕ aaa = @aaa

1. Почему оба процесса запрашивают блокировку U, когда они оба уже удерживают блокировку X, наверняка они могут выполнить обновление с блокировкой X?
2. Как оба процесса получили X-блокировку одновременно?
3. Как мне исправить это?:-)

Спасибо за помощь.

редактировать: дополнительная информация

Точная процедура:

CREATE PROC spuPlayerStats
    @PlayerId int,
    @HandsPlayed int
AS
BEGIN
        UPDATE Player  
        SET
            HandsPlayed = HandsPlayed + @HandsPlayed
        WHERE
            PlayerId = @PlayerId
END
GO

Индекс - это просто первичный кластерный индекс.

Answer 1

ПЫТАТЬСЯ:

SELECT @updateValue = HandsPlayed + @HandsPLayed FROM Player WHERE PlayerId = @PlayerId

UPDATE Player  
    SET
        HandsPlayed = updateValue 
    WHERE
        PlayerId = @PlayerId

Answer 2

Я рекомендую вам опубликовать фактический тупик XML. Графическое представление не всегда точное, см . Загадку U-блокировок в графе тупиков s. Блокировки могут возникать даже при обманчиво простых утверждениях в хорошо настроенных запросах, в зависимости от порядка применения обновлений, см. " Блокировка чтения / записи". Кроме того, могут возникать взаимоблокировки даже в системах, которые, по-видимому, на 100% безопасны, как та, которую вы первоначально описали в посте (обновление одной строки в кластеризованном индексе без обновлений вторичного индекса для разных ключей) из-за коллизий хешей, см. %%lockres%% вероятность столкновения магический маркер: 16,777,215.

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