Eskalacja blokad do poziomu tabeli

Eskalacja blokad do poziomu tabeli to konkretny przypadek automatycznego rozszerzenia blokady obejmującej całą strukturę danych.

Eskalacja blokad do poziomu tabeli – czym jest to zjawisko

Eskalacja blokad do poziomu tabeli oznacza sytuację, w której blokada założona początkowo na pojedynczy rekord, zakres wierszy albo konkretny fragment operacji zostaje rozszerzona na całą tabelę. W efekcie inne transakcje, które chciałyby odczytać lub zmodyfikować dane w tej samej strukturze, muszą oczekiwać na zwolnienie zasobu. Nie jest to zwykłe zwiększenie liczby blokowanych wierszy, lecz zmiana skali ochrony dostępu: system przechodzi z blokady bardziej szczegółowej do blokady obejmującej obiekt wyższego poziomu.

Mechanizm ma służyć zachowaniu spójności danych oraz ograniczeniu kosztu zarządzania bardzo dużą liczbą pojedynczych blokad. Każda blokada wymaga przechowywania informacji o zasobie, właścicielu, trybie dostępu i zależnościach z innymi blokadami. Gdy takich wpisów przybywa, narzut organizacyjny może stać się większy niż koszt objęcia blokadą większego obszaru. Wtedy następuje eskalacja, której skutkiem bywa uproszczenie zarządzania blokadami, ale jednocześnie ograniczenie współbieżności.

Warto odróżnić eskalację blokad od oczekiwania na blokadę. Oczekiwanie opisuje stan, w którym jedna operacja nie może kontynuować pracy, ponieważ zasób jest już zajęty. Eskalacja jest natomiast decyzją mechanizmu zarządzania blokadami, który zmienia zakres istniejącej ochrony. Może ona doprowadzić do większej liczby oczekujących operacji, choć sama nie musi oznaczać błędu.

Eskalacja blokad do poziomu tabeli a poziomy dostępu i porównania

Blokady można rozpatrywać hierarchicznie. Najniższy poziom może dotyczyć pojedynczego rekordu, wyższy zakresu rekordów, a jeszcze wyższy całej tabeli. W niektórych rozwiązaniach występują także blokady stron lub innych wewnętrznych jednostek przechowywania. Hierarchia pozwala systemowi dobierać kompromis pomiędzy precyzją a kosztem obsługi. Blokada pojedynczego rekordu daje zwykle większą swobodę innym operacjom, natomiast blokada tabeli upraszcza kontrolę, lecz zatrzymuje znacznie szerszy zestaw działań.

Można porównać trzy podstawowe sytuacje. Przy blokadzie rekordu operacja modyfikująca jeden element nie musi zatrzymywać pracy z pozostałymi elementami tabeli. Przy blokadzie zakresu ograniczenie obejmuje większy fragment, na przykład rekordy spełniające warunek wyszukiwania. Przy blokadzie tabeli blokowany jest cały obiekt, więc nawet operacja dotycząca danych niezwiązanych z pierwotnym zakresem może zostać zmuszona do oczekiwania.

Istotne jest także rozróżnienie blokad współdzielonych i wyłącznych. Blokada współdzielona może pozwalać wielu operacjom na jednoczesny odczyt, o ile żadna z nich nie żąda modyfikacji. Blokada wyłączna rezerwuje zasób dla operacji zmieniającej dane. Eskalacja może dotyczyć różnych trybów blokad, dlatego sama informacja o tym, że objęta została tabela, nie wystarcza do oceny skutku. Należy sprawdzić, czy blokada uniemożliwia odczyt, modyfikację, zmianę struktury, czy tylko określony rodzaj współbieżnego dostępu.

Znaczenie ma też izolacja transakcji. Przy bardziej restrykcyjnym poziomie izolacji dłużej utrzymywane są blokady odczytu i modyfikacji, co zwiększa prawdopodobieństwo ich nagromadzenia. Przy mniej restrykcyjnych ustawieniach część odczytów może działać z mniejszym udziałem blokad, ale zmienia się sposób obserwowania danych w trakcie równoległych operacji. Ocena eskalacji powinna więc uwzględniać nie tylko samą tabelę, ale również typ transakcji, czas jej trwania i wymagany poziom spójności.

Eskalacja blokad do poziomu tabeli – typowe problemy i objawy

Najczęściej zauważalnym objawem jest nagłe wydłużenie czasu wykonywania operacji, które wcześniej działały płynnie. Odczyty mogą przechodzić w stan oczekiwania, aktualizacje mogą tworzyć kolejkę, a zadania wykonywane równolegle zaczynają kończyć się w innej kolejności. W monitoringu widoczne bywają zwiększone czasy odpowiedzi, większa liczba aktywnych transakcji oraz zależności pomiędzy procesem posiadającym blokadę a procesami oczekującymi.

Problem może pojawić się podczas masowej aktualizacji, usuwania dużej liczby rekordów, przebudowy danych albo wykonywania zapytania obejmującego szeroki zakres. Ryzyko rośnie, gdy transakcja pozostaje otwarta przez długi czas, ponieważ blokady są utrzymywane aż do zakończenia odpowiedniej fazy pracy. Dodatkowym czynnikiem może być niewłaściwie dobrany warunek wyszukiwania. Jeśli odczyt nie korzysta z odpowiedniego indeksu, system może przeglądać wiele rekordów, zakładać liczne blokady i ostatecznie uznać, że korzystniejsza będzie blokada wyższego poziomu.

Eskalacja może także zwiększyć ryzyko zakleszczenia. Do zakleszczenia dochodzi wtedy, gdy co najmniej dwie transakcje oczekują na zasoby zajęte przez siebie nawzajem. Przejście do blokady tabeli nie jest równoznaczne z zakleszczeniem, lecz większy zakres zajętego zasobu może ułatwić powstanie niekorzystnej zależności. W takiej sytuacji analizuje się kolejność odwołań do tabel, czas przetrzymywania blokad, kolejność modyfikowanych obiektów oraz komunikaty diagnostyczne.

Nie powinno się zakładać, że każda blokada tabeli jest przyczyną spowolnienia. Może być ona zamierzona, krótkotrwała i całkowicie zgodna z charakterem operacji. Diagnoza wymaga zestawienia czasu rozpoczęcia i zakończenia transakcji, rodzaju wykonywanego polecenia, planu działania, liczby przetwarzanych rekordów oraz informacji o innych operacjach uruchomionych w tym samym czasie.

Eskalacja blokad do poziomu tabeli – praktyczne wskazówki diagnostyczne

W pierwszej kolejności należy ustalić, jaki zasób został zablokowany, jaki jest tryb blokady oraz która transakcja ją posiada. Pomocne jest zebranie informacji o sesji wykonującej operację, czasie jej rozpoczęcia i aktualnym stanie. Warto również sprawdzić, czy oczekiwanie dotyczy odczytu, zapisu, zmiany struktury lub zatwierdzenia transakcji. Bez tych danych łatwo pomylić eskalację z przeciążeniem procesora, wolnym nośnikiem danych albo nieefektywnym planem wykonania.

Znaczenie ma skracanie transakcji. Zadania niezwiązane bezpośrednio z modyfikacją danych nie powinny być wykonywane pomiędzy rozpoczęciem a zatwierdzeniem transakcji, ponieważ przedłużają czas utrzymywania blokad. Należy także unikać oczekiwania na wejście użytkownika, operacji sieciowych i długich obliczeń wewnątrz transakcji. Im krótszy jest odcinek pracy objęty blokadą, tym mniejsza jest szansa, że wiele blokad zgromadzi się przed zatwierdzeniem.

W przypadku dużych zmian pomocne może być dzielenie operacji na mniejsze partie. Każda partia może zostać zakończona osobno, dzięki czemu zasoby są okresowo zwalniane. Trzeba jednak zachować ostrożność: zbyt małe partie zwiększają liczbę zatwierdzeń i narzutów, a zbyt duże nadal mogą prowadzić do długiego oczekiwania. Dobór wielkości partii powinien wynikać z obserwacji czasu wykonania, obciążenia i wymagań dotyczących spójności.

Należy sprawdzić indeksy oraz warunki łączenia i filtrowania danych. Dobrze dobrany indeks może ograniczyć liczbę przeglądanych rekordów, skrócić pracę transakcji i zmniejszyć liczbę zakładanych blokad. Nie powinno się jednak dodawać indeksów bez analizy, ponieważ każdy dodatkowy indeks zwiększa koszt modyfikacji danych i może wprowadzać własne zależności blokad.

Zmiany ustawień dotyczących eskalacji powinny być wykonywane dopiero po zebraniu danych. Wyłączenie mechanizmu lub wymuszenie szczegółowych blokad może poprawić współbieżność w jednym scenariuszu, lecz zwiększyć zużycie pamięci i narzut zarządzania w innym. Najpierw należy ustalić, czy źródłem problemu jest liczba blokad, czas trwania transakcji, nieefektywny plan, brak indeksu, nieprawidłowa kolejność operacji czy zbyt szeroki zakres modyfikacji.

Kiedy zgłosić eskalację blokad do poziomu tabeli do serwisu

Do serwisu warto zgłosić sytuację, w której blokady powtarzają się, utrudniają wykonywanie codziennych operacji albo prowadzą do przerw w pracy programu. Szczególnej uwagi wymaga stan, gdy po zakończeniu dużej operacji tabela nadal pozostaje niedostępna, procesy regularnie oczekują na ten sam zasób lub pojawiają się komunikaty o przekroczeniu czasu oczekiwania. Przydatne będzie zachowanie dokładnej godziny wystąpienia problemu, nazwy operacji, informacji o liczbie jednocześnie pracujących użytkowników oraz komunikatów wyświetlanych przez aplikację.

W ramach przygotowania do diagnozy nie należy przerywać przypadkowych procesów ani usuwać danych tylko dlatego, że widoczna jest blokada. Zakończenie niewłaściwej transakcji może przerwać prawidłową operację i utrudnić późniejsze ustalenie przyczyny. Bezpieczniej jest zebrać informacje diagnostyczne, zabezpieczyć kopię danych zgodnie z przyjętą procedurą i przekazać opis objawów osobie zajmującej się obsługą systemu.

W Warszawskim Pogotowiu Komputerowym 24/7 można zgłosić problem z działaniem komputera, aplikacji lub przechowywaniem danych, gdy eskalacja blokad powoduje wyraźne spowolnienia albo przestoje. Przy zgłoszeniu warto opisać, czy problem dotyczy jednej operacji, całej tabeli, konkretnego programu czy wszystkich użytkowników. Takie rozróżnienie ułatwia ocenę, czy przyczyny należy szukać w transakcji, konfiguracji, strukturze danych, indeksach, komunikacji pomiędzy procesami czy w ogólnym stanie urządzenia.