Brent Ozar weet alles van snel gaan - hij racet met auto's en hij blaast SQL Servers dagelijks op met adembenemende databaseprestaties. In zijn webcast 'Hoe SQL Server meten', voor de serie Database Training Days van Quest, Brent herinnerde ons eraan dat prestatie draait om meten.
Opgewekt voor prestaties
Brent maakte van de gelegenheid gebruik om sociale afstand te nemen en kleedde zich aan door een volledig racepak en helm aan te trekken. In een pre-webcast geklets leerden we dat hij een microfoon in de helm moest aansluiten en de oordopjes aan zijn oren moest plakken! Maar we dwalen af. De webcast ging helemaal over prestaties, en er waren genoeg auto-analogieën om rond te gaan.
Om de prestaties van SQL Server te verbeteren, zijn de volgende uitgangspunten:
- Kies statistieken om u te concentreren op verbetering
- Meet de prestaties voor en na het aanbrengen van beperkte wijzigingen (wetenschappelijke basismethode)
- Begrijp wanneer je de verkeerde apparatuur hebt voor wat je probeert te bereiken
Statistieken voor het afstemmen van databaseprestaties
Een lange discussie over Ford F150-trucks, Ford Fiesta's en enkele andere interessante voertuigen illustreerde dat er verschillende manieren zijn om de tijd die nodig is om van 0 naar 60 mijl per uur te gaan, te verbeteren. U kunt het gewicht van het voertuig verlagen, een grotere motor toevoegen of beginnen met het verwijderen van niet-essentiële zaken, zoals een voorruit. Er zal een compromis zijn tussen prestaties en bruikbaarheid. Databases zijn precies zo - ze worden vaak geladen. Dit is wanneer aangepaste prestatieafstemming nodig is, waarvoor het kennen en verbeteren van de statistieken vereist is.
Brent stelt dat er drie primaire statistieken zijn die je nodig hebt voor het afstemmen van auto's en databases:gewicht, snelheidsbenchmark (zoals 0 tot 60) en hoe hard de engine (server) werkt.
De grootte van de database meten
Gewicht voor SQL Server vertaalt zich naar de totale databasegrootte en hoeveel gegevens u hebt. Dit wordt meestal gemeten in gigabytes of terabytes. Vanaf ongeveer 1-150 GB zou SQL Server Standard Edition voldoende moeten zijn. Van 150-500 GB is een gemakkelijke belasting voor de Enterprise Edition. Boven 500 GB begint het uit te maken of het actieve gegevens zijn en hoe deze worden geopend. En alles boven 1 TB aan OLTP-gegevens kan een hele uitdaging zijn.
Prestatiesnelheid bijhouden
De snelheidsbenchmark in auto's is eenvoudig - MPH. Voor de database zijn het batchverzoeken per seconde, maar dit moet gedurende verschillende tijdsperioden elk uur worden trending. Het is duidelijk dat hoe meer vragen er zijn, hoe langzamer de prestaties zullen zijn, afhankelijk van de hardware.
Query-workloads beoordelen
Ten slotte, om te begrijpen hoe hard de database werkt, moet u begrijpen welke query's momenteel worden uitgevoerd en wat er in de wachtrij staat. Dit geeft u een wachttijdverhouding - in feite hoe lang wachten taken tot andere taken zijn voltooid. Uw wachttijdverhouding wordt uitgedrukt in uren wachttijd per uur (of seconden wachttijd per seconde) - combineer uw meeteenheden niet. Als je deze statistieken in de loop van de tijd goed onder de knie hebt, kun je zien wat de wachttijd beïnvloedt, bijvoorbeeld of er meer of minder batchverzoeken zijn, beter of slechter afgestemde zoekopdrachten, enz. Dan kun je die problemen aanpakken.
Bekijk de on-demand webinar-opname voor alle wijze raad en humor van Brent.