sql >> Database teknologi >  >> RDS >> Sqlserver

Brug af Spotlight Cloud til at løse SQL Server-blokering

SQL Server-blokering i en database sker, når en transaktion holder en lås på en ressource og forhindrer en eller flere forbindelser i at fungere på den samme ressource. Den anden forbindelse skal vente på, at låsen udløses, før den kan fortsætte. Dette gøres for at sikre isolationskomponenten af ​​ACID - hvilket betyder, at samtidige transaktioner ikke er synlige for hinanden, før de er afsluttet. Blokering i SQL Server kan ødelægge ydeevnen i ethvert miljø.

En af de opgaver, databaseadministratorer udfører, er at identificere forespørgslen, der udfører blokeringen, afhjælpe den og derefter gå et skridt videre for at fastslå årsagen. Det kan være en meget vanskelig opgave at undersøge den grundlæggende årsag, især efter kendsgerningen. For de fleste betyder dette en meget tidskrævende proces med at roote gennem SQL Server dynamiske administrationsvisninger såsom s ys.dm_exec_requests eller køre systemprocedurer som sp_who2 for at finde ud af detaljer om systemproces-id'erne (SPIDS), der er involveret i blockchain. Spotlight Cloud kan i høj grad reducere din indsats for at identificere disse blokerende begivenheder.

Brug af databaseovervågning til at identificere SQL Server-blokke

Figur 1:Oversigtskontrolpanel

Fra oversigtsdashboardet giver Spotlight Cloud et klart overblik over hele miljøet. Den viser målinger, herunder sessionstal, processer, hukommelsesforbrug, diskforbrug og venter på et øjeblik. Endnu vigtigere, det viser tydeligt blokerende aktivitet; i midten af ​​figur 1 kan du tydeligt se, at der i øjeblikket er to blokerede processer.

For en DBA er det nødvendigt at komme ind i detaljerne for at løse blokeringsproblemer. Spotlight Cloud giver os mulighed for at bore i flere sessionsdetaljer ved blot at vælge rullemenuen fra Oversigt som vist i figur 2.

Figur 2:Dropdown fra oversigt

Spotlight Cloud lader dig nemt se, hvilke sessioner der er blokeret, og hvilke udsagn der er involveret. I figur 3 kan du se, at SPID 59 og 65 begge er blokeret (angivet med orange markering omkring status), hvilket matcher antallet af blokerede. Du vil også bemærke, at Spotlight Cloud fortsætter med at give opsummerende detaljer om vores nuværende instanstilstand, så vi kan holde øje med vigtige tællere, mens vi dykker ned i ydeevneproblemer.

Brug af Spotlight Cloud SQL Server-overvågning til at løse blokeringsproblemer

Figur 3:Sessionskontrolpanel

Sessions-dashboardet (som vist i figur 3) giver os vigtige oplysninger, som vi har brug for for at løse problemet. Her kan du finde vigtig information som hvilken bruger der kører sætningerne, hvilken database der er påvirket og hvornår sessionen er angivet. Den givne detaljedybde er en reel tidsbesparelse for de DBA'er, der har brug for hurtige svar på, hvad der forårsager blokering, så de kan løse det. Du kan ikke kun se, at du har to blokerede overgange, men vi kan også se, at de begge er UPDATE-udsagn på den samme tabel, der køres af Network Services-kontoen mod Salg-databasen. Selve opgørelsen er vist i nederste højre hjørne. Til sidst kan vi se både det aktive SPID og det SPID, det blokeres af.

Mod det øverste højre hjørne af figur 3, i blå tekst, fortæller Spotlight Cloud dig, hvor du skal gå videre i din undersøgelse. Produktet inden for hvert lag giver en klar vej til, hvordan man kan dykke endnu dybere. Ved at klikke på linket Undersøg i Workload Analyzer kan du se, hvad der påkaldte SPID 61, som tilfældigvis er en lead-blokering for SPID 65.

Figur 4:Workload Analyzer (det er her, vi vil udvide blokerede sessioner)

Workload Analyzer giver dig en drilldown-dimension, der giver dig mulighed for at køre ind i specifikke ressourcer såsom blokering. I figur 4 kan du se, hvordan vi dykker længere ned ved at klikke på de to udvidelsespile i hjørnet af sektionen Blokerede sessioner.

Figur 5:Oplysninger om blokerede sessioner

Nu hvor du kender den involverede database, kan du grave lidt længere. På venstre navigation kan du bore i salgsdatabasen. Her kan du se SPID 61 og 64 inklusive den aktuelle status. Begge disse systemproces-id'er blokerer, og bemærk, at SPID 59 nu også er blokeret af SPID 64. Denne visning er med til at sikre, at du kan være på forkant med blokeringen, mens du fortsætter med at undersøge.

I den nederste halvdel af figur 5 kan du se i Blocked Session Mapping, at den fortæller dig detaljerne i SPID 61, som i dette tilfælde er vores lead blocker. Synderen er faktisk en del af et SQL Agent Job, der kører, hvilket giver mening baseret på den bruger, vi fandt, der kører sætningen. Hvis du husker, at det var netværkstjenestekontoen, NT AUTHORITY\NETWORK SERVICE. I dette tilfælde kører SQL Agent Service under dette særlige sæt legitimationsoplysninger.

Det næste trin er at finde ud af, hvilke job der kører, og se om du kan dræbe jobbet for at stoppe blokeringen. Normalt ville du gå ud til SQL Server Management Studio for at gennemgå SQL Agent og se på jobs, men Spotlight gør det nemt for dig og giver dig også et omfattende overblik over jobs. Du kan finde dette ved at klikke på pilen ved siden af ​​ordene "Workload Analyzer" øverst, ligesom du gjorde, da du navigerede fra Oversigt til Sessioner.

Figur 6:Dropdown fra Workload Analyzer

Forebyggelse af fremtidige SQL Server-blokke

At undersøge blokering tager tid, og nogle gange, mens vi undersøger et bestemt problem, løser blokeringen sig selv. I dette tilfælde var det job, der kørte, fuldført, og de opdateringer, der blev blokeret, kunne køre. Selvom det umiddelbare problem ikke længere eksisterer, er du stadig nødt til at blive ved med at grave efter årsagen for at sikre, at du kan forhindre det i fremtiden.

Da du allerede har identificeret SPID 61 som det job, der kørte, og fordi tiden er gået, skal du nu se på historien. For at gennemgå historikken skal du blot ændre det datointerval, der vises, til tidsintervallet for den aktive blokering. I figur 7 kan du se datointervallet i højre hjørne, du kan klikke på rullemenuen og justere tiderne i overensstemmelse hermed. Dernæst vil du søge efter SPID 61 ved hjælp af søgefunktionen. Hvert miljø er anderledes, så hvad du gør med disse oplysninger vil nu afhænge. Om du justerer timingen af ​​jobbet, foretager nogle ændringer i indekser, kode eller konfigurationer, er helt op til dig.

Figur 7 job

Figur 8:Lange løbeblokke

Nogle blokke kommer og går bare så hurtigt, at de ikke har nogen væsentlig effekt på ydeevnen. Når de bliver ved længere, skal vi vide om dette hurtigt. Spotlight Cloud har en "long running lock"-alarm, der giver brugeren besked om blokke, der ikke forsvinder.

Figur 9:Dimension af blokeret objekt

Blokering er et symptom på nogle større problemer, og det kræver ofte forskellige perspektiver at nå frem til årsagen. Dimensionen for blokerede objekter i Spotlight Cloud-arbejdsbelastningsanalysatoren giver brugeren mulighed for hurtigt at finde ud af objekter, der genererer den mest blokerende aktivitet for en given instans.

At identificere blokering og grave i årsagen er den sværeste del for DBA'er. Spotlight Cloud Professional giver os mulighed for at komme til disse oplysninger hurtigt og effektivt. Når tiden løser det aktive problem, giver Spotlight Cloud os mulighed for at blive ved med at undersøge for at finde frem til en grundlæggende årsag og i sidste ende giver os den information, vi har brug for til at træffe informerede beslutninger om, hvordan vi forhindrer fremtidige hændelser.

Vil du se Spotlight Cloud i aktion? Start din gratis 30-dages prøveperiode i dag.


  1. Hvordan kan jeg tælle antallet af ord i en streng i Oracle?

  2. Hvordan kan jeg få en liste over elementnavne fra en XML-værdi i SQL Server

  3. Sådan bundter du cx_oracle med Pyinstaller

  4. 6 sjove fakta om Microsoft, som du sandsynligvis ikke kender!