Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



01.06.2021

Monitory interaktywne Newline...

Na rynek trafiły nowe monitory interaktywne Newline MIRA stanowiące kompletne narzędzia...
27.05.2021

Anywhere Workspace

VMware wprowadza rozwiązanie Anywhere Workspace
27.05.2021

Narzędzie SaaS

Lenovo Device Intelligence Plus
27.05.2021

Nowa fala przetwarzania edge

Red Hat Edge
27.05.2021

Wirtualny router od QNAP-a

QuWAN vRouter
27.05.2021

Ochrona endpointów

Cisco SASE
27.05.2021

Monitor graficzny

Monitor graficzny PD2725U od BenQ zaprojektowany jest z myślą o wygodnej pracy...
27.05.2021

Monitoring wizyjny

D-Link Vigilance
27.05.2021

Moc i elastyczność

Liebert EXM2

Audyt wydajności serwera bazodanowego Oracle

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:

 

  • CONCURRENCY – klasie, która zawiera oczekiwania dotyczące blokad na poziomie obszaru współdzielonego; bardzo często dotyczy problemów z parsowaniem zapytań, co powoduje zakładanie muteksów lub latchy, może też być związana z nadmiernym skanowaniem bloków danych w buffer cache;
  • APPLICATION – w tej klasie znajdują się wszystkie oczekiwania związane z problemami aplikacyjnymi, np. blokady transakcyjne czy blokady dotyczące błędów w architekturze systemu;
  • User I/O – tu zgromadzone są wszystkie oczekiwania na podsystem dyskowy, np. odczyty pojedynczego bloku, odczyty wieloblokowe buforowane, odczyty wieloblokowe bezpośrednie;•Network – nadmierne oczekiwania w tej klasie mogą świadczyć o problemach sieciowych lub wywołaniu wielu zewnętrznych serwisów z poziomu bazy danych;


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

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"