MS SQL deadlock

← →
ProstoTak © (2014-10-03 15:21) [0]

В программе, которая цепляется к MS SQL Server 2005 через ADO выдается:

Transaction was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

http://goo.gl/FZcqHk

В мониторе активности для данного процесса стоит: "exec MyProc 1, 0, 0, 0"

MyProc это простая процедура, которая делает SELECT с несколькими джойнами

PROCEDURE MyProc(@flag1 bit, @flag2 bit, @flag3 bit, @flag4 bit) AS BEGIN SELECT ... FROM tblClaim a INNER JOIN ... ON ... LEFT JOIN ... ON ... LEFT JOIN ... ON ... WHERE (x.y = @flag1) ... AND ... ORDER BY zzz DESC END

Собственно, и все. Отчего может возникать дедлок?!

Возникает очень редко, но бывает. Причем если начинает возникать - то массово. А потом пропадет.

← →
junglecat © (2014-10-03 15:30) [1]

а кто-то может параллельно обновлять участвующие таблицы? или читать с блокировкой?
попробуй
SELECT ...
FROM tblClaim a WITH (NOLOCK)

ну и в джойнах тоже добавь WITH (NOLOCK)

← →
ProstoTak © (2014-10-03 15:31) [2]

> а кто-то может параллельно обновлять участвующие таблицы?

может. Но ведь программа должна зависнуть в ожидании окончания разблокировки.

Как select может выдать дедлок?

← →
junglecat © (2014-10-03 15:44) [3]

> Как select может выдать дедлок?

если уровень изоляции read commited, то запросто

процесс А селект из таб А джойн Б - залочили страницу
процесс Х апдейт таблицы Б джойн А - вдруг по условию залочили ту же страницу, ждем А, а А в это время ждет Б.
Дед Лок пришел.

← →
ProstoTak © (2014-10-03 16:30) [4]

> процесс Х апдейт таблицы Б джойн А

это как?

← →
junglecat © (2014-10-03 17:22) [5]

http://technet.microsoft.com/ru-ru/library/ms178104(v=sql.105).aspx

← →
ВладОшин © (2014-10-03 18:15) [6]

померяйте пинг до сервера в такие ситуации
есть подозрение..
сообщите, плз, резулт :)

← →
ProstoTak © (2014-10-03 18:31) [7]

> http://technet.microsoft.com/ru-ru/library/ms178104(v=sql.
> 105).aspx

я это читал. Я не понял как можно апдейтить с джойном.

> есть подозрение..

озвучь? Просто проблема крайне плавающая, быстро сама по себе исчезающая, поэтому сложно что-то анализировать :(

← →
Кщд © (2014-10-03 18:32) [8]

>junglecat © (03.10.14 15:30) [1]
dirty reads - плохо-плохой совет

← →
Кщд © (2014-10-03 18:36) [9]

>ProstoTak © (03.10.14 18:31) [7]
>я это читал. Я не понял как можно апдейтить с джойном.
просто:
1. определить запросы, вызывающие deadlock (трассировка);
2. скорректировать подход к работе с данными (почитать про блокировочники и best practice).

← →
ВладОшин © (2014-10-03 18:40) [10]

да что озвучивать..
как только у MSSQL возникают проблемы с коннектом, начинаются такие ошибки

т.е. или сисадмин что-то должен выставить или надо принять как данность и
сидеть на стуле прямо, обрабатывая ошибки

вопрос или у меня так(как только у MSSQL возникают проблемы с коннектом, начинаются такие ошибки) или у всех

← →
ВладОшин © (2014-10-03 18:42) [11]

причем в программе ничего не менялось, а ошибки то есть то нет
сплошь рядом, есть такое, да
по наблиюдениям именно от скорсоти ответа зависит.

← →
Кщд © (2014-10-03 20:44) [12]

>ВладОшин © (03.10.14 18:42) [11]
зачем гадать?
трассируйте

← →
ВладОшин © (2014-10-03 20:55) [13]

> Кщд © (03.10.14 20:44) [12]

да я бы рад, но сейчас нет таких проблем.

было два дня назад, ночью
спал тогда :)

там у меня execept.. end - и заново, если что (ну, что бы хоть что-то делалаось)
когда в след.раз будет - неизвестно.

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

← →
ВладОшин © (2014-10-03 21:01) [14]

тогда зачем написано

> сплошь рядом, есть такое, да

неправильно тогда написано.
уточнение - Было пару раз, подозреваю пропорциональность ответу

в принципе, можно,завтра проэмулировать
через какой нить китайский, потом индийский, потом .. ский проксий прокси добиться ответа в 30-40 секунд и проверить..

oк
Попробуем :)

спасибо :)

← →
turbouser © (2014-10-03 22:58) [15]

> ВладОшин © (03.10.14 18:40) [10]
>
> да что озвучивать..
> как только у MSSQL возникают проблемы с коннектом, начинаются
> такие ошибки

Что-то в консерватории не так

← →
ProstoTak © (2014-10-04 13:02) [16]

> просто

что просто? Камрад junglecat написал:

> процесс Х апдейт таблицы Б джойн А

у меня вопрос - как можно апдейтить с джойном.

А более крупный вопрос - как SELECT может вызывать deadlock.

> как SELECT может вызывать deadlock.

сам по себе селект нет. Но он выбирается жертвой дедлока как наименее приоритетная транзакция, поскольку не обновляет данные

https://www.simple-talk.com/sql/performance/sql-server-deadlocks-by-example/

> junglecat © (04.10.14 13:27) [17]

> сам по себе селект нет. Но он выбирается жертвой

КО

> ProstoTak ©

а кто headblocker в таких ситуациях?

> [0] ProstoTak © (03.10.14 15:21)

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

> сам по себе селект нет. Но он выбирается жертвой дедлока
> как наименее приоритетная транзакция

ничего не понимаю. Если select наталкивается на блокировку - он просто будет ЖДАТЬ окончания модификации данных.

Каким образом он может привести к дедлоку?

> Каким образом он может привести к дедлоку?

например, селекту нужны 2 индекса для покрытия запроса, и параллельному апдейту тоже нужны эти же 2 индекса. Здесь они и могут упереться рогом.
или вот
http://blogs.msdn.com/b/bartd/archive/2006/09/25/deadlock-troubleshooting-part-3.aspx

> Каким образом он может привести к дедлоку?

SELECT ...
FROM tblClaim a
INNER JOIN tblInfo

время t
процесс_X1 в рамках транзакции Т1 залочил под апдейт tblClaim

время t +1
процесс_Select в рамках транзакции Т2 встал в очередь лочить

время t +2
процесс_X1 в рамках транзакции Т1 захотел залочить tblInfo, но процесс_Select уже ее залочил и ждет освобождения

Т1 не может закончить транзакцию из-за процесс_Select
процесс_Select не может начать из-за Т1

если процесс_Select
>> если уровень изоляции read commited,

можно попробовать дописать WITH (NOLOCK) за каждой таблой, если не важно гарантированность согласования
или установить соотв уровень через set transaction

-------------
PS
а мое подозрение на долгий отклик походу ни при чем, не воспроизвелось
------

проверьте еще триггеры, про эти штуки можно забыть, а они что-то делают - и попадос

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

MS SQL deadlock Найти похожие ветки