Все ли блокировки вызваны неправильным запросом

"транзакция (идентификатор процесса 63) был взаимно блокировки | буфер связи с другим процессом и была выбрана в качестве жертвы взаимоблокировки. Повторите транзакцию.". Возможные причины сбоя: проблемы с запросом, свойство "ResultSet" установлено неправильно, параметры установлены неправильно или соединение установлено неправильно."

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

9
deadlock sql-server

3 ответов

две таблицы доступ к одной таблице в то же время происходит все время в приложении. Обычно это не приводит к тупику. Тупик обычно происходит, если сказать, процесс " а " попытке обновления таблицы 1 и таблицы 2 и таблицы 3, и у вас есть процесс Б пытается обновить таблицу 3, затем таблицу 2 и таблицу 1. Процесс " A "будет иметь заблокированный ресурс, который нужен процессу "B", а процесс " B "имеет потребности процесса "a". SQL Server обнаруживает это как взаимоблокировка и откат одного из процессов назад, как неудачная транзакция.

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

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

8

отсутствующие индексы-еще одна распространенная причина тупиков. Если запрос select может получить необходимую информацию из индекса вместо базовой таблицы, он не будет заблокирован никакими обновлениями/вставками в самой таблице.

чтобы узнать наверняка, используйте SQL profiler для трассировки событий "Deadlock Graph", которые покажут вам детали самой взаимоблокировки.

4

на основе этой, Я не думаю, что сама Почта SQL будет напрямую быть виновником. Я говорю "прямо", потому что не знаю, что вы с ним делаете. Однако Я ... --3-->предположим SQL Mail, вероятно, медленный по сравнению с остальными вашими SQL ops, поэтому, если вы много делаете с этим, это может косвенно создать узкое место, которое приводит к взаимоблокировке, если вы держитесь за таблицы при отправке SQL Mail.

трудно рекомендовать конкретный стратегия, не имея слишком много деталей о том, что вы делаете. Короче говоря, вы должны рассмотреть, есть ли способ сломать вашу зависимость от удержания на столе, пока вы делаете это, например, используя NOLOCK, используя временную таблицу или нетемповую таблицу "удержания" или просто рефакторинг SP, который делает вызов.

2