Med dette korte indlæg vil jeg gerne fjerne en misforståelse relateret til analysen af AWR-databaser, der kører på Oracle Exadata. I næsten 10 år har jeg konstant stået over for spørgsmålet: hvad er Exadata Softwares bidrag til produktiviteten? Eller ved at bruge nyopfundne ord: hvor "ekspert" er arbejdet i en bestemt database?
Ofte bliver dette korrekte spørgsmål efter min mening besvaret forkert med henvisning til AWR-statistikker. Den præsenterer systemets ventemetode, som behandler responstid som summen af processorernes (DB CPU'ers) driftstid og ventetiden for forskellige klasser.
Med fremkomsten af Exadata optrådte specifikke systemforventninger relateret til driften af Exadata Software i AWR-statistikker. Som regel begynder navnene på sådanne ventetider med ordet "celle" (Exadata Storage-serveren kaldes en celle), hvoraf de mest almindelige er ventetider med de selvforklarende navne "celle smart table scan", "celle multiblok fysisk læsning" og "celle enkelt blok fysisk læsning".
I de fleste tilfælde er andelen af sådanne Exadata-venter i den samlede responstid lille, og derfor falder de ikke engang ind under Top10 Foreground Events by Total Wait Time (i dette tilfælde skal du lede efter dem i Foreground Wait) Begivenheder sektion). Med stort besvær fandt vi et eksempel på daglig AWR fra vores kunder, hvor Exadata-forventninger var inkluderet i Top10-sektionen og i alt udgjorde omkring 5%:
begivenhed
Venter
Samlet ventetid (sek.)
Gns. Vent
%DB tid
Vent klasse
DB CPU
115.2K
70.4
SQL*Net flere data fra dblink
670,196
5471.5
8.16ms
3.3
Netværk
celle enkelt blok fysisk læsning
5,661,452
3827.6
676.07us
2.3
Bruger I/O
Synkroniser ASM-genbalancering
4,350,012
3481.3
800.30us
2.1
Andet
celle multiblok fysisk læsning
759,885
2252
2.96ms
1.4
Bruger I/O
direkte vejlæsning
374,368
1811.3
4.84ms
1.1
Bruger I/O
SQL*Net besked fra dblink
7,983
1725
216.08ms
1.1
Netværk
celle smart tabel scanning
1,007,520
1260.7
1.25ms
0.8
Bruger I/O
direkte vej læse temp
520,211
808.4
1.55ms
0.5
Bruger I/O
enq: TM - påstand
652
795.8
1220.55ms
0.5
Anvendelse
Følgende konklusioner drages ofte fra sådanne AWR-statistikker:
1. Bidraget fra Exadata-magi til databasens ydeevne er ikke højt - det overstiger ikke 5%, og databasen "exadatiserer" dårligt.
2. Hvis en sådan database overføres fra Exadata til den klassiske "server + array"-arkitektur, så vil ydeevnen ikke ændre sig meget. For selvom dette array viser sig at være tre gange langsommere end Exadata-lagringssystemet (hvilket næppe er muligt for moderne All Flash-arrays), så får vi ved at gange 5 % med tre en stigning i andelen af I/O-venter til 15 % - databasen vil helt sikkert overleve dette!
Begge disse konklusioner er unøjagtige, desuden fordrejer de forståelsen af ideen bag Exadata Software. Exadata leverer ikke bare hurtig I/O, det fungerer fundamentalt anderledes sammenlignet med den klassiske server + array-arkitektur. Hvis databaseoperationen virkelig er "tilpasset", så overføres SQL-logikken til lagersystemet. Storageservere, takket være en række specielle mekanismer (primært Exadata Storage Indexes, men ikke kun), finder selv de nødvendige data og sender DB'en til serverne. Det gør de ret effektivt, så andelen af typiske Exadata-venter i den samlede responstid er lille.
Hvordan vil denne andel ændre sig uden for Exadata? Hvordan vil dette påvirke ydelsen af databasen som helhed? Test vil bedst besvare disse spørgsmål. For eksempel kan ventetiden på en "cellesmart tabelscanning" uden for Exadata blive til en så tung Table Full Scan, at I/O optager hele responstiden og ydeevnen forringes dramatisk. Derfor er det forkert, når man analyserer AWR, at betragte den samlede procentdel af Exadata-forventninger som bidraget fra dens magi til ydeevnen, og endnu mere at bruge denne procentdel til at forudsige ydeevne uden for Exadata. For at forstå, hvor "præcis" arbejdet i databasen er, skal du studere AWR-statistikken i afsnittet "Instance Activity Stats" (der er en masse statistikker med selvforklarende navne) og sammenligne dem med hinanden.
Og for at forstå, hvordan en database uden for Exadata vil føles, er det bedst at lave en databaseklone fra en backup på målarkitekturen og analysere ydelsen af denne klon under belastning. Exadata-ejere har som udgangspunkt denne mulighed.
Forfatter: Alexey Struchenko, leder af Jet Infosystems databaseafdeling
Kilde: www.habr.com