Med detta korta inlägg skulle jag vilja skingra ett missförstånd relaterat till analysen av AWR-databaser som körs på Oracle Exadata. I nästan 10 år har jag ständigt ställts inför frågan: vad är Exadata Softwares bidrag till produktiviteten? Eller genom att använda nyligen myntade ord: hur "expert" är arbetet i en viss databas?
Ofta besvaras denna korrekta fråga, enligt min mening, felaktigt med hänvisning till AWR-statistik. Den presenterar systemets väntemetod, som behandlar svarstid som summan av drifttiden för processorer (DB-CPU) och väntetiden för olika klasser.
Med tillkomsten av Exadata dök specifika systemförväntningar relaterade till driften av Exadata Software upp i AWR-statistiken. Som regel börjar namnen på sådana väntar med ordet "cell" (Exadata Storage-servern kallas en cell), varav de vanligaste är väntar med de självförklarande namnen "cell smart table scan", "cell multiblock". fysisk avläsning" och "fysisk avläsning av ett enda block för cell".
I de flesta fall är andelen sådana Exadata-väntningar av den totala svarstiden liten, och därför hamnar de inte ens i avsnittet Top10 förgrundshändelser efter total väntetid (i det här fallet måste du leta efter dem i förgrundsväntan Evenemangssektionen). Med stor svårighet hittade vi ett exempel på daglig AWR från våra kunder, där Exadatas förväntningar ingick i Top10-sektionen och totalt uppgick till cirka 5 %:
händelse
Väntar
Total väntetid (sek)
Genomsnittlig vänta
%DB tid
Vänta klass
DB CPU
115.2K
70.4
SQL*Net mer data från dblink
670,196
5471.5
8.16ms
3.3
nätverks
fysisk läsning av enbart cell
5,661,452
3827.6
676.07us
2.3
Användar-I/O
Synkronisera ombalansering av ASM
4,350,012
3481.3
800.30us
2.1
Övriga
cell multiblock fysisk läsning
759,885
2252
2.96ms
1.4
Användar-I/O
direkt vägläsning
374,368
1811.3
4.84ms
1.1
Användar-I/O
SQL*Net meddelande från dblink
7,983
1725
216.08ms
1.1
nätverks
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Användar-I/O
direkt väg läsa temp
520,211
808.4
1.55ms
0.5
Användar-I/O
enq: TM - påstående
652
795.8
1220.55ms
0.5
Ansökan
Följande slutsatser dras ofta från sådan AWR-statistik:
1. Bidraget från Exadata magi till databasprestanda är inte högt - det överstiger inte 5%, och databasen "exadatiserar" dåligt.
2. Om en sådan databas överförs från Exadata till den klassiska "server + array"-arkitekturen kommer prestandan inte att förändras mycket. För även om denna array visar sig vara tre gånger långsammare än Exadata-lagringssystemet (vilket knappast är möjligt för moderna All Flash-arrayer), då multiplicerar vi 5 % med tre får vi en ökning av andelen I/O-väntningar till 15 % – databasen kommer säkerligen att överleva detta!
Båda dessa slutsatser är felaktiga, dessutom förvränger de förståelsen av idén bakom Exadata Software. Exadata tillhandahåller inte bara snabb I/O, det fungerar fundamentalt annorlunda jämfört med den klassiska server + array-arkitekturen. Om databasoperationen verkligen är "anpassad" överförs SQL-logiken till lagringssystemet. Lagringsservrar, tack vare ett antal speciella mekanismer (främst Exadata Storage Index, men inte bara), hittar själva nödvändiga data och skickar DB till servrarna. De gör detta ganska effektivt, så andelen typiska Exadata-väntningar i den totala svarstiden är liten.
Hur kommer denna andel att förändras utanför Exadata? Hur kommer detta att påverka prestandan för databasen som helhet? Testning ger bäst svar på dessa frågor. Att till exempel vänta på en "cell smart table scan" utanför Exadata kan förvandlas till en så tung Table Full Scan att I/O tar upp hela svarstiden och prestandan försämras dramatiskt. Det är därför det är fel, när man analyserar AWR, att betrakta den totala procentandelen av Exadata-förväntningar som bidraget från dess magi till prestanda, och ännu mer att använda denna procentsats för att förutsäga prestanda utanför Exadata. För att förstå hur "exakt" arbetet med databasen är måste du studera AWR-statistiken i avsnittet "Instance Activity Stats" (det finns mycket statistik med självförklarande namn) och jämföra dem med varandra.
Och för att förstå hur en databas utanför Exadata kommer att kännas är det bäst att göra en databasklon från en säkerhetskopia på målarkitekturen och analysera prestandan för denna klon under belastning. Exadata-ägare har som regel denna möjlighet.
Författare: Alexey Struchenko, chef för Jet Infosystems databasavdelning
Källa: will.com