Database-konsolkommandoen CHECKDB (DBCC CHECKDB) bruges til at kontrollere integriteten (fysisk & logisk) af objekter i en SQL Server-database.Kommandoen understøttes i databaser, der indeholder hukommelsesoptimerede tabeller, men valideringen understøttes kun i diskbaserede tabeller. DBCC repair-muligheden er ikke tilgængelig i hukommelsesoptimerede tabeller og fører derfor til et behov for regelmæssig database backup. hvis der opstår et problem i en hukommelsesoptimeret tabel, kan dataene gendannes fra den sidst udførte backup.
De forskellige operationer, der udføres af CHECKDB, er:
- DBCC CHECKALLOC-udførelse på SQL-databasen.
- DBCC CHECKTABLE-udførelse på hver tabel og visning i SQL-databasen.
- DBCC CHECKCATALOG-udførelse på SQL-databasen.
- Validering af indhold i den indekserede visning af databasen.
- Validering af konsistens på linkniveau blandt filmapper og tabelmetadata.
- Validering af servicemæglerdata.
Da DBCC CHECKDB kører alle de andre kommandoer, vil det ikke være nødvendigt at køre kommandoerne CHECKALLOC, CHECKTABLE og CHECKCATALOG separat.
DBCC CHECKDB Syntaks
Argumenterne, der anvendes i ovenstående syntaks, betyder følgende:
database_name | database_id | 0 Dette er navnet på databasen. hvis navnet ikke er angivet, eller der kun er skrevet 0, bruges den aktuelle database. NOINDEX Angiver, at integritetskontrollen af ikke-clusterede indekstabeller ikke skal udføres. Dette fører til en reduktion af den samlede udførelsestid.Denne syntaks påvirker ikke de data, der findes i tabellerne. REPAIR_ALLOW_DATA_LOSS Denne syntaks reparerer de fejl, der findes i databasen, hvilket kan føre til tab af nogle data.
Bemærk: Denne syntaks understøttes af Microsoft og viser sig ikke hver gang at være en ideel løsning til at gøre databasen i en god fysisk tilstand. Dette skyldes, at den sletter alle de data, der findes at være beskadiget, og kan føre til større tab af data, end der oprindeligt blev gjort ved databasen.
REPAIR_FAST Dette argument opretholder kun bagudkompatibilitet og udfører ikke nogen reparation. REPAIR REBUILD Dette argument omfatter en hurtigere reparationsproces, som ikke indebærer nogen trussel om tab af data. ALL_ERRORMSGS Dette viser alle de fejl, der er genereret i alle objekter. At medtage eller udelukke denne syntaks vil ikke have nogen virkning, da fejlmeddelelser normalt sorteres efter objekt-ID. Det maksimale antal fejlmeddelelser, der genereres, kan nå op på 1000. EXTENDED_LOGICAL_CHECKS Dette argument kører en logisk konsistent kontrol af visninger og indekser, men kun hvis kompatibilitetsniveauet er 100. NO_INFOMSGS Det fjerner alle informationsmeddelelser. TABLOCK Denne syntaks opnår en eksklusiv lås på databasen og vil øge hastigheden af DBCC CHECKDB på en database i perioder med stor belastning. Men den mindsker databasens tilgængelighed for samtidige operationer. ESTIMATEONLY Angiver eller anslår den mængde plads, som databasen vil kræve for at køre CHECKDB-kommandoen. PHYSICAL_ONLY Dette sætter en begrænsning for kun at kontrollere databasens fysiske struktur. En kort overheadkontrol af den fysiske database ledsages af registrering af revet sider, fejl og almindelige problemer, som brugerne oplever. DATA PURITY Denne syntaks kontrollerer for kolonneværdier, der enten er uden for området eller ikke er gyldige. Integritetskontrol af kolonneværdier er som standard aktiveret og kræver ikke DATA_PURITY-syntaksen.
Ting du skal være opmærksom på
- Deaktiverede indekser kan ikke kontrolleres af DBCC CHECKDB.
- De brugerdefinerede og byte-orderede typer skal serialiseres, hvis DBCC CHECKDB skal udføres. I alle andre tilfælde opstår fejl 2537.
- DBCC CHECKDB kan ikke køres direkte på Ressource-databasen, da den kun kan ændres i single-mode.
Fejlemeldinger genereret af DBCC CHECKDB
Når CHECKDB-kommandoen er færdig med at køre, skrives der en meddelelse til SQL-fejlloggen. I tilfælde af succes genereres der en meddelelse, der angiver succes og den samlede tid, som kommandoen kørte i. I tilfælde af fejl afsluttes processen på grund af en fejl, hvilket angives af en meddelelse. De forskellige tilstandsværdier, der repræsenterer fejlmeddelelsen, er:
Fejlerapport
Når korruption opdages af CHECKDB-kommandoen, oprettes der en dump-fil med navnet SQLDUMPNNNNNN.txt i logmappen på SQL-serveren. Hvis funktionen Indsamling af brugsdata og fejlrapportering er aktiveret i SQL, sendes fejlrapporten til Microsoft til forbedringsformål.
Databaserestaurering
I scenariet med fejlgenerering i SQL-server anbefales det at gendanne databasen fra den senest oprettede sikkerhedskopi i stedet for at reparere databasen.Hvis der ikke findes nogen sikkerhedskopi, kan du vælge reparationsmuligheder. Men at vælge reparation med REPAIR_ALLOW_DATA_LOSS kan føre til sletning af nogle data.
Alternativ løsning til databasegenoprettelse
Grundlæggende kontrollerer DBCC CHECKDB-kommandoen konsistenserne i databasen, herunder fysisk eller logisk. Denne kommando kontrollerer siderne, indekset og nogle andre komponenter i SQL-serverdatabasen, men på nogle kritiske punkter vælger denne kommando at nægte at genoprette SQL-databasen. I tilfælde af manglende backup af MS SQL server-databasen kan de valgte reparationsmuligheder slette en betydelig mængde data.For at gendanne databasen uden at gå på kompromis med dataintegriteten kan du derfor vælge en Microsoft SQL-database recovery-løsning. De garanterer fuldstændig gendannelse af databasen uden at slette nogen mængde data.