как решить проблему мертвой блокировки?
В дополнение к другим ответам есть оптимизация: когда вы компилируете программу, вам, как правило, не важно, сколько времени занимает компиляция - у компилятора есть много времени для оптимизации вашего кода. Когда вы интерпретируете код, это должно быть сделано очень быстро, поэтому некоторые из более умных оптимизаций могут быть невозможны.
5 ответов
I'll throw my own articles and posts into the mix about deadlocks:
https://www.sqlskills.com/blogs/jonathan/category/deadlock/
I also have a series of videos on troubleshooting deadlocking on JumpstartTv.com as well:
http://jumpstarttv.com/profiles/1379/Jonathan-Kehayias.aspx
Deadlocks can be difficult to resolve, but unless you post your deadlock graph information, there isn't anyway we can do more than offer up links to posts and information on solving deadlocks.
Вы не предоставили достаточно информации, чтобы напрямую ответить на ваш вопрос.
Но большинство блокировок и блокировок можно уменьшить (или даже устранить), установив «правильные» индексы для покрытия вашей рабочей нагрузки запросов. .
У вас запланировано регулярное обслуживание индекса?
Если у вас есть SELECT , которые не должны быть на 100% точными (т.е. разрешать грязное чтение и т. Д.), Вы можете запустить некоторые SELECTS с WITH (NOLOCK) , что соответствует уровню изоляции READ UNCOMMITED. Обратите внимание: я не предлагаю размещать везде WITH (NOLOCK) ; только на тех SELECTS, которым не нужны 100% неповрежденные данные.
Тупик может произойти по многим причинам, поэтому вам придется сначала немного поработать, если вы хотите, чтобы вам помогли и сказали нам, что вызывает тупик, т. Е. какие пакеты связаны с выполнением тупиковой ситуации, какие ресурсы задействованы и так далее и так далее. График тупиковых событий Profiler всегда является отличным местом для начала расследования.
Если бы я рискнул сделать снимок в темноте, то случится так, что ваши запросы и индексы не настроены должным образом, поэтому большая часть ваших операции чтения (и, возможно, некоторые из операций записи) представляют собой полное сканирование таблицы и, следовательно, гарантированно сталкиваются с обновлениями. Это может вызвать взаимоблокировки по порядку доступа к индексу , тупик по порядку операций, тупик по эскалации и т. Д. И т. Д.
Как только вы определите причину тупиковой ситуации, можно будет предпринять соответствующие действия по ее устранению. Случаи, когда правильное действие - прибегать к грязному чтению, крайне редки.
Кстати, я не уверен, что вы имеете в виду под «TransactNo updlock». Вы конкретно спрашиваете об асимметрии SU / US U-образных замков ?
Распространенная проблема с высокой изоляцией - эскалация блокировки приводит в тупик по следующему сценарию; т.е. (где X - любой ресурс, например, строка)
- SPID a читает X - получает блокировку чтения
- SPID b читает X - получает блокировку чтения
- SPID a пытается обновить X - заблокировано b блокировка чтения, поэтому должен ждать
- SPID b пытается обновить X - заблокирован блокировкой чтения, поэтому должен ждать
Тупик! Этого сценария можно избежать, взяв больше блокировок:
- SPID a читает X с указанным
(UPDLOCK)- получает монопольную блокировку - SPID b пытается читать X - заблокировано эксклюзивным замком, поэтому должен ждать
- SPID a пытается обновить X - отлично
- ... (SPID a фиксирует / откатывается и в какой-то момент снимает блокировку)
- ... (SPID b делает то, что он хотел сделать)
«Устранение неполадок в тупиках, часть 1»
http://blogs.msdn.com/bartd/archive/2006/09/09/Deadlock-Troubleshooting_2C00_-Part-1.aspx
«Когда покрытие индекса предотвращает взаимоблокировки»