Använda Spotlight Cloud för att lösa blockering av SQL Server

SQL Server-blockering i en databas sker när en transaktion håller ett lås på en resurs och förhindrar en eller flera anslutningar från att fungera på samma resurs. Den andra anslutningen måste vänta på att låset släpper innan det kan fortsätta. Detta görs för att säkerställa isoleringskomponenten av ACID – vilket innebär att samtidiga transaktioner inte är synliga för varandra förrän de slutförs. Blockering i SQL Server kan förstöra prestanda i alla miljöer.

En av uppgifterna som databasadministratörer gör är att identifiera frågan som blockerar, åtgärda den och sedan gå ett steg längre för att fastställa grundorsaken. Att undersöka grundorsaken, särskilt i efterhand, kan vara en mycket svår uppgift. För de flesta innebär detta en mycket tidskrävande process att rota genom SQL Servers dynamiska hanteringsvyer som s ys.dm_exec_requests eller köra systemprocedurer som sp_who2 för att ta reda på detaljer om systemprocess-ID:n (SPIDS) som är involverade i blockkedjan. Spotlight Cloud kan avsevärt minska dina ansträngningar för att identifiera dessa blockerande händelser.

Använda databasövervakning för att identifiera SQL Server-block

Från och med översiktsinstrumentpanelen ger Spotlight Cloud en tydlig bild av hela miljön. Den visar mätvärden inklusive antal sessioner, processer, minnesanvändning, diskförbrukning och väntar på ett ögonkast. Ännu viktigare, det visar tydligt blockerande aktivitet; i mitten av figur 1 kan du tydligt se att det för närvarande finns två blockerade processer.

För en DBA är det nödvändigt att komma in i detaljerna för att lösa blockeringsproblem. Spotlight Cloud ger oss möjligheten att borra in mer detaljer i sessionen genom att helt enkelt välja rullgardinsmenyn från Översikt som visas i figur 2.

Figur 2:Dropdown från översikt

Spotlight Cloud låter dig enkelt se vilka sessioner som är blockerade och vilka uttalanden som är inblandade. I figur 3 kan du se att SPID 59 och 65 båda är blockerade (indikeras med orange markering runt statusen), vilket matchar antalet blockerade. Du kommer också att märka att Spotlight Cloud fortsätter att tillhandahålla sammanfattande detaljer om vårt nuvarande instansläge, vilket gör att vi kan hålla ett öga på viktiga räknare medan vi dyker in i prestandaproblem.

Använda Spotlight Cloud SQL Server Monitoring för att lösa blockeringsproblem

Sessions-instrumentpanelen (som ses i figur 3) ger oss viktig information som vi behöver för att lösa problemet. Här kan du hitta viktig information som vilken användare som kör satserna, vilken databas som påverkas och när sessionen angavs. Detaljdjupet som ges är en realtidssparare för de DBA:er som behöver snabba svar på vad som orsakar blockering, så att de kan lösa det. Du ser inte bara att du har två blockerade övergångar, utan vi kan också se att de båda är UPDATE-satser på samma tabell som körs av Network Services-kontot mot Sales-databasen. Själva uttalandet visas i det nedre högra hörnet. Slutligen kan vi se både den aktiva SPID och SPID den blockeras av.

Mot det övre högra hörnet av figur 3, i blå text, berättar Spotlight Cloud dig vart du ska gå härnäst i din undersökning. Produkten inom varje lager ger en tydlig väg om hur man kan dyka ännu djupare. Genom att klicka på länken Undersök i Workload Analyzer kan du se vad som anropade SPID 61 som råkar vara en lead-blockerare för SPID 65.

Workload Analyzer ger dig en detaljerad dimension som låter dig köra in i specifika resurser som blockering. I figur 4 kan du se hur vi dyker ner ytterligare genom att klicka på de två expanderpilarna i hörnet av avsnittet Blockerade sessioner.

Figur 5:Information om blockerade sessioner

Nu när du känner till databasen kan du gräva lite längre. På den vänstra navigeringen kan du borra in i försäljningsdatabasen. Här kan du se SPID 61 och 64 inklusive aktuell status. Båda dessa systemprocess-ID blockerar och noterar att SPID 59 nu också blockeras av SPID 64. Den här vyn hjälper till att säkerställa att du kan ligga steget före blockeringen medan du fortsätter att undersöka.

I den nedre halvan av figur 5 kan du se i kartläggningen av blockerade sessioner att den berättar detaljerna för SPID 61, som i det här fallet är vår huvudblockerare. Den skyldige är faktiskt en del av ett SQL Agent Job som körs, vilket är vettigt baserat på användaren vi hittade som kör uttalandet. Om du minns att det var nätverkstjänstkontot, NT AUTHORITY\NETWORK SERVICE. I den här instansen körs SQL Agent Service under denna speciella uppsättning autentiseringsuppgifter.

Nästa steg är att ta reda på vilka jobb som körs och se om du kan döda jobbet för att stoppa blockeringen. Normalt skulle du gå ut till SQL Server Management Studio för att granska SQL Agent och titta på jobben, men Spotlight gör det enkelt för dig och ger dig också en heltäckande bild av jobben. Du hittar detta genom att klicka på pilen bredvid orden "Workload Analyzer" högst upp precis som du gjorde när du navigerade från Översikt till Sessioner.

Figur 6:Dropdown från Workload Analyzer

Förhindra framtida SQL Server-blockeringar

Att undersöka blockering tar tid, och ibland, medan vi undersöker ett visst problem, löser blockeringen sig själv. I det här fallet kunde jobbet som kördes slutföras och uppdateringarna som blockerades köras. Även om det omedelbara problemet inte längre existerar, måste du fortsätta att leta efter grundorsaken för att se till att du kan förhindra det i framtiden.

Eftersom du redan har identifierat SPID 61 som jobbet som kördes och eftersom tiden har gått måste du nu behöva titta på historiken. För att granska historiken, ändra helt enkelt datumintervallet som visas till tidsintervallet för den aktiva blockeringen. I figur 7 kan du se datumintervallet i det högra hörnet du kan klicka på rullgardinsmenyn och anpassa tiderna därefter. Därefter vill du leta efter SPID 61 med hjälp av sökfunktionen. Varje miljö är olika så vad du gör med denna information kommer nu att bero på. Om du justerar tidpunkten för jobbet, gör några ändringar i index, kod eller konfigurationer är helt upp till dig.

Figur 7 jobb

Figur 8:Långa löparblock

Vissa block bara kommer och går så snabbt att de inte har någon nämnvärd effekt på prestandan. När de stannar kvar längre behöver vi veta om detta snabbt. Spotlight Cloud har ett "långvarigt lås"-larm som meddelar användaren om block som inte försvinner.

Figur 9:Dimensionen för blockerat objekt

Blockering är ett symptom på vissa större problem och det krävs ofta olika perspektiv för att komma fram till grundorsaken. Dimensionen för blockerade objekt i Spotlight Cloud Workload Analyser gör att användaren snabbt kan fastställa objekt som genererar den mest blockerande aktiviteten för en given instans.

Att identifiera blockering och gräva i orsaken är den svåraste delen för DBA:er. Spotlight Cloud Professional låter oss komma till denna information snabbt och effektivt. När tiden löser det aktiva problemet tillåter Spotlight Cloud oss ​​att fortsätta undersöka för att komma till en rotorsak och ger oss i slutändan den information vi behöver för att fatta välgrundade beslut om hur vi ska förhindra framtida händelser.

Vill du se Spotlight Cloud i aktion? Starta din kostnadsfria 30-dagars provperiod idag.