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



29.04.2021

KasperskyOS

Podczas targów Hannover Messe zaprezentowano rozwiązanie Kaspersky IoT Secure Gateway 100...
29.04.2021

Serwery OVHcloud

Scale i High-Grade
29.04.2021

NaaS od Cisco

Cisco Plus
29.04.2021

Inwestycja Google'a w Polsce

Google Cloud
29.04.2021

Usługa od AWS i RedHata

ROSA
29.04.2021

Samsung

Samsung prezentuje nowe serie monitorów dla biznesu i profesjonalistów.
29.04.2021

Tęczowe Maki

iMac na M1
29.04.2021

Polska drukarka 3D

Zmorph i500
29.04.2021

W ekosystemie Microsoftu

Surface Laptop 4

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"