Ja, het grootste deel van databaseonderhoud kan worden uitgevoerd zonder downtime. Moderne databasesystemen zoals SQL Server en Azure SQL bieden online onderhoudsmogelijkheden waarmee indexen, statistieken en andere structuren worden bijgewerkt terwijl gebruikers gewoon doorwerken. Het sleutelwoord is planning: welke taken je wanneer uitvoert, bepaalt of je productieprocessen worden geraakt.
In dit artikel beantwoorden we de meest gestelde vragen over databaseonderhoud zonder downtime, van indexbeheer tot het inplannen van onderhoudstaken.
Welke onderhoudstaken veroorzaken downtime en welke niet?
De meeste reguliere onderhoudstaken veroorzaken geen downtime als ze correct worden uitgevoerd. Online indexonderhoud, het bijwerken van statistieken en het uitvoeren van integriteitscontroles kunnen allemaal plaatsvinden terwijl de database actief in gebruik is. Taken die wél downtime veroorzaken, zijn onder andere het toevoegen van bepaalde kolommen met standaardwaarden, het wijzigen van datatypes en sommige schema-aanpassingen.
Een handig onderscheid om te onthouden:
- Geen downtime nodig: online index rebuild, index reorganize, statistieken bijwerken, DBCC CHECKDB (met beperkte vergrendeling), logbackups
- Mogelijk korte downtime: offline index rebuild, het toevoegen van NOT NULL-kolommen zonder standaardwaarde, sommige tabelwijzigingen
- Downtime vereist: het wijzigen van een primaire sleutel, bepaalde partitioneringsoperaties, databasehersteloperaties
De grens tussen deze categorieën verschuift met elke nieuwe versie van SQL Server en Azure SQL. Wat vroeger downtime vereiste, is in modernere versies vaak online beschikbaar geworden. Het loont dus om regelmatig te controleren welke opties beschikbaar zijn voor jouw specifieke versie.
Hoe werkt online indexonderhoud in SQL Server en Azure SQL?
Online indexonderhoud in SQL Server en Azure SQL werkt door tijdelijk een extra kopie van de index te bouwen naast de bestaande versie. Gedurende dit proces blijven lees- en schrijfbewerkingen gewoon doorlopen op de originele index. Pas wanneer de nieuwe index volledig is opgebouwd, wordt de overschakeling gemaakt en wordt de oude versie verwijderd.
Dit mechanisme heet een online index operation en is beschikbaar via de ONLINE = ON optie bij een ALTER INDEX REBUILD statement. Het brengt wel extra schijfruimte en CPU-gebruik met zich mee, omdat de database tijdelijk twee versies van de index bijhoudt.
In Azure SQL en SQL Server Enterprise Edition zijn online index operaties standaard beschikbaar. In de Standard Edition zijn de mogelijkheden beperkter. Het is verstandig om dit vooraf te controleren, zodat je niet voor verrassingen staat tijdens een geplande onderhoudsronde.
Wat is het verschil tussen een index rebuild en een index reorganize?
Een index rebuild verwijdert de bestaande index volledig en bouwt deze opnieuw op, wat resulteert in een volledig gedefragmenteerde index. Een index reorganize herschikt de bestaande pagina’s van de index op hun plek, zonder de index te verwijderen. Reorganize is lichter en altijd online; rebuild is grondiger maar zwaarder voor het systeem.
Wanneer kies je voor rebuild?
Een rebuild is de juiste keuze wanneer de fragmentatie van een index boven de 30% uitkomt. De operatie kan online worden uitgevoerd (met ONLINE = ON), maar vergt meer resources en duurt langer. Na een rebuild worden ook de statistieken van de index automatisch bijgewerkt, wat een extra voordeel is.
Wanneer kies je voor reorganize?
Bij een fragmentatiegraad tussen de 10% en 30% is reorganize de voorkeurskeuze. De operatie is altijd online, onderbreekbaar en verbruikt minder resources. Het nadeel: statistieken worden niet automatisch bijgewerkt, dus die moeten apart worden bijgehouden. Voor drukke productiedatabases overdag is reorganize daardoor vaak de veiligste optie.
Kun je databasestatistieken bijwerken zonder de database te vergrendelen?
Ja, statistieken kunnen worden bijgewerkt zonder de database te vergrendelen. Het standaard UPDATE STATISTICS commando plaatst alleen een korte, gedeelde vergrendeling op de tabel tijdens het lezen van een steekproef van de data. Tijdens dit proces kunnen lees- en schrijfbewerkingen gewoon doorgaan. De vergrendeling is zo kort dat gebruikers er in de praktijk niets van merken.
Er zijn twee opties die het gedrag verder beïnvloeden:
- FULLSCAN: leest de volledige tabel in plaats van een steekproef, wat nauwkeurigere statistieken oplevert maar langer duurt
- SAMPLE: leest een percentage van de rijen, sneller maar minder precies
Voor de meeste productiedatabases is UPDATE STATISTICS WITH SAMPLE een goede balans tussen snelheid en nauwkeurigheid. Wil je maximale nauwkeurigheid, plan dan een FULLSCAN in buiten de drukste uren, ook al is downtime daarvoor niet nodig.
Hoe plan je onderhoudstaken in zonder productieprocessen te verstoren?
De kern van verstoringsvrij databaseonderhoud is het scheiden van zware taken van de drukste gebruiksperiodes. Dit doe je door onderhoudstaken te analyseren op resourcegebruik en ze te spreiden over momenten waarop de database minder belast is, zoals vroege ochtenduren of het weekend.
Een praktische aanpak:
- Monitor fragmentatie en statistieken voordat je onderhoud plant. Voer onderhoud alleen uit waar het nodig is, niet op schema voor alle objecten.
- Gebruik de Ola Hallengren maintenance solution of een vergelijkbaar framework dat automatisch bepaalt of rebuild of reorganize nodig is op basis van actuele fragmentatiewaarden.
- Beperk CPU- en schijfgebruik tijdens online operaties met de
MAXDOPenMAX_DURATIONopties, zodat andere processen niet worden verdrongen. - Stel prioriteiten: kritieke tabellen die veel worden bevraagd, verdienen frequenter onderhoud dan archiefdatabases.
- Test je onderhoudsvenster eerst op een niet-productieomgeving om de duur en het resourcegebruik te meten.
Een goed ingerichte data-omgeving maakt dit soort planning aanzienlijk eenvoudiger, omdat je altijd inzicht hebt in welke objecten onderhoud nodig hebben.
Wanneer is een gepland onderhoudsvenster toch onvermijdelijk?
Een gepland onderhoudsvenster is onvermijdelijk wanneer de benodigde wijziging geen online variant ondersteunt, of wanneer de combinatie van meerdere zware operaties het systeem te zwaar belast om naast productieverkeer uit te voeren. Denk aan grote schema-aanpassingen, het omzetten van een heap naar een geclusterde index op een zeer grote tabel, of het uitvoeren van een volledige databasehersteloperatie.
Situaties waarin een onderhoudsvenster verstandig of noodzakelijk is:
- Schema-wijzigingen die tabelstructuren fundamenteel aanpassen
- Migraties naar een nieuwe SQL Server versie of Azure SQL tier
- Het uitvoeren van een offline rebuild op een tabel die te groot is voor online operaties binnen aanvaardbare tijd
- Herstel na ernstige corruptie waarbij DBCC CHECKDB reparaties nodig zijn
- Wijzigingen aan beveiligingsinstellingen of authenticatiestructuren die actieve verbindingen beïnvloeden
Zelfs dan geldt: minimaliseer de impact door het onderhoudsvenster zo kort mogelijk te houden, gebruikers tijdig te informeren en een terugvalplan klaar te hebben. Een goed gedocumenteerde aanpak voorkomt dat een gepland venster uitloopt.
Hoe helpt Brander Company bij databaseonderhoud zonder downtime?
Wij ondersteunen organisaties bij het opzetten en uitvoeren van een professioneel database maintenance beleid dat aansluit op hun specifieke situatie. Of het nu gaat om SQL Server, Azure SQL, Oracle of PostgreSQL, we zorgen ervoor dat onderhoud plaatsvindt zonder dat productieprocessen worden verstoord.
Wat we concreet bieden:
- Analyse van de huidige onderhoudssituatie: welke taken worden uitgevoerd, wanneer en met welk effect op de beschikbaarheid
- Inrichting van geautomatiseerd indexonderhoud en statistiekenbeheer op basis van actuele fragmentatiewaarden
- Advies over online versus offline operaties, afgestemd op jouw SQL Server versie en workload
- Monitoring van databasegezondheid zodat onderhoud proactief wordt gepland in plaats van reactief
- Begeleiding bij schema-aanpassingen en migraties waarbij een onderhoudsvenster onvermijdelijk is
We geloven niet in generieke onderhoudsscripts die op elke database hetzelfde draaien. Elke omgeving is anders, en goed databaseonderhoud begint met inzicht in wat jouw systeem nodig heeft. Wil je weten hoe jouw database ervoor staat? Neem contact met ons op voor een vrijblijvend gesprek.
Frequently Asked Questions
Hoe weet ik of mijn indexen daadwerkelijk onderhoud nodig hebben?
Je kunt de fragmentatiegraad van indexen opvragen via de dynamische beheerweergave sys.dm_db_index_physical_stats. Deze geeft per index de gemiddelde fragmentatie in procenten terug, zodat je gericht onderhoud kunt plannen in plaats van alles op een vast schema te draaien. Een fragmentatie onder de 10% vereist doorgaans geen actie, tussen 10–30% is reorganize aanbevolen, en boven de 30% is een rebuild de betere keuze.
Wat zijn de meest gemaakte fouten bij het inplannen van databaseonderhoud?
Een veelgemaakte fout is het uitvoeren van onderhoud op alle indexen en statistieken op een vast tijdschema, ongeacht of ze het daadwerkelijk nodig hebben. Dit verspilt resources en vergroot onnodig het risico op verstoring. Een andere veelvoorkomende fout is het uitvoeren van online rebuilds zonder de beschikbare schijfruimte te controleren, terwijl de database tijdelijk twee versies van een index bijhoudt en daarvoor voldoende ruimte nodig is.
Kan ik een lopende onderhoudstaak afbreken als deze toch te veel impact heeft op de productie?
Ja, een index reorganize kan op elk moment worden onderbroken en hervat zonder dataverlies of corruptie. Een online index rebuild kan met de optie RESUMABLE = ON worden geconfigureerd, waardoor je de operatie kunt pauzeren en later hervatten vanaf het punt waar je gebleven was. Dit maakt het mogelijk om onderhoud te starten en veilig te stoppen als de impact toch groter blijkt dan verwacht.
Werkt online indexonderhoud ook goed bij zeer grote tabellen met miljoenen rijen?
Online indexonderhoud werkt ook bij grote tabellen, maar de duur en het resourcegebruik nemen uiteraard toe met de tabelgrootte. Voor zeer grote tabellen is het verstandig om de MAXDOP-optie te beperken zodat andere processen niet worden verdrongen, en om de RESUMABLE-optie te gebruiken zodat de operatie over meerdere onderhoudsvensters kan worden verspreid. Het is ook aan te raden om de operatie eerst in een testomgeving te timen voordat je deze in productie uitvoert.
Hoe ga ik om met databaseonderhoud in een Always On Availability Group-omgeving?
In een Always On Availability Group-omgeving moet je rekening houden met het feit dat onderhoudstaken op de primaire replica worden gerepliceerd naar de secundaire replica’s, wat extra netwerkbelasting en redo-activiteit op de secundairen veroorzaakt. Een gangbare aanpak is om statistieken bij te werken op de secundaire replica (indien de database readable is) en indexonderhoud te spreiden over meerdere sessies met beperkte MAXDOP. Controleer ook altijd de synchronisatiestatus na zware onderhoudstaken om te bevestigen dat de replica’s niet zijn achtergelopen.
Hoe vaak zou ik databaseonderhoud moeten uitvoeren?
Er is geen universele frequentie die voor elke database geldt; het hangt af van de hoeveelheid schrijfactiviteit, de grootte van de tabellen en de kritikaliteit van de data. Een drukke OLTP-database met veel inserts, updates en deletes kan wekelijks of zelfs meerdere keren per week indexonderhoud nodig hebben, terwijl een relatief statische rapportagedatabase maandelijks voldoende kan zijn. De beste aanpak is om fragmentatiewaarden en statistiekleeftijden actief te monitoren en onderhoud te triggeren op basis van drempelwaarden in plaats van een vaste kalender.
Wat is het verschil tussen databaseonderhoud in SQL Server on-premises en Azure SQL?
In Azure SQL neemt Microsoft een deel van het onderhoud automatisch over, zoals het bijwerken van statistieken en in sommige gevallen automatisch indexbeheer via de Automatic Tuning-functie. Dit betekent niet dat je zelf niets meer hoeft te doen: complexere onderhoudstaken, het bewaken van fragmentatie en het afstemmen op jouw specifieke workload blijven de verantwoordelijkheid van de beheerder. Het grote voordeel van Azure SQL is dat je geen rekening hoeft te houden met SQL Server-versielimieten voor online operaties, omdat Microsoft de onderliggende engine actueel houdt.
Related Articles
- Wat is RPO in datacenters?
- Hoe haal ik de database terug met database recovery?
- Welke certificeringen heeft een database expert nodig?
- Wat zijn database performance problemen?
- Wat kost een ERP systeem per jaar?
This content was generated with the help of AI — it may contain mistakes
