Deadlock w bazach danych to prawdziwy koszmar
14/3/2024
Tomasz Chwasewicz
Deadlock występuje, gdy dwie lub więcej transakcji w systemie bazy danych utrzymuje blokady na zasobach, których potrzebują inni. Każda transakcja czeka, aż inni zwolnią swoje blokady i tak jak dwóch kierowców, którzy nie są pewni, kto ma prawo drogi, żaden nie może kontynuować.
Byłoby wspaniale móc wyliczyć przyczyny zakleszczeń i zająć się nimi wszystkimi. Niestety, jest to zbyt skomplikowane. Można jednak powiedzieć, że wynikają one przede wszystkim ze złego projektu aplikacji, braku odpowiedniego zarządzania transakcjami lub nieuniknionej złożoności wysoce współbieżnych systemów.
Transakcje, które blokują zasoby w niespójnych kolejnościach, są szczególnie podatne na zakleszczenia. Na przykład, jeśli transakcja A zablokuje zasób 1, a następnie spróbuje zablokować zasób 2, podczas gdy transakcja B zablokuje zasób 2, a następnie spróbuje zablokować zasób 1, dojdzie do zakleszczenia, jeśli obie transakcje wystąpią jednocześnie.
To ciekawa sprawa - Oracle nie robi tego, przynajmniej nie u podstaw. Zamiast zająć się sednem problemu, pozwala na wykonanie jednej transakcji i wycofuje drugą.
Gdy Oracle wykryje deadlock, nie pozostawia transakcji w zawieszeniu. Zamiast tego wybiera jedną z transakcji jako "ofiarę" i wycofuje ją, zwalniając zasoby, które zablokowała. To działanie pozwala innym transakcjom działać dalej. Decyzja o tym, która transakcja ma zostać wycofana, jest zazwyczaj oparta na wewnętrznych kryteriach mających na celu zminimalizowanie utraty pracy i utrzymanie integralności systemu.
Po rozwiązaniu impasu Oracle rejestruje incydent, generując błąd ORA-00600 w alertlogu wraz z plikiem śledzenia zawierającym szczegółowe informacje o sytuacji impasu. Ten plik śledzenia zawiera zaangażowane instrukcje SQL, zablokowane obiekty i identyfikatory transakcji, zapewniając cenny wgląd w diagnozowanie pierwotnej przyczyny zakleszczenia.
Deadlock to ogromne wyzwanie dla DBA, głównie ze względu na ich nieuchwytną naturę i złożoność związaną z ich diagnozowaniem i rozwiązywaniem. Dlaczego? - na to pytanie odpowiemy za chwilę.
Jednym z głównych powodów, dla których deadlocki są koszmarem dla DBA, jest ich niewidoczność dla programistów. Występują one głęboko w infrastrukturze bazy danych, zużywając zasoby serwera i wpływając na wydajność bazy danych bez widocznej przyczyny z warstwy aplikacji. Czyni to z nich upiorny problem: obecny i mający wpływ, ale trudny do wykrycia i wyeliminowania.
Problem niewidoczności jest potęgowany przez fakt, że martwe punkty są zazwyczaj objawem problemów na poziomie aplikacji - takich jak zły projekt lub zarządzanie transakcjami - manifestujących się w środowisku bazy danych. To stawia DBA na pierwszej linii frontu. Często są oni pierwszymi, którzy napotykają te problemy, ale ich pierwotna przyczyna leży w kodzie aplikacji, poza ich bezpośrednią kontrolą.
Replikacja i diagnozowanie zakleszczeń to kolejne wyzwanie. Dzieje się tak głównie dlatego, że są one trudne do przewidzenia i odtworzenia w środowisku nieprodukcyjnym. Zakleszczenia często wynikają z bardzo specyficznego czasu i sekwencji operacji, które trudno jest celowo naśladować. W lokalnym środowisku dewelopera, gdzie obciążenie i współbieżność są znacznie niższe niż w środowisku produkcyjnym, deadlock może nigdy się nie pojawić.
Ta nieprzewidywalność oznacza, że w 99,99% przypadków (źródło: Zaufaj nam) deweloperzy nie przewidują wystąpienia zakleszczeń. W rezultacie aplikacje często nie są projektowane z myślą o obsłudze zakleszczeń. Dlatego też czasami mamy do czynienia z dziwnymi, jednorazowymi błędami, które trudno jest powiązać z zakleszczeniem, co dodatkowo zaciemnia sprawę.
Kiedy pojawiają się zakleszczenia, mogą one powodować nieoczekiwane zachowanie aplikacji, prowadząc do błędów lub problemów z wydajnością, które są trudne do zdiagnozowania. Ponieważ aplikacja nie była przygotowana do obsługi zakleszczeń, problemy te mogą wydawać się przypadkowe, co prowadzi do frustrujących doświadczeń zarówno dla użytkowników, jak i zespołów technicznych próbujących je rozwiązać.
Co więcej, baza danych jest często obwiniana za te problemy spowodowane przez aplikację, stawiając DBA w trudnej sytuacji. Muszą oni nie tylko identyfikować i rozwiązywać symptomy impasu, ale także komunikować się z zespołami programistów w celu rozwiązania problemów w kodzie aplikacji.
Poświęćmy minutę ciszy wszystkim DBA, którzy obecnie zmagają się z deadlockami, ponieważ zazwyczaj niewiele mogą zrobić.
Kiedy dochodzi do deadlocków, DBAs mają ręce związane przez ograniczenia systemów zarządzania bazami danych. To, co mogą zrobić, obejmuje generowanie i analizowanie obszernych dzienników, które rejestrują najdrobniejsze transakcje bazy danych. Logi te, często ogromnych rozmiarów, są kluczem do zrozumienia impasu. Klucz nie jest jednak dostarczany z zamkiem ani instrukcją obsługi. Nie oferuje bezpośredniego rozwiązania problemu.
Oczywiście, doświadczeni DBA mają własne zestawy skryptów do diagnozowania i rozwiązywania takich przypadków, ale jest to niemal wiedza tajemna.
Wśród ograniczonych dostępnych sposobów interwencji, jednym z najbardziej zdecydowanych działań, jakie może podjąć DBA, jest zakończenie sesji zaangażowanych w deadlock. Ten drastyczny środek, opisany przez eksperta baz danych Jonathana Lewisa, polega na wybraniu transakcji "ofiary" do wycofania, przerywając w ten sposób impas i umożliwiając kontynuowanie innych transakcji.
Wybór sesji do zakończenia nie jest wyborem łatwym. Wymaga starannego rozważenia pracy utraconej w wyniku wycofania transakcji oraz potencjalnego wpływu na cały system i operacje biznesowe. Czasami decyzja jest jednoznaczna, na przykład gdy jedna transakcja znacznie przewyższa inną pod względem czasu przetwarzania lub znaczenia. Innym razem jest to decyzja podjęta pod presją utrzymania integralności systemu i zminimalizowania zakłóceń.
Wśród wielu funkcji DBPLUS PERFORMANCE MONITORa, zakładki "Locks" i "Logs" mogą być bardzo przydatne, jeśli chodzi o analizę scenariuszy zakleszczeń.
