Introduktion
Regelmæssig databasevedligeholdelse er en vigtig del af en databaseadministrators job, som hjælper med at sikre, at kritisk vigtige systemer kører som normalt. En af de nemmeste måder at opnå dette på vil være at automatisere opgaver relateret til DBCC CheckDB. Uanset hvilken version af SQL Server du kører, vil der aldrig være en database, der ikke kræver vedligeholdelse. Du bliver nødt til at planlægge vedligeholdelsen til at finde sted regelmæssigt, så du kan dække din ryg, især på tidspunktet for et virkeligt katastrofescenarie.
DBA er altid synderen
Når der er et databaseproblem, er alle øjne rettet mod DBA. Uanset om problemet er forårsaget af regn eller på grund af en udvikler, der har skrevet ubehagelig kode, hvilket resulterer i databasens langsomhed, forventes DBA altid at ordne rodet. Og du kan forestille dig, hvilken form for pres du skal håndtere, hvis du bliver bedt om hurtigt at gendanne en database ved hjælp af den sidste tilgængelige backup, som, som du finder ud af i processen, ikke er gyldig, og databasens integritet allerede var kompromitteret et par måneder siden. Her ligger forskellen mellem en proaktiv DBA og en reaktiv DBA. I virkeligheden er din gendannelsesstrategi meget mere kritisk sammenlignet med sikkerhedskopieringsstrategien. Hvilket formål kan daglige databasesikkerhedskopier tjene, hvis de ikke er til nogen nytte på gendannelsestidspunktet?
Hvorfor er vedligeholdelse vigtig?
Med den hidtil usete vækst af databaseteknologier og med nye funktioner, der vises med hver udgivelse, er det bydende nødvendigt for dig som DBA at være på forkant med resten og sikre dig, at du følger branchens bedste praksis i database vedligeholdelse.
DBCC CheckDB og hvordan vi kan køre det
DBCC CheckDB – dette navn er ret beskrivende for funktionalitet. Sagt på en enkel måde kontrollerer den databaser. Dette er vigtigt for at sikre, at databasen fungerer som forventet. Grundlæggende kontrollerer DBCC CheckDB den logiske og fysiske integritet af alle objekter i databasen. Dette er, hvad DBCC CheckDB gør under motorhjelmen ifølge officielle Microsoft-dokumentation:
Kører DBCC CHECKALLOC på databasen – konsistensen af diskpladsallokeringer
Kører DBCC CHECKTABLE på hver tabel og visning i databasen – dette er integriteten af alle de sider og strukturer, der udgør tabellen eller den indekserede visning.
Kører DBCC CHECKCATALOG på databasen – dette kontrollerer for katalogkonsistens i den angivne database.
Validerer indholdet af hver indekseret visning i databasen.
Validerer sammenhængen på linkniveau mellem tabelmetadata og filsystemmapper/filer ved lagring af varbinary(max) data i filsystemet ved hjælp af FILESTREAM.
Validerer Service Broker-dataene i databasen.
Når du kører kommandoen DBCC CheckDB eksplicit eller gennem et job, udfører den stort set alt ovenstående.
Kørsel af DBCC CheckDB direkte på en database
Du kan køre kommandoen DBCC CheckDB direkte på en database og se efter resultaterne. Kontroller kommandoens output som vist på skærmbilledet nedenfor. Outputtet viser detaljerne om rækker i tabellerne og antallet af sider, der bruges af disse rækker.
Hvis du ser godt efter, vil du se flere detaljer, der er specifikke for databaseobjekter. For eksempel på "VLDB"-databasen kan jeg se følgende output:
“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 dette output viser, understøttes DBCC CheckDB ikke med hukommelsesoptimerede tabeller. Hukommelsesoptimerede tabeller blev først introduceret i SQL Server 2014 som en Enterprise-only funktion. Men gennem årene er de blevet en populær og udbredt funktionalitet i SQL Server.
Du vil også bemærke, at DBCC Check validerede servicemæglerdataene i databasen som vist nedenfor.
“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.”
Til sidst, når DBCC CheckDB-kommandoen er gennemført, vil du se følgende output:
Hvad sker der, hvis der rapporteres fejl efter kørsel af DBCC CheckDB?
I ovenstående eksempel kunne du se, at DBCC CheckDB blev gennemført uden nogen fejl. Men hvis du ikke er så heldig, kan du støde på konsistensfejl - og det vil være tidspunktet, hvor du skal træffe nogle kritiske beslutninger. Hvis du støder på problemer i en produktionsdatabase, er det bedst at informere virksomhedsejerne eller din driftsleder om at lægge dine kort på bordet. Du kan enten give dem mulighed for at gendanne databasen fra den sidste tilgængelige sikkerhedskopi, eller du kan eksperimentere med at køre DBCC CheckDB-kommandoer med yderligere muligheder.
DBCC-fejlmeddelelserne kan ligne nedenstående:
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 fejlmeddelelsen kan du se en omhyggeligt formuleret fejlmeddelelse – "repair_rebuild is the minimum reparationsniveau for fejl fundet af DBCC CHECKDB ” – foreslår, at du kører DBCC CheckDB med muligheden repair_rebuild. Se bare på det ord, der fremhæves - 'minimum'. Det betyder, at med reparation_rebuild-indstillingen er der ingen reel mulighed for tab af data, og SQL Server laver nogle hurtige rettelser under motorhjelmen. Se venligst kommandoen nedenfor for at køre DBCC CheckDB med muligheden repair_rebuild. Sørg for at placere databasen i enkeltbrugertilstand.
I henhold til Microsoft-dokumentationen er REPAIR_REBUILD-indstillingen den mest harmløse version, da der ikke kan forekomme datatab. Men hvis REPAIR_REBUILD stadig ikke retter konsistensfejlene, er der en anden mulighed – at aktivere REPAIR_ALLOW_DATA_LOSS. Når vi ser på navnet, ved vi, at der ville være en mulighed for datatab, hvis vi slår denne mulighed til. På grund af dette advarer Microsoft os om at bruge dette med ekstrem forsigtighed, da der kan være uventede konsekvenser ved at køre DBCC CheckDB med REPAIR_ALLOW_DATA_LOSS. DBCC CheckDB-kommandoen vil i dette tilfælde se ud på følgende måde:
Punkter at overveje, før du bruger Reparationsindstillingen med DBCC CheckDB
Hvor kritisk er den pågældende database?
Er databasen på produktions- eller et testmiljø?
Hvor stor er databasen?
Har du en god gendannelsesstrategi, hvis der skulle opstå problemer?
Har du valideret dine databasesikkerhedskopier?
Baseret på situationen og svarene på ovenstående spørgsmål, prøv at træffe en beslutning med kundens bedste for øje.
Automatisering af DBCC CheckDB-opgaver på SQL Server ved hjælp af databasevedligeholdelsesplaner
Nå, du behøver ikke at køre alle disse kommandoer manuelt på dine servere. Derfor har vi vedligeholdelsesplaner på plads. Sørg for at planlægge en regelmæssig vedligeholdelsescyklus for alle dine databaser ved hjælp af databasevedligeholdelsesplanerne. Det er en ret simpel og ligetil opgave. Under "Vedligeholdelsesplanopgaver" skal du vælge "Kontroller databaseintegritetsopgave".
Dette vil tilføje en underopgave til din vedligeholdelsesplan for at planlægge integritetstjek for dine databaser. Sørg for at vælge de nødvendige databaser som vist.
Sørg venligst for at køre alle databasetjek uden for spidsbelastningsperioder på ugen. Normalt er vedligeholdelsesvinduerne i weekenden, hvor serveren er mindre optaget sammenlignet med de andre dage i ugen. Dette vil dog variere fra server til server og afhænger af applikationen. På kritiske databasesystemer vises advarsler generelt, når der er forpasset DBCC CheckDB eller integritetstjek. På denne måde kan DBA'erne proaktivt kontrollere og sikre, at de får gennemført integritetskontrollen for at undgå overraskelser senere.
Automatisering af DBCC CheckDB-opgaver på SQL Server ved hjælp af tilpassede scripts eller andre populære scripts
SQL Server-vedligeholdelsesplaner behøver ikke at blive brugt hele tiden til at udføre vedligeholdelsesopgaver på din SQL Server-instans. Der er andre tilgængelige tilpassede scripts, du kan bruge. Et af de populære gratis vedligeholdelsesværktøjer er Ola Hallengrens vedligeholdelsesløsning. Du kan installere hele vedligeholdelsesløsningen, som inkluderer opgaver til backup, optimering osv., eller du kan kun downloade de relevante scripts relateret til integritetstjek. I denne demo vil vi forsøge at installere de scripts, der er specifikke for databaseintegritetstjek.
Klik på indstillingen DatabaseIntegrityCheck.sql som vist for at downloade de lagrede procedurer, der kontrollerer databasens integritet. Efter at have kørt disse lagrede procedurer på masterdatabasen stødte jeg på disse advarselsmeddelelser:
“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.”
Hvis du kører den lagrede procedure til at udføre integritetstjek, får du følgende fejlmeddelelse:
Som fejlen angiver, kan du downloade den manglende kode her. Når dette er gjort, kan du begynde at prøve databasens integritetstjek.
Du kan justere forskellige muligheder ved at bruge de ekstra DBCC-kommandoparametre. Du kan finde flere detaljer og eksempler på dem her.
I denne demo vil vi dog tjekke nogle få eksempler for at se, hvor nemme og brugervenlige disse scripts egentlig er.
Til at køre DBCC CheckDB på alle brugerdatabaser , skal du udføre følgende:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'USER_DATABASES', @CheckCommands = 'CHECKDB'
Du kan se kommandoen, der blev kørt, og resultatstatus, som bekræfter, at DBCC CheckDB blev gennemført.
For at køre DBCC Check kun for systemdatabaserne, udfør denne kommando:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'SYSTEM_DATABASES', @CheckCommands = 'CHECKDB'
På skærmbilledet kan du se, at DBCC CheckDB blev gennemført med succes for systemdatabaserne.
For at køre DBCC CheckDB kun for en specifik database, udfør følgende:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'VLDB', -- your specific DB Name @CheckCommands = 'CHECKDB'
I ovenstående eksempel så du et par måder, vi kan bruge parametre på. Der er dog en række andre filtre, du kan vælge ud fra dine præferencer. Som allerede nævnt kan du også henvise til dette link for yderligere forståelse af Ola Hallengrens manuskripter. Bare for at gentage, jeg bruger Ola Hallengrens scripts på de servere, jeg administrerer, og det kan varmt anbefales og anerkendes i SQL Server-fællesskabet. Du kan planlægge de lagrede procedurer baseret på dine foretrukne parametre og køre det som et SQL-job uden for myldretiden. På denne måde behøver du ikke rigtig at køre nogen af disse scripts manuelt, så du kan fokusere på andre vigtige opgaver.
Konklusion
- Fra denne artikel har du lært om DBCC CheckDB og hvordan det kan bruges
- Du forstod også vigtigheden af at køre DBCC CheckDB regelmæssigt på alle dine vigtige databaser
- Du lærte også om vigtigheden af at have en testet backup-strategi – det anbefales at gendanne dine databaser ved hjælp af en god backup i stedet for at løse eventuelle konsistensfejl ved hjælp af DBCC-reparationsmulighederne
- Du så også, hvor nemt det er at konfigurere og automatisere scripts enten ved hjælp af SQL Server-vedligeholdelsesplaner eller tilpassede scripts, f.eks. det fra Ola Hallengren
- Du lærte også risikoen ved ikke at planlægge DBCC CheckDB på din understøttede infrastruktur
- Du lærte også, at uanset hvilken server du er på, eller hvilken infrastruktur du kører, kan der ikke være nogen database, der ikke kræver vedligeholdelse
- Sørg endelig for at holde dine databaser sunde og under alle omstændigheder være klar til de OFF-dage, som måske ikke er under din kontrol