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.
Jak Oracle rozwiązuje problem współbieżnych zmian?
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.
Dylemat DBA
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ę.
Niewidzialny wróg
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ą.
Wyzwanie związane z replikacją i diagnostyką
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ę.
Operacyjny koszmar
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.
Jak radzić sobie z zakleszczeniami?
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.
Zakończenie sesji
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ń.
DBPLUS odpowiada na potrzeby administratorów baz danych
Wśród wielu funkcji DBPLUS PERFORMANCE MONITORa, zakładki „Locks” i „Logs” mogą być bardzo przydatne, jeśli chodzi o analizę scenariuszy zakleszczeń.
Podstawowe funkcje DBPLUS w zarządzaniu zakleszczeniami:
- Zakładka „Locks”: umożliwia użytkownikom przeglądanie kompleksowej historii blokad. Lista obejmuje blokady tabel, blokady bibliotek i określone zablokowane obiekty.
- Prezentacja wizualna: Wykresy i diagramy, takie jak te pokazujące liczbę zablokowanych sesji i całkowity czas trwania blokady, pomagają w zrozumieniu problemu, który spowodował deadlock. Chociaż te wizualizacje sugerują prostotę rozwiązania, prawdziwe rozwiązanie często leży w głębszym przeprojektowaniu aplikacji.
- Zakładka „Logs”: Dostęp do alertlogu Oracle poprzez DBPLUS dostarcza danych bez potrzeby bezpośredniego dostępu do serwera. Ta funkcja jest szczególnie przydatna do diagnozowania problemów po incydencie, koncentrując się na wpisach błędów, takich jak ORA-00600, aby lepiej zrozumieć i zapobiegać przyszłym zakleszczeniom.
Kluczowe punkty w zakładce „Locks”:
- Overview: Przedstawia kartę i jej przeznaczenie.
- Locked Sessions Chart: Wyświetla liczbę aktualnie zablokowanych sesji.
- Total Lock Duration Chart: Pokazuje łączny czas trwania blokad we wszystkich sesjach.
- Blocking and Blocked Session Details: Dostarcza informacji o sesjach powodujących i dotkniętych blokadami.
- SQL of Blocked Session: Lista poleceń SQL zaangażowanych w zablokowaną sesję.
- Detailed Session Information: Oferuje szczegółowe informacje o sesjach zaangażowanych w impas.
Additional Features:
- Locked Objects Screen: Przedstawia, które obiekty są aktualnie zablokowane, zwiększając zrozumienie źródeł zakleszczeń.
- Session Termination Capability: Autoryzowani użytkownicy mogą kończyć sesje bezpośrednio w DBPLUS, aby szybko rozwiązywać zakleszczenia, chociaż ta opcja jest zwykle domyślnie wyłączona.
- Oracle Alertlog Access: Ułatwia przeglądanie dzienników alertów Oracle z ostatnich 30 dni z naciskiem na wpisy błędów, pomagając w szczegółowej analizie incydentów zakleszczenia
