как решить проблему взаимоблокировки? - PullRequest
7 голосов
/ 30 мая 2009

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

Связана ли эта проблема взаимоблокировки с блокировкой TransactNo? Если вы знаете эту проблему, дайте мне знать, пожалуйста. Заранее спасибо.

Ответы [ 6 ]

8 голосов
/ 15 декабря 2012

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

То, что я использую, чтобы найти и избавиться от взаимоблокировок, вне простого SQL Profiler, - это легкий инструмент, который дает графическое представление взаимоблокировок по мере их возникновения. Когда вы видите тупик, вы можете углубиться и получить ценную информацию. Детектор тупиковой ситуации - http://www.sqlsolutions.com/products/sql-deadlock-detector

Это простой инструмент, но для меня он делает именно то, что должен делать. Одна вещь: когда я впервые использовал ее, мне пришлось ждать 15 минут, пока инструмент соберет достаточно метрик, чтобы начать показывать тупики.

4 голосов
/ 01 июня 2009

Распространенная проблема с высокой изоляцией - эскалация блокировки взаимоблокировки из-за следующего сценария; то есть (где X - любой ресурс, например строка)

  • SPID a читает X - получает блокировку чтения
  • SPID b читает X - получает блокировку чтения
  • SPID a пытается обновить X - заблокирован блокировкой чтения b, поэтому должен ждать
  • SPID b пытается обновить X - заблокирован блокировкой чтения a, поэтому должен ждать

Тупик! Этого сценария можно избежать, взяв больше блокировок:

  • SPID читает X с указанием (UPDLOCK) - получает эксклюзивную блокировку
  • SPID b пытается прочитать X - заблокирован эксклюзивной блокировкой a, поэтому должен ждать
  • SPID попытки обновления X - отлично
  • ... (ПРОВЕРИТЬ фиксацию / откат и в какой-то момент снять блокировку)
  • ... (SPID b делает все, что хотел)
4 голосов
/ 31 мая 2009

Может возникнуть тупик по многим причинам, поэтому сначала вам нужно будет сделать небольшую домашнюю работу, если вы хотите, чтобы вам помогли, и сказать нам, что является причиной тупика, т.е. какие партии включают в себя выполнение тупиковой ситуации, какие ресурсы задействованы и так далее, и так далее. График событий тупика Profiler всегда является отличным местом для начала расследования.

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

Как только вы определили причину тупика, тогда могут быть предприняты соответствующие действия для его устранения. Случаи, когда он правильно прибегает к грязному чтению, крайне редки.

Кстати, я не уверен, что вы подразумеваете под «TransactNo updlock». Вы конкретно спрашиваете об S-U / U-S асимметрии U-замков ?

3 голосов
/ 01 июня 2009

Я добавлю свои статьи и посты в смесь о тупиках:

https://www.sqlskills.com/blogs/jonathan/category/deadlock/

У меня также есть серия видеороликов о поиске и устранении взаимоблокировок на JumpstartTv.com:

http://jumpstarttv.com/profiles/1379/Jonathan-Kehayias.aspx

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

3 голосов
/ 30 мая 2009

Вы не предоставили достаточно информации, чтобы ответить на ваш вопрос напрямую.

Но большинство блокировок и блокировок можно уменьшить (или даже устранить), если иметь «правильные» индексы для покрытия рабочей нагрузки вашего запроса.

Из-за того, что у вас запланирована регулярная работа по поддержанию индекса?

Если у вас есть SELECT s, которые не должны быть точными на 100% (то есть разрешить грязное чтение и т. Д.), Вы можете запустить SELECTS с WITH(NOLOCK), что соответствует уровню изоляции READ UNCOMMITED , Обратите внимание: я не предлагаю вам разместить WITH(NOLOCK) везде; только на те SELECT, которые не нуждаются в 100% нетронутых данных.

1 голос
/ 01 июня 2009

"Устранение неисправностей тупиковой ситуации, часть 1"

http://blogs.msdn.com/bartd/archive/2006/09/09/Deadlock-Troubleshooting_2C00_-Part-1.aspx

«Когда индексное покрытие предотвращает тупики»

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2008/05/03/when-index-covering-prevents-deadlocks.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...