Почему использование ЧТЕНИЕ ОТМЕНИЛО ФИКСАЦИЮ уровня изоляции?
Без обиняков, что является недостатками и преимуществами использования
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
в запросе для приложений.NET и создания отчетов о сервисных приложениях?
3 ответа
Этот уровень изоляции допускает грязное чтение. Одна транзакция может видеть незафиксированные изменения, сделанные другой транзакцией.
Для поддержания наивысшего уровня изоляции СУБД обычно устанавливает блокировки данных, что может привести к потере параллелизма и высоким накладным расходам на блокировку. Этот уровень изоляции ослабляет это свойство.
Вы можете ознакомиться со статьей Википедии о ПРОЧИТАТЬ НЕПРЕРЫВНО , где есть несколько примеров и дальнейшее чтение.
Возможно, вас заинтересует статья Джеффа Этвуда о том, как он и его команда решали проблему тупика на заре Stack Overflow. По словам Джеффа:
Но опасен ли
nolock? Не могли бы вы завершить чтение недействительных данных включивчтение незафиксированных? Да теоретически. Вы не найдете недостатка в базах данных астронавтов, которые начнут рассказывать о КИСЛОТАХ вам и всем , но включат пожарную сигнализацию здания, когда {{1} } вы говорите им, что хотите попробоватьnolock. Это правда: теория пугает. Но вот что я думаю: «Теоретически нет разницы между теорией и практикой. На практике есть».Я бы никогда не рекомендовал использовать
nolockв качестве общего "полезного для того, что вас беспокоит" змеиное масло для исправления любых проблем с блокировкой базы данных, которые могут у вас возникнуть. Вы должны сначала попытаться диагностировать источник проблемы.Но на практике добавление
nolockк запросам, которые, как вы знаете, являются простыми и понятными только для чтения, никогда не приводит к проблемам ... Пока вы знаете, что делаете .
Одной из альтернатив уровня READ UNCOMMITTED , которую вы можете рассмотреть, является READ COMMITTED SNAPSHOT . Еще раз процитируем Джеффа:
Снимки полагаются на совершенно новый метод отслеживания изменений данных ... больше, чем просто небольшое логическое изменение, он требует, чтобы сервер обрабатывал данные физически по-другому. Как только этот новый метод отслеживания изменений данных включен, он создает копию или моментальный снимок каждого изменения данных. Благодаря чтению этих снимков, а не данных в реальном времени во время конкуренции, общие блокировки больше не нужны при чтении, и общая производительность базы данных может повыситься.
Это может быть полезно, чтобы увидеть ход выполнения длинных запросов вставки, сделать какие-либо приблизительные оценки (например, COUNT (*) или приблизительный SUM (* ) ) и т. Д.
Другими словами, результаты, возвращаемые запросами грязного чтения, хороши, если вы относитесь к ним как к оценкам и не принимаете на их основе каких-либо критических решений.
Преимущество в том, что это может быть быстрее в некоторых ситуациях. Недостаток в том, что результат может быть неверным (могут быть возвращены данные, которые еще не были зафиксированы), и нет гарантии, что результат будет повторяемым.
Если вам важна точность, не используйте этот метод.
Более подробная информация на MSDN:
Реализует грязное чтение, или блокировку уровня изоляции 0, что означает, что не выдаются общие блокировки и не соблюдаются эксклюзивные блокировки. Когда эта опция установлена, можно читать незафиксированные или грязные данные; значения в данных могут быть изменены, а строки могут появляться или исчезать в наборе данных до завершения транзакции. Эта опция имеет тот же эффект, что и установка NOLOCK для всех таблиц во всех операторах SELECT в транзакции. Это наименее ограничительный из четырех уровней изоляции.