Poziomy izolacji transakcji

 

Poziomy izolacji

W ten sposób dochodzimy do pojęcia poziomu izolacji bazy danych, który definiuje dostęp do określonych zasobów przez wiele równoległych procesów. Wyróżniamy następujące poziomy izolacji:

Read uncommited – jest to najmniej restrykcyjne ustawienie, które praktycznie powoduje ignorowanie założonych blokad. Jeżeli jedna transakcja nie została zatwierdzona (commit) ale zmieniła dane w bazie to w tym samym czasie inny proces może te dane odczytać. Jeżeli wspomniana transakcja zostanie wycofana to w efekcie okaże się, że drugi proces pobrał dane, które zostały wycofane.
Oznacza, że można odczytywać wiersze zmienione zanim transakcja które je zmieniła wykona commit. Oznacza to dopuszczenie do „brudnych odczytów”, a więc danych które mogą nigdy nie zostać „oficjalnie” zapisane w bazie, a jedynie być efektem działania transakcji która w efekcie zostanie wycofana.

Read commited – jest to domyślna opcja, która powoduje, że we wspomnianym przykładzie zostaną odczytane dane sprzed rozpoczęcia pierwszej transakcji. Podstawową wadą tej opcji jest oczywiście odwrotna sytuacja niż poprzednio – w momencie zatwierdzenia transakcji dane zostaną zmienione czyli nasz pierwotny odczyt będzie nieaktualny.
Przeciwnie do poprzedniego przypadku. Czytamy tylko dane aktualne bez „brudnych odczytów”. Jednak dane mogą zostać zmodyfikowane w trakcie wykonywania transakcji (na przykład przez innych żytkowników), wtedy wiersz który dał się odczytać w jednym zapytaniu, może już nie istnieć przy kolejnej próbie jego odczytu.

Repeatable read – w tym przypadku odczytywane są jedynie dane z zatwierdzonych transakcji, a żadna z transakcji nie może zmodyfikować danych, które zostały odczytane
Odczytujemy tylko dane które zostały commitowane, a także żadna transakcja nie ma prawa modyfikować danych które odczytaliśmy. To zapewnia nam powtarzalność odczytów, ale nie do końca bo inne zapytania dalej mogą insertować dane które spełniają warunki zapytań naszej transakcji. W efekcie możemy znowu dostać niespójne odczyty.  

Snapshot – w tym przypadku każda transakcja w momencie jej utworzenia tworzy sobie snapshot danych i na nim pracuje do czasu jej zakończenia. W ten sposób inne transakcje nie są w stanie zmodyfikować danych, które zostały użyte. Nawet jeżeli inna transakcja zmodyfikuje dane to oryginalna transakcja cały czas pracuje na danych z momentu jej utworzenia. W ten sposób upraszczamy dostęp do danych ale powoduje to dodatkowe obciążenie tabeli tempdb.
Pracujemy na stanie bazy z początku transakcji – nic nie jest w stanie zmodyfikować danych na których pracujemy (brak wad poprzednich trybów).

Serializable – odczyt danych z tabeli za pośrednictwem instrukcji select powoduje zablokowanie danego zakresu. W efekcie żadna inna transakcja nie będzie miała możliwości zmiany danych w tym okresie.

W tym trybie zakładane są locki na klucze które wpadają w zakres zapytań w naszej transakcji. Czyli inna transakcja nie doda nic do tabeli na której zrobimy SELECT * FROM ….w trakcie naszej transakcji. Dzięki temu zachowujemy spójność odczytów w trakcie całej transakcji.

Należy używać tego trybu tylko w ostateczności gdyż może skutecznie zblokować inne zapytania.


http://sqlwpraktyce.wordpress.com/tag/poziom-izolacji/
http://easysql.wordpress.com/2011/03/12/poziomy-izolacji-transakcji/

http://technet.microsoft.com/pl-pl/library/ms187373.aspx