Vedligeholdelsesplaner i SQL Server giver os en nem måde at organisere, konfigurere og planlægge opgaver, der sikrer, at databasemotoren og de databaser, der er hostet deri, holdes i form.
Vedligeholdelsesplaner giver en databaseadministrator mulighed for at konfigurere nøgleopgaver som indeksering, statistikopdateringer, sikkerhedskopier, logoprydning og andre. I tidligere artikel har vi allerede diskuteret, hvordan man opretter en grundlæggende vedligeholdelsesplan for at udføre databasekonsistenstjek. I denne artikel skal vi lave en gennemgang af oprettelse af en vedligeholdelsesplan for en databaseinstans, der er vært for små databaser. I løbet af gennemgangen vil jeg forklare de vigtigste valg, der er foretaget i hvert trin i forbindelse med en instans med et moderat stort antal små databaser. Ideen er at konfigurere vedligeholdelse for disse databaser uden at skulle gøre det én efter én. Fokus på små databaser er beregnet til at undgå ydeevneomkostninger forbundet med vedligeholdelsesoperationer.
Vedligeholdelsesplan for ugentlige opgaver
Figur 1:Start guiden vedligeholdelsesplan
Vi starter Maintenance Plan Wizard fra Object Explorer>[Forekomstnavn]>Management>Maintenance Plans (se figur 1). Den første side i guiden giver os et overblik over de opgaver, der kan konfigureres. Mens der er andre måder at udføre disse opgaver på ved hjælp af kode og jobplanlægning, gør vedligeholdelsesplan-guiden det ret nemt at udføre, når man har at gøre med et stort antal databaser, der hostes på én instans.
Figur 2:Guiden Vedligeholdelsesplan
I figur 3 ser vi SQL Server, der afslører felter, så vi kan navngive og beskrive vedligeholdelsesplanen. Indtastning af en beskrivelse af planen er fornuftig af dokumentationsøjemed. Forestil dig at overtage en ny SQL Server-instans hos en ny virksomhed. Det ville være nyttigt, hvis du finder beskrivelser af SQL Server-objekter i objekterne. Du bør gøre det samme for andre. Bemærk venligst, at beskrivelsen, jeg har givet, blot er beregnet til at illustrere pointen. En mere detaljeret beskrivelse vil være ønskelig i et produktionsmiljø.
Figur 3:Navngivning af vedligeholdelsesplanen
Bemærk, at vi i figur 3 har mulighed for at vælge, om vi vil bruge et enkelt skema for alle opgaver eller et separat skema for hver opgave. Jeg har valgt at bruge separate skemaer for at have fleksibiliteten til at forskyde opgaverne. Vi ønsker ikke for mange vedligeholdelsesoperationer, der kører samtidigt eller ryg mod ryg over lang tid for at undgå risikoen for overvældende serverressourcer. Den beslutning, du træffer på dette tidspunkt, kan også afhænge af kapaciteten af de ressourcer, du har til rådighed, og det tilgængelige vedligeholdelsesvindue. Nogle mennesker har tilstrækkelig kapacitet og vil gerne klare opgaven hurtigt under hver løbetur. I scenariet dækket af denne artikel antager vi, at den pågældende instans ikke bruges i weekenden.
I figur 4 vælger vi de opgaver, vi ønsker at udføre. En af de gode ting ved SQL Server er, at hver opgave er beskrevet nederst i vinduet. Det betaler sig, når du arbejder som DBA, at forstå, hvad du laver, selv når du arbejder på "Windows". Efter min erfaring har mange "administratorer" for vane blot at klikke på "NEXT, NEXT, NEXT", fordi de har travlt med at få funktionaliteten til at fungere. Men at tage sig tid til at forstå virkningen af det næste "NEXT" hjælper med at sikre, at du gør noget, der vil tilføje værdi, ikke forårsage nye problemer.
Figur 4:Valg af vedligeholdelsesopgaver
De opgaver vi har udvalgt er beskrevet som følger:
Kontroller databaseintegritet opgave udfører interne konsistenstjek af data og indekssider i databasen.
Reorganize Index opgave defragmenterer og komprimerer klyngede og ikke-klyngede indekser på tabeller og visninger. Dette vil forbedre ydeevnen for indeksscanning.
Genopbygningsindekset opgave omorganiserer data på data og indekssider ved at genopbygge indekser. Dette forbedrer ydeevnen af indeksscanninger og -søgninger. Denne opgave optimerer også distributionen af data og ledig plads på indekssiderne, hvilket muliggør hurtigere fremtidig vækst.
Opdater statistik opgave sikrer, at forespørgselsoptimeringsværktøjet har opdateret information om fordelingen af dataværdier i tabellerne. Dette giver optimeringsværktøjet mulighed for bedre at vurdere strategier for dataadgang.
Oprydning i historik opgave sletter historiske data om sikkerhedskopiering og gendannelse, SQL Server Agent og vedligeholdelsesplan operationer. Denne guide giver dig mulighed for at angive typen og alderen for de data, der skal slettes.
Sikkerhedskopieringsdatabasen (fuld) opgave giver dig mulighed for at angive kildedatabaser, destinationsfiler eller bånd og overskrive muligheder for en fuld sikkerhedskopi.
Vedligeholdelsesoprydning opgave fjerner filer, der er tilbage fra udførelse af en vedligeholdelsesplan.
Figur 5 viser, hvor vi vælger den rækkefølge, som disse opgaver udføres i. Dette er vigtigt af et par grunde. For eksempel giver det ikke mening at udføre en indeksstatistikopdatering efter en Index Rebuild, da en Index Rebuild også udfører indeksstatistikopdatering i SQL Server. Vi skal se senere i artiklen, hvordan vi håndterer dette givet den rækkefølge, vi har valgt. En anden mulig overvejelse er, at du måske beslutter, at det giver mere mening at udføre en sikkerhedskopi først, før du fortsætter med visse former for vedligeholdelse.
Figur 5:Opgaverækkefølge
I figur 6 vælger vi, hvilke databaser vi vil anvende den første vedligeholdelsesopgave på. Det skal vi også gøre for hver af de efterfølgende opgaver. Dette er vigtigt i den forstand, at nogle databaser muligvis skal undtages fra sådanne operationer. For eksempel, hvor du har en blanding af meget store databaser (VLDB'er) og meget små databaser i samme instans (en dårlig idé i sig selv), skal du muligvis udelukke VLDB'erne fra direkte blinde indeksgenopbygninger. I et sådant tilfælde skal du identificere nøgletabellerne i den VLDB og fokusere genopbygningerne og andre intensive vedligeholdelsesoperationer på nøgletabeller. I dette eksempel har jeg udelukket systemdatabaser, da jeg omhyggeligt kan planlægge vedligeholdelse for dem separat. Jeg tror, det er mere sikkert at håndtere systemdatabaser separat, da enhver skade på dem kan påvirke hele forekomsten.
Figur 6:Bestem omfanget
Hver vedligeholdelsesoperation har sit eget sæt muligheder. Figur 7 viser de muligheder, vi skal tage stilling til for DBCC CHECKDB. Jeg har afveget lidt fra standardindstillingerne ved at øge MAXDOP til 2. I figur 8 vælger vi at køre denne opgave kl. 1:00 lørdag og søndag aften.
Figur 7:DBCC-indstillinger
Figur 8:DBCC-skema
Opgaven Reorganize Index har også et specifikt sæt muligheder. Værd at nævne er det sæt af betingelser, der vil afgøre, om et indeks skal reorganiseres eller ej – 30 % Fragmentering, 1000+ sideantal og senest brugt i 28 dage igen. Dette vindue understreger behovet for at forstå de muligheder, vi laver. For at gøre disse muligheder korrekt, skal du forstå indekser og indeksering i et rimeligt omfang. Bemærk, at lignende valg skal foretages i genopbygningsindeksopgaven. Vær også opmærksom på, at den anbefalede fragmenteringstærskel for indeksomlægning faktisk er 15 % og ikke 30 %.
Figur 9:Omorganiser indeksindstillinger
Genopbyg indeksopgaven tilbyder et par andre muligheder udover dem til indeksomorganisering. (Se figur 10). Bemærk at jeg har valgt at sortere resultater i TempDB. For at dette valg skal være effektivt, er det vigtigt at tune TempDB korrekt, da valget indebærer, at sortering for denne operation i ALLE databaser vil ske i TempDB. Derudover skal vi opsætte tidsplanen for Genopbygning af indeks. Jeg har også sat MAXDOP til 2 for denne opgave.
Figur 10:Genopbyg indeksindstillinger
Vi nævnte tidligere, at når en indeksgenopbygning påkaldes i SQL Server, påkaldes statistikopdatering på indekser også som standard. Så når vi konfigurerer statistikopdateringsopgaven, vælger vi kun at opdatere kolonnestatistik (Figur 11). Dette vindue giver os også mulighed for enten at lave en fuld scanning eller prøveudtagning. Da konteksten er små databaser, vælger vi muligheden for fuld scanning. Igen, dette kræver en vis forståelse af statistik.
Figur 11:Statistikopdateringsopgave
Vi vælger at konfigurere oprydningsjobbet til at slette data, der er ældre end 4 uger, som vist i figur 12.
Figur 12:Historieoprydningsopgave
Sikkerhedskopieringsopgaven afslører en hel del konfigurationsmuligheder i tre faner! Figur 13 viser, at vi vælger at begrænse denne backup-opgave til brugerdatabaser. Vi planlægger det til kl. 3:00 om søndagen, og vi går videre for at vælge backup-destinationen som E:\MSSQL\Backup (se figur 14). På den tredje fane (figur 15) træffer vi valg om at verificere sikkerhedskopien og også udføre en kontrolsum, så vi er tættere på at være sikre på, at sikkerhedskopien er pålidelig.
Figur 13:Backup-databaseopgave
Figur 14:Backup-destination
Figur 15:Sikkerhedskopieringsmuligheder
Til sidst konfigurerer vi en opgave, der vil styre opbevaringen af vores vedligeholdelsesplanlog. (Figur 16). Igen vælger vi at slette eventuelle logposter, der er ældre end 4 uger. Figur 17 viser de muligheder, vi vælger for at sikre, at vedligeholdelsesplanaktiviteterne er logget og sendt til databaseadministratorgruppen. For at denne sidste mulighed skal fungere, skal vi selvfølgelig have konfigureret Database Mail og konfigureret operatører korrekt.
Figur 16:Oprydningsopgave for vedligeholdelsesplan
Figur 17:Rapportindstillinger
Figur 18 og 19 viser en oversigt over de opgaver, vi har konfigureret, og feedback på den vellykkede afslutning af guiden.
Figur 18:Oversigt over muligheder
Figur 19:Fuldførelse af guiden
Vedligeholdelsesplan for daglige opgaver
Vi kan også opsætte separate vedligeholdelsesplaner til andre formål, såsom blot at være organiseret. Vi behøver ikke oprette en separat plan for daglige opgaver, da vi kan konfigurere tidsplanerne separat for hver opgave. En grund til, at vi måske ønsker at oprette en separat plan, kunne være at vælge et andet sæt opgaver målrettet mod et andet sæt databaser (faktisk kan vi muligvis også gøre dette i den eksisterende plan).
Lad os i det følgende eksempel antage, at vi har et andet sæt store databaser inden for samme instans med forskellige gendannelsespunkter. Vi skal derefter bruge en anden backup-strategi – en daglig differentiel backup-plan og en time-transaktionslog-backup-plan foruden en ugentlig fuld backup for at sikre en RPO på 1 time. (Se figur 21 og 22).
Figur 20:Vedligeholdelsesplan for daglige opgaver
Figur 21:Differential- og Tlog-backup-opgaver
Figur 22:Opgavebestilling for daglig vedligeholdelsesplan
Til den differentielle backup vælger vi en daglig tidsplan, som udløses kl. 02.00 dagligt. (Se figur 23). Og vælg de samme sikkerhedskopieringsmuligheder, som vi gjorde for den fulde ugentlige sikkerhedskopiering, der er konfigureret tidligere.
Figur 23:Daglig vedligeholdelsesplan
Figur 24:Differentiel backupplacering
Figur 25:Differentielle sikkerhedskopieringsmuligheder
På den anden side vælger vi at planlægge den differentielle backup til at finde sted hver time hver dag. Vi sikrer også, at hvert database-backupsæt er gemt i en mappe med sit eget navn. Resten af guiden er meget den samme som den forrige gennemgang.
Figur 26:Sikkerhedskopiering af transaktionslog
Figur 27:Placering af sikkerhedskopiering af transaktionslog
Figur 28:Sikkerhedskopieringsmuligheder for transaktionslog
Konklusion
Når vi har fuldført guiden Vedligeholdelsesplan, ender vi med en vedligeholdelsesplan og et tilsvarende sæt SQL Agent-job (se figur 29). Grundlæggende er vedligeholdelsesplanen en samling af SSIS-pakker, og når du undersøger de planlagte job, vil du opdage, at jobtrinnet, der udføres i hvert underplanjob, er en SSIS-pakke (se figur 30).
I et efterfølgende eksempel vil vi vise, at vi kan udføre delplanjobbene årligt. Vi vil også gennemgå resultaterne af udførelsen af vedligeholdelsesplanen og fejlfinde fejl i forbindelse med udførelsen af jobtrinnene. Vi vil også undersøge vedligeholdelsesplanloggen.
Figur 29:Resulterende SQL Agent-job
Figur 30:SSIS-pakkejobtrin