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



23.09.2021

5 edycja konferencji Test...

21 października startuje kolejna, piąta już edycja największej w Polsce konferencji...
23.09.2021

Zero Trust Firewall

FortiGate 3500F
23.09.2021

Ochrona IoT

Kaspersky SHS
23.09.2021

Wydatki lobbingowe

Cyfrowy monopol
23.09.2021

Współdziałanie klastrów

SUSE Rancher 2.6
23.09.2021

Panasonic TOUGHBOOK 55

Najnowsza wersja wszechstronnego Panasonic TOUGHBOOK 55 to wytrzymały notebook typu...
23.09.2021

Elastyczna dystrybucja...

Liebert RXA i MBX
23.09.2021

Zdalny podgląd w 360°

D-Link DCS-8635LH
23.09.2021

Sejf na dane

Szyfrowany pendrive

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"