Tym krótkim postem chciałbym rozwiać jedno nieporozumienie związane z analizą baz danych AWR działających na platformie Oracle Exadata. Od prawie 10 lat nieustannie spotykam się z pytaniem: jaki jest wkład Exadata Software w produktywność? Lub używając nowo wymyślonych słów: jak „ekspercka” jest praca konkretnej bazy danych?
Często, moim zdaniem, odpowiedź na to właściwe pytanie jest błędna w odniesieniu do statystyk AWR. Przedstawia metodę oczekiwania systemu, która traktuje czas odpowiedzi jako sumę czasu pracy procesorów (DB CPU) i czasu oczekiwania różnych klas.
Wraz z pojawieniem się Exadata w statystykach AWR pojawiły się specyficzne oczekiwania systemowe związane z działaniem Exadata Software. Z reguły nazwy takich oczekiwań zaczynają się od słowa „komórka” (serwer Exadata Storage nazywany jest komórką), z czego najczęściej spotykane są oczekiwania o oczywistych nazwach „komórka inteligentne skanowanie tabeli”, „komórka multiblok odczyt fizyczny” i „fizyczny odczyt pojedynczego bloku komórki”.
W większości przypadków udział takich oczekiwań Exadata w całkowitym czasie odpowiedzi jest niewielki i dlatego nie mieszczą się one nawet w sekcji 10 najpopularniejszych zdarzeń na pierwszym planie według całkowitego czasu oczekiwania (w tym przypadku należy ich szukać w sekcji Czekanie na pierwszym planie sekcja Wydarzenia). Z wielkim trudem znaleźliśmy przykład dziennego AWR od naszych klientów, w którym oczekiwania Exadata znalazły się w sekcji Top10 i łącznie wyniosły około 5%:
wydarzenie
Czeka
Całkowity czas oczekiwania (s)
Średnio czekaj
Czas %DB
Klasa czekania
Procesor DB
115.2 tysięcy
70.4
SQL*Net więcej danych z dblink
670,196
5471.5
8.16ms
3.3
Sieć
Fizyczny odczyt pojedynczego bloku komórki
5,661,452
3827.6
676.07us
2.3
We/wy użytkownika
Zsynchronizuj przywracanie równowagi ASM
4,350,012
3481.3
800.30us
2.1
Inne
Fizyczny odczyt wieloblokowy komórki
759,885
2252
2.96ms
1.4
We/wy użytkownika
bezpośredni odczyt ścieżki
374,368
1811.3
4.84ms
1.1
We/wy użytkownika
Komunikat SQL*Net z dblink
7,983
1725
216.08ms
1.1
Sieć
inteligentne skanowanie tabeli komórek
1,007,520
1260.7
1.25ms
0.8
We/wy użytkownika
ścieżka bezpośrednia odczyt temp
520,211
808.4
1.55ms
0.5
We/wy użytkownika
enq: TM - rywalizacja
652
795.8
1220.55ms
0.5
Zastosowanie
Z takich statystyk AWR często wyciąga się następujące wnioski:
1. Udział Exadata magic w wydajności bazy danych nie jest duży – nie przekracza 5%, a baza danych słabo „egzadatyzuje”.
2. Jeśli taka baza danych zostanie przeniesiona z Exadata na klasyczną architekturę „serwer + macierz”, wówczas wydajność nie ulegnie dużej zmianie. Bo nawet jeśli ta macierz okaże się trzykrotnie wolniejsza od systemu pamięci masowej Exadata (co jest mało możliwe w przypadku nowoczesnych macierzy All Flash), to mnożąc 5% przez trzy otrzymamy wzrost udziału I/O czeka do 15% - baza danych na pewno to przetrwa!
Obydwa te wnioski są nietrafne, ponadto wypaczają zrozumienie idei Exadata Software. Exadata nie tylko zapewnia szybkie operacje we/wy, ale działa zasadniczo inaczej w porównaniu z klasyczną architekturą serwer + macierz. Jeśli działanie bazy danych jest rzeczywiście „dostosowane”, wówczas logika SQL jest przesyłana do systemu pamięci masowej. Serwery Storage, dzięki szeregowi specjalnych mechanizmów (przede wszystkim Exadata Storage Indexs, ale nie tylko), same wyszukują potrzebne dane i wysyłają bazę danych do serwerów. Robią to dość sprawnie, dlatego udział typowych oczekiwań Exadaty w całkowitym czasie odpowiedzi jest niewielki.
Jak zmieni się ten udział poza Exadata? Jak wpłynie to na wydajność bazy danych jako całości? Testowanie najlepiej odpowie na te pytania. Na przykład oczekiwanie na „inteligentne skanowanie tabeli komórek” poza Exadata może przerodzić się w tak intensywne pełne skanowanie tabeli, że operacje we/wy zajmują cały czas odpowiedzi, a wydajność drastycznie spada. Dlatego też błędem jest, analizując AWR, uwzględnianie całkowitego procentu oczekiwań Exadata jako wkładu jej magii w wydajność, a tym bardziej wykorzystywanie tego procentu do przewidywania wydajności poza Exadata. Aby zrozumieć, jak „dokładne” jest działanie bazy danych, należy przestudiować statystyki AWR w sekcji „Statystyki aktywności instancji” (jest wiele statystyk o oczywistych nazwach) i porównać je ze sobą.
Aby zrozumieć, jak będzie się zachowywać baza danych poza Exadata, najlepiej utworzyć klon bazy danych z kopii zapasowej w docelowej architekturze i przeanalizować wydajność tego klonu pod obciążeniem. Właściciele Exadata z reguły mają taką możliwość.
Autor: Aleksiej Struczenko, szef działu baz danych Jet Infosystems
Źródło: www.habr.com