Gdy dochodzimy do ściany

Gdy problem pojawia się i znika

Niekiedy problemy wydajnościowe pojawiają się niespodziewanie i równie niespodziewanie znikają "same". Klienci aplikacji zauważają to jako okresowe i bardzo duże spadki wydajności, gdy to samo zapytanie wykonuje się kilka minut, zamiast "natychmiast". Gdy dokonuje się dokładnej analizy, widać, że baza okresowo zmienia plan wykonania zapytań. Problem dotyczy bazy od wersji 10, w wersji 9 i starszej występował rzadko. Wykrycie przyczyn zmian i wymuszenie obsługi zapytania likwiduje problem, ale wymaga to analizy pracy bazy przez dłuższy czas, by wychwycić nieprawidłowości.

O wiele trudniejszym problemem, który powoduje znaczące obniżenie wydajności bazy, jest przetwarzanie przez bazę Oracle niektórych typów zapytań zawierających osadzone wartości (literały). Takie kłopoty są bardzo trudne w analizie tradycyjnymi metodami, gdyż zdarza się radykalne zmniejszenie wydajności bazy spowodowane przez zestaw prostych zapytań w czasie dnia, podczas gdy za problem odpowiedzialne są również zapytania dużego przetwarzania wsadowego, realizowane na przykład nocą. Aplikacja dokonująca przetwarzania wsadowego w nocy uruchamiała zapytania z literałami, które zapełniały zasób shared pool, ale po zakończeniu pracy zapytania baza działała. Drugie zadanie, realizowane w południe, również zawierało zapytanie z literałami, ale tym razem generowało ono tak dużą kolejkę do shared pool, że baza praktycznie przestawała działać. Zmiana jednego z nich poprawiła znacząco wydajność i usunęła problem. Taka optymalizacja byłaby trudna do przeprowadzenia przez administratorów, ponadto jest wątpliwe, czy modernizacja sprzętu i dodanie nowych licencji na bazę danych usunęłoby problem.

Co można osiągnąć

Dokładna analiza zapytań i eliminacja zapełniania zasobów umożliwiła nie tylko poprawę wydajności istniejącej aplikacji, ale także zmniejszyła dwukrotnie liczbę rdzeni niezbędnych do sprawnej pracy pojedynczej instancji bazy. Dział IT w firmie miał już plan modernizacji do 128 rdzeni, a po optymalizacji bazy od czterech lat pracuje ona na 64 rdzeniach na tej samej maszynie, przy czym liczba przetwarzanych rekordów wzrosła w tym czasie czterokrotnie.

Optymalizacja w wielu przypadkach umożliwia zejście z liczbą rdzeni, na przykład ze 100 do 50 lub z 16 na 4, co przekłada się na duże oszczędności na kosztach licencji oraz wsparcia technicznego Oracle. W pewnych przypadkach firma może się zdecydować na wykorzystanie znacznie tańszych licencji Standard zamiast Enterprise, gdyż optymalizacja bazy sprawia, że opcje wymagające dotąd licencji klasy Enterprise nie będą już niezbędne do pracy aplikacji.

Niekiedy można nawet dokonać migracji z drogich środowisk, takich jak Itanium lub RS/6000, na tańsze serwery Intel x86 z zachowaniem wymagań pracy aplikacji. Migracja w niedużych środowiskach przynosi olbrzymie oszczędności związane z kosztami licencji na bazę danych.

Jak podjąć decyzję o usłudze z zewnątrz?

Istotnym problemem jest podejście firm do zaawansowanej optymalizacji. Menedżer IT nie zawsze może przekonać zarząd do inwestycji w usługę zewnętrzną, gdy w dziale pracuje na przykład 60 osób, włącznie z wysoko wykwalifikowanymi administratorami, ponadto zakontraktowano usługę wsparcia technicznego producenta aplikacji, który twierdzi, że wszystko opracowano zgodnie z przyjętymi zasadami. Niekiedy problemy spotyka się już na poziomie kierownika działu IT, który otrzymuje informacje z działu, że wszystkie niezbędne zabiegi optymalizacyjne już zostały wykonane. Przyczyną może być także przeciążenie pracą administratorów, którzy nie mają czasu zajmować się wydajnością pojedynczej aplikacji, obsługują wiele baz i są rozliczani z zupełnie innych działań. Takie wymagania są stawiane dostawcy, który zazwyczaj informuje, że wszystkie optymalizacje już zostały poprawnie wykonane.


TOP 200