Med dette lille indlæg vil jeg gerne aflive en misforståelse omkring analysen af AWR-databaser, der kører på Oracle Exadata. I næsten 10 år har jeg konstant stødt på spørgsmålet: Hvad er Exadata Softwares bidrag til ydeevnen? Eller med nydannede ord: Hvor meget vil arbejdet med en given database "exadata-se"?
Ofte gives der et forkert svar på dette korrekte spørgsmål, efter min mening, med henvisning til AWR-statistik. Den præsenterer en metode til systemventetid, der fortolker respons tiden som summen af tid brugt af processorerne (DB CPU) og ventetider fra forskellige klasser.
Med fremkomsten af Exadata er der i AWR-statistikken opstået specifikke systemventetider relateret til Exadata Software. Normalt begynder navnene på disse ventetider med ordet "cell" (en celle kaldes Exadata Storage server), hvor de mest almindeligt forekommende ventetider har talende navne som "cell smart table scan", "cell multiblock physical read" og "cell single block physical read".
I de fleste tilfælde er andelen af sådanne Exadata-ventetider i den samlede responstid lille, og derfor kommer de endda ikke ind i sektionen Top10 Foreground Events by Total Wait Time (i dette tilfælde skal de findes i afsnittet Foreground Wait Events). Vi har med stort besvær opdaget et eksempel på en daglig AWR hos vores kunder, hvor Exadata-ventetider kom ind i sektionen Top10 og i alt udgjorde omkring 5%:
Hændelse
Ventetider
Total Ventetid (sek)
Gns. Ventetid
% DB tid
Venteklasse
DB CPU
115.2K
70.4
SQL*Net mere data fra dblink
670,196
5471.5
8.16ms
3.3
Netværk
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Bruger I/O
Sync ASM rebalance
4,350,012
3481.3
800.30us
2.1
Andet
cell multiblock physical read
759,885
2252
2.96ms
1.4
Bruger I/O
direct path read
374,368
1811.3
4.84ms
1.1
Bruger I/O
SQL*Net meddelelse fra dblink
7,983
1725
216.08ms
1.1
Netværk
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Bruger I/O
direct path read temp
520,211
808.4
1.55ms
0.5
Bruger I/O
enq: TM — indhold
652
795.8
1220.55ms
0.5
Applikation
Fra sådanne AWR-statistikker drages ofte følgende konklusioner:
1. Exadatas "magi" bidrag til databasen er ikke højt — det overstiger ikke 5%, og databasen "exadata-se" dårligt.
2. Hvis en sådan database flyttes fra Exadata til en klassisk arkitektur "server + array", så vil ydeevnen ikke ændre sig meget. For selv hvis dette array skulle vise 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 multiplicere 5% med tre, en stigning i andelen af ventetider for ind- og udlæsning op til 15% — sådan en database vil helt sikkert klare det!
Begge disse output er unøjagtige, ja endda forvrænger de forståelsen af ideen bag Exadata Software. Exadata leverer ikke kun hurtig input-output; den fungerer fundamentalt anderledes end en klassisk arkitektur med "server + lagring". Hvis databasen virkelig "exadateres", så overføres SQL-logikken til lagringssystemet. servere takket være en række specielle mekanismer (først og fremmest Exadata Storage Indexes, men ikke kun dem) finder de selv de nødvendige data og sender dem til DB-serverne. De gør dette ret effektivt, så andelen af karakteristiske Exadata-ventetider i den samlede svartid er lille.
Hvordan vil denne andel ændre sig uden for Exadata? Hvordan vil det påvirke databaseydelsen generelt? Testning vil give de bedste svar på disse spørgsmål. For eksempel kan ventetiden "cell smart table scan" uden for Exadata blive til en så tung Table Full Scan, at input-output optager al svartiden, hvilket dramatisk forringer ydeevnen. Derfor er det forkert at betragte den samlede procentdel af Exadata-ventetider som et bidrag til dens magi i ydelsen, især ikke at bruge denne procent til at forudsige ydeevnen uden for Exadata. For at forstå, hvor meget databasen "exadateres", skal statistikkerne fra AWR-sektionen "Instance Activity Stats" studeres (der er mange statistikker med sigende navne) og sammenlignes med hinanden.
Og for at forstå, hvordan databasen vil have det uden for Exadata, er det bedst at lave en klon af databasen fra en backup på den målarkitektur og analysere ydeevnen af denne klon under belastning. Ejere af Exadata har som regel denne mulighed.
Forfatter: Aleksey Struchenko, leder af DB-afdelingen "Infosystems Jet"
Kilde: habr.com
