Wanneer een gebruiker of toepassing verzoeken doet aan een database, verbruikt deze bronnen op dat systeem. Naarmate het aantal verzoeken toeneemt, kunt u te maken krijgen met wachttijden voor resources. Deze wachttijden leiden tot prestatieknelpunten en, in het geval van in de cloud geïmplementeerde databases, extra maandelijkse kosten! Bij het diagnosticeren van prestatieknelpunten is de eerste stap om te begrijpen welke bronnen worden beïnvloed.
Als u een prestatieknelpunt terug kunt koppelen aan een specifieke resource wait, vervolgens aan specifieke code en uiteindelijk aan de werklast van een specifieke gebruiker, kunt u de oorzaak achterhalen en het knelpunt permanent oplossen.
U kunt bijvoorbeeld ontdekken dat een toepassing traag werkt omdat de CPU op de databaseserver te veel wordt verbruikt, omdat Matt van de inkoopafdeling een inventarisatierapport in de fabrieksdatabase uitvoert.
Spotlight Cloud's Workload Analyzer is de tool die dit mogelijk maakt met zijn gebruiksvriendelijke navigatie.
Hoe de Workload Analyzer van Spotlight Cloud te gebruiken
Om te beginnen, kunt u het gewenste tijdsbestek selecteren. Spotlight Cloud slaat één jaar aan gegevens op, zodat u terug kunt gaan naar elk punt in de tijd of periode in het afgelopen jaar.
Dan heb je de mogelijkheid om te filteren op resource. Als u bijvoorbeeld weet dat het probleem CPU-gerelateerd is, kunt u de CPU-bron selecteren. Hierdoor wordt de informatie met betrekking tot alle andere bronnen, zoals I/O, vergrendelingen en geheugen, gefilterd, waardoor de witte ruis effectief wordt geëlimineerd en het gemakkelijker wordt om de oorzaak te achterhalen.
Standaardpagina Workload Analyzer
Boor in de databasedimensie en het zal de topdatabases die de meeste bronnen verbruiken, van hoog naar laag rangschikken en dienovereenkomstig schaduwen. Dit sorteermechanisme blijft behouden bij elke herhaling van een drilldown.
Borden in de databasedimensie
Bovendien moet u in de verkoopdatabase duiken, omdat het belangrijk is om te weten wat het gedrag van de wachttijden is in de database die het meest wordt verbruikt. In dit voorbeeld lijkt het erop dat de meeste werklast werd veroorzaakt door CPU (45,7 procent) en I/O-bronnen (30,2 procent), en hun snelheden liggen dicht bij 0,48 sec/s en 0,43 sec/s.
Borden in de dimensie van de verkoopdatabase
Tegelijkertijd zal het selecteren van CPU de andere bronnen uitfilteren en een aangepaste CPU-only uitlezing opleveren. De mogelijkheid om een specifieke werklast te isoleren is handig omdat het de afleidende statistieken visueel uitsluit, zodat u zich alleen kunt concentreren op wat voorrang heeft. Ook kunnen prestatie-indicatoren boven elkaar worden weergegeven, zodat u visueel correlaties kunt zien.
Belangrijke prestatie-indicatoren gefilterd voor alleen CPU-statistieken
Zoom vervolgens in op T-SQL-batches. Hierdoor kunnen we achterhalen welke batches binnen de verkoopdatabase het meest belastend zijn. 
Boren in de T-SQL-batches
Omdat deze batch zeer CPU-intensief is, is het belangrijk om te weten welke query's binnen die batch de boosdoener zijn voor de extra kosten. Het gebruik van de T-SQL-tekst in combinatie met het uitvoeringsplan laat zien dat de sorteeroperator de schuldige is. SQL Optimizer voorspelt dat de geschatte kosten 97 procent zijn. Het toevoegen van een index kan de prestaties helpen optimaliseren.
T-SQL-verklaringen
Uitvoeringsplan en kostenanalyse van de uitgevoerde bewerkingen
Houd er rekening mee dat de resourcekiezer kan worden geconfigureerd om een resource te markeren zodra het gebruik ervan een vooraf gedefinieerde drempel overschrijdt. U kunt de selector bijvoorbeeld instellen om I/O-bronnen te markeren als de wachttijd meer dan 30 procent is.
Resourcekiezerconfiguraties aanpassen voor I/O-bronnen
Bijgewerkte configuraties voor toegepaste I/O-bronkiezer