Мертвая блокировка SQLServer

взаимоблокировки в SQLServer почти всегда возникают из-за того, что один поток пытается писать и читать, используя два соединения и, следовательно, две транзакции. Если вы хотите, чтобы это работало, выполняйте все операции в одном потоке, используя ОДНО соединение, и убедитесь, что вы действительно повторно используете соединение. Это может быть связано с тем, что в вашем приложении вы случайно используете другое соединение для чтения во время транзакции, что заставляет это чтение ждать завершения другого кода (используя другое соединение), что никогда не происходит, так как чтение никогда не заканчивается.

Пример (псевдо шаги)

start trans

• записывать данные (например, INSERT, UPDATE) в таблицу Foo
• считывать некоторые данные (которые запускают сканирование таблицы) из Foo, используя другое соединение DEADLOCK, так как чтение никогда не заканчивается, поэтому транзакция никогда не фиксируется

Я предполагаю, что вы запустили что-то вроде: DBCC TRACEON (1222, -1) «и / или» DBCC TRACEON (1204, -1). Я нахожу трассировку тупиковой ситуации в журналах SQLServer трудной для чтения. Вы уверены, что это попытка перейти к монопольным (X) блокировкам?

Попробуйте запустить трассировку в профилировщике (выберите пустой шаблон), выберите «событие графика взаимоблокировки» и на новой вкладке Появится (Настройки извлечения событий), сохраните каждое (установите флажок «отдельно сохранять события блокировки XML») в своем собственном файле. Откройте этот файл в программе просмотра XML, и вам будет легко узнать, что происходит. Каждый процесс содержится со стеком выполнения вызовов процедур / триггеров и т. Д. И т. Д., И все блокировки также присутствуют там.col = @ value вызывают проблему, посмотрите на стек выполнения, есть ли триггер или что-то еще происходит?

Посмотрите на раздел «список ресурсов» файла, он покажет, что блокируется и удерживается каждым процесс, вызывающий тупик. Выясните, как не заблокировать один из них, и тупик будет устранен.

Добро пожаловать в ужас.

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

Итак, если вы можете изолировать некоторые из запросов, проверьте их в sql и посмотрите, не можете ли вы поэкспериментировать с предоставлением некоторых покрывающих индексов.

Покрывающий индекс - это индекс, который включает все поля в конкретном предложении where.

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

... Да, транзакция объявлена убедитесь, что весь граф объекта удалены или оставлены нетронутыми, если есть ошибка. Нет другой базы данных операций в сделке, некоторые чтения выполняются перед транзакцией запускается, но внутри него нет ...

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

При этом ...

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

Сначала не используйте подсказки, обычно SQL Server лучше оставить сам по себе.

Затем проверьте, что у вас нет НАСТОЯЩЕГО тупика (но это случается гораздо реже из-за появления тупика. может намекнуть).

В-третьих, как кто-то предложил, проверьте, есть ли у вас медленный запрос, и настройте его.

По моему опыту каждый раз клиент сообщал о тупиковой ситуации, это произошло потому, что был медленный запрос, который обострялся, и никогда не возникала настоящая тупиковая ситуация, и настройка запроса или добавление определенного индекса всегда решала проблему.

Я не понимаю, о какой версии SQL Server вы говорите но каждая следующая версия имеет лучшее управление взаимоблокировками, чем предыдущая, и SQL Server 2000 был особенно неприятен в этой теме.

С уважением
Massimo