Witam,nie do końca rozumiem różnicę między problemem not repeatible read a Phantom read. Skoro uniknięcie tego pierwszego gwarantuje powtarzalność odczytów z tabeli, to nie gwarantuje jednocześnie tego co omija problem Phantom read?
Repeatable read zapewnia spójność w obszarze istniejących danych, o które twoja transakcja poprosiła np. Jeżeli napisałeś Select, w którym poprosiłeś o 10 rekordów, to na każdym z tych wierszy tworzony jest lock, który uniemożliwi modyfikację danych przez inną transakcję (będzie kręciła się tak długo, aż twoja transakcja się zakończy). Phantom read dotyczy głównie nowych danych (insertów) i jest efektem wyżej opisanej lokalnej blokady na rekord, nie cały obiekt (tabelę), a więc przy poziomie izolacji repeatable read inne transkacje mogą dodać nowe wiersze do tabeli, w trakcie trwania twojej transakcji. Dlatego też 2 Select może być ilościowo, nie jakościowo różny. Serializable lockuje całą tabelę - więc na czas trwania twojej transakcji, tylko Ty masz dostęp do jej modyfikacji, a co gorsza również odpytania. Izolacja jest wysoka, ale wspóbieżność zerowa, więc w systemach o wysokim współczynniku wspóbieżności to nie jest najwspanialszy pomysł... Sql server oferuje jeszcze 5 typ izolacji - Snapshot, który oferuje benefity serializable, przy jednoczesnym braku blokad. Z tą jednak różnicą, że Twoje operacje wykonywane są na tymczasowej kopi - ograniczeniem jest więc prędkość samej transakcji oraz miejsce, jeżeli chcemy dokonać operacji na większych zbiorach. Materiał zawiera też błąd - podstawowym poziomem izolacji w sql server jest read committed, aczkolwiek do danych niezatwierdzonych bardzo łatwo się dostać za pomocą hinta nolock. Należy też zauważyć, że domyślna transakcyjność jest niejawna, a więc wszystkie operacje DML zostaną automatycznie zatwierdzone po ich wykonaniu. Należy na to uważać, zwłaszcza gdy przychodzi się np. Z Oracle. Problemem nadużywania nolock w sql server jest inny poziom zachowania samego silnika współbieżności. Np. W Oracle, tak długo jak trqnskacja nie jest zatwierdzona, użytkownicy mogą odpytać tabelę w jej niezmienionej formie. W sql server, tak długo aż nie wykona się ostatnia operacja z batcha, tak długo modyfikowane rekordy będą zablokowane, a więc w przypadku Select * innego użytkownika, taka operacja będzie wisieć.
Właśnie się uczę do poprawki z baz danych :) Bardzo pomocny materiał!
Super wytłumaczone!
Świetnie wytłumaczone :)
co z tym kursem administracji? :)
Powstaje :-)
@@bazydanychalternatywnie1873pozostaje czekać :)
Witam,nie do końca rozumiem różnicę między problemem not repeatible read a Phantom read. Skoro uniknięcie tego pierwszego gwarantuje powtarzalność odczytów z tabeli, to nie gwarantuje jednocześnie tego co omija problem Phantom read?
Repeatable read zapewnia spójność w obszarze istniejących danych, o które twoja transakcja poprosiła np. Jeżeli napisałeś Select, w którym poprosiłeś o 10 rekordów, to na każdym z tych wierszy tworzony jest lock, który uniemożliwi modyfikację danych przez inną transakcję (będzie kręciła się tak długo, aż twoja transakcja się zakończy). Phantom read dotyczy głównie nowych danych (insertów) i jest efektem wyżej opisanej lokalnej blokady na rekord, nie cały obiekt (tabelę), a więc przy poziomie izolacji repeatable read inne transkacje mogą dodać nowe wiersze do tabeli, w trakcie trwania twojej transakcji. Dlatego też 2 Select może być ilościowo, nie jakościowo różny. Serializable lockuje całą tabelę - więc na czas trwania twojej transakcji, tylko Ty masz dostęp do jej modyfikacji, a co gorsza również odpytania. Izolacja jest wysoka, ale wspóbieżność zerowa, więc w systemach o wysokim współczynniku wspóbieżności to nie jest najwspanialszy pomysł... Sql server oferuje jeszcze 5 typ izolacji - Snapshot, który oferuje benefity serializable, przy jednoczesnym braku blokad. Z tą jednak różnicą, że Twoje operacje wykonywane są na tymczasowej kopi - ograniczeniem jest więc prędkość samej transakcji oraz miejsce, jeżeli chcemy dokonać operacji na większych zbiorach.
Materiał zawiera też błąd - podstawowym poziomem izolacji w sql server jest read committed, aczkolwiek do danych niezatwierdzonych bardzo łatwo się dostać za pomocą hinta nolock. Należy też zauważyć, że domyślna transakcyjność jest niejawna, a więc wszystkie operacje DML zostaną automatycznie zatwierdzone po ich wykonaniu. Należy na to uważać, zwłaszcza gdy przychodzi się np. Z Oracle. Problemem nadużywania nolock w sql server jest inny poziom zachowania samego silnika współbieżności. Np. W Oracle, tak długo jak trqnskacja nie jest zatwierdzona, użytkownicy mogą odpytać tabelę w jej niezmienionej formie. W sql server, tak długo aż nie wykona się ostatnia operacja z batcha, tak długo modyfikowane rekordy będą zablokowane, a więc w przypadku Select * innego użytkownika, taka operacja będzie wisieć.
Poddał się, to ostatni filmik
Fajne
Dzięki :-)