Underhållsplaner i SQL Server ger oss ett enkelt sätt att organisera, konfigurera och schemalägga uppgifter som säkerställer att databasmotorn och de databaser som finns däri hålls i form.
Underhållsplaner ger en databasadministratör en möjlighet att konfigurera viktiga uppgifter som indexering, statistikuppdateringar, säkerhetskopior, loggrensningar och annat. I tidigare artikel har vi redan diskuterat hur man skapar en grundläggande underhållsplan för att utföra databaskonsistenskontroll. I den här artikeln ska vi göra en genomgång av att skapa en underhållsplan för en databasinstans som är värd för små databaser. Under loppet av genomgången kommer jag att förklara de viktigaste valen som görs i varje steg i samband med en instans med ett måttligt stort antal små databaser. Tanken är att konfigurera underhåll för dessa databaser utan att behöva göra det en efter en. Fokus på små databaser är avsett att undvika de prestandakostnader som är förknippade med underhållsoperationer.
Underhållsplan för veckouppgifter
Figur 1:Starta guiden Underhållsplan
Vi startar guiden Underhållsplan från Object Explorer>[Instansnamn]>Management>Underhållsplaner (se figur 1). Den första sidan i guiden ger oss en översikt över de uppgifter som kan konfigureras. Även om det finns andra sätt att utföra dessa uppgifter med hjälp av kod och jobbschemaläggning, gör Maintenance Plan Wizard det ganska enkelt att utföra när man hanterar ett stort antal databaser som finns på en instans.
Figur 2:Guiden Underhållsplan
I figur 3 ser vi att SQL Server exponerar fält för oss att namnge och beskriva underhållsplanen. Att ange en beskrivning av planen är vettigt för dokumentationsändamål. Tänk dig att ta över en ny SQL Server-instans på ett nytt företag. Det skulle vara användbart om du hittar beskrivningar av SQL Server-objekt i objekten. Du bör göra detsamma för andra. Observera att beskrivningen jag har gett bara är avsedd att illustrera poängen. En mer detaljerad beskrivning är önskvärt i en produktionsmiljö.
Figur 3:Namnge underhållsplanen
Observera att i figur 3 har vi möjlighet att välja om vi vill använda ett enda schema för alla uppgifter eller ett separat schema för varje uppgift. Jag har valt att använda separata scheman för att ha flexibiliteten att fördela uppgifterna. Vi skulle inte vilja ha för många underhållsoperationer som körs samtidigt eller rygg mot rygg under lång tid för att undvika risken för överväldigande serverresurser. Beslutet du fattar vid denna tidpunkt kan också bero på kapaciteten hos resurser som är tillgängliga för dig och det tillgängliga underhållsfönstret. Vissa personer har tillräcklig kapacitet och skulle vilja bli av med uppgiften snabbt under varje löpning. I scenariot som omfattas av den här artikeln antar vi att instansen i fråga inte används under helgen.
I figur 4 väljer vi de uppgifter vi vill utföra. En av de fantastiska sakerna med SQL Server är att varje uppgift beskrivs längst ner i fönstret. Det lönar sig när du arbetar som DBA att förstå vad du gör även när du arbetar på "Windows". Enligt min erfarenhet har många "administratörer" för vana att helt enkelt klicka på "NÄSTA, NÄSTA, NÄSTA" eftersom de har bråttom att få funktionen att fungera. Men att ta dig tid att förstå effekten av nästa "NÄSTA" hjälper till att säkerställa att du gör något som ger mervärde, inte orsakar nya problem.
Figur 4:Välja underhållsuppgifter
De uppgifter vi har valt beskrivs enligt följande:
Kontrollera databasintegritet uppgiften utför interna konsistenskontroller av data och indexsidor i databasen.
Omorganisera index uppgift defragmenterar och komprimerar klustrade och icke-klustrade index på tabeller och vyer. Detta kommer att förbättra prestanda för indexskanning.
Rebuild Index uppgift omorganiserar data på data och indexsidor genom att bygga om index. Detta förbättrar prestandan för indexskanningar och -sökningar. Denna uppgift optimerar också distributionen av data och ledigt utrymme på indexsidorna, vilket möjliggör snabbare framtida tillväxt.
Uppdatera statistik uppgift säkerställer att frågeoptimeraren har uppdaterad information om fördelningen av datavärden i tabellerna. Detta gör att optimeraren kan göra bättre bedömningar om strategier för dataåtkomst.
Historisrensningen Uppgiften tar bort historisk data om säkerhetskopiering och återställning, SQL Server Agent och underhållsplan. Den här guiden låter dig ange typen och åldern för de data som ska raderas.
Säkerhetskopiera databasen (fullständig) uppgift låter dig ange källdatabaser, målfiler eller band och skriva över alternativ för en fullständig säkerhetskopia.
Underhållsrensningen Uppgiften tar bort filer som blir över från att köra en underhållsplan.
Figur 5 visar var vi väljer i vilken ordning dessa uppgifter ska utföras. Detta är viktigt av några anledningar. Till exempel är det inte meningsfullt att utföra en indexstatistikuppdatering efter en indexombyggnad eftersom en indexombyggnad också utför uppdatering av indexstatistik i SQL Server. Vi ska se längre fram i artikeln hur vi hanterar detta givet den ordning vi har valt. En annan möjlig övervägande är att du kan bestämma dig för att det är mer meningsfullt att göra en säkerhetskopiering först innan du fortsätter med vissa typer av underhåll.
Figur 5:Uppgifternas ordning
I figur 6 väljer vi vilka databaser vi vill tillämpa den första underhållsuppgiften på. Vi måste göra detta för var och en av de efterföljande uppgifterna också. Detta är viktigt i den meningen att vissa databaser kan behöva undantas från sådana operationer. Till exempel, där du har en blandning av mycket stora databaser (VLDB) och mycket små databaser i samma instans (en dålig idé i sig), kan du behöva utesluta VLDB:er från direkt blinda index-ombyggnader. I ett sådant fall måste du identifiera nyckeltabellerna i den VLDB och fokusera ombyggnaderna och andra intensiva underhållsoperationer på nyckeltabeller. I det här exemplet har jag uteslutit systemdatabaser eftersom jag noggrant kan planera underhåll för dem separat. Jag tror att det är säkrare att hantera systemdatabaser separat, med tanke på att eventuell skada på dem kan påverka hela instansen.
Figur 6:Bestäm omfattningen
Varje underhållsoperation har sin egen uppsättning alternativ. Figur 7 visar alternativen vi måste besluta om för DBCC CHECKDB. Jag har avvikit något från standardinställningarna genom att öka MAXDOP till 2. I figur 8 väljer vi att köra den här uppgiften kl. 01:00 på lördags- och söndagskvällar.
Figur 7:DBCC-alternativ
Figur 8:DBCC-schema
Uppgiften Reorganize Index har också en specifik uppsättning alternativ. Värt att nämna är uppsättningen villkor som avgör om ett index ska omorganiseras eller inte – 30 % fragmentering, 1000+ sidantal och senast använd högst 28 dagar igen. Detta fönster understryker behovet av att förstå de alternativ vi gör. För att göra dessa alternativ korrekt måste du förstå index och indexering i rimlig utsträckning. Observera att liknande val måste göras i Återuppbyggnadsindexuppgiften. Observera också att den rekommenderade fragmenteringströskeln för indexomorganisation faktiskt är 15 % och inte 30 %.
Figur 9:Omorganisera indexalternativ
Återbygga indexuppgiften erbjuder några andra alternativ förutom de för indexomorganisation. (Se figur 10). Lägg märke till att jag har valt att sortera resultat i TempDB. För att detta val ska vara effektivt är det viktigt att justera TempDB på lämpligt sätt eftersom valet innebär att sortering för denna operation i ALLA databaser kommer att ske i TempDB. Dessutom måste vi ställa in schemat för Index Rebuild. Jag har också ställt in MAXDOP på 2 för denna uppgift.
Figur 10:Återskapa indexalternativ
Vi nämnde tidigare att när en Index Rebuild anropas i SQL Server, anropas även statistikuppdatering på index som standard. Så när vi konfigurerar statistikuppdateringsuppgiften väljer vi att endast uppdatera kolumnstatistik (Figur 11). Detta fönster ger oss också möjlighet att antingen göra en fullständig skanning eller provtagning. Eftersom sammanhanget är små databaser väljer vi alternativet för fullständig genomsökning. Återigen, detta kräver viss förståelse för statistik.
Figur 11:Uppdatering av statistik
Vi väljer att konfigurera rensningsjobbet för att radera data som är äldre än 4 veckor, som visas i figur 12.
Figur 12:Uppgift om historikrensning
Säkerhetskopieringsuppgiften visar ett stort antal konfigurationsalternativ på tre flikar! Figur 13 visar att vi väljer att begränsa denna säkerhetskopieringsuppgift till användardatabaser. Vi schemalägger det till 03:00 på söndagar, och vi går vidare för att välja backupdestinationen som E:\MSSQL\Backup (se figur 14). På den tredje fliken (Figur 15) gör vi val för att verifiera säkerhetskopian och även utföra en kontrollsumma, så vi är närmare säkra på att säkerhetskopieringen är tillförlitlig.
Figur 13:Säkerhetskopiera databasuppgift
Figur 14:Backup-destination
Figur 15:Säkerhetskopieringsalternativ
Slutligen konfigurerar vi en uppgift som kommer att hantera bevarandet av vår underhållsplanlogg. (Figur 16). Återigen väljer vi att radera alla loggposter som är äldre än 4 veckor. Figur 17 visar alternativen vi väljer för att säkerställa att underhållsplansaktiviteterna loggas och skickas till Databas Admin-gruppen. För att det sista alternativet ska fungera måste vi naturligtvis ha konfigurerat Database Mail och konfigurerat operatörer korrekt.
Figur 16:Rengöringsuppgift för underhållsplan
Figur 17:Rapportalternativ
Figurerna 18 och 19 visar en sammanfattning av de uppgifter vi har konfigurerat och feedback om hur guiden har slutförts.
Figur 18:Sammanfattning av alternativ
Figur 19:Wizard Completion
Underhållsplan för dagliga uppgifter
Vi kan också sätta upp separata underhållsplaner för andra ändamål, som att bara organisera. Vi behöver inte sätta upp en separat plan för dagliga uppgifter eftersom vi kan konfigurera scheman separat för varje uppgift. En anledning till att vi kanske vill skapa en separat plan kan vara att välja en annan uppsättning uppgifter som är inriktade på en annan uppsättning databaser (faktiskt kanske vi fortfarande kan göra detta i den befintliga planen också).
I följande exempel, låt oss anta att vi har en annan uppsättning stora databaser inom samma instans med olika återställningspunktsmål. Vi behöver då använda en annan backupstrategi – ett dagligt Differential Backup-schema och ett schema för backup av transaktionsloggar varje timme utöver en veckovis fullständig backup för att säkerställa en RPO på 1 timme. (Se figurerna 21 och 22).
Figur 20:Underhållsplan för dagliga uppgifter
Figur 21:Differential- och Tlog-säkerhetskopieringsuppgifter
Figur 22:Uppgiftsbeställning för daglig underhållsplan
För differentialbackupen väljer vi ett dagligt schema som utlöses klockan 02:00 dagligen. (Se figur 23). Och välj samma säkerhetskopieringsalternativ som vi gjorde för Full Weekly Backup som konfigurerats tidigare.
Figur 23:Dagligt underhållsplan
Figur 24:Differentiell säkerhetskopieringsplats
Figur 25:Differentiella säkerhetskopieringsalternativ
Å andra sidan väljer vi att schemalägga den differentiella säkerhetskopieringen så att den sker varje timme varje dag. Vi säkerställer också att varje säkerhetskopia av databas lagras i en katalog med sitt eget namn. Resten av guiden är ungefär densamma som föregående genomgång.
Figur 26:Schema för säkerhetskopiering av transaktionslogg
Figur 27:Plats för säkerhetskopiering av transaktionslogg
Figur 28:Alternativ för säkerhetskopiering av transaktionslogg
Slutsats
När vi har slutfört guiden Underhållsplan får vi en underhållsplan och en motsvarande uppsättning SQL-agentjobb (se figur 29). I huvudsak är underhållsplanen en samling SSIS-paket, och när du undersöker de schemalagda jobben kommer du att upptäcka att jobbsteget som utförs i varje delplansjobb är ett SSIS-paket (se figur 30).
I ett efterföljande exempel kommer vi att visa att vi kan utföra delplansjobben årligen. Vi kommer också att granska resultatet av utförandet av underhållsplanen och felsöka fel relaterade till att utföra jobbstegen. Vi ska också granska underhållsplansloggen.
Figur 29:Resulterande SQL Agent-jobb
Figur 30:SSIS Package Job Step