Introduktion
Regelbundet databasunderhåll är en viktig del av en databasadministratörs jobb som hjälper till att säkerställa att kritiskt viktiga system körs som vanligt. Ett av de enklaste sätten att åstadkomma detta är att automatisera uppgifter relaterade till DBCC CheckDB. Oavsett vilken version av SQL Server du kör, kommer det aldrig att finnas en databas som inte kräver något underhåll. Du måste planera att underhållet sker regelbundet så att du kan täcka din rygg, särskilt vid tidpunkten för ett riktigt katastrofscenario.
DBA är alltid boven
När det finns ett databasproblem är alla ögon riktade mot DBA. Oavsett om problemet har orsakats av regn eller på grund av att någon utvecklare skrivit otäck kod som resulterar i långsam databas, förväntas DBA alltid fixa röran. Och du kan föreställa dig vilken typ av press du måste hantera om du blir ombedd att snabbt återställa en databas med hjälp av den senaste tillgängliga säkerhetskopian som, som du får reda på i processen, inte är giltig och databasens integritet äventyras för några månader. sedan. Här ligger skillnaden mellan en proaktiv DBA och en reaktiv DBA. I verkligheten är din återställningsstrategi mycket mer kritisk jämfört med säkerhetskopieringsstrategin. Vilket syfte kan dagliga säkerhetskopior av databaser tjäna om de inte är till någon nytta vid tidpunkten för återställning?
Varför är underhåll viktigt?
Med den oöverträffade tillväxten av databasteknik och med nya funktioner som dyker upp med varje utgåva, är det absolut nödvändigt för dig som DBA att ligga före resten och se till att du följer branschens bästa praxis i databasunderhåll.
DBCC CheckDB och hur vi kan köra det
DBCC CheckDB – detta namn är ganska beskrivande för funktionalitet. Enkelt uttryckt kontrollerar den databaser. Detta är viktigt för att säkerställa att databasen fungerar som förväntat. I grund och botten kontrollerar DBCC CheckDB den logiska och fysiska integriteten för alla objekt i databasen. Detta är vad DBCC CheckDB gör under huven enligt tjänstemannen Microsoft-dokumentation:
Kör DBCC CHECKALLOC på databasen – konsekventa diskutrymmestilldelningar
Kör DBCC CHECKTABLE på varje tabell och vy i databasen – detta är integriteten för alla sidor och strukturer som utgör tabellen eller den indexerade vyn.
Kör DBCC CHECKCATALOG på databasen – detta kontrollerar katalogkonsistens inom den angivna databasen.
Validerar innehållet i varje indexerad vy i databasen.
Validerar överensstämmelse på länknivå mellan tabellmetadata och filsystemkataloger/filer när varbinary(max) data lagras i filsystemet med FILESTREAM.
Validerar Service Broker-data i databasen.
När du kör kommandot DBCC CheckDB explicit eller genom ett jobb, gör det i princip allt ovanstående.
Köra DBCC CheckDB direkt i en databas
Du kan köra kommandot DBCC CheckDB direkt på en databas och leta efter resultaten. Kontrollera kommandots utdata som visas på skärmdumpen nedan. Utdata visar detaljerna om rader i tabellerna och antalet sidor som används av dessa rader.
Om du tittar noga kommer du att se mer detaljer som är specifika för databasobjekt. Till exempel på "VLDB"-databasen kan jag se följande utdata:
“Object ID 1179151246 (object 'Warehouse.ColdRoomTemperatures'): The operation is not supported with memory optimized tables. This object has been skipped and will not be processed.”
Som denna utdata visar, stöds inte DBCC CheckDB med minnesoptimerade tabeller. Minnesoptimerade tabeller introducerades först i SQL Server 2014 som en endast Enterprise-funktion. Men under åren har de blivit en populär och utbredd funktion i SQL Server.
Du kommer också att märka att DBCC Check validerade tjänstemäklarens data i databasen enligt nedan.
“DBCC results for 'VLDB'. Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.”
Slutligen, när kommandot DBCC CheckDB har slutförts, kommer du att se följande utdata:
Vad händer om fel rapporteras efter att ha kört DBCC CheckDB?
I exemplet ovan kunde du se att DBCC CheckDB slutfördes utan några fel. Men om du inte har så tur kan du stöta på konsistensfel – och det kommer att vara den tid då du behöver fatta några kritiska beslut. Om du stöter på problem i en produktionsdatabas är det bäst att informera företagsägarna eller din verksamhetschef att lägga dina kort på bordet. Du kan antingen ge dem möjlighet att återställa databasen från den senaste tillgängliga säkerhetskopian eller så kan du experimentera med att köra DBCC CheckDB-kommandon med ytterligare alternativ.
DBCC-felmeddelandena kan se ut ungefär som nedan:
Table error: Object ID 36, index ID 1, partition ID, alloc unit ID (type In-row data). Keys out of order on page (1:107), slots 6 and 9. CHECKDB found 0 allocation errors and 1 consistency errors in table 'sys.syk' (object ID 36). CHECKDB found 0 allocation errors and 1 consistency errors in database 'VLDB'. repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (VLDB).
I felmeddelandet kan du se ett noggrant formulerat felmeddelande – "repair_rebuild is the minst reparationsnivå för de fel som hittats av DBCC CHECKDB ” – föreslår att du kör DBCC CheckDB med alternativet repair_rebuild. Titta bara på ordet som markeras - "minimum". Detta innebär att med alternativet repair_rebuild finns det ingen verklig möjlighet till dataförlust och SQL Server gör några snabba fixar under huven. Se kommandot nedan för att köra DBCC CheckDB med alternativet repair_rebuild. Se till att placera databasen i enanvändarläge.
I enlighet med Microsofts dokumentation är alternativet REPAIR_REBUILD den mest ofarliga versionen eftersom det inte kan ske någon dataförlust. Men om REPAIR_REBUILD fortfarande inte fixar konsistensfelen finns det ett annat alternativ – att aktivera REPAIR_ALLOW_DATA_LOSS. När vi tittar på namnet vet vi att det skulle finnas en risk för viss dataförlust om vi aktiverar det här alternativet. På grund av detta varnar Microsoft oss för att använda detta med extrem försiktighet eftersom det kan bli oväntade konsekvenser om vi kör DBCC CheckDB med REPAIR_ALLOW_DATA_LOSS. Kommandot DBCC CheckDB i det här fallet kommer att se ut på följande sätt:
Poäng att tänka på innan du använder Reparationsalternativet med DBCC CheckDB
Hur kritisk är databasen i fråga?
Är databasen på produktions- eller en testmiljö?
Hur stor är databasen?
Har du en bra återställningsstrategi om problem uppstår?
Har du validerat dina databassäkerhetskopior?
Baserat på situationen och svaren på ovanstående frågor, försök att fatta ett beslut med kundens bästa i åtanke.
Automatisera DBCC CheckDB-uppgifter på SQL Server med hjälp av databasunderhållsplaner
Tja, du behöver inte köra alla dessa kommandon manuellt på dina servrar. Det är därför vi har underhållsplaner på plats. Se till att schemalägga en regelbunden underhållscykel för alla dina databaser med hjälp av databasunderhållsplanerna. Det är en ganska enkel och okomplicerad uppgift. Under "Underhållsplanuppgifter", välj "Kontrollera databasintegritetsuppgift".
Detta kommer att lägga till en underuppgift till din underhållsplan för att schemalägga integritetskontroller för dina databaser. Se till att välja de nödvändiga databaserna som visas.
Se till att köra alla databaskontroller under en lågtrafiktid på veckan. Vanligtvis är underhållsfönstren på helgerna när servern är mindre upptagen jämfört med andra dagar i veckan. Detta kommer dock att variera från server till server och beror på applikationen. På kritiska databassystem visas varningar i allmänhet när det saknas DBCC CheckDB eller integritetskontroller. På så sätt kan DBA:erna proaktivt kontrollera och säkerställa att de genomför integritetskontrollerna för att undvika överraskningar senare.
Automatisera DBCC CheckDB-uppgifter på SQL Server med hjälp av anpassade skript eller andra populära skript
SQL Server-underhållsplaner behöver inte användas hela tiden för att utföra underhållsuppgifter på din SQL Server-instans. Det finns andra tillgängliga anpassade skript du kan använda. Ett av de populära gratis underhållsverktygen är Ola Hallengrens underhållslösning. Du kan installera hela underhållslösningen som inkluderar uppgifter för säkerhetskopiering, optimering etc., eller så kan du bara ladda ner relevanta skript relaterade till integritetskontroller. I den här demon kommer vi att försöka installera de skript som är specifika för databasintegritetskontroller.
Klicka på alternativet DatabaseIntegrityCheck.sql som visas för att ladda ner de lagrade procedurerna som kontrollerar databasens integritet. Efter att ha kört dessa lagrade procedurer i huvuddatabasen, stötte jag på dessa varningsmeddelanden:
“The module 'DatabaseIntegrityCheck' depends on the missing object 'dbo.CommandExecute'. The module will still be created; however, it cannot run successfully until the object exists.”
Om du kör den lagrade proceduren för att utföra integritetskontroller får du följande felmeddelande:
Som felet anger kan du ladda ner den saknade koden här. När detta är gjort kan du börja testa databasens integritetskontroller.
Du kan justera olika alternativ med hjälp av de ytterligare DBCC-kommandoparametrarna. Du kan hitta mer information och exempel på dem här.
Men i den här demon kommer vi att kontrollera några exempel för att se hur enkla och användarvänliga dessa skript verkligen är.
För att köra DBCC CheckDB på alla användardatabaser måste du utföra följande:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'USER_DATABASES', @CheckCommands = 'CHECKDB'
Du kan se kommandot som kördes och resultatstatusen som bekräftar att DBCC CheckDB slutfördes.
För att köra DBCC Kontrollera endast för systemdatabaserna, kör detta kommando:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'SYSTEM_DATABASES', @CheckCommands = 'CHECKDB'
På skärmdumpen kan du se att DBCC CheckDB slutfördes framgångsrikt för systemdatabaserna.
För att köra DBCC CheckDB endast för en specifik databas, kör följande:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'VLDB', -- your specific DB Name @CheckCommands = 'CHECKDB'
I exemplet ovan såg du några sätt vi kan använda parametrar. Det finns dock ett antal andra filter du kan välja baserat på dina preferenser. Du kan också, som redan nämnts, hänvisa till denna länk för ytterligare förståelse av Ola Hallengrens manus. Bara för att upprepa, jag använder Ola Hallengrens skript på de servrar jag hanterar och det rekommenderas starkt och erkänns inom SQL Server-communityt. Du kan schemalägga de lagrade procedurerna baserat på dina föredragna parametrar och köra det som ett SQL-jobb under lågtrafik. På så sätt behöver du egentligen inte köra något av dessa skript manuellt, så du kan fokusera på andra viktiga uppgifter.
Slutsats
- I den här artikeln har du lärt dig om DBCC CheckDB och hur det kan användas
- Du förstod också vikten av att köra DBCC CheckDB regelbundet på alla dina viktiga databaser
- Du lärde dig också om vikten av att ha en testad säkerhetskopieringsstrategi – det rekommenderas att du återställer dina databaser med en bra säkerhetskopia istället för att lösa eventuella konsistensfel med hjälp av DBCC-reparationsalternativen
- Du såg också hur enkelt det är att konfigurera och automatisera skript antingen med SQL Server-underhållsplaner eller anpassade skript, t.ex. det från Ola Hallengren
- Du lärde dig också riskerna med att inte schemalägga DBCC CheckDB på din infrastruktur som stöds
- Du lärde dig också att, oavsett vilken server du är på eller vilken infrastruktur du kör, kan det inte finnas någon databas som inte kräver något underhåll
- Slutligen, se till att hålla dina databaser friska och i alla fall vara redo för de lediga dagar som kanske inte är under din kontroll