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

Question

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

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

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

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

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

edit: Дополнительная информация

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

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

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

Answer 1

TRY:

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, а не графический рендеринг.