Зачем использовать уровень изоляции READ UNCOMMITTED?

Ответ 1

Этот уровень изоляции позволяет выполнять грязные чтения. Одна транзакция может видеть незафиксированные изменения, сделанные другой транзакцией.

Для поддержания самого высокого уровня изоляции СУБД обычно получает блокировки данных, что может привести к потере concurrency и высокой блокировке. Этот уровень изоляции ослабляет это свойство.

Вы можете проверить Статья в Википедии на READ UNCOMMITTED для нескольких примеров и дальнейшего чтения.

Вы также можете быть заинтересованы в том, чтобы проверить Jeff Atwood статья в блоге о том, как он и его команда занялись проблема блокировки в первые дни. Согласно Джеффу:

Но nolock опасно? Не могли бы вы закончить Чтение неверных данных с помощью READ UNCOMMITTED on? Да, в теории. Вы будете не найти нехватки базы данных архитектуры астронавтов, которые начинают бросить науку ACID на вас и всех но вытащите пожарную сигнализацию здания, когда вы скажете им, что хотите попробовать nolock. Это правда: теория пугает. Но вот что я думаю: "Теоретически там нет никакой разницы между теорией и практика. На практике это происходит.

Я бы никогда не рекомендовал использовать nolockкак общее" хорошее для того, что вас беспокоит", змеиное масло для любой базы данных проблемы с блокировкой, которые могут возникнуть у вас. Вы следует попытаться диагностировать источник проблема первая.

Но на практике добавление nolock к запросам, которые вы абсолютно знаете, просты, простые дела только для чтения никогда не приводят к проблемам... Пока вы знаете, что делаете.

Одна альтернатива уровню READ UNCOMMITTED, которую вы можете рассмотреть, - это READ COMMITTED SNAPSHOT. Еще раз цитируем Джеффа:

Снимки полагаются на совершенно новый метод отслеживания изменений данных... больше, чем просто небольшое логическое изменение, это требует, чтобы сервер обрабатывал данные физически по-разному. Как только этот новый метод отслеживания изменений данных включен, он создает копию или моментальный снимок каждого изменения данных. Прочитав эти моментальные снимки, а не живые данные во время конфликтов, Shared Locks больше не нужны для чтения, а общая производительность базы данных может увеличиться.

Ответ 2

Это может быть полезно, чтобы увидеть ход длинных запросов вставки, выполнить любые приблизительные оценки (например, COUNT(*) или грубая SUM(*)) и т.д.

Другими словами, результаты, полученные при возврате грязных прочитанных запросов, прекрасны, если вы рассматриваете их как оценки и не принимаете на их основе каких-либо критических решений.

Ответ 3

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

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

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

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

Ответ 4

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

Если вы заботитесь о точности, не используйте это.

Дополнительная информация находится на MSDN:

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

Ответ 5

Когда можно использовать READ UNCOMMITTED?

Правило большого пальца

Хороший: большие статистические отчеты, показывающие постоянно изменяющиеся итоговые значения.

Рискованный: почти все остальное.

Хорошей новостью является то, что большинство отчетов только для чтения попадают в категорию Хорошее.

Подробнее...

Хорошо использовать его:

• Почти все пользовательские сводные отчеты для текущих, нестатических данных, например. Годовые продажи. Он рискует погрешностью (возможно, < 0,1%), которая намного ниже, чем другие факторы неопределенности, такие как ввод ошибки.

Это покрывает, вероятно, большую часть того, что подразделение MIS будет делать, скажем, в SSRS. Исключением, конечно, является что-либо с знаками $перед ним. Многие люди получают деньги с гораздо большим рвением, чем применяют к соответствующим основным показателям, необходимым для обслуживания клиента и генерирования этих денег. (Я обвиняю бухгалтеров).

Когда рискованно

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

• Исторические данные. Это редко делает практические различия, но в то время как пользователи понимают, что постоянно изменяющиеся данные не могут быть идеальными, они не чувствуют то же самое относительно статических данных. Грязные прочтения здесь не повредит, но иногда могут быть двойные чтения. Увидев, что в любом случае у вас не должно быть блоков на статических данных, зачем рисковать?

• Почти все, что подает приложение, которое также имеет возможности записи.

Если даже сценарий OK не в порядке.

• Являются ли какие-либо приложения или процессы обновления использующими большие одиночные транзакции? Которые удаляют, а затем повторно вставляют много записей, о которых вы сообщаете? В этом случае вы действительно не можете использовать NOLOCK в этих таблицах для чего-либо.

Ответ 6

Что касается отчетности, мы используем ее во всех наших отчетах, чтобы предотвратить опрос данных из баз данных. Мы можем это сделать, потому что мы извлекаем исторические данные, а не данные до микросекунды.

Ответ 7

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

Также интересно отметить, что не происходит. READ UNCOMMITTED не только игнорирует другие блокировки таблиц. Это также не вызывает никаких блокировок.

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

Если вы используете READ UNCOMMITTED, вы не будете устанавливать общую блокировку в таблице. Вы можете получить результат от каких-либо новых транзакций, или вы не можете зависеть от того, где находится таблица, в которую были вставлены данные, и как долго длилась ваша транзакция SELECT. Вы также можете получить те же данные дважды, если, например, происходит разбивка страницы (данные будут скопированы в другое место в файле данных).

Итак, если для вас очень важно, чтобы данные могли быть вставлены при выполнении SELECT, READ UNCOMMITTED может иметь смысл. Вы должны учитывать, что ваш отчет может содержать некоторые ошибки, но если он основан на миллионах строк и только некоторые из них обновляются при выборе результата, это может быть "достаточно хорошим". Ваша транзакция также может потерпеть неудачу, поскольку уникальность строки может быть не гарантирована.

Лучше всего использовать SNAPSHOT ISOLATION LEVEL, но ваши приложения могут нуждаться в некоторых корректировках, чтобы использовать это. Одним из примеров этого является то, что ваше приложение использует исключительную блокировку в строке, чтобы другие пользователи не могли ее прочитать и перейти в режим редактирования в пользовательском интерфейсе. УРОВЕНЬ ИЗОЛЯЦИИ SNAPSHOT также имеет значительное снижение производительности (особенно на диске). Но вы можете преодолеть это, бросив оборудование на проблему.:)

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

Ответ 8

Используйте READ_UNCOMMITTED в ситуации, когда источник вряд ли изменится.

• При чтении исторических данных. например, некоторые журналы развертывания, которые произошли два дня назад.
• При повторном чтении метаданных. например на основе метаданных.

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

Ответ 9

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

Ответ 10

Я всегда использую READ UNCOMMITTED. Это быстро с наименьшими проблемами. При использовании других изоляций вы почти всегда сталкиваетесь с некоторыми проблемами блокировки.

Пока вы используете поля Auto Increment и уделяете немного больше внимания вложениям, тогда ваш штраф, и вы можете попрощаться с проблемами блокировки.

Вы можете делать ошибки с READ UNCOMMITED, но, честно говоря, очень просто убедиться, что ваши вставки являются полным доказательством. Вставки/Обновления, которые используют результаты выбора, - это только то, что вам нужно, чтобы следить. (Используйте READ COMMITTED здесь или убедитесь, что грязные чтения не вызовут проблемы)

Итак, пойдите Dirty Reads (специально для больших отчетов), ваше программное обеспечение будет работать более плавно...