Herken je het beeld dat je seconden lang naar je monitor zit te staren, hoe een zandloper rond draait, terwijl je alleen maar een artikelkaart van je ERP aan het openen bent? We zijn veelal gewend om informatie direct beschikbaar te hebben en wanneer dat niet gebeurt dan begint de frustratie flink toe te nemen.
Als SQL-specialist krijg ik regelmatig de vraag : “Waarom is mijn SQL-server traag?”
Hoewel dit een makkelijke vraag is, is het antwoord lastiger om direct te geven.
Probleem-analyse SQL-server
Bij een analyse van performance problemen zal deze zich dan ook moeten richten op de bovengenoemde resources. De problemen worden vaak niet veroorzaakt door verkeerde hardware, maar meer door het inefficiënt gebruik van één van genoemde resources. Zoekopdrachten (query’s) die te veel tijd nodig hebben of query’s die steeds opnieuw uitgevoerd worden. Dit kan allemaal een enorme impact hebben op de performance van je SQL-server. Maar ook onvolledige of zelfs niet gebruikte indexen kunnen een reden zijn. Soms geeft een simpele aanpassing in de logica van een query al het gewenste resultaat. Heb je geen indexen bepaald in je SQL-server of heb je ze wel aangebracht maar worden ze niet bijgewerkt, dan kan dit ook een bron van frustratie opleveren voor de eindgebruiker. Pas als je het idee en gevoel hebt dat dit niet meer efficiënter kan dan kan er gekeken worden naar de hardware.
En dan?
Stel je hebt je SQL-server optimaal draaien, maar wat gebeurt er als er een calamiteit optreedt en je database niet meer opstart? Een nachtmerrie voor elk bedrijf die geen goed beeld heeft van hun ‘disaster recovery’.
- Worden er dagelijks back-ups gemaakt?
- Zijn deze back-ups betrouwbaar?
- Waar staan de back-ups?
Allemaal vragen die eigenlijk niet gesteld zouden hoeven worden mits het allemaal geregeld en gedocumenteerd is.
Hoeveel dataverlies is acceptabel?
De vraag die ik vaak stel aan klanten is: “Als midden op de dag je database corrupt raakt en niet meer te repareren is en je moet een back-up terugzetten. Hoeveel dataverlies is dan acceptabel? 1 uur, 2 uur of een halve dag?”
Vaak wordt geantwoord ‘geen‘ maar in de praktijk is dat lastiger te realiseren. In heel veel gevallen moet ik het nieuws vertellen dat er alleen ’s nachts een back-up wordt gemaakt. Dit betekent dat je in geval van calamiteiten op het midden van de dag, een halve dag werk kwijt bent. Wanneer je heel erg afhankelijk bent van je data in je database dan is dit een rampscenario natuurlijk. Maar de oplossing is heel simpel door bijvoorbeeld ieder uur ‘log’ back-ups te maken.
Een jaarlijkse brandoefening
Samen met je ‘full’ back-up van ’s nachts vormt dit je herstel van de gegevens met minimaal verlies van data. Als je dit nu helemaal tot in de puntjes geregeld hebt, wat dan? Weet je dan wat je moet doen tijdens een calamiteit? Vaak niet, want in de praktijk vertrouw je erop dat het geregeld is.
Ik raad aan om minimaal 1 x per jaar een soort ‘brandoefening’ te doen om te checken of alles werkt en om te zien waar er nog aanpassingen gedaan moeten worden.