Planista (scheduler) Transakcje Blokowanie Dwufazowe (B2F) Tadeusz Pankowski www.put.poznan.pl/~tadeusz.pankowski Zarządzaniem transakcjami zajmuje się wyspecjalizowany moduł planisty. Planista związany jest z każdym menedżerem danych (MD) zarządzającym danymi określonej lokalnej bazy danych na określonym węźle sieci. Tylu jest planistów ile lokalnych baz danych w systemie. Nie ma natomiast żadnego centralnego planisty, który koordynowałby dostęp do lokalnych baz danych (taki centralny nadzorca jest natomiast potrzebny do rozwiązywania globalnych zakleszczeń). Każda transakcja może kierować swoje operacje odczytu/zapisu do wielu lokalnych baz danych. B2F 1 B2F 2 T 1,..., T n Menadżer Transakcji MT Planista Menadżer Danych MD Serwer bazy danych (SZBD) Przetwarzanie transakcji T n+1,..., T m Menadżer Transakcji MT Planista Menadżer Danych MD Serwer bazy danych (SZBD) T m+1,..., T p Menadżer Transakcji MT Planista Menadżer Danych MD Serwer bazy danych (SZBD) Menadżer transakcji (MT) koordynuje wykonywanie transakcji. Decyduje, do jakiego menadżera danych (MD) przekazać operację transakcji. Operacje przejmuje planista związany z MD i zarządza ich wykonywaniem posługując się protokołem B2F (Blokowanie 2-Fazowe) B2F 3 Działanie planisty Planista przyjmując operację o ma do dyspozycji następujące działania: przekazanie operacji o do wykonania menadżerowi danych, umieszczenie operacji o w kolejce, jeśli znajduje się ona w konflikcie z inną operacją i należy poczekać na zakończenie tej operacji; odrzucenie operacji i tym samym całej transakcji, jeśli na przykład konieczne jest to z punktu widzenia rozwiązywania zakleszczeń (dead locs). Opisana strategia działania planisty jest w komercyjnych SZBD realizowana za pomocą tzw. protokołu blokowania dwufazowego (B2F). Planista realizujący tę strategię nazywany jest planistą blokowania dwufazowego (planistą B2F). B2F 4
Reguły planisty B2F Jeśli operacja p i [x] może być wykonana, to planista zakłada blokadę (odpowiednio do odczytu, SHARED, lub do zapisu, EXCLUSIVE) na daną x dla transakcji T i i operację tę przekazuje MD do wykonania; jeśli operacja ta nie może być wykonana, to umieszczana jest w kolejce. Zdjęcie założonej blokady może nastąpić najwcześniej wtedy, gdy MD powiadomi planistę o zakończeniu wykonywania operacji. Jeśli nastąpiło zdjęcie jakiejkolwiek blokady założonej dla transakcji T, to dla T nie można już założyć żadnej innej blokady (reguła B2F). Fazy B2F Trzecia reguła B2F uzasadnia nazwę blokowanie dwufazowe, gdyż w procesie wykonywania transakcji można wyróżnić dwie fazy: fazę zakładania blokad i fazę zdejmowania blokad. Zakładanie blokad na rzecz transakcji T Zdejmowanie blokad założonych na rzecz transakcji T Sposób zdejmowania blokad związany jest z realizacją przetwarzania odpowiadającego różnym poziomom izolacji. B2F 5 B2F 6 Realizacja różnych poziomów izolacji w protokole B2F Założenia: Blokadę S (SHARED) dla tej samej danej może uzyskać dowolna liczba transakcji. Blokadę X (EXCLUSIVE) dla konkretnej danej może uzyskać tylko jedna transakcja. S i X nie mogą być jednocześnie założone na tę samą daną dla dwóch różnych transakcji. Uzyskanie blokady S jest konieczne dla odczytania danej. Uzyskanie blokady X jest konieczne dla zapisania (modyfikacji, usunięcia) danej. B2F 7 B2F realizacja poziomu izolacji 0 Dana zablokowana na czas realizacji operacji Read (blokada S) jest natychmiast odblokowywana po zakończeniu tej operacji. Dana zablokowana na czas realizacji operacji Write (blokada X) zmienia blokadę na S, to znaczy może na niej być realizowana operacja Read, ale nie operacja Write. Blokada dla operacji Write zdejmowana jest całkowicie dopiero po zatwierdzeniu transakcji B2F 8
B2F realizacja poziomu izolacji 1 B2F realizacja poziomu izolacji 2 i 3 Dana zablokowana na czas realizacji operacji Read (blokada S) jest natychmiast odblokowywana po zakończeniu tej operacji. Dana zablokowana na czas realizacji operacji Write (blokada X) odblokowywana jest dopiero po zatwierdzeniu transakcji. B2F z poziomem izolacji 2: Zdejmowanie blokad następuje dopiero po zatwierdzeniu transakcji. B2F z poziomem izolacji 3: dodatkowo utrzymywane są blokady sterowane przez warunki, tzn. zblokowana jest możliwość takich aktualizacji (w tym dołączania), które wpływają na rekordy spełniające określony warunek. B2F 9 B2F 10 Cechy B2F Poprawność B2F Niech H = (o 1, o 2,..., o m ) będzie historią przetwarzania dla zbioru transakcji,..., T n }. Podstawową cechę planisty B2F jest to, że każda historia przetwarzania transakcji utworzona przez planistę B2F jest poprawna. Wadą planisty B2F jest to, że może prowadzić do powstania zakleszczeń (ang. deadlock). Definicja Mówimy, że operacja o j poprzedza w H operację o k, jeśli j < k oraz operacje te są konfliktowe stosujemy wówczas zapis o j < o k. Definicja Mówimy, że transakcja T poprzedza w H transakcję T, co zapisujemy T < T, jeśli zachodzi jeden z dwóch warunków: istnieją w H operacje o i o pochodzące odpowiednio z T i T, takie że o < o, lub istnieje transakcja T, taka że T < T < T. B2F 11 B2F 12
Poprawność B2F (c.d.) Definicja Historię H nazywamy poprawną, jeśli dla każdej pary transakcji T, T Σ spełniony jest warunek: jeśli T < T, to nieprawda, że T < T. Jeśli historia H jest poprawna, to określona na niej relacja < wprowadza częściowy porządek w zbiorze transakcji. Zbiór transakcji możemy wówczas przedstawić w postaci acyklicznego grafu skierowanego zwanego grafem uszeregowalności (GU) transakcji. Poprawność B2F przykład } przetwarzane transakcje. H 1 = (w 2 [x], w 3 [y], w 3 [x], r 1 [y], w 1 [y] ) Zatem: T 2 < T 3 < T 1. H 1 jest poprawną historią przetwarzania transakcji. } przetwarzane transakcje H 2 = ( r 1 [x], w 2 [x], r 1 [x], w 3 [y], c 2, w 3 [x], r 1 [y], w 1 [y] ) Zatem: T 2 < T 1 < T 3 < T 1. H 2 nie jest poprawną historią przetwarzania transakcji. B2F 13 B2F 14 Poprawność B2F przykład } przetwarzane transakcje. H 1 = ( r 1 [x], w 2 [x], w 3 [y], c 2, w 3 [x], r 1 [y], w 1 [y] ) Zatem: T 2 < T 3 < T 1. H 1 jest poprawną historią przetwarzania transakcji. } przetwarzane transakcje H 2 = ( r 1 [x], w 2 [x], r 1 [x], w 3 [y], c 2, w 3 [x], r 1 [y], w 1 [y] ) Zatem: T 2 < T 1 < T 3 < T 1. H 2 nie jest poprawną historią przetwarzania transakcji. B2F 15 Poprawność B2F - twierdzenie Twierdzenie Każda historia przetwarzania utworzona przez planistę B2F jest poprawna. Dowód: Pokażemy, że w każdej historii przetwarzania H utworzonej przez planistę B2F, dla każdej pary transakcji T i T zachodzi warunek: jeśli T < T, to nieprawda, że T < T. 1. Zauważmy, że jeśli T < T, to założenie jakiejś blokady na rzecz transakcji T musi być poprzedzone zdjęciem jakiejś blokady założonej na rzecz transakcji T. 2. Dowód poprowadzimy nie wprost. Przypuśćmy, że w H zachodzą: T < T oraz T < T. Wówczas, uwzględniając p. 1 widzimy, że założenie jakiejś blokady na rzecz transakcji T musi być poprzedzone zdjęciem jakiejś blokady założonej na rzecz tej transakcji. Jest to sprzeczne z trzecią regułą B2F. 3. Z 2. wynika zatem, że rozważana historia przetwarzania H nie mogła by utworzona przez planistę B2F. Dowodzi to prawdziwości twierdzenia. B2F 16
Pamiętanie danych (MS SQL Server) Blokowanie zasobów na różnych poziomach granulacji (MS SQL Server) Database Zasób Opis Data (file).mdf or.ndf Log (file).idf RID Key Page Row IDentifier. Używany do blokowania pojedynczego wiersza w tabeli Klucz; blokowanie krotek w indeksie. Stosowany do blokowania zakresów wartości klucza na poziomie izolacji SERIALIZABLE. 8-KB strona danych lub indeksu. Tables, Indexes Dane Page (8 KB) Extent (8 contiguous 8-KB pages) Extent Table DB Spójna grupa ośmiu stron danych lub stron indeksu Cała tabela obejmująca wszystkie dane i indeksy. Baza danych. Max row size = 8060 bytes B2F 17 B2F 18 Tryby blokowanie (MS SQL Server) Tryby blokowanie (MS SQL Server) Typ blokady Opis Typ blokowanie Opis Współdzielenie Shared (S) Aktualizacja Update (U) Dla operacji, które nie zmieniają danych (korzystają z nich w trybie readonly), takich np. jak wyrażenie SELECT Zakładany na dane, które mogą być aktualizowane. Zapobiega zakleszczeniom w sytuacji, gdy wiele transakcji czyta dane z zamiarem ich aktualizacji. Intencja współdzielenia Intent shared (IS) Intencja wyłączności Intent exclusive (IX) Wskazuje intencję czytania pewnych (ale nie wszystkich) zasobów na niższym poziomie hierarchii przez założenie na te zasoby blokady S. Wskazuje intencję modyfikowania pewnych (ale nie wszystkich) zasobów na niższym poziomie hierarchii przez założenie blokady X na te zasoby. IX jest nadzbiorem dla IS. Wyłączność Exclusive (X) Intencja dot. hierarchii Intent (IS, IX, SIX) Na schemacie Schema (Sch-S, SCh-M) Aktualizacja masowa Bulk update (BU) Dla operacji modyfikacji danych, takich jak UPDATE, INSERT, DELETE. Zapewnia, że aktualizacje nie mogą być wykonane przez różne transakcje na tych samych danych w tym samym czasie. Używany w celu ustalenia hierarchii blokad. Dwa rodzaje blokad: SCh-S (stabilność schematu) zakładana w czasie kompilacji zapytania (uniemożliwia zmianę schematu); SCh-M (modyfikacja schematu) zakładana w czasie modyfikacji schematu tabeli (dodanie kolumny, usunięcie tabeli). W czasie masowego kopiowania danych, gdy ustawiony jest TABLOCK 19 Współdzielony z intencją wyłączności Shared with intent exclusive (SIX) Wskazuje intencję czytania wszystkich zasobów na niższym poziomie hierarchii i modyfikacji pewnych (nie wszystkich) zasobów na niższym poziomie hierarchii przez założenie blokady IX na te zasoby. Możliwa jest następująca sytuacja: Czytamy wszystkie strony należące do tabeli i chcemy modyfikować niektóre krotki z tych stron. Wówczas: X na modyfikowanych krotkach, IX blokada na modyfikowanych stronach SIX na tabeli. B2F 20
Kompatybilność blokad (MS SQL Server) Blokowanie zakresu klucza (Key-range Locking) Żądany typ blokowania Istniejący typ blokowania IS S U IX SIX X Intent shared (IS) Yes Yes Yes Yes Yes No Shared (S) Yes Yes Yes No No No Update (U) Yes Yes No No No No Intent exclusive (IX) Shared with intent exclusive (SIX) Yes No No Yes No No Yes No No No No No Exclusive (X) No No No No No No B2F 21 Blokowanie zakresu klucza rozwiązuje problem fantomów i umożliwia zrealizowanie postulatu szeregowalności transakcji. Blokada pokrywa indywidualne rekordy oraz zakresy między rekordami, dzięki czemu nie jest możliwe włączenie ani usuwanie fantomów w zbiorze rekordów przetwarzanych przez transakcję. Realizowana jest tylko na poziomie izolacji SERIALIZABLE. Uszeregowalność wymaga, aby każde zapytanie wykonywane w obrębie transakcji miało dostępny dokładnie ten sam zbiór krotek, również wtedy, gdy jest ponownie wykonywane w obrębie tej samej transakcji. Jeśli zapytanie chce mieć dostęp do krotki, która nie istnieje, to krotka ta nie może być dołączona przez inną transakcję przed zakończeniem pierwszej transakcji. Gdyby druga transakcja miała prawo dołączenia tej krotki, to krotka ta byłaby fantomem. Mechanizm blokowania musi także zabronić dołączenia krotki do strony, która nie jest blokowana przez pierwszą transakcję. B2F 22 Blokowanie zakresu klucza (Key-range Locking) (c.d.) Blokowanie zakresu klucza oparte jest na pokrywaniu pozycji w indeksie i zakresów między tymi pozycjami, a nie na blokowaniu krotek w tabeli bazowej. Każda próba dołączenia, modyfikacji czy usunięcia krotki z danego zakresu przez drugą transakcję wymaga modyfikacji indeksu, zatem druga transakcja jest wstrzymywana do czasu zakończenia pierwszej, gdyż blokada zakresu klucza pokrywa odpowiednie pozycje indeksu. B2F 23 B2F 24