тупиковая жертва в транзакции, как изменить приоритет?

Я зарегистрировал исключение, созданное приложением ASP.NET.

Сообщение: Транзакция (ID процесса 56) была заблокирована при блокировке | ресурсы буфера обмена данными с другим процессом и был выбран в качестве жертвы тупика. Повторите транзакцию.

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

Итак, теперь мой вопрос:

  • Могу ли я изменить приоритет, который SQL-сервер выбирает «жертвы тупика»? Я хотел бы выбрать «себя» (SSMS) в качестве жертвы взаимоблокировки, а не ASP.NET, потому что это критичное ко времени приложение, и мне легче повторно выполнить ручной запрос, чем пользователям принять ошибку.

Заранее спасибо.


sql-server tsql ssms deadlock database-deadlocks
person Tim Schmelter    schedule 09.06.2011    source источник

Ответы (1)


arrow_upward
5
arrow_downward

SET DEADLOCK_PRIORITY позволяет точно настроить приоритет

Вы можете указать это в сеансе SSMS (для каждого окна запроса) или глобально:

Инструменты..Options..etc

person gbn    schedule 09.06.2011
comment
Спасибо. Это означает, что я могу изменить его на Low, чтобы снизить приоритет запросов SSMS? Это сработает для меня. Есть ли другие варианты точной настройки приоритетов тупиков? Я читал, что SQL-Server по умолчанию выбирает жертв тупика при попытке отката транзакции. Это правильно? - person Tim Schmelter; 09.06.2011
comment
@ Тим Шмелтер: Да, слишком мало для запросов SSMS. Других вариантов нет. Жертвы выбираются с наименьшим ресурсом для отката согласно моей ссылке выше: если оба сеанса имеют одинаковый приоритет взаимоблокировки, экземпляр SQL Server выбирает сеанс, откат которого обходится дешевле, в качестве жертвы взаимоблокировки. Ваше здоровье - person gbn; 09.06.2011
comment
Проклятие MS Dynamics NAV за то, что он не позволил изменить это внутри их кода C / AL. Если это происходит между пользователем и автоматическим процессом (который может повторить попытку в случае сбоя), я бы предпочел, чтобы автоматический процесс проиграл. - person Vincent Vancalbergh; 25.04.2013