Някои разяснения относно различното ниво на изолация в транзакцията на базата данни?

По-долу е изявлението, написано от статията за изолацията в Wikipedia относно REPEATABLE READS

В това ниво на изолация внедряването на СУБД за управление на едновременност, базирано на заключване, поддържа заключвания за четене и запис (придобити върху избрани данни) до края на транзакцията. Заключванията на обхват обаче не се управляват, така че може да възникне феноменът на фантомните четения (вижте по-долу).

Въпросът ми тук е съответно кога започва и приключва транзакцията.

Ако вземем примера на Неповторими четения с ниво на изолация REPEATABLE READS на същата връзка, според моето разбиране trnsaction 1 започва, когато се задейства първата заявка, т.е. SELECT * FROM users WHERE id = 1. DBMS ще запази заключването на потребителската таблица, докато и освен ако транзакцията не приключи. тук Покрай имам предвид, когато връзката бъде върната назад или не е ангажирана при завършване на 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, защото в сериализуемото ще бъде последователно и в случай на транзакция трябва да изчака освобождаването на заключването от друга транзакция. Нали? Така че, за да получим най-доброто от трите, можем да използваме ниво на изолация като Read Committed с SELECT FOR UPDATE (за постигане на повтарящо се четене).Не сме сигурни как можем да постигнем фантомно четене, ако искаме, в случай на ниво на изолация на четене?


person M Sach    schedule 14.09.2011    source източник
comment
Вижте stackoverflow.com/questions/10935850/ за дискусия на SELECT ... FOR UPDATE   -  person Gili    schedule 29.11.2012
comment
Така че, за да получим най-доброто от трите, можем да използваме ниво на изолация като Read Committed с SELECT FOR UPDATE - това е подходът на JDO слоевете за устойчивост като Datanucleus. Те предоставят механизъм за управление на ИЗБОР ЗА АКТУАЛИЗИРАНЕ на базата на транзакция. Вярвам, че този подход ще даде предимствата на сериализуемия механизъм за заключване на транзакции при използване на по-ниски типове транзакции.   -  person marcolopes    schedule 10.06.2014
comment
Сигурни ли сте, че повторяемото четене може да възникне в транзакция с ниво на изолация за неповторяемо? В тази статия таблицата е различна - oracle. com/technetwork/issue-archive/2010/10-jan/   -  person naXa    schedule 29.12.2015


Отговори (1)


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

Що се отнася до въпрос 2: Да, колкото по-високо е нивото на изолация, толкова по-лошо ще се представят вашите едновременни транзакции, защото трябва да изчакат освобождаването на повече ключалки. Не съм сигурен какво имате предвид, като получавате най-доброто от трите, като използвате SELECT FOR UPDATE, защото SELECT FOR UPDATE ще постави ключалки на редове на всички избрани редове.

И накрая, ето цитат от ръководството на Oracle за фантомни четения:

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

Например, транзакция прави запитване за броя на служителите. Пет минути по-късно той изпълнява същата заявка, но сега броят се е увеличил с един, защото друг потребител е вмъкнал запис за ново наемане. Повече данни отговарят на критериите на заявката, отколкото преди, но за разлика от размитото четене, предишните прочетени данни са непроменени.


Справка:

person NullUserException    schedule 14.09.2011
comment
Не съм сигурен какво имате предвид, като получавате най-доброто от трите. Основно това, което се опитвам да попитам тук, е, че ако използваме ниво на изолация, ангажирано за четене в Oracle, все още ще имаме проблеми с неповтарящо се и фантомно четене. Нали? Според моето разбиране, първо не трябва да ги наричаме проблеми, но те трябва да се считат за правилно поведение, защото между първата транзакция, ако втората транзакция се ангажира, тогава трябва да получим актуализирани данни. Нали? Продължава... - person M Sach; 15.09.2011
comment
продължение... Вторият въпрос е, че ако искаме да избегнем проблеми с неповтарящо се и фантомно четене с четене, ангажирано на oracle, има ли някакъв начин? Според мен, ако използваме избор за заявка за актуализиране, можем да бъдем спасени от неповтарящи се четения. Coorect? Но не сте сигурни как можем да избегнем фантомното четене? - person M Sach; 15.09.2011