Med dette korte innlegget vil jeg fjerne en misforståelse knyttet til analysen av AWR-databaser som kjører på Oracle Exadata. I nesten 10 år har jeg konstant blitt møtt med spørsmålet: hva er Exadata Softwares bidrag til produktiviteten? Eller ved å bruke nyskapte ord: hvor "ekspert" er arbeidet til en bestemt database?
Ofte blir dette riktige spørsmålet, etter min mening, besvart feil med henvisning til AWR-statistikk. Den presenterer systemventemetoden, som behandler responstid som summen av driftstiden til prosessorer (DB CPUer) og ventetiden til ulike klasser.
Med bruken av Exadata dukket spesifikke systemforventninger knyttet til driften av Exadata Software opp i AWR-statistikken. Som regel begynner navnene på slike ventetider med ordet "celle" (Exadata Storage-serveren kalles en celle), hvorav de vanligste er ventetider med de selvforklarende navnene "cell smart table scan", "cell multiblock". fysisk lesing" og "celle enkeltblokk fysisk lesing".
I de fleste tilfeller er andelen av slike Exadata-ventinger i den totale responstiden liten, og derfor faller de ikke engang inn i Top10 Foreground Events by Total Wait Time-seksjonen (i dette tilfellet må du se etter dem i Foreground Wait Arrangementsdelen). Med store vanskeligheter fant vi et eksempel på daglig AWR fra våre kunder, der Exadata-forventninger ble inkludert i Top10-seksjonen og totalt utgjorde ca 5 %:
Event
Venter
Total ventetid (sek.)
Gj.sn. vent
%DB tid
Vent klasse
DB CPU
115.2K
70.4
SQL*Net mer data fra dblink
670,196
5471.5
8.16ms
3.3
Network
fysisk lesing av enkeltblokker
5,661,452
3827.6
676.07us
2.3
Bruker I/O
Synkroniser ASM-rebalansering
4,350,012
3481.3
800.30us
2.1
Annen
celle multiblokk fysisk lesing
759,885
2252
2.96ms
1.4
Bruker I/O
direkte veilesing
374,368
1811.3
4.84ms
1.1
Bruker I/O
SQL*Net melding fra dblink
7,983
1725
216.08ms
1.1
Network
celle smart bordskanning
1,007,520
1260.7
1.25ms
0.8
Bruker I/O
direkte vei lese temp
520,211
808.4
1.55ms
0.5
Bruker I/O
enq: TM - påstand
652
795.8
1220.55ms
0.5
Søknad
Følgende konklusjoner trekkes ofte fra slik AWR-statistikk:
1. Bidraget fra Exadata-magi til databaseytelse er ikke høyt - det overstiger ikke 5%, og databasen "exadatiserer" dårlig.
2. Hvis en slik database overføres fra Exadata til den klassiske "server + array"-arkitekturen, vil ytelsen ikke endre seg mye. For selv om denne matrisen viser seg å være tre ganger tregere enn Exadata-lagringssystemet (som neppe er mulig for moderne All Flash-matriser), så får vi en økning i andelen av I/O-venter til 5% ved å multiplisere 15 % med tre – databasen vil helt sikkert overleve dette!
Begge disse konklusjonene er unøyaktige, dessuten forvrenger de forståelsen av ideen bak Exadata Software. Exadata gir ikke bare rask I/O, det fungerer fundamentalt annerledes sammenlignet med den klassiske server + array-arkitekturen. Hvis databaseoperasjonen virkelig er "tilpasset", overføres SQL-logikken til lagringssystemet. Lagringsservere, takket være en rekke spesielle mekanismer (primært Exadata Storage Indexes, men ikke bare), finner de nødvendige dataene selv og sender DB til serverne. De gjør dette ganske effektivt, så andelen typiske Exadata-ventinger i den totale responstiden er liten.
Hvordan vil denne andelen endres utenfor Exadata? Hvordan vil dette påvirke ytelsen til databasen som helhet? Testing vil best svare på disse spørsmålene. For eksempel kan det å vente på en "celle smart tabellskanning" utenfor Exadata bli til en så tung Table Full Scan at I/O tar opp hele responstiden og ytelsen reduseres dramatisk. Det er derfor det er feil, når man analyserer AWR, å betrakte den totale prosentandelen av Exadata-forventninger som bidraget fra dens magi til ytelsen, og enda mer å bruke denne prosentandelen til å forutsi ytelse utenfor Exadata. For å forstå hvor "nøyaktig" arbeidet med databasen er, må du studere AWR-statistikken i delen "Instance Activity Stats" (det er mye statistikk med selvforklarende navn) og sammenligne dem med hverandre.
Og for å forstå hvordan en database utenfor Exadata vil føles, er det best å lage en databaseklone fra en sikkerhetskopi på målarkitekturen og analysere ytelsen til denne klonen under belastning. Exadata-eiere har som regel denne muligheten.
Forfatter: Alexey Struchenko, leder for Jet Infosystems databaseavdeling
Kilde: www.habr.com