Database beheer

De verwachting is dat de performance van een SQL database goed is en blijft. Helaas is dit niet altijd de werkelijkheid. Want naar mate de tijd vordert zakt de performance van de database vaak steeds meer in. En op een bepaald moment gaan mensen dit merken en wordt gestart met een uitgebreid performance onderzoek.
Senet kan dit performance onderzoek uitvoeren en advies geven. Eventueel kan Senet ook op basis van nacalculatie of op projectbasis de adviezen verwerken.
Maar belangrijker nog is dat Senet ernaar streeft dit performance verlies te voorkomen door bij de software ontwikkeling al direct een database beheerder (DBA) te betrekken. Hierdoor kan bij aanvang van de ontwikkeling al direct DBA ervaring worden toegevoegd aan:

• Datamodellering,
• Optimale indexering,
• Query optimalisatie,
• Impact analyse van database componenten

Daarnaast dient een database ook altijd beschikbaar te zijn. Zeker indien uw klanten rechtstreeks gegevens kunnen opvragen via een website/webservice.
Gelukkig biedt Microsoft SQL Server veel high availability technieken zoals:

• Database mirroring,
• Log shipping,
• Replicatie,
• Database clustering

Voor de meeste van deze technieken is het van belang dat de database aan een aantal voorwaarden voldoet. Neem bijvoorbeeld replicatie, deze techniek vergt veel aandacht bij wijziging van de onderliggende structuur. Tijdens de ontwikkeling is het echter wel wenselijk de vrijheid om de structuur te wijzigen te behouden.
Een ander belangrijk aandachtspunt rondom beschikbaarheid is over welke gegevens het precies gaat. De behoefte om gegevens op te slaan neemt steeds meer toe, maar moeten deze dan ook altijd direct beschikbaar zijn? Vaak hoor je dat extra capaciteit in verhouding niet duur is. Maar is dat wel zo?:

RAID configuraties vragen minimaal dubbele harde schijf capaciteit,
Doorlooptijden van onderhoudsactiviteiten lopen op bij grote databases. Hier kan het gebeuren dat deze niet meer zijn uit te voeren binnen het gestelde tijdsbestek,
Capaciteiten van tapes zijn beperkt en alleen back-up op harde schijven is niet altijd acceptabel,
Conversies lopen lang. En al helemaal als deze niet in 1 keer correct loopt.

Kortom, het is goed bewust te zijn van de beschikbaarheid van gegevens zodat hiermee rekening gehouden kan worden bij het opzetten van een hardware/software architectuur. Daar dit één van de eerste stappen is van een project van Senet, is het dus ook nuttig om op dat moment DBA kennis er bij te betrekken.

Niet alleen worden steeds meer gegevens opgeslagen ook worden deze door steeds meer mensen bekeken en/of gewijzigd. Zolang de gegevens alleen binnen het eigen netwerk beschikbaar blijven, zijn de beveiligingeisen vaak overzichtelijk en duidelijk. Maar wat als de gegevens in de database ook via internet beschikbaar moeten zijn? Volstaat dan nog het ingestelde beveiligingsniveau? En zijn de applicaties die gebruik maken van een database ook zodanig opgezet dat deze bijvoorbeeld:

• Gebruikers identificeren en autoriseren
• Geen wachtwoorden over internet versturen
• Beveiligd zijn tegen SQL-injection
• Gebruikersinvoer controleren op scripting
• Niet rechtstreeks de database kunnen bereiken (maar middels webservices, datalaag of stored procedures)
• En mocht dan iemand toch op de database komen, heeft deze persoon dan ook direct controle over het gehele systeem?

Bij de beveiliging van een database is het van belang een balans te vinden tussen kosten en risico's. Het is onbetaalbaar een feilloos systeem op te zetten, echter is het eenvoudig inregelen van gebruikers met wachtwoorden niet meer voldoende tegenwoordig, zeker niet in combinatie met internet. Daarbij werkt beveiliging effectiever als deze vanaf het begin is meegenomen in de architectuur en niet achteraf eroverheen geprojecteerd wordt.
Tot slot is het net als bij beschikbaarheid van een database van belang te weten wat voor een soort gegevens in de database staan. Sommige gegevens vragen minder beveiliging als andere gegevens. Privacy gegevens mogen bijvoorbeeld nooit uitlekken, daarentegen zullen product gegevens van een webwinkel minder spannend zijn.

Net als een auto heeft ook een database zijn periodiek onderhoud nodig. Hoewel het bij de auto geaccepteerd en normaal is, is dit voor de database nog niet zo standaard. Echter kan ook een database in de problemen komen door het ontbreken van het onderhoud, met o.a. het volgende als gevolg:

• Veel extra benodigde schijfruimte, zowel database bestanden als back-ups
• Performance verlies
• Applicaties die zeer traag tot niet reageren door locks in de database
• Uiteindelijk corrupte databases

SQL Server heeft zelf een aantal mogelijkheden voor onderhoud die eenvoudig zijn in te zetten. Het blijft dan wel van belang de logboeken hiervan in de gaten te houden!
Senet kan hieraan invulling geven, door een DBA periodiek op afstand in te laten loggen en de bestaande procedures te controleren. Bij het ontbreken van een DBA kan ook advies gegeven worden en/of kunnen procedures hiervoor ingericht worden.
Naast het onderhoud dat een Microsoft SQL Server of een MySQL database nodig heeft kan het goed zijn dat 1 of meer applicaties zelf onderhoudsactiviteiten nodig hebben. Door een DBA bij het ontwikkelproces te betrekken, kan deze beide zaken op zich nemen. Met als resultaat dat ontwikkelaars meer tijd kunnen besteden aan de ontwikkeling van de software maar ook dat bij de oplevering het onderhoud op de database geregeld is.

Databases groeien en naarmate meer gegevens beschikbaar komen ontstaat ook vaak de behoefte gegevens anders te kunnen raadplegen. In eerste instantie zal hiervoor de reguliere database gebruikt worden. Omdat deze echter is opgezet om transacties te verwerken, blijkt deze vaak niet geschikt voor zware data analyses. Dit leidt vaak tot de geboorte van een datawarehouse database welke juist ideaal is voor data analyses en rapportages.
De complexiteit zit hem in het feit dat er nu 2 databases zijn welke aan elkaar gerelateerd dienen te blijven. Door het schrijven van een conversie routine (ETL) wordt de datawarehouse gevoed vanuit de andere (bron) database, hierbij is het van belang:

• Om de doorlooptijden minimaal te houden
• Alleen die informatie over te nemen die nodig is
• Tijdens deze conversie beide database niet teveel te belasten
• Een goede balans te vinden tussen accuratesse van de datawarehouse en belasting van de bron database
• Dat de datawarehouse op wens opnieuw kan worden gevuld vanuit de bron database
• Geen data verloren kan gaan tijdens deze conversie

Om het bovenstaande te realiseren is het belang deze conversie te laten opzetten door iemand die gespecialiseerd is in databases. Ook hierin kan Senet een belangrijke rol vervullen door inzet van zijn BI specialisten en/of database beheerders.