Når en bruger eller applikation sender anmodninger til en database, bruger den ressourcer på det system. Efterhånden som antallet af anmodninger stiger, kan du opleve ressourceventer. Disse ventetider fører til ydeevneflaskehalse og, i tilfælde af cloud-implementerede databaser, ekstra månedlige omkostninger! Når man diagnosticerer ydeevneflaskehalse, er det første skridt at forstå, hvilke ressourcer der er berørt.
At være i stand til at kortlægge en ydeevneflaskehals tilbage til en specifik ressourcevent, derefter til specifik kode og til sidst til en specifik brugers arbejdsbyrde vil gøre dig i stand til at komme til hovedårsagen og løse flaskehalsen permanent.
For eksempel kan du opdage, at en applikation kører langsomt, fordi CPU'en er overforbrugt på databaseserveren, fordi Matt i indkøbsafdelingen kører en lageropgørelsesrapport i anlægsdatabasen.
Spotlight Clouds Workload Analyzer er værktøjet, der gør dette muligt med sin brugervenlige navigation.
Sådan bruger du Spotlight Clouds Workload Analyzer
Til at begynde med kan du vælge tidsrammen for interesse. Spotlight Cloud gemmer et års data, så du kan gå tilbage til ethvert tidspunkt eller tidsinterval i det seneste år.
Så har du mulighed for at filtrere efter ressource. For eksempel, hvis du ved, at problemet er CPU-relateret, kan du vælge CPU-ressourcen. Hvis du gør det, bortfiltreres informationen relateret til alle andre ressourcer, såsom I/O, låse og hukommelse, hvilket effektivt eliminerer den hvide støj og gør det nemmere at finde frem til årsagen.
Workload Analyzer Standardside
Bor i databasens dimension, og den vil sortere de øverste databaser, der bruger flest ressourcer, fra høj til lav og skygge dem tilsvarende. Denne sorteringsmekanisme bevares gennem hver iteration af en drilldown.
Drilling i databasedimensionen
Ydermere bør du bore i salgsdatabasen, fordi det er vigtigt at vide, hvad opførselen af ventetiden er inden for den topforbrugende database specifikt. I dette eksempel ser det ud til, at det meste af arbejdsbyrden blev tegnet af CPU (45,7 procent) og I/O-ressourcer (30,2 procent), og deres hastigheder er tæt på 0,48 sek/s og 0,43 sek/s.
Drilling i salgsdatabasedimensionen
Parallelt hermed vil valg af CPU filtrere de andre ressourcer fra og give en tilpasset, kun CPU-udlæsning. Evnen til at isolere en specifik arbejdsbyrde er nyttig, fordi den visuelt fjerner de distraherende metrikker, så du kun kan fokusere på det, der har forrang. Ydeevneindikatorer kan også tegnes oven på hinanden, så du visuelt kan se sammenhænge.
Nøgleydelsesindikatorer filtreret kun til CPU-statistikker
Dernæst borer du ned i T-SQL-batches. Dette giver os mulighed for at finde ud af, hvilke partier i salgsdatabasen der er mest belastende. 
Drilling i T-SQL-batches
Fordi denne batch er meget CPU-intensiv, er det vigtigt at vide, hvilke forespørgsler inden for den batch, der tjener som synderen for de ekstra omkostninger. Brug af T-SQL-teksten i forbindelse med udførelsesplanen viser, at Sort-operatøren har skylden. SQL Optimizer forudsiger, at den estimerede afgift er 97 procent. Tilføjelse af et indeks kan hjælpe med at optimere ydeevnen.
T-SQL-erklæringer
Udførelsesplan og omkostningsanalyse af de udførte operationer
Bemærk, at ressourcevælgeren kan konfigureres til at fremhæve en ressource, når dens udnyttelse overskrider en foruddefineret tærskel. For eksempel kan du indstille vælgeren til at fremhæve I/O-ressourcer, hvis ventetiden er mere end 30 procent.
Justering af ressourcevælgerkonfigurationer for I/O-ressourcer
Opdaterede konfigurationer for I/O-ressourcevælger anvendt