Все мертвые блокировки, вызванные плохим запросом
"Транзакция (идентификатор 63 Процесса) была заведена в тупик на блокировке | коммуникационные буферные ресурсы с другим процессом и была выбрана в качестве жертвы мертвой блокировки. Повторно выполните транзакцию".. Возможные причины отказа: проблемы с запросом, свойство "ResultSet" не набор правильно, параметры не набор правильно или соединение, не установленное правильно."
Это могло зайти в тупик быть вызванным чем-то, что сохранило использование proc как почта SQL? Или это всегда вызывается мой что-то как два приложения, получающие доступ к той же таблице одновременно?
3 ответа
В приложении постоянно происходит одновременный доступ двух таблиц к одной и той же таблице. Обычно это не вызывает тупика. Тупиковая ситуация обычно возникает, когда вы говорите, что процесс «A» пытается обновить таблицу 1, а затем таблицу 2, а затем таблицу 3, и у вас есть процесс «B», пытающийся обновить таблицу 3, затем таблицу 2, а затем таблицу 1. Процесс » Ресурс A 'будет заблокирован, что требуется процессу' B ', а процесс' B 'имеет ресурсы, необходимые процессу' A '. SQL Server определяет это как тупиковую ситуацию и откатывает один из процессов как неудачную транзакцию.
Суть в том, что у вас есть два процесса, пытающихся обновить одни и те же таблицы одновременно, но не в одном порядке. Это часто приводит к тупикам.
Один из простых способов справиться с этим в вашем приложении - обработать неудачную транзакцию и просто повторно выполнить транзакцию. Он почти всегда выполняется успешно. Лучшее решение - убедиться, что ваши процессы обновляют таблицы в том же порядке, насколько это возможно.
Отсутствующие индексы - еще одна частая причина взаимоблокировок. Если запрос выбора может получить необходимую информацию из индекса, а не из базовой таблицы, он не будет заблокирован никакими обновлениями / вставками в самой таблице.
Чтобы узнать наверняка, используйте профилировщик SQL для отслеживания событий «График тупиковых ситуаций», который покажет вам детали самой тупиковой ситуации.
Основываясь на этом, я не думаю, что сама SQL Mail может непосредственно быть виновником. Я говорю "непосредственно", потому что не знаю, что вы с ней делаете. Однако я предполагаю, что SQL Mail, вероятно, работает медленно по сравнению с остальными операциями SQL, так что если вы много делаете с этим, это может косвенно создать узкое место, которое приведет к тупику, если вы удерживаете таблицы во время отправки SQL Mail.
Трудно рекомендовать конкретную стратегию, не имея слишком много конкретики о том, что вы делаете. Короче говоря, вам следует подумать, есть ли способ избавиться от зависимости от удержания таблицы во время выполнения этого действия, например, использование NOLOCK, использование временной таблицы или не временной "удерживающей" таблицы или просто рефакторинг SP, выполняющего вызов.