Hoewel we allemaal weten dat vergrendeling essentieel is voor gegevensintegriteit, verandert dit niets aan het feit dat het een serieuze doorn in het oog kan zijn!
Als we blokkeringen in onze database zien, gaan we er vaak vanuit dat er iets mis is – dat is niet altijd het geval. In mijn ervaring is het merendeel van de blokkering van SQL Server legitiem, maar het moet worden onderzocht en begrepen. Impasses daarentegen zijn zelden legitiem! Deadlocks worden in de SQL Server-wereld als kritiek beschouwd omdat processen automatisch worden afgebroken, aangezien SQL Server deadlocks oplost zonder handmatige tussenkomst. Nogmaals, ook al zijn ze "opgelost", ze moeten absoluut worden onderzocht en begrepen.
Er zijn een paar ontwerpstrategieën die kunnen helpen het voorkomen van SQL Server-blokkering en deadlocks in uw database te verminderen:
- Gebruik geclusterde indexen op tabellen die veel worden gebruikt
- Vermijd SQL-instructies met veel rijen
- Verdeel lange transacties in vele kortere transacties
- Zorg ervoor dat de UPDATE- en DELETE-instructies indexen gebruiken
- Plan geen batch-updatetaken zodat ze elkaar overlappen
- Houd je statistieken up-to-date
En ik weet zeker dat er nog veel meer zijn, maar de realiteit is dat je alle best practices kunt volgen die je kunt bedenken en nog steeds blokkades en impasses hebt. Dit komt omdat, in de meeste gevallen, deadlocks worden veroorzaakt door slecht ontworpen applicatiecode. (Het konijnenhol van applicatie-ontwerp:codering, transactie-isolatie en toegangspatronen. Maar laten we ons nu concentreren op het onderzoeken en begrijpen van blokkades en impasses).
SQL-serverblokkering en deadlocks
De eerste uitdaging met blokkeringen en impasses is om te identificeren wanneer en waar ze plaatsvinden, omdat ze meestal niet worden gemeld, achteraf worden gerapporteerd of automatisch worden opgelost. Om een echt begrip te krijgen van wat er in uw database gebeurt met betrekking tot blokkeringen en deadlocks, moet u hun gebeurtenissen in de loop van de tijd zien. Om het probleem op te lossen en toekomstige gebeurtenissen te stoppen, moet u ook de oorzaak van de blokkering aanpakken - uzelf bewapenen met informatie die u moet doorgeven aan de applicatie-ontwikkelaars en zo een einde maken aan het schuldspel tussen ontwikkelaars en DBA's.
Dit is waarom ik de Workload Analyzer zo leuk vind in Spotlight-cloud. Ik kan een tijdbereik selecteren - een uur, een dag of een aangepast bereik - en het Vergrendelen bekijken -gerelateerde activiteit voor dat bereik. Ik begrijp meteen beter wat er aan de hand is! Ik kan vergrendelingspatronen zien, de mate van vergrendeling in de loop van de tijd vergelijken met een eerder tijdbereik, de mate van blokkering over een specifiek tijdsbestek zien en vergrendelings-KPI's bekijken, zoals Lock Exclusive, Shared, &Update.
Dus nu wil ik naar de hoofdoorzaak gaan - dat is waar Dimensions Tree komt binnen. Ik kan de informatie voor een specifiek tijdsbestek filteren en filteren, zodat ik dezelfde informatie op diepere dimensies kan zien, zoals Databases , Gebruikers , Programma's , en SQL-statements , terwijl ik de "witte ruis" uitfilter terwijl ik bezig ben - duidelijk de bron(nen) van mijn probleem identificerend.
Hier kijk ik welke Databases ervaren de meeste vergrendeling gedurende de periode:
Nu ga ik dieper in op de Gebruikers binnen de geselecteerde database:
Vervolgens kies ik ervoor om de lijst met SQL-statements te zien waardoor vergrendeling werd uitgevoerd door de geselecteerde Gebruiker in de geselecteerde Database voor het opgegeven Tijdbereik .
Nu kan ik alle Vergrendelingen . zien gerelateerde informatie voor de geselecteerde SQL-instructie .
Dus als u uw problemen met vergrendeling, blokkering en impasse tot op de bodem wilt uitzoeken, raad ik u aan Spotlight Cloud te bekijken. Spotlight Cloud maakt het gemakkelijker dan ooit om de vergrendelingsproblemen in de database te onderzoeken en te begrijpen en er uiteindelijk voor te zorgen dat uw applicatiecode vrij van impasses is.