Как я могу доказать, что NOLOCK является источником проблем с блокировкой?

Я не пытаюсь начать обсуждение типа Windows / Mac.

Лично мне не нужно убеждать, что NOLOCKэто плохая идея как рефлексивная практика. Кажется, когда вы развиваете, все должно быть целенаправленным, а не реакционным (/ аминь)

Итак ... ответственный программист настаивает NOLOCKна этом. Рекомендуется со всеми специальными запросами и при каждом запросе продукции. Я не видел хранимой процедуры без подсказок nolock на каждой таблице.

Не хочу быть тем парнем, который приходит и говорит всем, что основополагающее убеждение - это неправильно, если что-то не подкрепит.

Просто глядя на сессии комментариев под различными сообщениями в блоге, отправка ссылки может быть недостаточно. Давние убеждения и т. Д. Некоторые люди не уверены, что это проблема. См. Раздел «Комментарии» под каждым прочитанным мною постом в блоге.

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

Было предложено смотреть на XML по трассировкам и т. Д., Но это не будет явно указывать на то, что проблемы вызваны взаимоблокировками, не так ли? Я никогда не видел сообщений об ошибках, которые прямо вперед. это правда?

Как еще можно зацепить эти тупики?

DDL заявления вроде CREATEбы были бы подсказкой. Есть ли какие-либо выходные данные, на которые я мог бы указать, или какие-то данные, которые я мог бы найти, которые помогли бы подтвердить мою теорию, прежде чем я поднял тревогу?

Или я запускаю флаги трассировки или расширенные события, чтобы определить, что происходит, когда возникают взаимоблокировки, а затем выводится из операторов DDL?

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

Архитектор отвечает, как настаивать, NOLOCKэто путь. Рекомендуется со всеми специальными запросами и при каждом запросе продукции. Я не видел sproc без намеков на каждый стол.

Жаль это слышать. Это довольно хорошо повсеместно считается антипаттерном среди опытных практиков SQL Server, но вы не можете ничего сделать, чтобы изменить факты на местах, если практика действительно укоренилась и основана на искренних и глубоких убеждениях одного человека ,

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

Тем не менее, следующие пункты охватывают большинство пунктов, которые некоторые люди считают достаточно убедительными, чтобы изменить ранее распространенную практику:

• Вредные привычки: Везде NOLOCKвезде Аарон Бертран
• NOLOCKПодсказка по SQL Server и другие плохие идеи Дэвид Лин (Microsoft)
• Прочитанный мной уровень незафиксированной изоляции
• Обоснуйте НЕ используя подсказку (nolock) в каждом запросе (связанные вопросы и ответы здесь)

Тем не менее, вы не сможете «выиграть» эту битву. Я работал в такой среде, которая понимала риски и причины не делать этого, но все равно продолжала. Это были яркие, логичные люди, но, в конце концов, это была среда, в которой я не мог быть счастлив, работая.

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

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

Тем не менее, NOLOCKподсказки могут ввести новые способы тупика. Использование изоляции uncommitted для чтения может удалить условие временной блокировки (разрешается, когда конкурирующий ресурс становится доступным) в неразрешимый тупик (где ни один из официантов не может добиться прогресса) просто потому, что конфликт теперь происходит в другой точке, где, например, операции записи в другом порядке перекрытия. У Дейва Баллантайна есть пример здесь:

• Увеличение тупиков с NOLOCK

Для более общих советов по работе с тупиками, я рекомендую следующее в качестве отправной точки:

• Сложность с тупиками от Иеремии Пешки

Вам также следует ознакомиться с документацией:

• Блокировка (и все три подтемы есть)

Другие полезные ресурсы:

• Взаимные блокировки SQL Server на примере Гейл Шоу
• Устранение тупиковой ситуации Бартом Дунканом