Chciałbym rozwiać pewne nieporozumienie dotyczące analizy baz danych AWR działających na Oracle Exadata. Od prawie 10 lat zadaję sobie to samo pytanie: jaki jest wkład oprogramowania Exadata w wydajność? Albo używając nowo utworzonych słów: na ile „ekzadatuje” działanie danej bazy danych?
Często na to poprawne pytanie, moim zdaniem, udziela się błędnej odpowiedzi, odwołując się do statystyki AWR. Zawiera ona metodę systemowych oczekiwań, traktującą czas odpowiedzi jako sumę czasu pracy procesorów (DB CPU) i czasu oczekiwania różnych klas.
Wraz z pojawieniem się Exadata w statystyce AWR pojawiły się specyficzne oczekiwania systemowe związane z działaniem oprogramowania Exadata. Zazwyczaj nazwy takich oczekiwań zaczynają się od słowa “cell” (komórka to serwer pamięci Exadata), z których najczęściej występują oczekiwania o mówiących nazwach „cell smart table scan”, „cell multiblock physical read” i „cell single block physical read”.
W większości przypadków udział takich oczekiwań Exadata w całkowitym czasie odpowiedzi jest niewielki i dlatego nawet nie trafiają one do sekcji Top10 Foreground Events by Total Wait Time (w takim przypadku należy ich szukać w sekcji Foreground Wait Events). Z trudnością znaleźliśmy u naszych klientów przykład dobowego AWR, w którym oczekiwania Exadata znalazły się w sekcji Top10 i w sumie wyniosły około 5%:
Zdarzenie
Oczekiwania
Łączny czas oczekiwania (sek.)
Średnie oczekiwanie
% czasu DB
Klasa oczekiwania
DB CPU
115.2K
70.4
SQL*Net więcej danych z dblink
670,196
5471.5
8.16ms
3.3
Sieć
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Użytkownik I/O
Sync ASM rebalance
4,350,012
3481.3
800.30us
2.1
Inne
cell multiblock physical read
759,885
2252
2.96ms
1.4
Użytkownik I/O
bezpośrednie odczyty ścieżki
374,368
1811.3
4.84ms
1.1
Użytkownik I/O
SQL*Net wiadomość z dblink
7,983
1725
216.08ms
1.1
Sieć
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Użytkownik I/O
bezpośrednie odczyty ścieżki temp
520,211
808.4
1.55ms
0.5
Użytkownik I/O
enq: TM — kontencja
652
795.8
1220.55ms
0.5
Application
Na podstawie podobnej statystyki AWR często wyciąga się takie wnioski:
1. Wkład magii Exadata w wydajność bazy danych nie jest wysoki — nie przekracza 5 %, a baza danych „ekzadatuje” źle.
2. Jeśli taką bazę przenieść z Exadata na klasyczną architekturę „serwer + macierz”, wydajność nie zmieni się znacząco. Ponieważ nawet jeśli ta macierz okaże się trzy razy wolniejsza od systemu przechowywania Exadata (co jest mało prawdopodobne dla współczesnych macierzy All Flash), to mnożąc 5% przez trzy, otrzymamy wzrost udziału oczekiwań wejścia-wyjścia do 15% — taka baza danych na pewno to przetrwa!
Oba te wyjścia są niedokładne, a co więcej, zniekształcają zrozumienie idei zawartej w oprogramowaniu Exadata. Exadata nie tylko zapewnia szybki wprowadzanie-wyprowadzanie, działa zasadniczo inaczej niż klasyczna architektura „serwer + macierz”. Jeśli praca bazy danych rzeczywiście „ekzadatizuje się” — to na system przechowywania przenoszona jest logika SQL. Storage serwery dzięki szeregowi specjalnych mechanizmów (w pierwszej kolejności Exadata Storage Indexes, ale nie tylko) same znajdują potrzebne dane i przesyłają je do serwerów DB. Robią to wystarczająco efektywnie, dlatego udział charakterystycznych oczekiwań Exadata w ogólnym czasie reakcji jest niewielki.
Jak zmieni się ten udział poza Exadata? Jak wpłynie to na wydajność bazy danych w ogóle? Najlepiej na te pytania odpowie testowanie. Na przykład oczekiwanie „cell smart table scan” poza Exadata może przekształcić się w tak ciężkie pełne skanowanie tabeli, że wprowadzanie-uwalnianie zajmie cały czas reakcji, a wydajność dramatycznie spadnie. Dlatego błędnie jest w analizie AWR uważać całkowity procent oczekiwań Exadata jako wkład jej magii w wydajność, a tym bardziej używać tego procentu do prognozowania wydajności poza Exadata. Aby zrozumieć, jak bardzo „ekzadatizowana” jest praca bazy, trzeba badać statystyki AWR w sekcji „Instance Activity Stats” (jest tam wiele statystyk z wymownymi nazwami) i porównywać je ze sobą.
Aby zrozumieć, jak będzie się czuła baza danych poza Exadata, najlepiej jest stworzyć klon bazy z kopii zapasowej na docelowej architekturze i przeanalizować wydajność tego klonu pod obciążeniem. Taka możliwość zazwyczaj mają posiadacze Exadata.
Autor: Aleksey Struchenkо, kierownik działu Bazy Danych „Infosystemy Jet”
Źródło: habr.com
