AWR: hur mycket "exadatas" databasen arbetar?

Med det här lilla inlägget skulle jag vilja klargöra ett missförstånd som rör analysen av AWR-databaser som körs på Oracle Exadata. I nästan 10 år har jag ständigt stött på frågan: vad är Exadata Softwares bidrag till prestandan? Eller med nybildade ord: hur mycket "exadaterar" arbetet hos en viss databas?

Ofta ges ett felaktigt svar på denna rätta fråga, enligt min mening, med hänvisning till AWR-statistik. I den presenteras en metod för systemväntan som tolkar svarstiden som summan av processorns arbetstid (DB CPU) och väntetiden för olika klasser.

Med införandet av Exadata har specifika systemväntor som är relaterade till Exadata Software dykt upp i AWR-statistiken. Vanligtvis börjar namnen på sådana väntor med ordet "cell" (en cell kallas Exadata Storage-server), och de vanligaste väntorna har beskrivande namn som "cell smart table scan", "cell multiblock physical read" och "cell single block physical read".

I de flesta fall är andelen sådana Exadata-väntor i den totala svarstiden låg, och därför kan de till och med inte hittas i sektionen Top10 Foreground Events by Total Wait Time (i så fall måste de sökas i avsnittet Foreground Wait Events). Vi hade stora svårigheter att hitta ett exempel på en daglig AWR-rapport hos våra kunder där Exadata-väntor kom in i sektionen Top10 och totalt utgjorde cirka 5 %:

Händelse

Väntningar

Total väntetid (sek)

Genomsnittlig väntan

% DB tid

Väntklass

DB CPU

115.2K

70.4

SQL*Net mer data från dblink

670,196

5471.5

8.16ms

3.3

Nätverk

cell single block physical read

5,661,452

3827.6

676.07us

2.3

Användare I/O

Sync ASM rebalance

4,350,012

3481.3

800.30us

2.1

Annat

cell multiblock physical read

759,885

2252

2.96ms

1.4

Användare I/O

direkt path read

374,368

1811.3

4.84ms

1.1

Användare I/O

SQL*Net meddelande från dblink

7,983

1725

216.08ms

1.1

Nätverk

cell smart table scan

1,007,520

1260.7

1.25ms

0.8

Användare I/O

direkt path read temp

520,211

808.4

1.55ms

0.5

Användare I/O

enq: TM — contention

652

795.8

1220.55ms

0.5

Application

Från sådan AWR-statistik dras ofta följande slutsatser:

1. Bidraget från Exadata-magi till databasens prestanda är inte stort — det överstiger inte 5 %, och databasen "exadaterar" dåligt.

2. Om en sådan databas flyttas från Exadata till en klassisk arkitektur "server + lagring", kommer prestandan inte att förändras nämnvärt. Därför, även om den lagringen är tre gånger långsammare än Exadata-lagringssystemet (vilket knappt är möjligt för moderna All Flash-lagringar), kommer vi genom att multiplicera 5 % med tre få en ökning av väntetiden för I/O till 15 % — en sådan databas kommer definitivt att överleva!

Båda dessa utsagor är oklara, dessutom förvränger de förståelsen av idén bakom Exadata Software. Exadata erbjuder inte bara snabb in- och utmatning, den fungerar principiellt annorlunda jämfört med klassisk arkitektur "server + lagring". Om databasen verkligen "exadateras" — så flyttas SQL-logiken till lagringssystemet. Storage servrar Tack vare en rad speciella mekanismer (främst Exadata Storage Indexes, men inte bara) hittar de själva de nödvändiga uppgifterna och skickar dem till DB-servrarna. De gör detta ganska effektivt, därför är andelen karakteristiska Exadata-väntetider i den totala svarstiden låg. 

Hur kommer denna andel att förändras utanför Exadata? Hur kommer det att påverka databasens prestanda överlag? Det bästa svaret på dessa frågor får man genom testning. Till exempel kan väntan på "cell smart table scan" utanför Exadata bli så tuff att det istället blir en tung Table Full Scan, vilket gör att in- och utmatning tar upp all svarstid och prestandan försämras dramatiskt. Just därför är det felaktigt att i analysen av AWR räkna den totala andelen väntetider från Exadata som en del av dess magi för prestanda, och än mindre använda denna procentandel för att prognosticera prestanda utanför Exadata. För att förstå hur mycket "exadaterad" arbetsbelastningen är, måste man studera statistik från AWR-sektionen "Instance Activity Stats" (där finns mycket statistik med talande namn) och jämföra dem med varandra.

Och för att förstå hur databasen kommer att må utanför Exadata, är det bäst att göra en klon av databasen från en backup på den målarkitektur som ska användas och analysera prestandan hos denna klon under belastning. Den möjligheten har oftast de som innehar Exadata.

Författare: Aleksej Struchenko, chef för DB-avdelningen "Infosysteme Jet"

Källa: habr.com