![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nMet deze korte post wil ik een misverstand ontkrachten dat verband houdt met de AWR-analyse van databases die draaien op Oracle Exadata. Al bijna 10 jaar krijg ik steeds de vraag: wat is de bijdrage van Exadata Software aan de prestaties? Of in nieuwe termen: in hoeverre is de werking van elk database 'exadata't?<\/p>\n
<\/p>\n
Vaak wordt er op deze juiste vraag, naar mijn mening, een onjuist antwoord gegeven met een verwijzing naar AWR-statistieken. Hierin wordt een methode voor systeemwachttijden gepresenteerd, die de responstijd interpreteert als de som van de tijd dat de processors werken (DB CPU) en de tijd van wachttijden van verschillende klassen.<\/p>\n
Met de komst van Exadata zijn er specifieke systeemwachttijden aan de AWR-statistieken toegevoegd, gerelateerd aan de werking van Exadata Software. Gewoonlijk beginnen de namen van deze wachttijden met het woord 'cell' (de cell is de Exadata Storage server), en de meest voorkomende wachttijden hebben sprekende namen zoals 'cell smart table scan', 'cell multiblock physical read' en 'cell single block physical read'.<\/p>\n
In de meeste gevallen is het aandeel van zulke Exadata-wachttijden in de totale responstijd klein, en daarom komen ze zelfs niet in de sectie Top10 Foreground Events by Total Wait Time voor (in dat geval moeten ze worden gezocht in de sectie Foreground Wait Events). We hebben met moeite een voorbeeld van een dagelijkse AWR bij onze klanten gevonden waarin Exadata-wachttijden in de Top10-sectie voor kwamen en gezamenlijk ongeveer 5% uitmaakten:<\/p>\n
Evenement<\/strong><\/p>\n Wachttijden<\/strong><\/p>\n Totale wachttijd (sec)<\/strong><\/p>\n Gem. wachttijd<\/strong><\/p>\n % DB tijd<\/strong><\/p>\n Wachtklasse<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115,2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net meer gegevens van dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8,16ms<\/p>\n 3.3<\/p>\n Netwerk\nglobal\n log \/dev\/log local0\n log \/dev\/log local1 notice\n chroot \/var\/lib\/haproxy\n stats timeout 30s\n user haproxy\n group haproxy\n daemon\n\ndefaults\n log global\n mode http\n option httplog\n option dontlognull\n timeout connect 5000\n timeout client 50000\n timeout server 50000\n\nfrontend http_front\n bind *:80\n stats uri \/haproxy?stats\n default_backend http_back\n\nbackend http_back\n balance roundrobin\n server server_name1 private_ip1:80 check\n server server_name2 private_ip2:80 check<\/p>\n cell single block physical read<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676,07\u00b5s<\/p>\n 2.3<\/p>\n User I\/O<\/p>\n Sync ASM rebalance<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800,30\u00b5s<\/p>\n 2.1<\/p>\n Overig<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2,96ms<\/p>\n 1.4<\/p>\n User I\/O<\/p>\n direct path read<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4,84ms<\/p>\n 1.1<\/p>\n User I\/O<\/p>\n SQL*Net bericht van dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216,08ms<\/p>\n 1.1<\/p>\n Netwerk\nglobal\n log \/dev\/log local0\n log \/dev\/log local1 notice\n chroot \/var\/lib\/haproxy\n stats timeout 30s\n user haproxy\n group haproxy\n daemon\n\ndefaults\n log global\n mode http\n option httplog\n option dontlognull\n timeout connect 5000\n timeout client 50000\n timeout server 50000\n\nfrontend http_front\n bind *:80\n stats uri \/haproxy?stats\n default_backend http_back\n\nbackend http_back\n balance roundrobin\n server server_name1 private_ip1:80 check\n server server_name2 private_ip2:80 check<\/p>\n cell smart table scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1,25ms<\/p>\n 0.8<\/p>\n User I\/O<\/p>\n direct path read temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1,55ms<\/p>\n 0.5<\/p>\n User I\/O<\/p>\n enq: TM \u2014 contention<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220,55ms<\/p>\n 0.5<\/p>\n ) \u2014 dit is de enige plek waar je de backend hoeft op te geven. Alles andere past transparant in het concept \u201cspecificatie->wrapper\u201d, waar we het verder over zullen hebben.<\/p>\n Van dergelijke AWR-statistieken worden vaak de volgende conclusies getrokken:<\/p>\n 1. De bijdrage van Exadata-magic aan de prestaties van de database is niet hoog \u2014 het overschrijdt niet 5 %, en de database heeft moeite met 'exadatizing'.<\/p>\n 2. Als we zo'n database van Exadata naar een klassieke architectuur van 'server + array' verplaatsen, zal de prestatie niet veel veranderen. Want zelfs als deze array drie keer langzamer is dan het Exadata-opslagsysteem (wat voor moderne All Flash- arrays nauwelijks mogelijk is), dan vermenigvuldigend met 5% door drie krijgen we een toename van de I\/O-wachttijd tot 15% \u2014 een dergelijke database zal dit zeker overleven!<\/p>\n Beide deze outputs zijn onnauwkeurig, bovendien vervormen ze het begrip van het idee dat in Exadata Software is gelegd. Exadata zorgt niet alleen voor snelle input-output, het werkt fundamenteel anders dan de klassieke architectuur van 'server + opslag'. Als de database echt \u2018exadata\u2019 is, wordt de SQL-logica overgebracht naar het opslagsysteem. Storage servers<\/a> dankzij een reeks speciale mechanismen (voornamelijk Exadata Storage Indexes, maar niet alleen) vinden zij zelf de benodigde gegevens en sturen deze naar de DB-servers. Ze doen dit vrij effici\u00ebnt, waardoor het aandeel van typische Exadata-wachttijden in de totale reactie-tijd klein is. <\/p>\n Hoe verandert dit aandeel buiten Exadata? Wat zijn de gevolgen voor de algehele databasesprestaties? Deze vragen kunnen het beste worden beantwoord door testen. Bijvoorbeeld, de wachttijd \u2018cell smart table scan\u2019 buiten Exadata kan veranderen in een zware Table Full Scan, waardoor de input-output alle tijd voor de reactie in beslag neemt en de prestaties dramatisch verslechteren. Daarom is het onjuist om bij de analyse van AWR het totale percentage van Exadata-wachttijden als bijdrage van zijn magie aan de prestaties te beschouwen, laat staan om dit percentage te gebruiken voor het voorspellen van de prestaties buiten Exadata. Om te begrijpen hoe \u2018exadata\u2019 de werking van de database is, moet je de statistieken van de AWR-sectie \u201cInstance Activity Stats\u201d bestuderen (daar zijn veel statistieken met veelzeggende namen) en ze met elkaar vergelijken.<\/p>\n Om te begrijpen hoe de database zich buiten Exadata zal voelen, is het het beste om uit een back-up een kloon van de database te maken op de doelarchitectuur en de prestaties van deze kloon onder belasting te analyseren. Gewoonlijk hebben eigenaren van Exadata deze mogelijkheid.<\/p>\n