Problemy z wydajnością rzadko występują w izolacji. Często pojedynczy problem może wywołać kaskadę powiązanych problemów, z których każdy potęguje ogólny wpływ na system. Niniejsze studium przypadku analizuje taki scenariusz w bazie danych T10 na g1rush Server.

Identyfikacja początkowego problemu: Przepełnienie tymczasowej przestrzeni tabel

W dniu 21 czerwca 2024 r. o godzinie 13:04:32, DBPLUS PERFORMANCE MONITOR oflagował krytyczny błąd: ORA-1652, wskazujący na niemożność rozszerzenia segmentu tymczasowego o 128 w przestrzeni tabel TEMPORARY_DATA w bazie danych T10 na g1rush Server. Błąd ten wystąpił z powodu jednoczesnych sesji przytłaczających tymczasową przestrzeń tabel, zużywając ponad 30 GB.

Podkreślony na wykresie skokowy wzrost wykorzystania zasobów natychmiast zwrócił uwagę firmy. Przepełnienie to zakłócało bieżące operacje i wskazywało na nieefektywne zarządzanie zasobami.

Problem drugorzędny: Wysokie obciążenie procesora

Dalsze dochodzenie ujawniło utrzymujące się wysokie obciążenie procesora, nawet po zmniejszeniu liczby aktywnych procesów. Cykliczny charakter tego obciążenia, osiągający szczyt w okresach wysokiej aktywności, sugerował głębsze problemy z optymalizacją zapytań i alokacją zasobów.

Powyższy wykres przedstawia czas zajętości (CPU), czas systemowy (CPU) i czas użytkownika (CPU) z wyraźnym wzorcem cyklicznych szczytów. To utrzymujące się wysokie obciążenie wymagało od nas zagłębienia się w konkretne zapytania i procesy zużywające zasoby procesora.

Szczegółowa analiza zapytań: Czas wykonania i zmiany planu

Następnym krokiem było przeanalizowanie konkretnych zapytań przyczyniających się do wysokiego obciążenia procesora. W szczególności zapytanie o identyfikatorze 3445255751 wykazało znaczące zmiany w czasie wykonania i planie. Podejrzewano, że zmiany te były związane z wydłużonym czasem wykonania innego zapytania, ID 904000402, ze względu na użycie funkcji współdzielonej.

Analiza wykazała, że zapytanie 3445255751 doświadczyło wahań czasu wykonania, co miało wpływ na ogólną wydajność. Porównując plany wykonania, zidentyfikowaliśmy hash planu 232983816 jako potencjalną przyczynę nieefektywności.

To porównanie podkreśliło potrzebę ustabilizowania wydajności zapytania poprzez wymuszenie określonego planu. Zmiana strategii wykonania zasugerowała potrzebę konsekwentnego monitorowania i terminowego dostosowywania planów.

Obciążenie sieci

Kontynuując nasze dochodzenie, zauważyliśmy znaczne obciążenie sieci, przy transferach danych sięgających nawet 52 GB w ciągu godziny. Wskazywało to na znaczny przepływ danych, co mogło zaostrzyć zaobserwowane problemy z wydajnością.

Analiza ruchu sieciowego wykazała dużą ilość bajtów odbieranych i wysyłanych przez SQL*Net, podkreślając wpływ transferu danych na ogólną wydajność.