Met dit korte bericht wil ik een misverstand wegnemen met betrekking tot de analyse van AWR-databases die op Oracle Exadata draaien. Al bijna 10 jaar word ik voortdurend geconfronteerd met de vraag: wat is de bijdrage van Exadata Software aan de productiviteit? Of met nieuw bedachte woorden: hoe ‘expert’ is het werk van een bepaalde database?
Vaak wordt deze juiste vraag naar mijn mening onjuist beantwoord met verwijzing naar AWR-statistieken. Het presenteert de systeemwachtmethode, die de responstijd behandelt als de som van de bedrijfstijd van processors (DB CPU's) en de wachttijd van verschillende klassen.
Met de komst van Exadata verschenen er specifieke systeemverwachtingen met betrekking tot de werking van Exadata Software in de AWR-statistieken. In de regel beginnen de namen van dergelijke wachttijden met het woord “cel” (de Exadata Storage-server wordt een cel genoemd), waarvan de meest voorkomende wachttijden zijn met de voor zichzelf sprekende namen “cell smart table scan”, “cell multiblock fysiek lezen” en “fysiek lezen van één celblok”.
In de meeste gevallen is het aandeel van dergelijke Exadata-wachttijden in de totale responstijd klein en daarom vallen ze niet eens in de Top10 voorgrondgebeurtenissen per totale wachttijd (in dit geval moet u ze zoeken in de sectie Wachttijd op de voorgrond). sectie Evenementen). Met grote moeite vonden we een voorbeeld van dagelijkse AWR van onze klanten, waarbij de verwachtingen van Exadata in de Top10-sectie waren opgenomen en in totaal ongeveer 5% bedroegen:
Event
Wacht
Totale wachttijd (sec)
Gemiddeld Wacht
%DB-tijd
Wacht klasse
DB-CPU
115.2K
70.4
SQL*Net meer gegevens van dblink
670,196
5471.5
8.16ms
3.3
Netwerk
cel fysiek lezen met één blok
5,661,452
3827.6
676.07us
2.3
Gebruikers-I/O
Synchroniseer ASM-herbalancering
4,350,012
3481.3
800.30us
2.1
Overige
cel multiblock fysiek lezen
759,885
2252
2.96ms
1.4
Gebruikers-I/O
directe pad lezen
374,368
1811.3
4.84ms
1.1
Gebruikers-I/O
SQL*Net-bericht van dblink
7,983
1725
216.08ms
1.1
Netwerk
cel slimme tabelscan
1,007,520
1260.7
1.25ms
0.8
Gebruikers-I/O
direct pad leestemp
520,211
808.4
1.55ms
0.5
Gebruikers-I/O
enq: TM - stelling
652
795.8
1220.55ms
0.5
Aanvraag
Uit dergelijke AWR-statistieken worden vaak de volgende conclusies getrokken:
1. De bijdrage van Exadata-magie aan de databaseprestaties is niet hoog: deze bedraagt niet meer dan 5%, en de database 'exadatiseert' slecht.
2. Als een dergelijke database wordt overgezet van Exadata naar de klassieke “server + array” -architectuur, zullen de prestaties niet veel veranderen. Want zelfs als deze array drie keer langzamer blijkt te zijn dan het Exadata-opslagsysteem (wat nauwelijks mogelijk is voor moderne All Flash-arrays), krijgen we door 5% met drie te vermenigvuldigen een toename van het aandeel I/O-wachttijden tot 15% - de database zal dit zeker overleven!
Beide conclusies zijn onnauwkeurig en vertekenen bovendien het begrip van het idee achter Exadata Software. Exadata biedt niet alleen snelle I/O, het werkt fundamenteel anders dan de klassieke server + array-architectuur. Als de databasebewerking daadwerkelijk wordt ‘aangepast’, wordt de SQL-logica overgebracht naar het opslagsysteem. Opslagservers vinden dankzij een aantal speciale mechanismen (voornamelijk Exadata Storage Indexes, maar niet alleen) zelf de benodigde gegevens en sturen de DB naar de servers. Ze doen dit vrij efficiënt, dus het aandeel typische Exadata-wachttijden in de totale responstijd is klein.
Hoe zal dit aandeel veranderen buiten Exadata? Welke invloed heeft dit op de prestaties van de database als geheel? Testen zal deze vragen het beste beantwoorden. Het wachten op een “cell smart table scan” buiten Exadata kan bijvoorbeeld uitmonden in een zo zware Table Full Scan dat I/O de gehele responstijd in beslag neemt en de prestaties dramatisch achteruitgaan. Daarom is het verkeerd om bij het analyseren van AWR het totale percentage van de verwachtingen van Exadata te beschouwen als de bijdrage van de magie ervan aan de prestaties, en nog meer om dit percentage te gebruiken om de prestaties buiten Exadata te voorspellen. Om te begrijpen hoe “exact” het werk van de database is, moet u de AWR-statistieken van de sectie “Instance Activity Stats” bestuderen (er zijn veel statistieken met voor zichzelf sprekende namen) en deze met elkaar vergelijken.
En om te begrijpen hoe een database buiten Exadata zal aanvoelen, kunt u het beste een databasekloon maken van een back-up op de doelarchitectuur en de prestaties van deze kloon onder belasting analyseren. Eigenaars van Exadata hebben in de regel deze mogelijkheid.
auteur: Alexey Struchenko, hoofd van de databaseafdeling van Jet Infosystems
Bron: www.habr.com