Houdbaarheidsdatum SQL Server verstreken? Tijd voor grip
Waarom wachten met upgraden zelden een slimme keuze is SQL Server 2012 en 2014 raken buiten beeld. De ondersteuning is…
De belofte van Optimized Locking
Optimized Locking helpt voorkomen dat wanneer er op een tabel een groot aantal updates gedaan wordt, er lock-escalatie plaatsvindt. De lock-escalatie leidt tot een table lock en dat zorgt ervoor dat er geen select op de tabel gedaan kan worden. Dat kan vrij hinderlijk zijn en soms zelfs tot deadlocks leiden.
Bij de “What’s new in SQL Server 2025” sessies tijdens conferenties werd dit met een demo aangetoond. Eerst werd getoond dat het uitvoeren van query’s tijdens een update van 10.000 rijen tot een error leidde. Daarna, met Optimized Locking aan, konden er in een ander window gewoon query’s uitgevoerd worden. Indrukwekkend.
De techniek onder de motorkap
Optimized Locking werkt niet meer met row identifier locks die geplaatst worden in het lock-geheugen, maar plaatst een transaction ID bij de rij in de tabel zelf. Bij een grote hoeveelheid locks raakt het geheugen normaal gesproken vol en volgt er lock-escalatie. De row lock wordt dan omgezet naar een table lock en andere sessies kunnen de tabel niet meer benaderen.
Wil je Optimized Locking aanzetten? Dan gaat dit met ALTER DATABASE … SET OPTIMIZED_LOCKING = ON. Het lijkt allemaal heel mooi, maar is er dan geen nadeel?
De keerzijde van de medaille
Jazeker, er is ook een nadeel. En dat zit hem vooral in de andere features die ervoor nodig zijn: Accelerated Database Recovery (ADR) en Read Committed Snapshot Isolation (RCSI). Nou zal RCSI je niet zo snel dwarszitten, dit is een feature die in weinig gevallen negatieve invloed heeft. ADR is een ander verhaal.
ADR is, zoals de naam al doet vermoeden, een feature die ervoor zorgt dat long-running transacties op een snelle manier teruggaan bij een rollback. Dit bereiken ze door onder andere een Persistent Version Store (PVS) te gebruiken. Deze houdt persistente versies van de rijen bij in de database zelf.
Waar de schoen wringt
De nadelen ontstaan doordat versies van rijen na een wijziging in de database zelf worden bijgehouden. Deze staan bij kleine tot middelgrote rijen op dezelfde page en bij grotere komen ze op een speciale PVS-page. De version cleaner ruimt ze na een tijdje weer op.
Het nadeel? Er is tijdelijk steeds extra ruimte nodig. Ook bij updates die de lengte van de rij niet aanpassen, gaat de tabel groeien. Daardoor vinden er allerlei page-splits plaats. Dit leidt tot fragmentatie van de tabel en rebuilds doen weinig, doordat na de rebuild updates weer direct hetzelfde veroorzaken.
En grotere tabellen zorgen voor langere back-up-tijden, meer tijd voor een table scan en meer van dat soort zaken. In veel situaties zal de performance achteruitgaan.
Wanneer het wél de juiste keuze is
Nu is dit bij PostgreSQL al jaren de standaard en zij leveren toch een populaire database. Maar bedenk wel dat dit een feature is die, zoals zoveel SQL Server-features, je niet moet gebruiken als je er geen probleem mee oplost.
Dus alleen aanzetten op een database waar grote transacties lopen die leiden tot (dead)lock-problemen. Het is een afweging tussen lockproblemen en performanceproblemen, die het beste getackeld kan worden met goed testen.
Bedenk ook dat ADR een database-scoped configuratieparameter is. Heb je maar één tabel die dit soort problemen heeft? Dan moet deze tabel afgesplitst worden in een aparte database om de andere tabellen niet te beïnvloeden.
De nuchtere conclusie
Optimized Locking is een krachtige toevoeging aan SQL Server 2025, maar geen wondermiddel. Bob Ward heeft gelijk dat het een verbetering is voor specifieke scenario’s. Maar het vraagt om zorgvuldige afweging.
Voor databases met veel gelijktijdige updates en deadlock-problemen kan het een uitkomst zijn. Voor andere workloads weeg je beter zorgvuldig de voor- en nadelen af. Test uitgebreid in een realistische omgeving voordat je deze feature in productie zet. Monitor niet alleen de lock-wait-statistics, maar ook storagegroei, fragmentatie en algemene queryprestaties.
Want uiteindelijk is het een afweging: accepteer je de performance-impact voor betere concurrency? Of zoek je een andere oplossing voor je lockproblemen? Die keuze kan alleen jij maken, met goede tests en realistische metingen.
Wil je eens praten of Optimized Locking jouw problemen kan oplossen?
Mijn collega’s en ik helpen je graag met het evalueren van nieuwe features en het optimaliseren van je SQL Server-omgeving. Neem contact op voor advies op maat.
