Некоторые разъяснения по разным уровням изоляции в транзакции базы данных? - PullRequest
Новая
       35

Некоторые разъяснения по разным уровням изоляции в транзакции базы данных?

5 голосов
/ 14 сентября 2011

Ниже приведено утверждение, написанное из Изоляционной статьи Википедии о REPEATABLE READS

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

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

Если мы возьмем пример неповторяющихся чтений с REPEATABLE READS, уровень изоляции по той же ссылке, согласно моему пониманию, начнется операция 1. при первом запросе, т.е. SELECT * FROM users WHERE id = 1. СУБД будет сохранять блокировку таблицы пользователей до тех пор, пока транзакция не завершится. здесь К концу Я имею в виду, когда соединение откатывается или фиксируется не по завершении SELECT * FROM users WHERE id = 1. До этого времени Транзакция 2 будет ждать, верно?

Вопрос 2: - Теперь, если мы рассмотрим уровень изоляции и их поведение, как указано ниже (по той же ссылке) 

Isolation level     Dirty reads   Non-repeatable   Phantoms
Read Uncommitted    may occur     may occur        may occur
Read Committed      -             may occur        may occur
Repeatable Read     -             may occur        -
Serializable        -             -                -

Согласно моему пониманию, наиболее надежным является Serializable, затем Repeatable Read и затем Read Committed, но все же я видел приложения, использующие Read Committed. Это потому что производительность Serializable и Repeatable Read плохая по сравнению с Read Committed, потому что в serializable она будет последовательной и в случае транзакции должен ждать снятия блокировки другой транзакцией. Правильно? Таким образом, чтобы получить лучшее из всех трех, мы можем использовать изоляцию уровень как Read Committed с SELECT FOR UPDATE (для достижения повторяемого чтения). Не уверен, как мы можем достичь фантомного чтения, если мы хотим, в случае чтения совершено уровень изоляции?

1 Ответ

6 голосов
/ 14 сентября 2011

Oracle не поддерживает уровень изоляции REPEATABLE READ. Тем не менее, SQL Server делает - и он устанавливает блокировки на все строки, выбранные транзакцией, до тех пор, пока она не завершится (то есть: будет зафиксирована или откатана). Таким образом, вы правы, это действительно заставит другие транзакции ждать (если они обновляют заблокированные данные) и может нанести ущерб параллелизму.

Что касается вопроса 2: Да, чем выше уровень изоляции, тем хуже будут выполняться ваши параллельные транзакции, поскольку они должны ждать освобождения большего количества блокировок. Я не уверен, что вы имеете в виду, когда «получаете лучшее из всех трех», используя SELECT FOR UPDATE, потому что SELECT FOR UPDATE установит блокировки строк на все выбранные строки.

И, наконец, вот цитата из руководства Oracle по фантому:

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

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

Справка:

...