![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nChcia\u0142bym rozwia\u0107 pewne nieporozumienie dotycz\u0105ce analizy baz danych AWR dzia\u0142aj\u0105cych na Oracle Exadata. Od prawie 10 lat zadaj\u0119 sobie to samo pytanie: jaki jest wk\u0142ad oprogramowania Exadata w wydajno\u015b\u0107? Albo u\u017cywaj\u0105c nowo utworzonych s\u0142\u00f3w: na ile \u201eekzadatuje\u201d dzia\u0142anie danej bazy danych?<\/p>\n
<\/p>\n
Cz\u0119sto na to poprawne pytanie, moim zdaniem, udziela si\u0119 b\u0142\u0119dnej odpowiedzi, odwo\u0142uj\u0105c si\u0119 do statystyki AWR. Zawiera ona metod\u0119 systemowych oczekiwa\u0144, traktuj\u0105c\u0105 czas odpowiedzi jako sum\u0119 czasu pracy procesor\u00f3w (DB CPU) i czasu oczekiwania r\u00f3\u017cnych klas.<\/p>\n
Wraz z pojawieniem si\u0119 Exadata w statystyce AWR pojawi\u0142y si\u0119 specyficzne oczekiwania systemowe zwi\u0105zane z dzia\u0142aniem oprogramowania Exadata. Zazwyczaj nazwy takich oczekiwa\u0144 zaczynaj\u0105 si\u0119 od s\u0142owa \u201ccell\u201d (kom\u00f3rka to serwer pami\u0119ci Exadata), z kt\u00f3rych najcz\u0119\u015bciej wyst\u0119puj\u0105 oczekiwania o m\u00f3wi\u0105cych nazwach \u201ecell smart table scan\u201d, \u201ecell multiblock physical read\u201d i \u201ecell single block physical read\u201d.<\/p>\n
W wi\u0119kszo\u015bci przypadk\u00f3w udzia\u0142 takich oczekiwa\u0144 Exadata w ca\u0142kowitym czasie odpowiedzi jest niewielki i dlatego nawet nie trafiaj\u0105 one do sekcji Top10 Foreground Events by Total Wait Time (w takim przypadku nale\u017cy ich szuka\u0107 w sekcji Foreground Wait Events). Z trudno\u015bci\u0105 znale\u017ali\u015bmy u naszych klient\u00f3w przyk\u0142ad dobowego AWR, w kt\u00f3rym oczekiwania Exadata znalaz\u0142y si\u0119 w sekcji Top10 i w sumie wynios\u0142y oko\u0142o 5%:<\/p>\n
Zdarzenie<\/strong><\/p>\n Oczekiwania<\/strong><\/p>\n \u0141\u0105czny czas oczekiwania (sek.)<\/strong><\/p>\n \u015arednie oczekiwanie<\/strong><\/p>\n % czasu DB<\/strong><\/p>\n Klasa oczekiwania<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net wi\u0119cej danych z dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Sie\u0107<\/p>\n cell single block physical read<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676.07us<\/p>\n 2.3<\/p>\n U\u017cytkownik I\/O<\/p>\n Sync ASM rebalance<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800.30us<\/p>\n 2.1<\/p>\n Inne<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n U\u017cytkownik I\/O<\/p>\n bezpo\u015brednie odczyty \u015bcie\u017cki<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n U\u017cytkownik I\/O<\/p>\n SQL*Net wiadomo\u015b\u0107 z dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Sie\u0107<\/p>\n cell smart table scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1.25ms<\/p>\n 0.8<\/p>\n U\u017cytkownik I\/O<\/p>\n bezpo\u015brednie odczyty \u015bcie\u017cki temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n U\u017cytkownik I\/O<\/p>\n enq: TM \u2014 contention<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220.55ms<\/p>\n 0.5<\/p>\n Application<\/p>\n Na podstawie podobnej statystyki AWR cz\u0119sto wyci\u0105ga si\u0119 takie wnioski:<\/p>\n 1. Wk\u0142ad magii Exadata w wydajno\u015b\u0107 bazy danych jest niewielki \u2014 nie przekracza 5%, a bazy danych \u017ale si\u0119 \"ekzadatyzuje\".<\/p>\n 2. Je\u015bli tak\u0105 baz\u0119 przeniesiemy z Exadata na klasyczn\u0105 architektur\u0119 \"serwer + macierz\", wydajno\u015b\u0107 nie zmieni si\u0119 znacz\u0105co. Nawet je\u015bli ta macierz oka\u017ce si\u0119 trzykrotnie wolniejsza ni\u017c system przechowywania Exadata (co jest ma\u0142o prawdopodobne w przypadku nowoczesnych macierzy All Flash), to mno\u017c\u0105c 5% przez trzy, otrzymamy zwi\u0119kszenie kwestii oczekiwa\u0144 I\/O do 15% \u2014 tak\u0105 baz\u0119 danych na pewno przetrwa!<\/p>\n Oba te wyj\u015bcia s\u0105 niedok\u0142adne, a co wi\u0119cej, zniekszta\u0142caj\u0105 zrozumienie idei zawartej w oprogramowaniu Exadata. Exadata nie tylko zapewnia szybki wprowadzanie-wyprowadzanie, dzia\u0142a zasadniczo inaczej ni\u017c klasyczna architektura \u201eserwer + macierz\u201d. Je\u015bli praca bazy danych rzeczywi\u015bcie \u201eekzadatizuje si\u0119\u201d \u2014 to na system przechowywania przenoszona jest logika SQL. Storage serwery<\/a> dzi\u0119ki szeregowi specjalnych mechanizm\u00f3w (w pierwszej kolejno\u015bci Exadata Storage Indexes, ale nie tylko) same znajduj\u0105 potrzebne dane i przesy\u0142aj\u0105 je do serwer\u00f3w DB. Robi\u0105 to wystarczaj\u0105co efektywnie, dlatego udzia\u0142 charakterystycznych oczekiwa\u0144 Exadata w og\u00f3lnym czasie reakcji jest niewielki. <\/p>\n Jak zmieni si\u0119 ten udzia\u0142 poza Exadata? Jak wp\u0142ynie to na wydajno\u015b\u0107 bazy danych w og\u00f3le? Najlepiej na te pytania odpowie testowanie. Na przyk\u0142ad oczekiwanie \u201ecell smart table scan\u201d poza Exadata mo\u017ce przekszta\u0142ci\u0107 si\u0119 w tak ci\u0119\u017ckie pe\u0142ne skanowanie tabeli, \u017ce wprowadzanie-uwalnianie zajmie ca\u0142y czas reakcji, a wydajno\u015b\u0107 dramatycznie spadnie. Dlatego b\u0142\u0119dnie jest w analizie AWR uwa\u017ca\u0107 ca\u0142kowity procent oczekiwa\u0144 Exadata jako wk\u0142ad jej magii w wydajno\u015b\u0107, a tym bardziej u\u017cywa\u0107 tego procentu do prognozowania wydajno\u015bci poza Exadata. Aby zrozumie\u0107, jak bardzo \u201eekzadatizowana\u201d jest praca bazy, trzeba bada\u0107 statystyki AWR w sekcji \u201eInstance Activity Stats\u201d (jest tam wiele statystyk z wymownymi nazwami) i por\u00f3wnywa\u0107 je ze sob\u0105.<\/p>\n Aby zrozumie\u0107, jak b\u0119dzie si\u0119 czu\u0142a baza danych poza Exadata, najlepiej jest stworzy\u0107 klon bazy z kopii zapasowej na docelowej architekturze i przeanalizowa\u0107 wydajno\u015b\u0107 tego klonu pod obci\u0105\u017ceniem. Taka mo\u017cliwo\u015b\u0107 zazwyczaj maj\u0105 posiadacze Exadata.<\/p>\n