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

Question

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

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

Answer 1

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

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

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

Answer 2

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

Чтобы узнать наверняка, используйте профилировщик SQL для отслеживания событий «График тупиков», который покажет вам детали самой тупиковой ситуации.

Answer 3

Исходя из этого , я не думаю, что сама SQL Mail напрямую будет виновником. Я говорю "напрямую", потому что я не знаю, что вы делаете с этим. Тем не менее, я предполагаю, что SQL Mail, вероятно, медленнее по сравнению с остальными операциями SQL, поэтому, если вы много делаете с этим, это может косвенно создать узкое место, которое приведет к тупику, если вы держаться за столы при отправке почты SQL.

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