Selvom vi alle ved, at låsning er afgørende for dataintegriteten, ændrer det ikke på, at det kan være en alvorlig torn i øjet!
Når vi ser blokering i vores database, antager vi ofte, at der er noget galt - det er ikke altid tilfældet. Efter min erfaring er størstedelen af SQL Server-blokering legitim, men den skal undersøges og forstås. Deadlocks, på den anden side, er sjældent legitime! Deadlocks betragtes som kritiske i SQL Server-verdenen, fordi processer bliver dræbt automatisk, da SQL Server løser deadlocks uden at kræve manuel indgriben. Igen, selvom de er "løst", skal de helt sikkert undersøges og forstås.
Der er et par designstrategier, der kan hjælpe med at reducere forekomsten af SQL Server-blokering og deadlocks i din database:
- Brug klyngede indekser på tabeller med høj brug
- Undgå SQL-sætninger med højt antal rækker
- Opdel lange transaktioner i mange kortere transaktioner
- Sørg for, at UPDATE- og DELETE-sætninger bruger indekser
- Planlæg ikke batchopdateringsjob til at overlappe
- Hold din statistik opdateret
Og jeg er sikker på, at der er mange flere, men virkeligheden er, at du kan følge alle de bedste praksisser, du kan komme i tanke om, og stadig have blokering og dødvande. Dette skyldes, at deadlocks i de fleste tilfælde er forårsaget af dårligt designet applikationskode. (Applikationsdesignets kaninhul:kodning, transaktionsisolering og adgangsmønstre. Men lad os nu fokusere på at undersøge og forstå blokering og dødvande).
SQL-serverblokering og deadlocks
Den første udfordring med blokering og dødvande er at identificere, hvornår og hvor de sker, fordi de normalt ikke rapporteres, rapporteres efter kendsgerningen eller løses automatisk. For at få en reel forståelse af, hvad der sker i din database vedrørende blokering og deadlocks, skal du se deres forekomster over tid. For at rette op på problemet og stoppe fremtidige hændelser skal du også finde årsagen til blokeringen - bevæbne dig selv med information, du skal sende tilbage til applikationsudviklerne og dermed sætte en stopper for skydespillet mellem udviklere og DBA'er.
Det er derfor, jeg virkelig godt kan lide Workload Analyzer i Spotlight Cloud. Jeg kan vælge et tidsinterval – en time, en dag eller et brugerdefineret interval – og se Låsen -relateret aktivitet for det område. Med det samme har jeg en bedre forståelse af, hvad der foregår! Jeg kan se låsemønstre, sammenligne låsehastigheden over tid med et tidligere tidsinterval, se blokeringshastigheden over en bestemt tidsramme og se låse-KPI'er såsom Lock Exclusive, Shared &Update.
Så nu vil jeg komme til hovedårsagen - det er her Dimensions Tree kommer ind. Jeg kan bore ned og filtrere oplysningerne for en bestemt tidsramme, så jeg kan se de samme oplysninger i dybere dimensioner såsom Databaser , Brugere , Programmer og SQL-erklæringer , mens jeg filtrerer den "hvide støj" fra, mens jeg går - tydeligt identificerer kilden/kilderne til mit problem.
Her ser jeg på hvilke databaser oplever mest låsning i tidsintervallet:
Nu vil jeg se nærmere på Brugerne i den valgte database:
Så vælger jeg at se listen over SQL-erklæringer forårsager låsning, der blev udført af den valgte bruger i den valgte database for det angivne Tidsinterval .
Nu kan jeg se alle Låsning relaterede oplysninger for den valgte SQL-erklæring .
Så hvis du ønsker at komme til bunds i dine problemer med låsning, blokering og dødvande, anbefaler jeg, at du tjekker Spotlight Cloud ud. Spotlight Cloud gør det nemmere end nogensinde før at undersøge og forstå låseproblemerne i databasen og i sidste ende sikre, at din applikationskode er fri for dødvande.