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

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

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

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

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

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

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

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

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

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

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

когда это нормально использовать READ UNCOMMITTED?

правило

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

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

хорошая новость заключается в том, что большинство отчетов только для чтения попадают в это хороший.

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

Ok, чтобы использовать его:

• почти всем пользователям агрегированные отчеты для текущих, нестатических данных, например, год к дате продажи. Он рискует погрешностью (возможно,

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

когда рискованные

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

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

• почти все, что кормит приложение, которое также пишут способности.

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

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

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

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

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

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

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

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

лучшим способом может быть использование уровня изоляции моментальных снимков, но для этого вашим приложениям могут потребоваться некоторые корректировки. Один из примеров этого - если ваше приложение принимает эксклюзивную блокировку строки, чтобы другие не могли ее прочитать и перейти в режим редактирования в пользовательском интерфейсе. СНИМОК Уровень изоляции также имеет значительный штраф за производительность (особенно на диске). Но вы можете преодолеть это, бросив аппаратное обеспечение на проблему. :)

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

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

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

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

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

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

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

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

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