Nieuwsbrief april 2021

Na mijn eerste nieuwsbrief van drie maanden geleden, hier de volgende met hopelijk een paar interessante onderwerpen uit mijn praktijk.

Wil je de nieuwsbrieven niet ontvangen, laat het me weten.

Met hartelijke groet,

Paul van Oordt

Pakketselectie, eisen aan de datalaag

Al de aanbevelingen voor het ontwikkelen op SQL Server gelden ook wanneer je overweegt een pakket aan te schaffen, bijvoorbeeld een ERP of warehouse management systeem. Wijzigingen op de datalaag zijn notoir moeilijk om door te voeren. Daar heeft niet alleen de ontwikkelaar van het pakket last van, maar jij als gebruiker straks ook. Hoe beter het pakket op de datalaag gebruikt maakt van juiste SQL Server technieken, hoe beter de datakwaliteit, de performance, de schaalbaarheid en de uitbreidbaarheid van je systeem.

Ik het bijzonder van belang zijn ten eerste een adequaat genormaliseerd datamodel met de juiste datatypes, nullability en foreign keys, en daarnaast een gedegen indexering en een efficiënte wijze van benaderen van de data. Zijn queries set-based, geschreven met kennis van zaken en maken ze gebruik van recente mogelijkheden die SQL Server biedt? Worden stored procedures gebruikt of is de code ad hoc? Hoe wordt een goede concurrency gerealiseerd? Zijn er lange locks? Wordt nolock gebruikt, wat tot incorrecte resultaten kan leiden (dit komt veel voor, ook bij bekende pakketten), of het veel betere optimistic locking met read committed snapshot isolation? Of kan je dit allemaal niet zien omdat de code encrypted is? En kan je zelf tunen en zo (cloud)kosten beperken, bijvoorbeeld door het aanmaken van indexes? Zo niet, gaat de leverancier dat dan voor je doen?

Het is logisch dat je vooral kijkt naar de functionaliteit van een pakket, maar ook de onderliggende database is héél belangrijk en bepaalt in hoge mate de kwaliteit van de data - jouw data. Zo lijkt het misschien een kleinigheid in het kader van een pakketselectie, maar een database met of zonder trusted foreign keys is een wereld van verschil als je de data ooit exporteert en zelf wilt verwerken. Mijn advies: Laat je niet verrassen en kijk kritisch naar de onderliggende database!

Index-(de)fragmentatie, een ontwikkelaars-verantwoordelijkheid

Bij performance-problemen wordt vaak als eerste aan index-fragmentatie gedacht. Fragmentatie van een index betekent dat de fysieke volgorde van de index-pagina's op disk afwijkt van de logische volgorde. Wanneer data van een spinning disk moet komen, vertraagt dit een ordered scan van de index. Maar niet alle indexes fragmenteren en fragmentatie is niet altijd een probleem, sowieso niet bij overvloedig geheugen en/of data op SSD.

Wekelijks of dagelijks defragmenteren van alle indexes (vaker kom ik ook wel eens tegen) kan ik niet zo maar aanbevelen. Het kan tijdelijk de performance behoorlijk verslechteren. Bovendien is de capaciteit waarmee dit gebeurt niet gratis, zeker niet in de cloud. Ook als de performance verbetert na defragmentatie zegt dat nog niet veel. Een index rebuild doet ook een statistics update en kan daarmee leiden tot een beter query plan. Alleen een statistics update uitvoeren is dan beter.

Het is mijn opvatting dat het creëren van de juiste indexes een verantwoordelijkheid is van de ontwikkelaar. Alleen deze weet hoe de data benaderd wordt. Bij het maken van een index kan direct nagedacht worden over het beheer ervan. Fragmenteert deze index? Is dat een probleem? Zo ja, wat is het defragmentatie-regime en de fill factor? Een index kan dan worden toegevoegd aan een job die defragmentatie uitvoert van een selectie van indexes. Zo kunnen ook indexes gedefragmenteerd worden die als gevolg van updates of deletes lijden aan een lage page-fullness (soms interne fragmentatie genoemd).

Pas altijd op met rebuild, zeker van grote indexes. Dit kan voor aanzienlijke tijd de executie en zelfs de compilatie van queries blokkeren. De Enterprise Edition heeft de optie om een rebuild online te doen waarbij deze problemen niet optreden. Kies anders voor een reorganize van de index.

En als de ontwikkelaars dit niet hebben geregeld? Dan zal een DBA het moeten doen. Query tuning kan duidelijk maken of fragmentatie een probleem is en geeft ook inzicht in de vele andere factoren die een rol spelen bij performance.

april 2021; de nieuwsbrief verschijnt enkele keren per jaar; aanmelden / afmelden