Ms sql ошибка transaction was deadlocked on lock resources with another process

Обновлено: 04.07.2024

In order to know what to look into, you would need to identify the deadlock. This query may help in providing that information. Otherwise, you could set up a trace in Profiler to help, also.

>>Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction

“Transaction was deadlocked” error occurs when two or more sessions are waiting to get a lock on a resource which has already locked by another session in the same blocking chain. As a result, none of the sessions can be completed and SQL Server has to intervene to solve this problem. It gets rid of the deadlock by automatically choosing one of the sessions as a victim and kills it allowing the other session to continue.

--Два процесса, два кейлока
05/25/2012 14:40:20,spid15s,Unknown,waiter mode=X requestType=wait
05/25/2012 14:40:20,spid15s,Unknown,waiter-list
05/25/2012 14:40:20,spid15s,Unknown,owner color="gray">process6a3fb88 mode=S
05/25/2012 14:40:20,spid15s,Unknown,owner-list
05/25/2012 14:40:20,spid15s,Unknown,keylock hobtid=72057594058506240 dbid=5 objectname= MyTable indexname=ix_MyTable___create_dt___ID mode=S associatedObjectId=72057594058506240
05/25/2012 14:40:20,spid15s,Unknown,waiter color="gray">process6a3fb88 mode=S requestType=wait
05/25/2012 14:40:20,spid15s,Unknown,waiter-list
05/25/2012 14:40:20,spid15s,Unknown,owner mode=X
05/25/2012 14:40:20,spid15s,Unknown,owner-list
05/25/2012 14:40:20,spid15s,Unknown,keylock hobtid=72057594061717504 dbid=5 objectname= MyTable indexname=PK_MyTable mode=X associatedObjectId=72057594061717504

--До свидания процесс process6a3fb88
05/25/2012 14:40:20,spid15s,Unknown,process-list
05/25/2012 14:40:20,spid15s,Unknown,deadlock victim= process6a3fb88
05/25/2012 14:40:20,spid15s,Unknown,deadlock-list

Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64)
Jun 17 2016 19:14:09
Copyright (c) Microsoft Corporation
Express Edition (64-bit) on Windows NT 6.3 <X64> (Build 14393: )

Выдаваемая ошибка:
Transaction (Process ID 51) was deadlocked on lock | generic waitable object resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Примитивная инструкция на которой процесс задидлочил сам себя:

Файл с графом дидлока во вложении.

Читал по форуму про проблему самодидлочения, - только сервиспаки советуют ставить, да писать письма в Микрософт.
Дидлок этот у нас первый раз возник без установленых сервиспаков.
Поставили SP, он все равно гарантировано воспроизводится.

Вопрос:
Кроме написания писем в MS, есть еще какието направления как можно попытаться решить эту проблему?
В какую сторону смотреть?

вычитал про MARS:
"MARS enables the interleaved execution of multiple requests within a single connection"

Правильно я понял, что есть возможность того, что внешняя программа, имея на SQL сервере коннектион (SPID=51) не дождавшись
выполнения инструкции

Спасибо за подсказку. Запрос пока менять не хотелось бы.
Пока сможем проверить вариант:

Чтобы избежать эксалации S в X внутри пула MARS, рекомендую сразу вешать WITH(TABLOCKX) на Update.
Проблема эта древняя как мамонт, еще в 2009 году обсуждали, что делать.
Поль Уайтт в 2014 проверял, что до сих пор все так же.

Как такое возможно?
В select на котором происходит deadlock используется много join'ов, подзапросов, top, а также join с Table-Value user-defined function которая тоже не очень тривиальная.

Казалось бы для deadlock'а надо чтобы были две транзакции с как минимум двумя последовательными действиями в каждой. Но в моей ситуации транзакций нет вообще!

Locks: Locks on database objects, including data rows, pages, tables, and index keys.

Worker threads: This can include scheduler and CLR synchronization objects.

Memory: In which two processes each need more memory but must wait for the other before it can be granted.

Parallel threads within a single query.

Multiple Active Results Sets (MARS) resources: Internal conflicts within MARS threads.

Inside Microsoft® SQL Server™ 2005: Query Tuning and Optimization
by Kalen Delaney

1083150904:1 это primary key по таблице
1083150904:2 это другой индекс по той же самой таблице

Если я правильно понимаю то delete по primary key конфликтует с select из той же таблице по другому индексу. Триггеров никаких нет.

Читайте также: