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



08.02.2021

Malwarebytes bezpieczne

Pokłosie Sunburst
08.02.2021

Microsoft i Linux

Endpoint Detection and Response
08.02.2021

Bezpieczeństwo chmury

Bitdefender Security for AWS
05.02.2021

Google ogranicza

Koniec z synchronizacją
05.02.2021

Intel NUC 11 Pro Mini PC

Intel poszerzył swoją linię miniaturowych komputerów klasy NUC do zastosowań biznesowych.
05.02.2021

Aktualizacja Dynabooków

Tecra A30-J oraz Satellite Pro: C40 i L50-J
04.02.2021

Punkty Wi-Fi 6

D-Link AX3600 i AX1800
04.02.2021

Inteligentny monitoring

QNAP Guardian PoE QGD-3014-16PT
04.02.2021

Secure SD-WAN dla OT

FortiGate Rugged 60F

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.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

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