В чем разница между неповторяющимся чтением и фантомным чтением?

Question

В чем разница между неповторяющимся чтением и фантомным чтением?

74

В чем разница между неповторяемым чтением и phantom read?

Я прочитал статью Изоляция (системы баз данных) из Википедии, но у меня есть несколько сомнений. В приведенном ниже примере произойдет следующее: не повторяемый читать и phantom читать?

Транзакция A

SELECT ID, USERNAME, accountno, amount FROM USERS WHERE ID=1

ВЫВОД:

1----MIKE------29019892---------5000

Транзакция B

UPDATE USERS SET amount=amount+5000 where ID=1 AND accountno=29019892;
COMMIT;

Транзакция A

SELECT ID, USERNAME, accountno, amount FROM USERS WHERE ID=1

Еще одно сомнение заключается в том, что в приведенном выше примере должен использоваться уровень изоляции? И почему?

user1357722 15 июнь 2012, в 02:31

Источник

3

en.wikipedia.org/wiki/Isolation_(database_systems)
Pavel Veller 15 июнь 2012, в 01:59

Теги:

oracle

isolation-level

transaction-isolation

6 ответов

56

Простым способом, который мне нравится думать, является:

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

Непрерывные чтения - это когда ваша транзакция считывает заверенные ОБНОВЛЕНИЯ из другой транзакции. Такая же строка имеет разные значения, чем при начале транзакции.

Phantom чтения аналогичны, но при чтении из объявленных ВСТАВКИ и/или DELETES из другой транзакции. Появляются новые строки или строки, которые исчезли с момента начала транзакции.

Грязные чтения похожи на неповторяющиеся и phantom чтения, но относятся к чтению данных UNCOMMITTED и происходят при чтении UPDATE, INSERT или DELETE из другой транзакции, а другая транзакция еще не передала данные, Он считывает данные "в процессе", которые могут быть неполными и никогда не могут быть выполнены.

BateTech 17 апр. 2014, в 18:04

0

Я поражен (или говорю, что не верю). Грязное чтение: чтение измененных данных (другой транзакцией), которые на самом деле не зафиксированы или могут никогда не быть зафиксированы. Где, возможно, этот сценарий может быть использован? (Это не я вам не верю - На самом деле я не понял концепцию должным образом) - Пожалуйста, не возражайте (Возможно, вы сможете понять разочарование новичка)
PHP Avenger 08 сен. 2015, в 21:57
3

Это связано с уровнями изоляции транзакций и параллелизмом. Используя уровень изоляции по умолчанию, вы не получите грязное чтение, и в большинстве случаев вы хотите избежать грязного чтения. Существуют уровни изоляции или подсказки запросов, которые допускают грязное чтение, что в некоторых случаях является приемлемым компромиссом для достижения более высокого уровня параллелизма или необходимо из-за пограничного случая, такого как устранение неполадок в текущей транзакции из другого соединения. Хорошо, что идея грязного чтения не проходит для вас «тест на запах», потому что, как правило, их следует избегать, но у них есть цель.
BateTech 08 сен. 2015, в 23:47
0

Что, если за удалением следует вставка, не может ли это быть использовано для эффективного обновления?
Kevin Wheeler 27 июль 2016, в 22:36
0

@KevinWheeler Я не уверен в релевантности этого поста, но удаление, сопровождаемое вставкой, почти всегда намного больше накладных расходов по сравнению с обновлением. У вас есть в два раза больше операторов, которые могут быть заблокированы или заблокированы, гораздо больше данных аудита (при отслеживании изменений dml), проверки ограничений FK и т. Д.
BateTech 29 июль 2016, в 03:04
0

@PHPAvenger в данном случае является примером использования для уровня изоляции READ UNCOMMITTED: всегда существует вероятность возникновения тупика между запросом на выборку и обновлением (объяснено здесь ). Если запрос выбора слишком сложен для создания покрывающего индекса, во избежание взаимных блокировок вы захотите использовать уровень изоляции READ UNCOMMITED с риском возникновения грязных чтений, но как часто вы выполняете откат транзакций, чтобы беспокоиться об этих грязных чтениях, не быть постоянным ?!
petrica.martinescu 24 март 2017, в 17:04
0

@ petrica.martinescu. Проблемы, вызванные грязным чтением, не связаны с тем, откатывается ли транзакция. Грязное чтение может привести к очень неточным результатам в зависимости от того, как были изменены данные в ожидающих транзакциях. Представьте себе транзакцию, которая выполняет серию из нескольких удалений, обновлений и / или вставок. Если вы прочитали данные в середине этой транзакции, используя «read uncommitted», они будут неполными. Уровень изоляции моментальных снимков (в SQL Server) - намного лучшая альтернатива чтению незафиксированных. Допустимый вариант использования для чтения незафиксированного уровня изоляции в производственной системе - редкий ИМО.
BateTech 03 март 2018, в 13:09
1

@BateTech UPDATE или DELETE могут иметь место для неповторяющихся чтений, или это только ОБНОВЛЕНИЕ?
Dipon Roy 23 апр. 2018, в 06:52
1

@DiponRoy отличный вопрос. Блокировка, реализованная при использовании изоляции с повторяющимся чтением (RR), должна предотвращать удаление в выбранных строках. За последние годы я видел разные определения уровней 2 iso, в основном говоря, что фантом - это изменение возвращаемых строк collection / #, а RR - это та же самая изменяемая строка. Я только что проверил обновленную документацию MS SQL, в которой говорится, что удаление может привести к отсутствию RR ( docs.microsoft.com/en-us/sql/odbc/reference/develop-app/… ), поэтому я думаю, что было бы безопасно группировать удаления в категория RR тоже
BateTech 26 апр. 2018, в 19:08
0

Вы сказали: « Грязное чтение похоже на неповторяемое и фантомное чтение, но относится к чтению НЕКОММИТИРОВАННЫХ данных и происходит, когда читается UPDATE, INSERT или DELETE из другой транзакции, а другая транзакция еще не зафиксировала данные. "Вы уверены, что ОБНОВЛЕНИЕ, ВСТАВКА или УДАЛЕНИЕ включены в грязную запись? Я считаю, что это должно быть просто ОБНОВЛЕНИЕ.
anir 24 март 2019, в 11:22
1

@anir да вставки и удаления включены в грязные чтения. Пример: начать транзакцию, вставить 2 из 100 строк счета-фактуры в соединение a, теперь соединение b считывает эти 2 строки перед фиксацией trx и перед добавлением остальных 98 строк, и поэтому не включает всю информацию для счета-фактуры. Это было бы грязное чтение, включающее вставку.
BateTech 24 март 2019, в 11:33
0

Ранее у меня были сомнения, может ли это быть просто ОБНОВЛЕНИЕ или все ВСТАВИТЬ, ОБНОВИТЬ и УДАЛИТЬ в случае грязного чтения. Однако теперь я считаю, что это может быть все, как говорится в определении «... изменено незафиксированной транзакцией». Таким образом, чтение любого эффекта из-за незафиксированной транзакции может привести к грязному чтению, и этот эффект может быть вызван любым из INSERT, UPDATE и DELETE, ( Q1 ), верно? Теперь у меня новый вопрос, нужно ли включать один элемент данных / строку или их набор? Опять же, я считаю, что это может быть что угодно, лишь бы оно соответствовало определению «эффект чтения, вызванный незафиксированным переходом». ( Q2 ) Верно?
anir 24 март 2019, в 12:13
0

[..продано из предыдущего комментария] с указанием двух определений для справки: (1) (из вики ) Грязное чтение (так называемая незафиксированная зависимость) происходит, когда транзакции разрешено читать данные из строки, которая была изменена другой запущенной транзакцией, и еще не совершено. (2) (из книги ) Транзакция считывает значения, записанные другой транзакцией, которая еще не зафиксирована. Теперь вы можете ответить на мои вопросы из предыдущего комментария?
anir 24 март 2019, в 12:15
1

@anir Q1 влияние на другие транзакции зависит от объема транзакции и уровня изоляции, которые используются. Q2 да, он может включать один элемент данных, строку или набор строк, а также может включать индексы.
BateTech 24 март 2019, в 12:47

Показать ещё 11 комментариев

4

Существует разница в реализации между этими уровнями изоляции двух типов.
Для "неповторяющегося чтения" требуется блокировка строк.
Для "phantom read" требуется блокировка с привязкой, даже блокировка таблицы.
Мы можем реализовать эти два уровня, используя двухфазную блокировку.

egraldlo 18 май 2015, в 07:10

0

Для реализации повторяемого чтения или сериализации нет необходимости использовать блокировку строк.
a_horse_with_no_name 02 авг. 2017, в 20:53

3

В системе с неповторяющимися чтениями результат второго запроса транзакции будет отражать обновление в транзакции B - он увидит новую сумму.

В системе, которая позволяет читать phantom, если Transaction B должен был вставить новую строку с ID = 1, Transaction A увидит новую строку при выполнении второго запроса; то есть phantom чтение является частным случаем не повторяемого чтения.

Jeffrey Kemp 15 июнь 2012, в 05:00

0

Я не думаю, что объяснение фантомного чтения правильное. Вы можете получить фантомное чтение, даже если данные без фиксации никогда не видны. Смотрите пример в Википедии (ссылка в комментариях выше).
Thilo 15 июнь 2012, в 05:14

1

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

Если "строка извлекается дважды, а значения внутри строки отличаются друг от друга", то они не являются одной и той же строкой (не такой же кортеж в правильной речи RDB), и тогда действительно по определению также случай, сбор строк, возвращаемых вторым запросом, отличается от первого ".

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

Erwin Smout 02 авг. 2017, в 21:13

0

Грязное чтение: прочитайте НЕОБХОДИМЫЕ данные из других транзакций.

Непрерывное чтение: прочитайте COMMITED данные из запроса UPDATE из другой транзакции.

Phantom читать: читать COMMITED данные из запроса INSERT или DELETE из другой транзакции.

Обратите внимание на то, что UPDATES может быть более частым занятием в некоторых случаях, а не в фактических INSERT или DELETES. В таких случаях остается опасность чтения не повторяющихся чтений - phantom в этих случаях чтение невозможно. Это почему UPDATES обрабатываются иначе, чем INSERT-DELETE, и соответствующая аномалия также называется по-разному.

Существует также дополнительная стоимость обработки, связанная с обработкой для INSERT-DELETES, а не просто обработка UPDATES.

Уровень изоляции TRANSACTION_READ_UNCOMMITTED не предотвращает ничего. Его уровень нулевой изоляции.

Уровень изоляции TRANSACTION_READ_COMMITTED предотвращает только одно, т.е. Грязный читает.

Уровень изоляции TRANSACTION_REPEATABLE_READ предотвращает две аномалии: Грязные чтения и Непрерывные чтения.

Уровень изоляции TRANSACTION_SERIALIZABLE предотвращает все три аномалии: Dirty reads, Non-repeatable reads и phantom читает.

Тогда почему бы просто не установить транзакцию SERIALIZABLE во все времена?

Ну, ответ на этот вопрос: SERIALIZABLE устанавливает очень медленные транзакции, которых мы опять не хотим.

Фактическое потребление времени транзакции имеет следующую скорость:

SERIALIZABLE > REPEATABLE_READ > READ_COMMITTED > READ_UNCOMMITTED.

Таким образом, настройка READ_UNCOMMITTED является самой быстрой.

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

Обратите внимание, что базы данных по умолчанию имеют параметр REPEATABLE_READ.

Subhadeep Ray 11 сен. 2017, в 11:02

0

ОБНОВЛЕНИЕ или УДАЛЕНИЕ оба могут иметь место для неповторяющихся чтений, или это только ОБНОВЛЕНИЕ?
Dipon Roy 23 апр. 2018, в 06:53
0

ОБНОВЛЕНИЕ или УДАЛЕНИЕ оба могут иметь место для неповторяющихся чтений
niket patel 28 сен. 2018, в 06:10

Ещё вопросы

Я поражен (или говорю, что не верю). Грязное чтение: чтение измененных данных (другой транзакцией), которые на самом деле не зафиксированы или могут никогда не быть зафиксированы. Где, возможно, этот сценарий может быть использован? (Это не я вам не верю - На самом деле я не понял концепцию должным образом) - Пожалуйста, не возражайте (Возможно, вы сможете понять разочарование новичка)
Это связано с уровнями изоляции транзакций и параллелизмом. Используя уровень изоляции по умолчанию, вы не получите грязное чтение, и в большинстве случаев вы хотите избежать грязного чтения. Существуют уровни изоляции или подсказки запросов, которые допускают грязное чтение, что в некоторых случаях является приемлемым компромиссом для достижения более высокого уровня параллелизма или необходимо из-за пограничного случая, такого как устранение неполадок в текущей транзакции из другого соединения. Хорошо, что идея грязного чтения не проходит для вас «тест на запах», потому что, как правило, их следует избегать, но у них есть цель.
Что, если за удалением следует вставка, не может ли это быть использовано для эффективного обновления?
@KevinWheeler Я не уверен в релевантности этого поста, но удаление, сопровождаемое вставкой, почти всегда намного больше накладных расходов по сравнению с обновлением. У вас есть в два раза больше операторов, которые могут быть заблокированы или заблокированы, гораздо больше данных аудита (при отслеживании изменений dml), проверки ограничений FK и т. Д.
@PHPAvenger в данном случае является примером использования для уровня изоляции READ UNCOMMITTED: всегда существует вероятность возникновения тупика между запросом на выборку и обновлением (объяснено здесь ). Если запрос выбора слишком сложен для создания покрывающего индекса, во избежание взаимных блокировок вы захотите использовать уровень изоляции READ UNCOMMITED с риском возникновения грязных чтений, но как часто вы выполняете откат транзакций, чтобы беспокоиться об этих грязных чтениях, не быть постоянным ?!
@ petrica.martinescu. Проблемы, вызванные грязным чтением, не связаны с тем, откатывается ли транзакция. Грязное чтение может привести к очень неточным результатам в зависимости от того, как были изменены данные в ожидающих транзакциях. Представьте себе транзакцию, которая выполняет серию из нескольких удалений, обновлений и / или вставок. Если вы прочитали данные в середине этой транзакции, используя «read uncommitted», они будут неполными. Уровень изоляции моментальных снимков (в SQL Server) - намного лучшая альтернатива чтению незафиксированных. Допустимый вариант использования для чтения незафиксированного уровня изоляции в производственной системе - редкий ИМО.
@BateTech UPDATE или DELETE могут иметь место для неповторяющихся чтений, или это только ОБНОВЛЕНИЕ?
@DiponRoy отличный вопрос. Блокировка, реализованная при использовании изоляции с повторяющимся чтением (RR), должна предотвращать удаление в выбранных строках. За последние годы я видел разные определения уровней 2 iso, в основном говоря, что фантом - это изменение возвращаемых строк collection / #, а RR - это та же самая изменяемая строка. Я только что проверил обновленную документацию MS SQL, в которой говорится, что удаление может привести к отсутствию RR ( docs.microsoft.com/en-us/sql/odbc/reference/develop-app/… ), поэтому я думаю, что было бы безопасно группировать удаления в категория RR тоже
Вы сказали: « Грязное чтение похоже на неповторяемое и фантомное чтение, но относится к чтению НЕКОММИТИРОВАННЫХ данных и происходит, когда читается UPDATE, INSERT или DELETE из другой транзакции, а другая транзакция еще не зафиксировала данные. "Вы уверены, что ОБНОВЛЕНИЕ, ВСТАВКА или УДАЛЕНИЕ включены в грязную запись? Я считаю, что это должно быть просто ОБНОВЛЕНИЕ.
@anir да вставки и удаления включены в грязные чтения. Пример: начать транзакцию, вставить 2 из 100 строк счета-фактуры в соединение a, теперь соединение b считывает эти 2 строки перед фиксацией trx и перед добавлением остальных 98 строк, и поэтому не включает всю информацию для счета-фактуры. Это было бы грязное чтение, включающее вставку.
Ранее у меня были сомнения, может ли это быть просто ОБНОВЛЕНИЕ или все ВСТАВИТЬ, ОБНОВИТЬ и УДАЛИТЬ в случае грязного чтения. Однако теперь я считаю, что это может быть все, как говорится в определении «... изменено незафиксированной транзакцией». Таким образом, чтение любого эффекта из-за незафиксированной транзакции может привести к грязному чтению, и этот эффект может быть вызван любым из INSERT, UPDATE и DELETE, ( Q1 ), верно? Теперь у меня новый вопрос, нужно ли включать один элемент данных / строку или их набор? Опять же, я считаю, что это может быть что угодно, лишь бы оно соответствовало определению «эффект чтения, вызванный незафиксированным переходом». ( Q2 ) Верно?
[..продано из предыдущего комментария] с указанием двух определений для справки: (1) (из вики ) Грязное чтение (так называемая незафиксированная зависимость) происходит, когда транзакции разрешено читать данные из строки, которая была изменена другой запущенной транзакцией, и еще не совершено. (2) (из книги ) Транзакция считывает значения, записанные другой транзакцией, которая еще не зафиксирована. Теперь вы можете ответить на мои вопросы из предыдущего комментария?
@anir Q1 влияние на другие транзакции зависит от объема транзакции и уровня изоляции, которые используются. Q2 да, он может включать один элемент данных, строку или набор строк, а также может включать индексы.
Для реализации повторяемого чтения или сериализации нет необходимости использовать блокировку строк.
Я не думаю, что объяснение фантомного чтения правильное. Вы можете получить фантомное чтение, даже если данные без фиксации никогда не видны. Смотрите пример в Википедии (ссылка в комментариях выше).
ОБНОВЛЕНИЕ или УДАЛЕНИЕ оба могут иметь место для неповторяющихся чтений, или это только ОБНОВЛЕНИЕ?
ОБНОВЛЕНИЕ или УДАЛЕНИЕ оба могут иметь место для неповторяющихся чтений

Thilo · Accepted Answer · 2012-06-15T06-19-00.000Z

Из Википедии (в котором есть большие и подробные примеры для этого):

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

и

A phantom чтение происходит, когда в ходе транзакции выполняются два идентичных запроса, а набор строк, возвращаемых вторым запросом, отличается от первого.

Простые примеры:

Пользователь A дважды выполняет один и тот же запрос.
В промежутке между Пользователем B выполняется транзакция и выполняется.
Непрерывное чтение: строка, которую запросил пользователь A, имеет второй раз.
Phantom read: Все строки запроса имеют одно и то же значение до и после, но выбираются разные строки (поскольку B удалил или вставил некоторые). Пример: select sum(x) from table; возвращает другой результат, даже если ни одна из затронутых строк не была обновлена, если строки были добавлены или удалены.

В приведенном выше примере, какой уровень изоляции будет использоваться?

Какой уровень изоляции вам нужен, зависит от вашего приложения. Существует высокая стоимость "лучшего" уровня изоляции (например, уменьшенная concurrency).

В вашем примере вы не будете читать phantom, потому что вы выбираете только одну строку (идентифицированную первичным ключом). Вы можете иметь не повторяющиеся чтения, поэтому, если это проблема, вы можете захотеть иметь уровень изоляции, который предотвращает это. В Oracle транзакция A также может выдавать SELECT FOR UPDATE, тогда транзакция B не может изменить строку до тех пор, пока не будет выполнена A.

Я не очень понимаю логику такого синтаксиса ... Неповторяемое чтение происходит, когда чтение повторяется (и получается другое значение) ??! ...
@serhio «неповторяемый» относится к тому факту, что вы можете прочитать значение один раз и получить x в качестве результата, а затем снова прочитать и получить y в качестве результата, так что вы не можете повторить (неповторяемые) одинаковые результаты из двух отдельные запросы одной и той же строки, потому что это значение строки было обновлено между чтениями.
@Thilo Какой-нибудь реальный пример использования, где repeatable-read может создать проблемы и где это необходимо?
Что если PK будет изменен в другой транзакции? Может ли это привести к фантомному чтению? (В большинстве случаев странная вещь, но не невозможная.)