Onderhoudsplannen in SQL Server bieden ons een gemakkelijke manier om taken te organiseren, configureren en plannen die ervoor zorgen dat de database-engine en de databases die daarin worden gehost, in vorm blijven.
Onderhoudsplannen bieden een databasebeheerder de mogelijkheid om belangrijke taken zoals indexering, statistische updates, back-ups, opschonen van logboeken en andere te configureren. In het vorige artikel hebben we al besproken hoe u een basisonderhoudsplan kunt maken om de consistentie van de database te controleren. In dit artikel zullen we een overzicht maken van het maken van een onderhoudsplan voor een database-instantie die kleine databases host. In de loop van de walkthrough zal ik de belangrijkste keuzes uitleggen die in elke stap zijn gemaakt in de context van een instantie met een redelijk groot aantal kleine databanken. Het idee is om het onderhoud voor deze databases te configureren zonder het één voor één te hoeven doen. De focus op kleine databases is bedoeld om de prestatieoverhead die gepaard gaat met onderhoudswerkzaamheden te vermijden.
Onderhoudsplan voor wekelijkse taken
Figuur 1:Wizard Onderhoudsplan starten
We starten de wizard Onderhoudsplan vanuit Objectverkenner>[Naam exemplaar]>Beheer>Onderhoudsplannen (zie afbeelding 1). De eerste pagina van de wizard geeft ons een overzicht van de taken die kunnen worden geconfigureerd. Hoewel er andere manieren zijn om deze taken uit te voeren met behulp van code en taakplanning, maakt de wizard Onderhoudsplan het vrij eenvoudig uit te voeren wanneer u te maken hebt met een groot aantal databases die op één instantie worden gehost.
Figuur 2:Wizard Onderhoudsplan
In Afbeelding 3 zien we dat SQL Server velden blootlegt die we kunnen gebruiken om het Onderhoudsplan te benoemen en te beschrijven. Het invoeren van een beschrijving van het plan is zinvol voor documentatiedoeleinden. Stelt u zich eens voor dat u een nieuwe SQL Server-instance overneemt bij een nieuw bedrijf. Het zou handig zijn als u beschrijvingen van SQL Server-objecten in de objecten vindt. Dat zou je ook voor anderen moeten doen. Let op:de beschrijving die ik heb gegeven is bedoeld om het punt eenvoudig te illustreren. Een meer gedetailleerde beschrijving is wenselijk in een productieomgeving.
Figuur 3:Het onderhoudsplan een naam geven
Merk op dat we in figuur 3 de optie hebben om te kiezen of we een enkel schema willen gebruiken voor alle taken of een apart schema voor elke taak. Ik heb ervoor gekozen om aparte schema's te gebruiken om de flexibiliteit te hebben om de taken te spreiden. We zouden niet willen dat te veel onderhoudsoperaties gelijktijdig of achtereenvolgens over een lange tijd worden uitgevoerd om het risico van overweldigende serverbronnen te vermijden. De beslissing die u op dit punt neemt, kan ook afhangen van de capaciteit van de beschikbare resources en het beschikbare onderhoudsvenster. Sommige mensen hebben voldoende capaciteit en zouden de taak tijdens elke run snel willen afronden. In het scenario dat in dit artikel wordt behandeld, gaan we ervan uit dat de betreffende instantie in het weekend niet wordt gebruikt.
In figuur 4 kiezen we de taken die we willen uitvoeren. Een van de geweldige dingen van SQL Server is dat elke taak onder aan het venster wordt beschreven. Het loont wanneer u als DBA werkt om te begrijpen wat u doet, zelfs wanneer u aan "Windows" werkt. In mijn ervaring hebben veel "beheerders" de gewoonte om gewoon op "VOLGENDE, VOLGENDE, VOLGENDE" te klikken omdat ze haast hebben om de functionaliteit werkend te krijgen. Maar als u de tijd neemt om de impact van de volgende "VOLGENDE" te begrijpen, zorgt u ervoor dat u iets doet dat waarde toevoegt en geen nieuwe problemen veroorzaakt.
Figuur 4:Onderhoudstaken selecteren
De taken die we hebben geselecteerd, worden als volgt beschreven:
De Controleer database-integriteit taak voert interne consistentiecontroles uit van de gegevens en indexpagina's in de database.
De Reorganiseer Index taak defragmenteert en comprimeert geclusterde en niet-geclusterde indexen op tabellen en views. Dit zal de prestaties van de indexscan verbeteren.
De Rebuild Index taak reorganiseert gegevens op de gegevens- en indexpagina's door indexen opnieuw op te bouwen. Dit verbetert de prestaties van indexscans en zoekacties. Deze taak optimaliseert ook de distributie van gegevens en vrije ruimte op de indexpagina's, wat een snellere toekomstige groei mogelijk maakt.
De Statistieken bijwerken taak zorgt ervoor dat de query-optimizer actuele informatie heeft over de verdeling van gegevenswaarden in de tabellen. Hierdoor kan de optimizer een beter oordeel vellen over strategieën voor gegevenstoegang.
De Geschiedenis opschonen taak verwijdert historische gegevens over back-up- en herstelbewerkingen, SQL Server Agent en onderhoudsplanbewerkingen. Met deze wizard kunt u het type en de leeftijd van de te verwijderen gegevens specificeren.
De Back-updatabase (volledig) task stelt u in staat om de brondatabases, doelbestanden of tapes en overschrijfopties voor een volledige back-up te specificeren.
De Onderhoudsopruiming taak verwijdert bestanden die overblijven bij het uitvoeren van een onderhoudsplan.
Figuur 5 laat zien waar we de volgorde selecteren waarin deze taken worden uitgevoerd. Dit is om een aantal redenen belangrijk. Het heeft bijvoorbeeld geen zin om een update van indexstatistieken uit te voeren na een Index Rebuild, aangezien een Index-rebuild ook een update van indexstatistieken in SQL Server uitvoert. Hoe we dit aanpakken, gezien de door ons gekozen volgorde, zullen we later in het artikel zien. Een andere mogelijke overweging is dat u kunt besluiten dat het verstandiger is om eerst een back-up te maken voordat u bepaalde soorten onderhoud uitvoert.
Figuur 5:Volgorde van taken
In figuur 6 kiezen we op welke databases we de eerste onderhoudstaak willen toepassen. We moeten dit ook voor elk van de volgende taken doen. Dit is belangrijk in die zin dat sommige databases mogelijk moeten worden vrijgesteld van dergelijke bewerkingen. Als u bijvoorbeeld een combinatie van Very Large Databases (VLDB's) en zeer kleine databases in dezelfde instance hebt (op zich al een slecht idee), moet u mogelijk de VLDB's uitsluiten van volledig blinde indexreconstructies. In zo'n geval moet u de sleuteltabellen in die VLDB identificeren en de verbouwingen en andere intensieve onderhoudswerkzaamheden richten op sleuteltabellen. In dit voorbeeld heb ik systeemdatabases uitgesloten omdat ik het onderhoud voor ze afzonderlijk zorgvuldig kan plannen. Ik ben van mening dat het veiliger is om systeemdatabases afzonderlijk te behandelen, aangezien eventuele schade eraan de hele instantie kan beïnvloeden.
Figuur 6:Bepaal het bereik
Elke onderhoudsoperatie heeft zijn eigen set van opties. Afbeelding 7 toont de opties die we moeten kiezen voor DBCC CHECKDB. Ik ben iets afgeweken van de standaardinstellingen door de MAXDOP te verhogen naar 2. In figuur 8 kiezen we ervoor om deze taak op zaterdag- en zondagavond om 01:00 uur uit te voeren.
Figuur 7:DBCC-opties
Figuur 8:DBCC-schema
De taak Index reorganiseren heeft ook een specifieke set opties. Vermeldenswaard is de reeks voorwaarden die bepalen of een index moet worden gereorganiseerd of niet - 30% fragmentatie, meer dan 1000 pagina's en voor het laatst maximaal 28 dagen opnieuw gebruikt. Dit venster onderstreept de noodzaak om de opties die we maken te begrijpen. Om deze opties correct te maken, moet u indexen en indexering in redelijke mate begrijpen. Houd er rekening mee dat vergelijkbare keuzes moeten worden gemaakt in de taak Index opnieuw opbouwen. Houd er ook rekening mee dat de aanbevolen fragmentatiedrempel voor indexreorganisatie eigenlijk 15% is en niet 30%.
Figuur 9:Indexopties reorganiseren
De taak Index opnieuw opbouwen biedt een paar andere opties naast die voor indexreorganisatie. (Zie afbeelding 10). Merk op dat ik ervoor heb gekozen om de resultaten in TempDB te sorteren. Om deze keuze effectief te laten zijn, is het belangrijk om TempDB op de juiste manier af te stemmen, aangezien de keuze impliceert dat het sorteren voor deze bewerking in ALLE databases in TempDB zal gebeuren. Bovendien moeten we het schema voor Index Rebuild opstellen. Ik heb MAXDOP ook ingesteld op 2 voor deze taak.
Figuur 10:Indexopties opnieuw opbouwen
We hebben eerder vermeld dat wanneer een Index Rebuild wordt aangeroepen in SQL Server, stats-update op indexen ook standaard wordt aangeroepen. Dus wanneer we de taak Statistieken bijwerken configureren, kiezen we ervoor om alleen kolomstatistieken bij te werken (Figuur 11). Dit venster geeft ons ook de mogelijkheid om een volledige scan uit te voeren of om steekproeven te nemen. Omdat de context kleine databases is, kiezen we voor de optie volledige scan. Nogmaals, dit vereist enig begrip van statistieken.
Figuur 11:Statistieken updatetaak
We kiezen ervoor om de opschoningstaak zo te configureren dat alle gegevens ouder dan 4 weken worden verwijderd, zoals weergegeven in Afbeelding 12.
Figuur 12:Taak opschonen geschiedenis
De back-uptaak onthult een flink aantal configuratie-opties in drie tabbladen! Figuur 13 laat zien dat we ervoor kiezen om deze back-uptaak te beperken tot gebruikersdatabases. We plannen het op zondag om 03:00 uur en we gaan verder om de back-upbestemming te kiezen als E:\MSSQL\Backup (zie afbeelding 14). Op het derde tabblad (Figuur 15) maken we keuzes om de back-up te verifiëren en voeren we ook een controlesom uit, zodat we er bijna zeker van zijn dat de back-up betrouwbaar is.
Figuur 13:Back-up databasetaak
Afbeelding 14:Back-upbestemming
Figuur 15:Back-upopties
Ten slotte configureren we een taak die het bewaren van ons Onderhoudsplan-logboek beheert. (Figuur 16). Nogmaals, we kiezen ervoor om alle logrecords ouder dan 4 weken te verwijderen. Afbeelding 17 toont de opties die we selecteren om ervoor te zorgen dat de activiteiten in het onderhoudsplan worden geregistreerd en naar de groep Database Admin worden gemaild. Om deze laatste optie te laten werken, moeten we natuurlijk Database Mail hebben geconfigureerd en operators correct hebben ingesteld.
Figuur 16:Opschoningstaak Onderhoudsplan
Figuur 17:Rapportopties
Afbeelding 18 en 19 tonen een samenvatting van de taken die we hebben geconfigureerd en feedback over de succesvolle voltooiing van de wizard.
Figuur 18:Overzicht van opties
Figuur 19:Wizard voltooien
Onderhoudsplan voor dagelijkse taken
Ook voor andere doeleinden, zoals het eenvoudig organiseren, kunnen wij aparte onderhoudsplannen opstellen. We hoeven geen apart plan voor dagelijkse taken op te stellen, omdat we de schema's voor elke taak afzonderlijk kunnen configureren. Een reden waarom we misschien een apart plan willen opzetten, kan zijn om een andere set taken te selecteren die gericht zijn op een andere set databases (eigenlijk kunnen we dit ook nog steeds doen in het bestaande plan).
Laten we in het volgende voorbeeld aannemen dat we binnen dezelfde instantie nog een set grote databases hebben met verschillende Recovery Point-doelstellingen. We moeten dan een andere back-upstrategie gebruiken – een dagelijks Differential Backup-schema en een Transaction Log Backup-schema per uur naast een wekelijkse volledige back-up om een RPO van 1 uur te garanderen. (Zie afbeeldingen 21 en 22).
Figuur 20:Onderhoudsplan voor dagelijkse taken
Afbeelding 21:Differentiële en Tlog-back-uptaken
Figuur 22:Taakvolgorde dagelijks onderhoudsplan
Voor de differentiële back-up kiezen we een dagelijks schema dat dagelijks om 2:00 uur wordt geactiveerd. (Zie afbeelding 23). En kies dezelfde back-upopties als voor de eerder geconfigureerde volledige wekelijkse back-up.
Figuur 23:Schema van het dagelijkse onderhoudsplan
Figuur 24:Differentiële back-uplocatie
Afbeelding 25:Differentiële back-upopties
Aan de andere kant kiezen we ervoor om de differentiële back-up elk uur van elke dag te laten plaatsvinden. We zorgen er ook voor dat elke databaseback-upset wordt opgeslagen in een directory met een eigen naam. De rest van de wizard is vrijwel hetzelfde als de vorige walkthrough.
Figuur 26:Back-upschema transactielogboek
Figuur 27:Back-uplocatie transactielogboek
Figuur 28:Back-upopties transactielogboek
Conclusie
Na het voltooien van de wizard Onderhoudsplan krijgen we een onderhoudsplan en een bijbehorende set SQL Agent-taken (zie afbeelding 29). In wezen is het onderhoudsplan een verzameling SSIS-pakketten, en wanneer u de geplande taken bekijkt, zult u ontdekken dat de taakstap die in elke subplantaak wordt uitgevoerd een SSIS-pakket is (zie afbeelding 30).
In een volgend voorbeeld laten we zien dat we de deelplanklussen jaarlijks kunnen uitvoeren. We zullen ook de resultaten van de uitvoering van het onderhoudsplan beoordelen en fouten oplossen die verband houden met het uitvoeren van de taakstappen. We zullen ook het onderhoudsplanlogboek bekijken.
Figuur 29:Resulterende SQL Agent-taken
Afbeelding 30:Taakstap SSIS-pakket