Bazy danych. Plan wykładu. Czynniki wpływające na fizyczny projekt bazy danych. bazy danych

Transkrypt

1 Plan wykładu Bazy danych Wykład 13: Praktyczne projektowanie i strojenie baz danych. Wstęp do transakcji. Budowa fizycznego projektu bazy danych Strojenie bazy danych Transakcje Małgorzata Krętowska m.kretowska@pb.edu.pl 2 Czynniki wpływające na fizyczny projekt bazy danych Projektowanie fizyczne to działanie, którego celem jest nie tylko otrzymanie odpowiedniej struktury przechowywania danych, ale również dokonanie tego w sposób gwarantujący wysoką wydajność działania: Analiza zapytań i transakcji w bazie danych Zapytania należy określić: Pliki, do których zapytanie będzie uzyskiwało dostęp. Atrybuty, na których są określone warunki wyboru zapytania Atrybuty, na których są określone warunki złączeń Atrybuty, których wartości będą zwracane przez zapytanie Atrybuty z pkt. 2 i 3 są kandydatami do określenia struktur dostępu Transakcje należy określić: Pliki, które będą aktualizowane Rodzaj operacji wykonywanej na każdym pliku (wstawianie, aktualizowanie...) Atrybuty, na których są określone warunki wyboru dla operacji usuwania lub aktualizowania Atrybuty, których wartości będą zmieniane przez operację aktualizacji Atrybuty z pkt. 3 to kandydaci do struktur dostępowych. Atrybuty z pkt. 4 nie powinny być wykorzystywane do definiowania struktur dostępowych. 3 Czynniki wpływające na fizyczny projekt bazy danych Analiza spodziewanej częstotliwości wywoływania zapytań i transakcji informacje o spodziewanej częstości użycia każdego atrybutu jako atrybutu wyboru lub złączenia ( reguła około 80% czasu przetwarzania jest związane z tylko 20% zapytań i transakcji) Analiza więzów czasowych na zapytaniach i transakcjach niektóre zapytania i transakcje mogą posiadać ograniczenia co do wydajności ich działania np. transakcja ma w 95 % przypadków kończyć swoje działanie przed upływem 5 sekund i nie powinna być wykonywana dłużej niż 20 sekund. Powoduje to ustalenie priorytetów ustalania struktur dostępu do odpowiednich atrybutów Analiza spodziewanej częstotliwości operacji aktualizacji dla pliku, który podlega częstym aktualizacjom należy określić minimalną liczbę ścieżek dostępu Analiza więzów unikatowości na atrybutach ścieżki dostępu powinny zostać określone na wszystkich atrybutach klucza kandydującego (klucz główny albo więzy unikatowości). Wówczas wszystkie wartości atrybutu występują w wierzchołkach liści indeksu. 4

2 Decyzje projektowe dotyczące indeksów Atrybuty, których wartości występują w warunkach wyboru oraz te, które są kluczami lub występują w warunkach złączeń wymagają określenia ścieżek dostępu. Z drugiej strony operacje wstawiania, usuwania, aktualizacji przy obecności indeksów trwają dłużej. Określenie, czy należy indeksować dany atrybut atrybut musi być kluczem lub musi występować zapytanie wykorzystujące ten atrybut w warunku wyboru lub złączeniu. Tworzenie wielu indeksów -> niektóre zapytania mogą być przetwarzane poprzez przegląd samego indeksu, bez pobierania danych z bazy. Określenie, jaki atrybut (atrybuty) powinien być indeksowany tworzenie indeksu zbudowanego z kilku atrybutów pochodzących z jednej relacji ma sens wówczas, gdy są one uwzględniane razem w kilku zapytaniach. Kolejność atrybutów w indeksie powinna być taka sama jak w zapytaniu Decyzje projektowe dotyczące indeksów Określenie, czy należy utworzyć indeks klastrowania w przypadku każdej tabeli może istnieć tylko jeden indeks główny (atrybut jest kluczem) lub klastrowania (atrybut nie jest kluczem). Jeżeli tabela wymaga kilku indeksów decyzja o tym, który powinien być indeksem klastrowania zależy od tego, czy istnieje konieczność uporządkowania tabeli według danego atrybutu. Jeżeli odpowiedź dla zapytania ma być uzyskiwana tylko przez przegląd indeksu, nie powinien być on indeksem klastrowania -> największe korzyści przynosi indeks klastrowania, gdy pobierane są rekordy danych. Określenie, czy należy użyć indeksu mieszającego (haszowanego) zamiast drzewa SZRBD wykorzystują przeważnie B + -drzewa w celu indeksowania. Obsługują one zarówno zapytania równościowe jak też zakresowe. W przypadku indeksu mieszającego jest on wykorzystywany w warunkach równościowych, szczególnie w trakcie złączeń. 5 6 Denormalizacja Normalizacja celem jest rozdzielenie logiczne powiązanych atrybutów między tabele w celu zminimalizowania nadmiarowości, a przez to uniknięcia anomalii aktualizacji Denormalizacja zmiana logicznego projektu bazy danych na słabszą postać np. 2NF w celu uzyskania możliwości szybszego wykonywania często występujących zapytań i transakcji. Zazwyczaj projektant dodaje do tabeli atrybuty, które są wymagane w celu uzyskania odpowiedzi na zapytanie, tak aby można było uniknąć złączenia z inną tabelą. Powoduje to powstanie odpowiednich problemów z redundancją danych. Strojenie baz danych Poprawa działania bazy danych po jej wdrożeniu i uruchomieniu, mająca na celu uwzględnienie problemów i czynników, których nie uwzględniono w czasie początkowego projektowania bazy. Konieczne stałe monitorowanie działania bazy. Cele procesu strojenia: Przyspieszenie działania aplikacji Skrócenie czasu odpowiedzi na zapytania i transakcje Zwiększenie ogólnej przepustowości transakcji Decyzje związane z etapem strojenia są takie same jak decyzje podejmowane na etapie budowy projektu fizycznego, przy czym danymi wejściowymi procesu strojenia są dane zebrane w trakcie działania systemu: Rozmiary poszczególnych tabel Liczba odrębnych wartości w kolumnie Liczba powtórzeń danego zapytania lub transakcji w danym okresie czasu Czas wymagany dla różnych etapów przetwarzania zapytań i transakcji 7 8

3 Strojenie baz danych Inne informacje otrzymywane na podstawie monitorowania działania systemu bazy danych: Statystyki dotyczące składowania danych podział obszaru składowania na przestrzenie tabel i indeksów Statystyki dotyczące operacji wejścia-wyjścia i wydajności urządzeń dane związane z operacjami odczytu i zapisu na dysku, obszary dysku o największej aktywności Statystyki dotyczące przetwarzania zapytań i transakcji - czas wykonania tych operacji, czas optymalizacji zapytań Statystyki dotyczące blokad i rejestrowania zdarzeń Statystyki dotyczące indeksów np. liczba poziomów indeksu Strojenie bazy danych wiąże się z pokonywaniem następujących problemów: Unikanie zbyt częstych rywalizacji o zasoby dzielone Minimalizowanie narzutu związanego z rejestrowaniem i niepotrzebnym awaryjnym kopiowaniem danych Optymalizowanie rozmiaru bufora i szeregowanie procesów Przydzielanie zasobów takich jak dyski, pamięć RAM i procesy w sposób zapewniający jak najwydajniejsze ich wykorzystanie. Strojenie indeksów i zapytań Początkowy wybór indeksów można zmienić z następujących powodów: Określone zapytania mogą działać zbyt długo ze względu na brak indeksu Niektóre indeksy mogą w ogóle nie być używane Niektóre indeksy mogą nakładać spory narzut związany z tym, że są zdefiniowane na atrybutach często podlegających zmianom Strojenie zapytań Zapytanie generuje zbyt wiele operacji dostępu do dysku Plan zapytania ujawnia, że odpowiednie indeksy nie są używane 9 10 Strojenie projektu bazy danych Istniejące tabele mogą być łączone (denormalizacja), ponieważ niektóre atrybuty pochodzące z dwóch lub większej liczby tabel są często wymagane wspólnie. W przypadku danego zbioru tabel mogą istnieć alternatywne rozwiązania projektowe, dające w efekcie schemat w postaci 3NF lub BCNF. Partycjonowanie pionowe tabeli jeżeli tabela zawiera bardzo dużą liczbę wierszy można ją rozbić na większą liczbę tabel z podzbiorami atrybutów i replikacjami klucza tabeli. Zapytania do każdej z tabel są niezależne. Atrybuty jednej tabeli mogą być powtórzone w innej Partycjonowanie poziome podział tabeli w poziomie na kilka oddzielnych tabel np. tabela sprzedaży produktów jest podzielona na na kilka tabel w oparciu na różne linie produkcyjne 11 Systemy jedno- i wieloużytkownikowe System jednoużytkownikowy jeżeli w danym momencie z systemu może korzystać tylko jeden użytkownik System wieloużytkownikowy w danym momencie z systemu może korzystać wielu użytkowników współbieżnie. Przetwarzanie z przeplotem A B A B Przetwarzanie równoległe t 1 t2 t 3 t 4 C D CPU 1 CPU 2 czas

4 Transakcje Transakcja jest wykonywanym programem, który tworzy logiczną jednostkę przetwarzania w bazie danych. Transakcja składa się z jednej lub wielu operacji dostępu do bazy danych. Jednym ze sposobów określania zakresu transakcji jest wyróżnienie jawnych instrukcji begin i end transaction. Jeżeli operacje bazodanowe należące do transakcji nie aktualizują bazy danych, a tylko pobierają dane, o transakcji mówimy, że jest tylko do odczytu. Pożądane właściwości transakcji (ACID) atomowość (atomicity) - cała transakcja powinna zostać przeprowadzona, albo żaden z jej elementów nie zostanie uwzględniony spójność (consistency) - np. miejsce w danym rejsie lotniczym nie może być przydzielone dwóm różnym pasażerom izolacja (isolation) - brak wpływu transakcji na siebie przy jednoczesnym ich przetwarzaniu trwałość (durability) - po zakończeniu transakcji jej wynik nie może zostać utracony Problem utraconej aktualizacji T1 T2 Problem aktualizacji tymczasowej T1 T2 X:=X-N; Zapisz_element (X); Odczytaj_element (Y); X:=X+M; X:=X-N; Zapisz_element (X); Zapisz_element (Y); X:=X+M; Zapisz_element(X); Y:=Y+N; Zapisz_element (Y); Zapisz_element(X); 15 Transakcja T1 kończy się niepowodzeniem i musi zmienić wartość X z powrotem do jej oryginalnego stanu; w tym czasie T2 odczytuje jej tymczasową niepoprawną wartość 16

5 Problem błędnego podsumowania T1 X:=X-N; Zapisz_element (X); Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); T2 Suma:=0; Odczytaj_element(A); suma:=suma+a;... suma:=suma+x; Odczytaj_element (Y); suma:=suma+y; Odczyt niepowtarzalny Występuje wówczas, gdy transakcja T1 odczytuje element dwukrotnie, czy czym element ten zostaje zmieniony przez inną transakcję T2 między tymi dwoma odczytami Przykład: T1: R(X), R(X), W(X) T2: R(X), W(X) Czas > Gdzie: R(X) odczytaj_ element X, W(X) zapisz_element X Potrzeba obsługi mechanizmów odtwarzania Po przekazaniu transakcji do wykonania, SZBD jest odpowiedzialny za zapewnienie, aby: Wszystkie operacje wykonywane w ramach transakcji zostały zakończone z powodzeniem i wyniki zapisane w bazie danych, albo Transakcja nie miała wpływu na bazę danych i inne transakcje Nie może być sytuacji, gdy pewne operacje są uwzględnione w bazie a inne nie. Taka możliwość może zachodzić w przypadku, gdy transakcja ulegnie uszkodzeniu po wykonaniu tylko części swoich operacji. Rodzaje awarii (transakcyjne, systemowe i nośników): Awaria komputera błąd sprzętowy Błąd transakcyjny lub systemowy uszkodzenie transakcji w trakcie jej wykonania np. dzielenie przez 0; błąd programisty; przerwanie transakcji przez użytkownika Potrzeba obsługi mechanizmów odtwarzania Błędy lokalne lub wyjątki wykryte przez transakcję np wymagane przez transakcję dane są niedostępne Wymuszenie sterowania współbieżnego metoda sterowania współbieżnego może zdecydować o anulowaniu transakcji i późniejszym jej wznowieniu np. stan zakleszczenia kilku transakcji Awaria dysku Problemy i katastrofy fizyczne zanik napięcia, pożar, zamontowanie nieodpowiedniej taśmy 19 20

6 Operacje związane z transakcjami Transakcja jest niepodzielną jednostką działań, które muszą być wykonane w całości lub w ogóle. Do celów odtwarzania system musi śledzić następujące operacje: ROZPOCZNIJ_TRANSAKCJĘ ODCZYTAJ lub ZAPISZ operacje odczytu i zapisu przeprowadzane na elementach bazy danych ZAKOŃCZ_TRANSAKCJĘ należy zweryfikować czy zmiany wprowadzone przez transakcję mogą zostać zatwierdzone, czy transakcja ma być anulowana ZATWIERDŹ_TRANSAKCJĘ oznaczenie udanego zakończenia transakcji WYCOFAJ nieudane zakończenie transakcji Diagram przejść stanów związanych w wykonaniem transakcji Rozpocznij transakcję Odczytaj zapisz Aktywna Zakończ transakcję Anuluj Zatwierdzona częściowo awaria Anuluj zatwierdź Zatwierdzona Zakończona Dziennik systemowy (ang. log) W celu umożliwienia odtwarzania po awariach wpływających na transakcje system przechowuje dziennik, w którym śledzi wszystkie operacje związane z transakcjami, mające wpływ na wartości elementów bazy danych. Dziennik jest przechowywany na dysku i jest okresowo archiwizowany na taśmie, w celu zabezpieczenia go przed awariami. Rodzaje wpisów do dziennika (rekordy dziennika): [rozpocznij_transakcję,t] [zapisz_element, T,X, stara wartość, nowa wartość] [odczytaj_element, T,X] [zatwierdź, T] [anuluj,t] Punkt zatwierdzenia transakcji Transakcja osiąga swój punkt zatwierdzenia, gdy wszystkie jej operacje zostaną z powodzeniem wykonane oraz ich wyniki zostaną zarejestrowane w dzienniku. Za punktem zatwierdzenia mówi się, ze transakcja została zatwierdzona, a jej działania za trwale zapisane w bazie Kolejną czynnością jest zapisanie do dziennika rekordu zatwierdzenia. Jeżeli nastąpi awaria wszystkie transakcje które rozpoczęły swoje działanie, a dla których nie ma wpisu w dzienniku należy wycofać

7 Harmonogramy (plany) transakcji Gdy transakcje są wykonywane współbieżnie w technice przeplotu, kolejność wykonywania operacji związanych z różnymi transakcjami określa się mianem harmonogramu (historii, planu). T1 X:=X-N; Przykład T2 Harmonogram S zbioru n transakcji T1, T2,.., Tn jest uporządkowaniem operacji transakcji podlegającym ograniczeniu, które określa, że dla każdej transakcji Ti należącej do harmonogramu S, operacje tej transakcji w S muszą występować w tej samej kolejności, w jakiej występują w Ti. Zapisz_element (X); Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); Sa: r1(x); r2(x); w1(x); r1(y); w2(x); w1(y) a: anulowanie; c zatwierdzanie transakcji X:=X+M; Zapisz_element(X); Konflikt w harmonogramie Dwie operacje w transakcji są w stanie konfliktu, jeżeli spełniają wszystkie trzy z następujących warunków: Należą do różnych transakcji Uzyskują dostęp do tego samego elementu X Przynajmniej jedna z operacji jest operacją zapisz_element(); Przykład: Które operacje są w konflikcie? S: r1(x); r2(x); w1(x); r1(y); w2(x); w1(y) Harmonogram pełny Harmonogram składający się z n transakcji jest pełny, gdy: Operacje harmonogramu S są dokładnie tymi samymi operacjami, które występowały w transakcjach T1,..., Tn wliczając w to operacje zatwierdzania lub anulowania dla każdej transakcji Dla dowolnej pary operacji należących do tej samej transakcji Ti kolejność ich występowania w harmonogramie S jest taka sama jak kolejność w transakcji Ti Dla dowolnych dwóch transakcji konfliktowych jedna z nich musi występować w harmonogramie przed drugą. r1(x), w2(x) r2(x), w1(x) w1(x), w2(x) 27 28

8 Możliwości odtwarzania harmonogramów Harmonogramy odtwarzalne dla których w momencie zatwierdzenia transakcji T już nigdy nie było konieczne jej wycofanie (lub inaczej: harmonogram, który umożliwia wycofanie każdej transakcji) Harmonogram S jest odtwarzalny, jeżeli żadna transakcja T w harmonogramie S nie jest zatwierdzona do momentu, aż wszystkie transakcje T, które zapisały element odczytywany przez transakcję T, zostaną zatwierdzone. S: r1(x), w1(x), r2(x), w2(x), c1, c2 (+) S: r1(x), w1(x), r2(x), w2(x), c2, c1 (-) Harmonogramy nieodtwarzalne nie spełniają powyższego wymogu, stąd nie powinno się pozwalać na ich występowanie (Przykłady: problem aktualizacji tymczasowej i problem utraconej aktualizacji) Szeregowalność harmonogramów Pojęcie szeregowalności harmonogramów jest używane w celu identyfikowania, które harmonogramy są poprawne w przypadku, gdy wykonanie transakcji dopuszcza przeplot ich operacji. Harmonogram szeregowy harmonogram ustawiający wykonywanie transakcji w ciąg: najpierw akcje jednej transakcji, następnie akcje drugiej transakcji itd. Zakładając, że transakcje są niezależne, można założyć, że każdy harmonogram szeregowy jest poprawny Dwa harmonogramy są równoważne, jeżeli efekt realizacji obu harmonogramów jest taki sam dla każdego stanu bazy danych, tzn W1: Każda transakcja w obu planach odczytuje i zapisuje te same wartości W2: Po realizacji każdego z planów otrzymujemy ten sam stan bazy danych Przykład Zakładamy wartości początkowe x=90, y=90, n=3, m=2 Sa (szeregowy), wynik: x=89, y=93): T1:r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m, w(x),c Sb (szeregowy, wynik: x=89, y=93): T1: r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m, w(x),c Sc (nieszeregowy, wynik: x=92, y=93) T1:r(x), x:=x-n; w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m, w(x),c Sd (nieszeregowy, wynik: x=89, y=93) T1:r(x), x:=x-n,w(x), r(y), y=y+n, w(y),c T2: r(x), x=x+m,w(x),c Plan szeregowalny Plan (harmonogram) szeregowalny jest to plan, który jest równoważny pewnemu planowi szeregowemu (a przez to jest poprawny). Dzięki własnościom W1 i W2 plan szeregowalny zapewnia uzyskanie własności izolacji (W1) i spójności (W2). Plan szeregowalny nie daje gwarancji, że po wycofaniu transakcji nie trzeba będzie wycofywać akcji innych transakcji, co może być niewykonalne, gdy jedna z transakcji zostanie już zatwierdzona. Brak gwarancji spełnienia własności atomowości i trwałości. Sprawdzenie szeregowalności: konstrukcja grafu pierwszeństwa (inaczej grafu szeregowania) 31

9 Weryfikacja szeregowalności (algorytm tworzenia grafu pierwszeństwa) 1. Dla każdej transakcji Ti należącej do harmonogramu S utwórz w grafie pierwszeństwa wierzchołek Ti 2. Dla każdego przypadku w S, gdy Tj wykonuje operację r(x) po wykonaniu przez transakcję Ti operacji w(x), utwórz w grafie pierwszeństwa krawędź (Ti->Tj) 3. Dla każdego przypadku w S, gdy Tj wykonuje operację w(x) po wykonaniu przez transakcję Ti operacji r(x), utwórz w grafie pierwszeństwa krawędź (Ti->Tj) 4. Dla każdego przypadku w S, gdy Tj wykonuje operację w(x) po wykonaniu przez transakcję Ti operacji w(x), utwórz w grafie pierwszeństwa krawędź (Ti->Tj) 5. Harmonogram S jest szeregowalny wtedy i tylko wtedy, gdy graf pierwszeństwa nie zawiera cykli. Przykład Przykład planu nieszeregowalnego: T1: r(a), w(a), r(b), w(b) T2: r(a), w(a), r(b), w(b), Cykl w grafie pierwszeństwa: Blokady Blokady (zamki) podstawowy mechanizm zapobiegający konfliktom przy współbieżnie wykonywanych transakcjach Rodzaje blokad: Współdzielona, typu S (ang. shared lock) daje transakcji współdzielony dostęp do zasobu (kilka transakcji może jednocześnie odczytywać wiersze z tej samej tabeli). Jeśli transakcja zakłada współdzieloną blokadę, inne transakcje też mogą założyć współdzieloną blokadę, ale nie mogą założyć blokady drugiego rodzaju, tzn. wyłącznej Wyłączna, typu X (ang. exclusive lock) daje transakcji wyłączne prawo do zmian obiektu. Tylko jedna transakcja może mieć założoną wyłączną blokadę na obiekcie i w tym czasie nie może być na obiekcie założonej żadnej innej blokady, nawet współdzielonej. Istnieje metoda zakładania blokad gwarantująca powstanie i realizację planów wyłącznie szeregowalnych i odtwarzalnych protokół ścisłego blokowania dwufazowego. Protokół ścisłego blokowania dwufazowego (Strict 2PL) Każda transakcja musi uzyskać blokadę S na obiekcie zanim odczyta ten obiekt oraz blokadę X na obiekcie przed zapisaniem go. Jeśli transakcja trzyma blokadę X na obiekcie, żadna inna transakcja nie ma prawa założyć żadnej blokady na tym obiekcie Jeśli transakcja trzyma blokadę S na obiekcie, żadna inna transakcja nie ma prawa założyć blokady X na tym obiekcie Gdy transakcja nie może założyć blokady na obiekcie, może ustawić się w kolejce oczekujących transakcji stowarzyszonej z tym obiektem. Wszystkie blokady trzymane przez transakcję są zwalniane jednocześnie, w chwili, gdy transakcja kończy się 35 36

10 Protokół ścisłego blokowania dwufazowego (Strict 2PL) Można w nim wyróżnić dwie fazy: Transakcja zakłada blokady i dokonuje wymaganych odczytów i zapisów na obiektach, na których założyła blokadę Transakcja wykonuje COMMIT/ROLLBACK jednocześnie zwalniając wszystkie blokady Protokół Strict 2PL nie dopuszcza do anomalii utraconej aktualizacji, aktualizacji tymczasowej, błędnego podsumowania oraz niepowtarzalnego odczytu: Protokół blokowania dwufazowego 2PL Zamiast punktu w protokole Strict 2PL: Wszystkie blokady trzymane przez transakcję są zwalniane jednocześnie, w chwili, gdy transakcja kończy się Występuje sformułowanie: Transakcja nie może założyć żadnej nowej blokady po zwolnieniu jakiejkolwiek blokady. Protokół 2PL prowadzi do planów szeregowalnych, ale nie gwarantuje planów odtwarzalnych. Przykład: T1: R(X) W(X) a T2: R(X) W(X) c Zakleszczenia (deadlocks) Zjawisko zakleszczenia występuje wówczas, kiedy dwie lub więcej transakcji wzajemnie blokują sobie potrzebne do kontynuowania swojego działania obiekty Zakleszczenie- jest to cykl transakcji oczekujących wzajemnie na zwolnienie blokady przez inną transakcję w cyklu. Sposoby radzenia sobie z zakleszczeniami: Zapobieganie Zapobieganie Wykrywania Ustalanie limitu oczekiwania na blokadę (metoda timeout) ustalenie priorytetu między transakcjami. Nie dopuszcza się aby transakcja z wyższym priorytetem czekała na transakcje z niższym priorytetem W przypadku zakleszczenia transakcja z niższym priorytetem zostaje wycofana przez system Zakleszczenia Wykrywanie zakleszczeń polega na analizie, która transakcja oczekuje na zwolnienie blokady przez która transakcję i sprawdzaniu, czy występuje cykl Utwórz graf oczekiwań na zwolnienie blokady (węzły transakcje, krawędź Ti do Tj jeśli transakcja Ti oczekuje na zwolnienie blokady przez Tj) Co jakiś czas sprawdzaj, czy w grafie jest cykl. Jeśli jest wycofaj jedną z transakcji w cyklu Przykład: T1:S(A), R(A) S(B) T2: X(B), W(B) X(C) T3: S(C), R(C) X(A) T4: X(B) Graf oczekiwań na zwolnienie blokady: 39