Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.
Data publikacji: 04-02-2021 | Autor: | Kamil Stawiarski |
Podstawą wydajnego systemu informatycznego jest w wielu przypadkach sprawnie działająca baza danych – dla większości dużych instytucji nadal oznacza to Oracle RDBMS. Sprawdźmy zatem, w jaki sposób dokonać audytu wydajności serwera, a także prześledźmy najlepsze praktyki w zakresie jego optymalizacji.
Audyty wydajnościowe środowiska o takim stopniu złożoności mogą wydawać się skomplikowane – zwłaszcza w obliczu braku licencji na Oracle Diagnostic Pack. Podobnie względu na podnoszone ograniczenia bezpieczeństwa, utrudniony jest coraz częściej także dostęp do graficznej reprezentacji wyników ASH. W tym artykule omówimy, w jaki sposób wygodnie rozpocząć analizę wydajnościową środowiska Oracle na podstawie raportów AWR lub Statspack.
> GENEROWANIE RAPORTÓW
W pierwszej kolejności należy wygenerować raporty Statspack lub AWR. Domyślnie raz na godzinę tworzone są migawki z widoków przechowujących statystyki wydajnościowe oraz dane zdarzeń oczekiwania. Każdy raport Statspack/AWR zawiera informacje wyliczone na podstawie delty dwóch migawek. Im dalej od siebie znajdują się migawki w czasie, tym trudniej zinterpretować dane raportu i zidentyfikować problem wydajnościowy. Dla prawidłowej wizualizacji i identyfikacji problemu należy wygenerować jak najwięcej raportów z jak najwęższej delty. Można w tym celu użyć jednego ze skryptów dostępnych na GitHubie: gen_statspack_reps.sh dostępnego pod adresem bit.ly/2LHX64l lub awr-generator.sql dostępnego pod adresem bit.ly/39kgw7H.
Po wygenerowaniu zestawu raportów uzyskujemy np. 648 plików do analizy. Kolejnym problemem jest identyfikacja tego pliku, którego analiza da nam najwięcej informacji i pomoże rozwiązać problem. W tym celu, w zależności od typu raportów do analizy, posłużymy się narzędziem statspack_analyzer.py (bit.ly/2LpKb7r) lub awr_analyzer.py (bit.ly/38vFT7s). Każde z narzędzi wygeneruje interaktywny raport HTML, dzięki któremu można zidentyfikować piki wydajnościowe i skorelować wysokie oczekiwania w poszczególnych klasach zdarzeń z modelem czasu bazy lub statystykami instancji.
Klasy zdarzeń oczekiwania zawierają zbiór statystyk o nazwie wait event, które są częścią znakomitej instrumentacji bazy danych Oracle i mówią o tym, na jakie zewnętrzne zasoby oczekuje sesja w bazie danych. Może to być odczyt dyskowy, oczekiwanie na blokady transakcyjne lub zakleszczenie na poziomie pamięci współdzielonej.
> INTERPRETACJA WIZUALIZACJI RAPORTÓW
Przykładowa analiza wizualizacji raportów Statspack oraz AWR przedstawiona została na rys. 1. Pierwsze dwie sekcje są bardzo ważne w interpretacji ogólnego stanu wydajnościowego serwera bazodanowego. Jak widać, zakres raportów został wygenerowany na podstawie dwóch tygodni pracy bazy, która korzysta z 14 procesorów. Pierwszy wykres zawiera informacje dotyczące czasu oczekiwania w poszczególnych klasach zdarzeń oczekiwania. Widzimy, że zazwyczaj najmocniejsze oczekiwania są w klasach:
Drugi wykres pokazuje różnice w wartościach DB Time oraz DB CPU. DB Time świadczy o liczbie sesji pracujących równolegle na bazie danych, a porównanie z DB CPU pozwala określić, czy sesje pracują aktywnie na procesorze, czy też oczekują na zewnętrzne zasoby. Im większa różnica w tych dwóch wartościach, tym większe oczekiwanie zamiast aktywnej pracy.
[...]
Laureat Oracle ACE Director i członek stowarzyszenia Oracle OakTable zrzeszającego ok. 100 najlepszych specjalistów na świecie.
Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.
Transmisje online zapewnia: StreamOnline