Met deze tekst willen wij niet alle problemen met betrekking tot een efficiënt databankbeheer in enkele lijnen oplossen. Het is echter onze bedoeling een eenvoudig voorbeeld te geven van hoe een SQL Server 2000© databank op een eenvoudige manier kan worden onderhouden. De lezer kan uit dit voorbeeld ideeën putten om een efficiënte onderhoudsstrategie op te stellen voor de situatie waarmee hij wordt geconfronteerd. In elk geval moet deze tekst niet worden gezien als een "kookrecept", het is vooral de bedoeling om enkele concepten uit te leggen.
SQL Server 2000© wordt standaard geleverd met twee krachtige programma's die ons in staat stellen een antwoord te geven op de vraag die gesteld wordt in de titel; die twee programma's zijn Enterprise Manager en SQL Server Agent. Het eerste programma staat op de installatie-cd-rom, men moet zich er enkel van vergewissen dat men het ook geïnstalleerd heeft (in dat geval staat het vermeld in het menu Microsoft SQL Server). Enterprise Manager wordt niet meegeleverd bij MSDE. SQL Server Agent is een dienst die gestuurd kan worden via de SQL Server Service Manager (het pictogram dat geïnstalleerd wordt in het traysysteem, links van de klok). Het meest praktische is om het vakje aan te vinken, zodat deze dienst automatisch opstart samen met Windows.
Enterprise Manager zal ons toelaten om de onderhoudsactiviteiten makkelijk in te stellen, die dan uiteindelijk zullen worden uitgevoerd door SQL Server Agent.
Laten we in Enterprise Manager een nieuw onderhoudsplan creëren.
De Masterdatabank bevat alle gegevens die nodig zijn voor de goede werking van SQL Server. Deze databank wordt slechts af en toe gewijzigd, bij verrichtingen aan de databanken zelf (aanmaak van een nieuwe databank, enz.). Toch integreren we ze in ons onderhoudsplan, gezien de erg bescheiden grootte en het onmisbare karakter ervan. Uiteraard moeten we ook de Mercatordatabank(en) (in dit geval "Mercatorfullv4") in het plan opnemen.
De opties die we achteraf selecteren, zullen mogelijk veel ruimte vrijmaken die echter op de harde schijf altijd toegewezen blijft aan de databank. Door de optie "Niet door databankbestanden gebruikte ruimte schrappen" aan te vinken, kan deze ruimte opnieuw beschikbaar worden gesteld voor andere applicaties. Logischerwijs moet deze verrichting zodanig worden gepland dat ze als laatste wordt uitgevoerd (in dit geval: dagelijks om 1 uur 's morgens).
In dit scherm kunnen de parameters worden ingesteld voor de back-up van de eigenlijke databanken. In ons voorbeeld plannen we de back-up zodat hij als eerste wordt uitgevoerd, dagelijks om middernacht.
De bovenstaande optie is erg interessant, ze biedt immers de mogelijkheid om oudere back-ups automatisch te wissen (in dit voorbeeld: back-ups ouder dan 4 weken).
Alle verrichtingen die uitgevoerd worden binnen een SQL Server-databank, worden gerealiseerd via transacties. Wanneer het onmogelijk is om een transactie te beëindigen, annuleert de SQL-server het hele transactiegedeelte dat al werd uitgevoerd. Dit noemen we een "roll back". Ook de omgekeerde handeling is mogelijk, namelijk transacties opnieuw toepassen op een databank; in dat geval spreken we van "roll forward". Dit is bijvoorbeeld interessant wanneer men een back-up wil herstellen, om vervolgens de transacties terug te brengen naar een bepaald uur waarop een verkeerde handeling werd gesteld. Daartoe maakt SQL Server een transactiejournaal aan waarin alle uitgevoerde transacties worden geregistreerd.
Een MSDE-databank wordt standaard ingesteld volgens een eenvoudig recuperatiemodel, een SQL Server-databank volgens het volledige model ("full recovery model"). In dit laatste model wordt het transactiejournaal nooit gewist, behalve wanneer men er een back-up van maakt. In het eerste model worden de transacties gewist naarmate ze voltooid zijn. Aangezien het transactiejournaal standaard ingesteld staat om oneindig aan te groeien, begrijpt men het belang van een regelmatige back-up van dit transactiejournaal wanneer men kiest voor het volledige model.
Merk wel dat, ongeacht het gekozen model, het bestand van het transactiejournaal nooit in grootte vermindert. Het overschrijft oude transacties hooguit met nieuwe. Om de grootte te verminderen, moet men de "Databank kleiner maken" ("shrink database"). Deze handeling wordt automatisch uitgevoerd indien u het vakje "Niet door databankbestanden gebruikte ruimte schrappen" aan het begin van de wizard hebt aangevinkt.
Ook de optie om oude back-ups automatisch te wissen, is hier beschikbaar.
Zodra uw onderhoudsplan volledig geconfigureerd is, raden we aan om regelmatig na te gaan of het ook correct wordt uitgevoerd. Zo zou het bijvoorbeeld kunnen gebeuren dat Agent SQL Server niet correct geladen wordt bij het opstarten. Om u te helpen bij de identificatie van problemen, beschikt elk onderhoudsplan over een bijbehorend foutenjournaal. Dit zal een fout van het type "Backup can not be performed on this database. This sub task is ignored" bijvoorbeeld systematisch vermelden bij de back-up van een databank die werd geconfigureerd volgens het eenvoudige recuperatiemodel. Dit is met name het geval bij de Masterdatabank. In dit stadium zal de lezer begrepen hebben dat deze fout logisch is en geen gevolgen heeft. Toch kan ze worden vermeden door twee afzonderlijke onderhoudsplannen te creëren: één met en één zonder back-up van het transactiejournaal. Volgens het recuperatiemodel van de verschillende databanken zou men het onderhoudsplan toewijzen aan het meest geschikte onderhoudsplan.