Лучшая ситуация для использования READ UNCOMMITTED уровня изоляции

Как мы все знаем, READ UNCOMMITTED - это самый низкий уровень изоляции, в котором могут возникать такие вещи, как грязные чтения и фантомные чтения. Когда самое лучшее время для использования этого уровня изоляции и по каким причинам оно может быть использовано?

Собственно, я читал ответы раньше, но я не мог понять это полностью, потому что примеров было недостаточно.

10 голосов | спросил PTTT 11 Maypm18 2018, 16:05:22

6 ответов


6

IMHO действительный прецедент only для READ UNCOMMITTED в современной системе - это отладка одного сеанса от другого в процессе разработки, чтобы вы могли видеть, что он делает, например, сохраненная процедура продолжает работать. Обычно он не будет использоваться в производственной системе. Может быть небольшое увеличение производительности, но в долгосрочной перспективе оно никогда не будет стоить того.

ответил Gaius 11 Maypm18 2018, 16:13:48
21

Я использую READ_UNCOMMITTED (или NOLOCK) при запросе производственных баз данных из SSMS, но не в обычном порядке из кода приложения. Эта практика (наряду с подсказкой запроса MAXDOP 1) помогает обеспечить случайные запросы для анализа данных и устранения неполадок, не влияя на производственную нагрузку, при этом понимание результатов может быть неверным.

К сожалению, я вижу READ_UNCOMMITTED /NOLOCK широко используется в производственном коде, чтобы избежать блокировки за счет целостности данных. Правильное решение - это уровень изоляции строк (SNAPSHOT или READ_COMMITTED с опцией READ_COMMITTED_SNAPSHOT ON) и /или внимание к настройке запроса и индекса.

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

ответил Dan Guzman 11 Maypm18 2018, 16:27:38
8

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

Для других опций я бы подталкивал людей к использованию Read Committed Snapshot Isolation (RCSI) для новых приложений или SNAPSHOT ISOLATION (SI) для старых приложений, где вы не можете легко протестировать всю базу кода для условий гонки с помощью RCSI.

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

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

Кроме того, у большинства людей нет проблем с блокировкой с их полным приложением . У них есть проблемы с такими вещами, как отчетность по данным OLTP. Если вы можете согласиться с компромиссами NOLOCK /RU в обмен на то, что эти сообщения не блокируются авторами, идите на это.

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

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

ответил sp_BlitzErik 11 Maypm18 2018, 16:55:30
5

Мы используем его в здравоохранении все время.

Удивительно редко для отдельных строк данных изменять средний запрос, а отношение чтения /записи равно 10 000/1 - и большинство из них - вставки, а не обновления. Например, когда лабораторный интерфейс записывает результаты лабораторных исследований пациента в базу данных, эти значения никогда не будут меняться.

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

С другой стороны, мы запускаем кучу запросов для сканирования таких вещей, как пациенты, возвращающиеся в ER за 72 часа или менее, что абсолютно забивает таблицы.

За 10 лет работы в области здравоохранения SQL я никогда не видел Rollback Transaction. Я хочу войти и выйти, не нарушая работу конечного пользователя. Если существует высокая вероятность замедления работы базы данных OLTP и низкого риска получения плохих данных, я буду NOLOCK.

Должны ли использовать его? Может быть, может и нет. Вообще говоря, я бы не сказал, что многие из баз данных приложений, над которыми я работал, хорошо разработаны. Обычно они заполнены анти-шаблонами.

ответил James 11 Maypm18 2018, 16:48:44
1

READ_UNCOMMITTED/NOLOCK - хороший вариант, когда точность данных на самом деле не является главной целью. Иногда, когда требуется приблизительное совокупное количество, которое требуется. Например: существуют хранимые процедуры, которые используются для таблиц INSERT или UPDATE. Иногда количество обновляемых или вставленных записей огромно (тысячи записей). Во время этих прогонов хранимых процедур мы можем периодически запускать простой запрос выбора с помощью NOLOCK в целевой таблице, чтобы убедиться, что он прогрессирует плавно (для обновления запрос, если у вас есть столбец изменения статуса для обновляемых записей, мы можем использовать этот столбец для запуска запроса group by с помощью NOLOCK, чтобы узнать, постоянно ли изменяется счет изменения статуса).

ответил GirKarr 16 Maypm18 2018, 20:43:18
0

Помните, что READ UNCOMMITTED вводит дополнительные проблемы согласованности, а не только грязные чтения. В зависимости от метода доступа вы можете пропустить строки или даже прочитать одну и ту же строку более одного раза. Если вас интересуют подробности, прочитайте Itzik Статья Бен-Гана

ответил SQLRaptor 11 Maypm18 2018, 19:15:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132