Деадлоки при использовании SQL Server

[DeSp]

Две сессии намертво лочат друг друга, при этом клиенты повисают пока принудительно вручную не убивается одна из сессий.
Используется SQL Server 2k и LOCKTABLE(true,false).

В чем может быть проблема?

[Advisor]

Возможно идет запись в одну таблицу, либо обе сессии под одним логином

[DeSp]

А почему не могут быть две сессии под одним логином?

[Advisor]

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

[DeSp]

Пробовал и с разными логинами - тот же результат с дедлоками.

[Advisor]

возможно я туплю, но если в первой сессии пользователь использовал LOCKTABLE и эта процедура еще не отработала, то второй естественно будет висеть ожидая освобождения данных. Разве нет? Вероятно у вас какая-то долгая обработка идет вроде учета

[DeSp]

В том то и дело, что так должно быть, но так не происходит - появляется дедлок. Операция дейстивтельно может быть длительной, но порядок блокирования то одинаков для каждого процесса, должны быть обычные блокировки, но не дедлоки.

[pikunov]

Два сеанса, работая параллельно, выполняют функцию LOCKTABLE над одними и теми же таблицами, но в разном порядке.
1 процесс
A.LOCKTABLE
2 процесс
B.LOCKTABLE
1 процесс
B.LOCKTABLE - переводится в ожидание
2 процесс
A.LOCKTABLE - ожидание бесперспективно, дедлок
Такие простые дедлоки распознает сам SQL сервер.
На не все дедлоки простые, когда имеется 50 параллельных процессов, ожидания возникают регулярно, целые очереди процессов к различным таблицам. Основной причиной дедлоков является различный ПОРЯДОК установления блокировки таблиц, рекомендуется всегда воспроизводить один и тот же порядок блокировки.
Это сложно, если блокировки разбросаны по всему коду транзакции, поэтому мы видим близко к началу учетных кодюнитов (12,22,80,90,...) сгруппированные вместе операции блокировки. Но нарушения все равно есть, это просто ошибки разработчиков, которые очень непросто выявить. Присмотритесь даже к группам блокировок в 80 и 90 кодеюнитах и увидите нарушение порядка.

[DeSp]

Опишу ситуацию подробнее:
Одноврменно запускаю одинаковую операцию на двух клиентах. Как правило, один из клиентов отключается сервером из-за дедлока, а второй успешно заканчивает свою транзакцию. Но, бывают мертвые зависы, когда оба клиента висят до тех пор (как минимум час), пока вручную не отключить одного из них - блокирующего, убив его процесс, тогда блокируемый также успешно заканчивает транзакцию. Информация по процессам мертвого зависа реглуярно обновляется в Enterprise Manager -> Process Info на протяжении всего времени зависа:

client1: spid=56, status=sleeping, open transactions=0, command=awaiting command, wait time=0, wait type=not waiting, wait resource=..., blocked by=0, blocking=1

client2: spid=55, status=sleeping, open transactions=1, command=execute, wait time=0, wait type=miscellaneous, wait resource=..., blocked by 56, blocking=0

Резалтсет процедуры sp_lock по 56 показывает, что он получил все необходимые ему ресурсы (status=GRANT), а 57 ждет освобождения ключа (status=WAIT).

В трассе профайлера в таком случае также обнаруживаются все полагающиеся ивенты для дедлока, по времени совпадающего с моментом времени зависа: Lockeadlock Chain, Lockeadlock и Exception (Error=1205, Severity=13, State=50) для блокирующего процесса. То есть сервер выбрал блокирующего жертвой дедлока и должен был откатить его транзакцию, а значит освободить заблокированные им ресурсы, нужные для продолжения транзакции блокируемого. Но клиенты продолжают висеть! Видимо по какой-то причине ресурсы блокирующего не были освобождены, а транзакция не была откатана. Если это был дедлок (а трасса говорит что был) то почему клиенты продолжают висеть? В чем может быть проблема?

Кроме того, если мониторить выполнение операции с помощью средств Navision (Code coverage, Client Monitor, Client Monitor (Multi-User) согласно инструкции "Performance troubleshooting guide.pdf", то у блокирующего клиента в момент времени зависа в логе появляется ошибка [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()). О чем говорит данная ошибка?

При мертвом зависе и последующем убивании вручную блокирующего процесса 56 его клиент иногда выдает сообщение вида: "Внутрення ошибка 1247 в модуле 19, обртитесь к вашему дилеру, если нужна помощь." Что это за ощибка?