Hur dåliga kan SQL Server-låsningar vara? – Recensioner av datorteknik

Innehållsförteckning

• Få upp farten med blockerat låsläge
• Med en balanserad bild

Förstå fördelarna med att blockera

• Värsta fall
• Åtgärda problem med dödläge

Få upp farten med dödläge

Innan du går in i kärnan i saken är det värt att fastställa grunderna för dödlägen i en SQL-servermiljö.

I de enklaste termerna, död låsningar uppstår när två processer har ett exklusivt lås på samma resurser, vilket innebär att det inte finns något sätt för dem att gå vidare utan att en avbryts. Experterna på SentryOne har förklarat detta mer i detalj och du kan läsa artikeln här för en mer djupgående titt på muttrarna och bultarna för blockering.

Ta en balanserad bild

Även om de kan låta dåliga är låsningar faktiskt mycket vanliga och bör inte nödvändigtvis ses som ett stort problem när de uppstår, även om det uppenbarligen finns några stora undantag som kommer att kräva ingripande.

Anledningen till att dödlägen är önskvärda är att de är väsentliga för att upprätthålla dataintegriteten i fallet att flera appar kommer att göra förfrågningar från din server samtidigt. Utan låsning skulle saker och ting snabbt hamna i kaos.

Det viktigaste problemet som de tar upp är att processen som avslutas av programvaran när en konflikt uppstår inte slutförs. Detta innebär att det måste startas om för att gå igenom, och om dödläget inträffar igen kan det hamna i en ond cirkel, vilket äventyrar prestandan.

Förstå fördelarna med blockering

En sak som alla databasadministratörer måste fastställa är att det finns en skillnad mellan fullständiga dödlägen och den mycket mer acceptabla blockeringen som förekommer i detta sammanhang.

Precis som låsning, när serverresurser är låsta av en viss process, kan ingen annan process svepa in förrän den har avslutad. Skillnaden är att blockering inte kommer att leda till att någon process avslutas; de som står i kö för att tilldelas en resurs väntar tålmodigt på sin tur, tills blockeringen lindras. Deadlocks indikerar att ett låsningsproblem inte kan lösas utan en brute force approach, vilket uppenbarligen inte är idealiskt. Det är därför viktigt att inte blanda ihop blockering med blockerat låsläge, eftersom detta kan försvåra dina underhållsinsatser.

Worst case scenarios

Så med allt detta i åtanke, hur illa kan dödlägen bli och är detta något du bör prioritera? Tja, det värsta scenariot är att ett dödläge mellan två processer upprepas upprepade gånger, där en av processerna ständigt pekas ut som offer och avslutas av programvaran innan den kan slutföras.

Om detta händer gång på gång, även om du har en mekanism på plats för att återuppta offerprocessen efter att den har avslutats, kommer din databas att fungera under- optimalt.

Vissa dödlägen är engångsinstanser, vilket säkert kan ses som att servern fungerar som det borde, medan de som fortsätter att dyka upp behöver hanteras.

Åtgärda problem med dödläge Det finns några sätt att ta itu med låsning på en SQL-server, varav det första är att ställa in spårningsflaggor och manuellt rita ut de dödlägen som uppstår så att du kan avgöra vilka processer, låsprioriteringar och uttalanden som ska vara överensstämmande. liorated.

Du kan också använda separata SQL-serverövervakningsprogram för att ta bort mycket av benarbetet ekvationen och ge automatisk detektering av dödlägen.

Ibland är den skyldige helt enkelt att schemalägga för många uppgifter för samma tidsperiod; var noga med att inkludera denna möjlighet i dina utredningar.

Kom ihåg framför allt att inte få panik när det låser sig inträffa, eftersom du kan använda de verktyg som står till ditt förfogande för att hantera dem och det är långt ifrån en katastrof för din SQL-databas. Inför regelbundna kontroller för dödlägen som en del av ditt bredare serverunderhållsschema och dina data bör vara tillgängliga effektivt och säkert, var du än förvarar dem.