Toen marktleider Aartsen overstapte op een nieuw ERP-systeem ontstond er vertraging in de hele versketen. Maar waarom? Twintos ontrafelde het mysterie en bouwde een systeem dat zichzelf versnelt. Kijk mee hoe we Aartsen met proactief database beheer helpen om de oogst op tijd te leveren.
Marktleider in groenten en fruit
Aartsen is de Nederlandse marktleider in de internationale import en export van groenten en fruit. Nu, terwijl jij naar deze case kijkt, reizen zeker 75.000 kratten van Aartsen vol met aardbeien, boerenkool en nog veel meer groenten en fruit razendsnel naar meer dan 1.000 afnemers in West-Europa en Azië. Elke dag opnieuw.
En daarbij telt elke minuut, want de centrale belofte van Aartsen is: vers. Sla, tomaten, bosbessen – alles moet kraakvers aankomen bij de klant.
AS/400 migratie naar Thinkwise ERP-systeem
Rond 2022 ging Aartsen over op een nieuw ERP-omgeving, of Enterprise Resource Planning systeem. Dit is hét centrale zenuwstelsel waarmee Aartsen de hele versketen aanstuurt en registreert. Van orders tot facturen; van realtime updates over voorraden tot zendingen naar de klant; alles is hierin met elkaar verbonden.
Zonder dit ERP-systeem komt de hele versketen van Aartsen piepend tot stilstand. Dan blijven tienduizenden kratten met dagverse oogst staan bij de teler of in de distributiecentra van Aartsen. Winkels, hotels en andere klanten van Aartsen kunnen die dag niet bestellen. Mensen stuiten op lege schappen in winkels van Parijs tot Hong Kong. Geen abrikozen, mango’s, daikon, paksoi, druiven, sterfruit en dadels meer.
‘Megaproject voor Aartsen’
Edward Dortland, mede-oprichter van Twintos: ‘de overgang naar dit nieuwe systeem was een megaproject voor Aartsen, met heel veel verschillende radertjes en veranderingen voor de medewerkers.’
Conversie van AS/400 naar Thinkwise ERP
Het oude ERP-systeem draaide op IBM’s AS/400-platform. Dit dateert uit de jaren ’80 en toch draait het nog in verrassend veel bedrijven. Maar voor de snelheid en schaalbaarheid die Aartsen nodig had, schoot het tekort. Aartsen koos voor hypermoderne software op basis van Thinkwise. Aartsen noemde de nieuwe applicatie – hoe kon het ook anders – Fresh.
De klassieke performance-indicatoren als ‘is de disk traag’ zeggen niet genoeg. Ervaart de gebruiker zélf een probleem? Dat is de KPI waar het ons om gaat.
Geen sla zonder hoogbeschikbare database
Nou blijft deze hele internationale versketen natuurlijk alleen draaien als de database non-stop online blijft. Elke seconde moet Aartsens ERP-applicatie Fresh hier data in kunnen ophalen en wegschrijven. Daarom heeft Twintos voor Aartsen een hoogbeschikbare database-omgeving ingericht met 2 noden. De database draait synchroon in datacentra van Aartsen op 2 verschillende locaties. Als er ook maar even een onderbreking is op de ene locatie, schakelt het systeem over naar de andere. Maar dat was voor Twintos het makkelijkste deel van dit project.
Trage systemen: wat dit je organisatie echt kost
Want terwijl we hieraan werkten, zagen we al snel dat er nog iets nodig was. We merkten namelijk dat de teams die nieuwe modules van Fresh in gebruik namen, soms te maken kregen met grote vertragingen. Met name het salesteam had hier flink last van. Schermen deden er regelmatig minuten over om te laden. Het resultaat: tijdverlies in de hele verdere keten.
Maar vertragingen kosten meer dan alleen tijd. Als wij bij klanten komen kijken wat er precies gebeurt met de database, zien we alle emoties: van boosheid en frustratie tot lijdzame berusting, zelfs tranen zijn geen uitzondering. Klinkt misschien gek, maar ook daardoor verlies je iets als organisatie. Energie. Alertheid. En de drive die nodig is om flink de schouders eronder te zetten in tijden van topdrukte.
Maar: waarom moesten medewerkers zo lang wachten?
Het was in eerste instantie een mysterie waarom teams soms minutenlang een lege pagina op hun monitor zagen. En wat het nog onduidelijker maakte: het probleem kwam soms wel voor, en dan plotseling ging alles weer snel.
Vaak bleek er niks geks uit de basissignalen, zoals de CPU-load (belasting van de processor), het RAM-gebruik (belasting van het werkgeheugen) en de disk latency (vertraging bij het ophalen van data). Daarom besloten we veel dieper te duiken. Edward: ‘Dit ERP-systeem is de core van alles wat Aartsen doet. Daarom besloten we dat Aartsen supergoede monitoring nodig had.’
Bij een project als dit helpt het dat we ervaring hebben in alle sectoren. Voor deze superkrachtige monitoring dachten we meteen aan ChipSoft HiX, de applicatie voor het elektronisch patiëntendossier in de zorg.
Onverklaarbare storingen vind je niet met standaard monitoring
Edward: ‘Het mooie van HiX is namelijk dat je per gebruiker kunt zien hoelang het duurt om een scherm te laden. En dat is wat ons betreft de allerbelangrijkste KPI als het gaat om database performance.
Want de klassieke performance-indicatoren als ‘is de disk traag’ of ‘is het CPU-verbruik heel hoog’ zeggen niet genoeg. Ervaart de gebruiker zélf een probleem? Dat is de KPI waar het ons om gaat.’
Pas als we dat weten, kunnen we ervoor zorgen dat Aartsen die tienduizenden kratten met verse oogst op tijd bij de klant krijgt.
Een low-code applicatie maakt generieke code die werkt voor alle organisaties. Dat kan vertragingen veroorzaken.
Performance optimalisatie van low-code applicaties
Toen we de monitoring zo hadden gebouwd dat we precies konden volgen hoe snel elk scherm laadde bij de gebruiker, zagen we wat er gebeurde. De manier waarop het ERP-systeem informatie ophaalde uit de database, sloot niet aan bij Aartsen.
Wat snel te implementeren is, kan later tijd kosten
Het Thinkwise platform is gebouwd met de low-code filosofie: de applicatie is te configureren met beproefde standaardmodules. Je hoeft dus weinig te programmeren, je hebt geen lange ontwikkeltijd en kunt snel live. Fantastisch natuurlijk.
Maar dat kan wel een nadeel hebben. Edward: ‘De applicatie haalt data op met statements die werken voor elke organisatie; ze zijn dus niet geoptimaliseerd voor jouw specifieke situatie. Dat kan soms enorme vertragingen veroorzaken.
(Nerd mode: on)
Hoe ontstaat die vertraging in een modulair ERP-systeem?
Waarom werden mensen soms gek van de wachttijd en konden ze daarna ineens weer snel doorwerken? Stroop je mouwen maar op, voor een deep dive in SQL Server database-optimalisatie.
SQL Server maakt een plan van aanpak: een execution plan
In SQL Server zitten allerlei mechanismen die de snelheid opvoeren. Nummer 1: voor elke query gebruikt SQL Server een plan van aanpak (een execution plan) om zo snel mogelijk de data bij elkaar te zoeken. Daarin staat zoiets als: gebruik deze index, lees deze tabel en sorteer hier. Dit proces heet compileren.
Statistieken versnellen het samenstellen van zo’n plan
Om een goed plan van aanpak te kunnen maken, moet SQL Server weten hoe de data is verdeeld in elke kolom. Het zou teveel tijd kosten om dat voor elke query opnieuw uit te zoeken. Daarom maakt SQL Server statistieken waarin staat: in deze kolom komen deze waarden voor, en ongeveer zo vaak. Dat maakt het opstellen van een plan een stuk efficiënter. Dat is snelheidsfunctie nummer 2.
Hergebruik van plannen scheelt tijd bij de volgende query
Snelheidsfunctie nummer 3 is plan caching: het bewaren en hergebruiken van eerdere execution plannen bij volgende query’s. Dat scheelt compiletijd, want het maken van execution plannen kost rekenkracht en tijd.
Normaal werken deze functies allemaal prima. Maar: deze 3 mechanismen kunnen ook averechts werken. En dat was precies wat er bij Fresh gebeurde.
Probleem 1: dynamische queries maakten caching onmogelijk
In een ideale wereld hergebruikt de server dus zijn eerdere rekenwerk. Maar hier was elke query ‘uniek’ doordat ze dynamisch werden opgebouwd. Bijvoorbeeld: de ene keer werd er gefilterd op klant én datum, de andere keer alleen op klant. SQL Server zag dat telkens als een compleet nieuw vraagstuk, zonder het eerdere plan te gebruiken. Het resultaat: elke keer opnieuw compileren. In de complexe omgeving van Aartsen loopt de wachttijd dan snel op.
Probleem 2: parameter sniffing – goede plannen op het verkeerde moment
Soms werkte de server juist wél met gecachete plannen, maar dan op basis van de verkeerde informatie. Dat heet parameter sniffing: SQL Server ‘snuift’ aan een eerste query en hergebruikt die indruk blind voor de volgende. Een razendsnel plan voor het opvragen van facturen van een kleine klant wordt zo afgevuurd op een grote klant met miljoenen facturen, waardoor milliseconden ineens minuten worden. Dit is een risico bij modulaire software: de code is generiek, waardoor de engine vaker gokt of een plan nog past.
Probleem 3: plan regression – nieuwe plannen die slechter zijn
Bovendien werkte SQL Server soms automatisch de statistieken bij, wat leidde tot nieuwe execution plannen. In principe een goede zaak natuurlijk, verse statistieken. Maar in de praktijk genereerde SQL Server daardoor een nieuw plan dat juist trager was dan het oude. Dit heet plan regression: de strategie werd niet beter, maar slechter.
Zo maakten we onzichtbare performance-problemen zichtbaar
En dat is nou net waarom dit probleem voor veel IT-afdelingen zo frustrerend is. Soms is het systeem snel, en dan ineens lijkt het alsof er stroop door de raderen loopt. En als een gebruiker belt en zegt ‘het is traag’, zie je daar in de CPU-grafieken of serverlogs meestal niets van terug.
Met standaard monitoring kun je zoiets niet opsporen. Want je ziet niet dat een query op zichzelf snel is, maar wordt gebruikt voor de verkeerde parameters (parameter sniffing). Of je ziet wel een CPU-piek, maar niet dat de server bezwijkt onder het constant herberekenen van opdrachten (dynamische query’s zonder caching). En je ziet niet waarom het systeem ineens trager is (plan regression).
(Nerd mode: off)
We hebben samengewerkt met Thinkwise om query’s te versnellen zonder de low-code filosofie aan te tasten. Dat werkte enorm goed.
CPU-load gedaald van 70% naar 25%
Daarom monitoren wij ook op compiletijden en plan regression
Voor Aartsen wilden we daarom veel dieper in het zenuwstelsel van de server kunnen kijken. We bouwden monitoring op de Query Store, die de statistieken en execution plans registreert. Ons team kreeg een alert zodra een plan eruit sprong door een lange compiletijd, of als een query opeens trager liep. En dat werkte: zodra de meter uitsloeg, konden we Aartsen en Thinkwise helderheid geven over de probleemquery’s.
Zo konden de Thinkwise developers gericht optimaliseren. Ze verbouwden complexe dynamische query’s naar cachebare plannen. Query’s die gevoelig waren voor parameter sniffing werden gesplitst in specifieke procedures. En plannen die ontregeld raakten door automatische statistieken-updates, kregen een ander regime voor het onderhouden van statistieken.
CPU-belasting van 70% naar 25%
Edward: ‘Daarna hebben we bij de livegang van nieuwe modules samengewerkt met Aartsen en de developers van Thinkwise om query’s te versnellen, zonder de low-code filosofie aan te tasten. Dat werkte enorm goed. In één geval was het probleem zo groot dat we het ook konden zien in de CPU-belasting op de server: die was 70%. Rijkelijk hoog voor een omgeving met zoveel gebruikers. Na optimalisatie daalde de CPU-load naar 25%.’
De salesafdeling merkte het direct toen we de optimalisaties doorvoerden, vertelt Edward: ‘de salesmodule is dankzij onze samenwerking met Aartsen en Thinkwise ontzettend veel sneller geworden. Daar waren de salesmensen heel happy mee.’
Vaak accepteren organisaties trage systemen als een soort natuurwet. Maar aan Aartsen zie je dat het wel degelijk op te lossen is.
SQL Server database beheer: optimale performance voor Thinkwise ERP
Toen we dit mysterie eenmaal opgelost hadden, wilden we de databases zo inrichten dat Aartsen hier nooit meer last van heeft. Edward: ‘als de database er bij Aartsen mee ophoudt, blijven er direct 60 pallets met sla staan bij de teler. Dat kan gewoon niet.’ Daarom houden we die performance-winst nu vast met het dagelijks database beheer van Twintos.
Proactieve monitoring van SQL Server. De statistieken onderhouden we nu dynamisch, vertelt Edward: ‘veel organisaties houden een vast schema aan voor indexen- en statistiekenonderhoud. Terwijl die niet volgens een vast schema verouderen. Onze tooling detecteert daarom verouderde statistieken en initieert een update. We controleren periodiek op lange compiletijden of plan regression en passen zo nodig het onderhoudsplan aan. Of we melden probleemquery’s bij Aartsen, zodat een developer ernaar kan kijken.’
En ‘s nachts? 24/7 incident response. Onze monitoring houdt de database continu in de gaten en stuurt direct meldingen bij afwijkingen. Is het een ernstige melding, dan gaat die 24/7 direct naar de database engineer die dienst heeft. Vaak lossen we de meldingen al op nog vóórdat Aartsen er last van krijgt.
Backups en disaster recovery voor ERP. We maken doorlopend backups naar meerdere locaties. Zo kan Aartsen tot op de minuut een Point-in-Time Recovery uitvoeren. Maar een backup is pas je redding als de restore werkt. Edward: ‘databasegoeroe Paul Randal zegt altijd: backups maak je voor de lol, restores testen doe je voor je carrière.’ Ook restores testen doet Twintos automatisch. Zo bereiden we klanten voor op scenario’s waarin álles misgaat. Dat geeft rust.
Database security die ISO-normering overstijgt. Veiligheid vormt het hart van alles wat we doen bij Twintos.
- Versleuteling en patching. Hackers kunnen buiten het netwerk van Aartsen niets met de bestanden. Ook houden wij de software up-to-date.
- Server hardening. We denken kritisch mee over endpoint protection, firewalling en welke componenten we van een server af kunnen strippen.
- Grip op autorisaties. Het grootste doelwit voor hackers is: de mens. We minimaliseren risico’s met afgekaderde rechten access-tokens.
- Audit logging. Onze automatische logging legt elke toegang tot de database vast. Dit leveren we bij onze klanten in ter controle.
- Twintos is ISO-27001-gecertificeerd. Wij zien het als onze rol meer te doen dan voldoen aan de norm. We houden ook onze klanten waakzaam.
AS400 conversie naar Thinkwise: de rem is eraf
De migratie van Aartsen was meer dan een technische overstap. Het werd een reis langs onzichtbare vertragingen en risico’s voor de continuïteit die vaak onbelicht blijven. Maar nu staat er een omgeving die razendsnel draait en zich automatisch kan herstellen. Dat is database beheer zoals Twintos het ziet.
Edward: ‘vaak accepteren organisaties trage systemen als een soort natuurwet. Maar aan Aartsen zie je dat het wel degelijk op te lossen is, met specialistisch database beheer.’
Aartsen opereert nu op volle snelheid. Benieuwd hoeveel sneller jouw organisatie kan werken? Neem gerust contact op; we laten het je graag zien.
Mail Edward Dortland, onze managing director.
Of bel ons om te sparren: +31 85 1302910.