• 14/12/2017
  • 22 minutter at læse
    • p
    • M
    • m
    • M
    • P
    • +3

Gælder for: SQL Server (alle understøttede versioner) Azure SQL Database

Kontrollerer den logiske og fysiske integritet for alle objekter i den angivne database ved at udføre følgende operationer:

  • Kører DBCC CHECKALLOC på databasen.
  • Kører DBCC CHECKTABLE på alle tabeller og visninger i databasen.
  • Kører DBCC CHECKCATALOG på databasen.
  • Validerer indholdet af alle indekserede visninger i databasen.
  • Validerer konsistensen på linkniveau mellem tabelmetadata og filsystemmapper og filer, når varbinære (max) data lagres i filsystemet ved hjælp af FILESTREAM.
  • Validerer Service Broker-dataene i databasen.

Dette betyder, at det ikke er nødvendigt at køre kommandoerne DBCC CHECKALLOC, DBCC CHECKTABLE eller DBCC CHECKCATALOG separat fra DBCC CHECKDB. Du kan finde mere detaljerede oplysninger om de kontroller, som disse kommandoer udfører, i beskrivelserne af disse kommandoer.

Note

DBCC CHECKDB understøttes på databaser, der indeholder hukommelsesoptimerede tabeller, men valideringen sker kun på diskbaserede tabeller. Som en del af sikkerhedskopiering og gendannelse af databaser udføres der dog en CHECKSUM-validering for filer i hukommelsesoptimerede filgrupper.

Da DBCC-reparationsmulighederne ikke er tilgængelige for hukommelsesoptimerede tabeller, skal du regelmæssigt sikkerhedskopiere dine databaser og teste sikkerhedskopierne. Hvis der opstår dataintegritetsproblemer i et hukommelsesoptimeret bord, skal du gendanne fra den sidst kendte gode sikkerhedskopi.

Transact-SQL-syntaks-konventioner

Syntaks

DBCC CHECKDB ) ] } ] ]

Note

For at få vist Transact-SQL-syntaks for SQL Server 2014 og tidligere skal du se Dokumentationen for tidligere versioner.

Argumenter

database_name | database_id | 0
Er navnet eller ID’et på den database, som der skal køres integritetskontrol for. Hvis den ikke er angivet, eller hvis der er angivet 0, bruges den aktuelle database. Databasenavne skal overholde reglerne for identifikatorer.

NOINDEX
Angiver, at der ikke skal udføres intensive kontroller af ikke-grupperede indekser for brugertabeller. Dette mindsker den samlede udførelsestid. NOINDEX påvirker ikke systemtabeller, fordi integritetskontroller altid udføres på indekser for systemtabeller.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Angiver, at DBCC CHECKDB skal reparere de fundne fejl. Brug kun REPAIR-indstillingerne som en sidste udvej. Den angivne database skal være i enkeltbrugertilstand for at kunne bruge en af følgende reparationsmuligheder.

REPAIR_ALLOW_DATA_LOSS
Forsøger at reparere alle rapporterede fejl. Disse reparationer kan medføre et vist tab af data.

Varsel

Optionen REPAIR_ALLOW_DATA_LOSS er en understøttet funktion, men den er måske ikke altid den bedste mulighed for at bringe en database til en fysisk konsistent tilstand. Hvis det lykkes, kan REPAIR_ALLOW_DATA_LOSS-indstillingen resultere i et vist tab af data, hvis den lykkes. Faktisk kan den resultere i flere tabte data, end hvis en bruger gendanner databasen fra den senest kendte gode sikkerhedskopi.

Microsoft anbefaler altid, at en bruger gendanner fra den senest kendte gode sikkerhedskopi som den primære metode til at genoprette fejl, der er rapporteret af DBCC CHECKDB. Indstillingen REPAIR_ALLOW_DATA_LOSS er ikke et alternativ til gendannelse fra en kendt god sikkerhedskopi. Det er en “sidste udvej”, der kun anbefales til brug, hvis det ikke er muligt at gendanne fra en sikkerhedskopi.

Visse fejl, som kun kan repareres ved hjælp af indstillingen REPAIR_ALLOW_DATA_LOSS, kan indebære, at en række, side eller serie af sider skal deallokeres for at slette fejlene. Alle deallokerede data er ikke længere tilgængelige eller genoprettelige for brugeren, og det nøjagtige indhold af de deallokerede data kan ikke bestemmes. Derfor er referentiel integritet muligvis ikke nøjagtig, efter at eventuelle rækker eller sider er blevet deallokeret, fordi fremmednøglebegrænsninger ikke kontrolleres eller vedligeholdes som en del af denne reparationsoperation. Brugeren skal kontrollere den referentielle integritet i sin database (ved hjælp af DBCC CHECKCONSTRAINTS) efter at have brugt indstillingen REPAIR_ALLOW_DATA_LOSS.

Før du udfører reparationen, skal du oprette fysiske kopier af de filer, der tilhører denne database. Dette omfatter den primære datafil (.mdf), eventuelle sekundære datafiler (.ndf), alle transaktionslogfiler (.ldf) og andre containere, der udgør databasen, herunder fuldtekstkataloger, filestrømmapper, hukommelsesoptimerede data osv.

Hvor du udfører reparationen, bør du overveje at ændre databasens tilstand til EMERGENCY-tilstand og forsøge at udtrække så mange oplysninger som muligt fra de kritiske tabeller og gemme disse data.

REPAIR_FAST
Holder kun syntaksen for bagudkompatibilitet. Der udføres ingen reparationshandlinger.

REPAIR_REBUILD
Udfører reparationer, der ikke har mulighed for tab af data. Dette kan omfatte hurtige reparationer, f.eks. reparation af manglende rækker i ikke-grupperede indekser, og mere tidskrævende reparationer, f.eks. genopbygning af et indeks.
Dette argument reparerer ikke fejl, der involverer FILESTREAM-data.

Vigtigt

Da DBCC CHECKDB med alle REPAIR-optioner er fuldstændig logget og kan genoprettes, anbefaler Microsoft altid, at brugeren bruger CHECKDB med alle REPAIR-optioner inden for en transaktion (udfør BEGIN TRANSACTION, før kommandoen køres), så brugeren kan bekræfte, at han/hun ønsker at acceptere resultaterne af operationen. Derefter kan brugeren udføre COMMIT TRANSACTION for at bekræfte alt det arbejde, der er udført af reparationsoperationen. Hvis brugeren ikke ønsker at acceptere resultaterne af operationen, kan han/hun udføre en ROLLBACK TRANSACTION for at fortryde virkningerne af reparationsoperationerne.

For at reparere fejl anbefaler vi, at du gendanner fra en sikkerhedskopi. Reparationsoperationer tager ikke hensyn til nogen af de begrænsninger, der kan eksistere på eller mellem tabeller. Hvis det angivne bord er involveret i en eller flere begrænsninger, anbefaler vi, at du kører DBCC CHECKCONSTRAINTS efter en reparationsoperation. Hvis du skal bruge REPAIR, skal du køre DBCC CHECKDB uden en reparationsindstilling for at finde det reparationsniveau, der skal bruges. Hvis du bruger niveauet REPAIR_ALLOW_DATA_LOSS, anbefaler vi, at du tager en sikkerhedskopi af databasen, før du kører DBCC CHECKDB med denne indstilling.

ALL_ERRORMSGS
Viser alle rapporterede fejl pr. objekt. Alle fejlmeddelelser vises som standard. Angivelse eller udeladelse af denne indstilling har ingen virkning. Fejlmeddelelser sorteres efter objekt-ID, bortset fra de meddelelser, der genereres fra tempdb-databasen.

EXTENDED_LOGICAL_CHECKS
Hvis kompatibilitetsniveauet er 100 ( SQL Server 2008) eller højere, udføres der logiske konsistenstjek på en indekseret visning, XML-indekser og rumlige indekser, hvis de findes.
Fors yderligere oplysninger, se Udførelse af logiske konsistenskontrol af indekser i afsnittet Bemærkninger senere i dette emne.

NO_INFOMSGS
Undertrykker alle informationsmeddelelser.

TABLOCK
Forårsager DBCC CHECKDB til at indhente låse i stedet for at bruge et internt database-snapshot. Dette omfatter en kortvarig eksklusiv (X) lås på databasen. TABLOCK får DBCC CHECKDB til at køre hurtigere på en database under stor belastning, men reducerer den tilgængelige samtidighed på databasen, mens DBCC CHECKDB kører.

Vigtigt

TABLOCK begrænser de kontroller, der udføres; DBCC CHECKCATALOG køres ikke på databasen, og Service Broker-data valideres ikke.

ESTIMATEONLY
Viser den anslåede mængde tempdb-plads, der er nødvendig for at køre DBCC CHECKDB med alle de andre angivne indstillinger. Selve databasekontrollen udføres ikke.

PHYSICAL_ONLY
Begrænser kontrollen til integriteten af den fysiske struktur af side- og recordoverskrifternes fysiske struktur og databasens tildelingskonsistens. Denne kontrol er designet til at give en lille overheadkontrol af databasens fysiske konsistens, men den kan også opdage revnede sider, fejl i checksummen og almindelige hardwarefejl, som kan kompromittere en brugers data.
En fuld kørsel af DBCC CHECKDB kan tage betydeligt længere tid end tidligere versioner. Denne adfærd opstår, fordi:

  • De logiske kontroller er mere omfattende.
  • Nogle af de underliggende strukturer, der skal kontrolleres, er mere komplekse.
  • Mange nye kontroller er blevet indført for at inkludere de nye funktioner.
    Derfor kan brugen af PHYSICAL_ONLY-indstillingen medføre en meget kortere køretid for DBCC CHECKDB på store databaser og anbefales til hyppig brug på produktionssystemer. Vi anbefaler stadig, at der med jævne mellemrum udføres en fuld kørsel af DBCC CHECKDB. Hyppigheden af disse kørsler afhænger af faktorer, der er specifikke for individuelle virksomheder og produktionsmiljøer.
    Dette argument indebærer altid NO_INFOMSGS og er ikke tilladt med nogen af reparationsindstillingerne.

Varsling

Angivelse af PHYSICAL_ONLY får DBCC CHECKDB til at springe alle kontroller af FILESTREAM-data over.

DATA_PURITY
Forårsager DBCC CHECKDB til at kontrollere databasen for kolonneværdier, der ikke er gyldige eller ligger uden for intervallet. DBCC CHECKDB registrerer f.eks. kolonner med dato- og tidsværdier, der er større end eller mindre end det acceptable område for datatypen datetime, eller kolonner af decimal- eller tilnærmet numerisk datatype med skala- eller præcisionsværdier, der ikke er gyldige.
Kolonneværdiintegritetskontroller er aktiveret som standard og kræver ikke indstillingen DATA_PURITY. For databaser, der er opgraderet fra tidligere versioner af SQL Server, er kolonneværdikontroller ikke aktiveret som standard, før DBCC CHECKDB WITH DATA_PURITY er blevet kørt fejlfrit på databasen. Herefter kontrollerer DBCC CHECKDB som standard kolonneværdiintegritet. Du kan finde flere oplysninger om, hvordan CHECKDB kan blive påvirket af opgradering af databasen fra tidligere versioner af SQL Server, i afsnittet Bemærkninger senere i dette emne.

Varsling

Hvis PHYSICAL_ONLY er angivet, udføres der ikke kolonneintegritetskontroller.

Valideringsfejl, der rapporteres af denne indstilling, kan ikke rettes ved hjælp af DBCC-reparationsindstillingerne. Du kan finde oplysninger om manuel korrektion af disse fejl i Knowledge Base-artikel 923247: Fejlfinding af DBCC-fejl 2570 i SQL Server 2005 og senere versioner.

MAXDOP
Gælder for: SQL Server ( SQL Server 2014 (12.x) SP2 og nyere).

Overskriver konfigurationsindstillingen max degree of parallelism (maks. grad af parallelitet) i sp_configure for angivelsen. MAXDOP kan overstige den værdi, der er konfigureret med sp_configure. Hvis MAXDOP overstiger den værdi, der er konfigureret med Resource Governor, bruger SQL Server Database Engine Resource Governor MAXDOP-værdien, som er beskrevet i ALTER WORKLOAD GROUP. Alle semantiske regler, der anvendes med konfigurationsindstillingen Max degree of parallelism, gælder, når du bruger forespørgselshintet MAXDOP. Du kan finde flere oplysninger i Konfigurer serverkonfigurationsindstillingen for maks. grad af parallelitet.

Varsling

Hvis MAXDOP er angivet til nul, vælger SQL Server den maksimale grad af parallelitet, der skal bruges.

Bemærkninger

DBCC CHECKDB undersøger ikke deaktiverede indekser. Du kan finde flere oplysninger om deaktiverede indekser under Deaktiver indekser og begrænsninger.

Hvis en brugerdefineret type er markeret som værende byteordnet, må der kun være én serialisering af den brugerdefinerede type. Hvis der ikke er en konsistent serialisering af byte-ordnede brugerdefinerede typer, forårsager det fejl 2537, når DBCC CHECKDB køres. Du kan finde flere oplysninger under Krav til brugerdefinerede typer.

Da Ressource-databasen kun kan ændres i enkeltbrugertilstand, kan kommandoen DBCC CHECKDB ikke køres direkte på den. Når DBCC CHECKDB udføres mod masterdatabasen, køres der imidlertid også en anden CHECKDB internt på Ressource-databasen. Det betyder, at DBCC CHECKDB kan give ekstra resultater. Kommandoen returnerer ekstra resultatsæt, når der ikke er angivet nogen indstillinger, eller når enten indstillingen PHYSICAL_ONLY eller ESTIMATEONLY er angivet.

Med start med SQL Server 2005 (9.x) SP2 rydder udførelsen af DBCC CHECKDB ikke længere plancachen for instansen af SQL Server. Før SQL Server 2005 (9.x) SP2 rydder udførelsen af DBCC CHECKDB plancachen ved at udføre DBCC CHECKDB. Rydning af plancachen medfører en ny kompilering af alle senere udførelsesplaner og kan medføre et pludseligt, midlertidigt fald i forespørgselsydelsen.

Udførelse af logiske konsistenskontrol på indekser

Logisk konsistenskontrol på indekser varierer afhængigt af databasens kompatibilitetsniveau som følger:

  • Hvis kompatibilitetsniveauet er 100 (SQL Server 2008) eller højere:
  • Medmindre NOINDEX er angivet, udfører DBCC CHECKDB både fysisk og logisk konsistenskontrol på et enkelt bord og på alle dets ikke-grupperede indekser. På XML-indekser, rumlige indekser og indekserede visninger udføres der dog som standard kun fysiske konsistenskontroller.
  • Hvis WITH EXTENDED_LOGICAL_CHECKS er angivet, udføres der logiske kontroller på en indekseret visning, XML-indekser og rumlige indekser, hvis de er til stede. Som standard udføres de fysiske konsistenskontroller før de logiske konsistenskontroller. Hvis NOINDEX også er angivet, udføres kun de logiske kontroller.

Disse logiske konsistenskontroller krydstjekker indeksobjektets interne indekstabel med den brugertabel, som det refererer til. For at finde rækker, der ligger udenfor, konstrueres en intern forespørgsel for at udføre en fuldstændig krydsning af de interne tabeller og brugertabellerne. Kørsel af denne forespørgsel kan have en meget stor indvirkning på ydeevnen, og dens forløb kan ikke følges. Derfor anbefaler vi, at du kun angiver WITH EXTENDED_LOGICAL_CHECKS, hvis du har mistanke om indeksproblemer, der ikke har noget med fysisk korruption at gøre, eller hvis kontrolsummer på sideplan er blevet slået fra, og du har mistanke om hardwarekorruption på kolonneplan.

  • Hvis indekset er et filtreret indeks, udfører DBCC CHECKDB konsistenskontrol for at verificere, at indeksposterne opfylder filterprædikatet.
  • Hvis kompatibilitetsniveauet er 90 eller mindre, medmindre NOINDEX er angivet, udfører DBCC CHECKDB både fysiske og logiske konsistenstjek på en enkelt tabel eller indekseret visning og på alle dens ikke-grupperede og XML-indekser. Rumlige indekser understøttes ikke.
  • Start med SQL Server 2016 vil yderligere kontroller af persisterede beregnede kolonner, UDT-kolonner og filtrerede indekser som standard ikke blive udført for at undgå de dyre udtryksevalueringer. Denne ændring reducerer i høj grad varigheden af CHECKDB mod databaser, der indeholder disse objekter. Den fysiske konsistenskontrol af disse objekter er dog altid afsluttet. Kun når EXTENDED_LOGICAL_CHECKS-indstillingen er angivet, vil udtryksvurderingerne blive udført i tillæg til allerede eksisterende logiske kontroller (indekseret visning, XML-indekser og rumlige indekser) som en del af EXTENDED_LOGICAL_CHECKS-indstillingen.

For at få oplysninger om kompatibilitetsniveauet for en database

  • Se eller ændre kompatibilitetsniveauet for en database

Internt database-snapshot

DBCC CHECKDB bruger et internt database-snapshot til den transaktionelle konsistens, der er nødvendig for at udføre disse kontroller. Dette forhindrer blokering og problemer med samtidighed, når disse kommandoer udføres. Du kan finde flere oplysninger under Vis størrelsen af den sparsomme fil i et øjebliksbillede af en database (Transact-SQL) og afsnittet DBCC Internal Database Snapshot Usage i DBCC (Transact-SQL). Hvis der ikke kan oprettes et snapshot, eller der er angivet TABLOCK, erhverver DBCC CHECKDB låse for at opnå den krævede konsistens. I dette tilfælde kræves der en eksklusiv databaselås for at udføre allokeringskontrollerne, og der kræves delte tabellåse for at udføre tabelkontrollerne.DBCC CHECKDB fejler, når den køres mod master, hvis der ikke kan oprettes et snapshot af den interne database.Når DBCC CHECKDB køres mod tempdb, udføres der ingen allokerings- eller katalogkontroller, og der skal erhverves delte tabellåse for at udføre tabelkontroller. Dette skyldes, at snapshots af databasen ikke er tilgængelige på tempdb af hensyn til ydelsen. Det betyder, at den krævede transaktionskonsistens ikke kan opnås. i Microsoft SQL Server 2012 eller en tidligere version af SQL Server kan du støde på fejlmeddelelser, når du kører kommandoen DBCC CHECKDB for en database, hvis filer er placeret på et ReFS-formateret volumen. Du kan finde flere oplysninger i Knowledge Base-artikel 2974455: DBCC CHECKDB-adfærd, når SQL Server-databasen er placeret på en ReFS-volumen.

Kontrol og reparation af FILESTREAM-data

Når FILESTREAM er aktiveret for en database og en tabel, kan du valgfrit gemme varbinary(max) binære store objekter (BLOB’er) i filsystemet. Når du bruger DBCC CHECKDB på en database, der gemmer BLOB’er i filsystemet, kontrollerer DBCC konsistensen på linkniveau mellem filsystemet og databasen. hvis en tabel f.eks. indeholder en varbinary(max)-kolonne, der bruger FILESTREAM-attributten, kontrollerer DBCC CHECKDB, at der er en én-til-én-tilknytning mellem filsystemets mapper og filer og tabellens rækker, kolonner og kolonneværdier. DBCC CHECKDB kan reparere korruption, hvis du angiver indstillingen REPAIR_ALLOW_DATA_LOSS. For at reparere FILESTREAM-korruption sletter DBCC alle tabelrækker, der mangler filsystemdata.

Bedste praksis

Vi anbefaler, at du bruger indstillingen PHYSICAL_ONLY ved hyppig brug på produktionssystemer. Brug af PHYSICAL_ONLY kan i høj grad forkorte køretiden for DBCC CHECKDB på store databaser. Vi anbefaler også, at du med jævne mellemrum kører DBCC CHECKDB uden indstillinger. Hvor ofte du bør udføre disse kørsler afhænger af de enkelte virksomheder og deres produktionsmiljøer.

Kontrol af objekter parallelt

Som standard udfører DBCC CHECKDB parallel kontrol af objekter. Graden af parallelitet bestemmes automatisk af forespørgselsprocessoren. Den maksimale grad af parallelitet er konfigureret ligesom parallelle forespørgsler. Hvis du vil begrænse det maksimale antal processorer, der er tilgængelige for DBCC-kontrol, skal du bruge sp_configure. Du kan finde flere oplysninger under Konfigurer den maksimale grad af parallelitet i Serverkonfigurationsindstillingen. Parallel kontrol kan deaktiveres ved at bruge trace-flag 2528. Du kan finde flere oplysninger under Traceflag (Transact-SQL).

Note

Denne funktion er ikke tilgængelig i alle udgaver af SQL Server. Du kan finde flere oplysninger under Parallel konsistenskontrol i afsnittet RDBMS-håndterbarhed i Funktioner understøttet af udgaverne af SQL Server 2016.

Forståelse af DBCC-fejlmeddelelser

Når DBCC CHECKDB-kommandoen afsluttes, skrives der en meddelelse til SQL Server-fejlloggen. Hvis DBCC-kommandoen udføres med succes, angiver meddelelsen succes og det tidsrum, som kommandoen kørte. Hvis DBCC-kommandoen stopper før afslutningen af kontrollen på grund af en fejl, angiver meddelelsen, at kommandoen blev afbrudt, en tilstandsværdi og det tidsrum, kommandoen kørte. Følgende tabel viser og beskriver de tilstandsværdier, der kan indgå i meddelelsen.

State Description
0 Fejrnummer 8930 blev udløst. Dette indikerer en korruption i metadata, som afsluttede DBCC-kommandoen.
1 Fejlenummer 8967 blev udløst. Der opstod en intern DBCC-fejl.
2 Der opstod en fejl under reparation af databasen i nødtilstand.
3 Dette indikerer en korruption i metadata, som afsluttede DBCC-kommandoen.
4 Der blev opdaget en assert- eller adgangsovertrædelse.
5 Der opstod en ukendt fejl, som afsluttede DBCC-kommandoen.

Note

SQL Server registrerer den dato og det tidspunkt, hvor der blev kørt en konsistenskontrol for en database uden fejl (eller en “ren” konsistenskontrol). Dette er kendt som last known clean check. Når en database startes første gang, skrives denne dato til EventLog (EventID-17573) og ERRORLOG i følgende format:

CHECKDB for database '<database>' finished without errors on 2019-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Fejlerapportering

En dumpfil (SQLDUMP*nnnn*.txt) oprettes i mappen SQL Server LOG, hver gang DBCC CHECKDB registrerer en korruptionsfejl. Når funktionerne Feature Usage-dataindsamling og Fejlrapportering er aktiveret for SQL Server-instansen, videresendes filen automatisk til Microsoft. De indsamlede data bruges til at forbedre SQL Server-funktionaliteten. dump-filen indeholder resultaterne af DBCC CHECKDB-kommandoen og yderligere diagnostiske output. Adgang er begrænset til SQL Server-tjenestekontoen og medlemmer af sysadmin-rollen. Som standard indeholder sysadmin-rollen alle medlemmer af gruppen Windows BUILTIN\Administrators og den lokale administratorgruppe. DBCC-kommandoen fejler ikke, hvis dataindsamlingsprocessen fejler.

Resolution af fejl

Hvis der rapporteres fejl af DBCC CHECKDB, anbefaler vi, at databasen gendannes fra databasens sikkerhedskopi i stedet for at køre REPAIR med en af REPAIR-indstillingerne. Hvis der ikke findes nogen sikkerhedskopi, korrigeres de rapporterede fejl ved at køre reparation. Den reparationsindstilling, der skal anvendes, er angivet i slutningen af listen over rapporterede fejl. Det kan dog være nødvendigt at slette nogle sider og dermed nogle data for at rette fejlene ved hjælp af indstillingen REPAIR_ALLOW_DATA_LOSS.

Under visse omstændigheder kan der blive indtastet værdier i databasen, som ikke er gyldige eller uden for intervallet baseret på kolonnens datatype. DBCC CHECKDB kan registrere kolonneværdier, der ikke er gyldige for alle kolonnens datatyper. Hvis du kører DBCC CHECKDB med indstillingen DATA_PURITY på databaser, der er blevet opgraderet fra tidligere versioner af SQL Server, kan du derfor muligvis afsløre allerede eksisterende kolonneværdifejl. Da SQL Server ikke automatisk kan reparere disse fejl, skal kolonneværdien opdateres manuelt. Hvis CHECKDB registrerer en sådan fejl, returnerer CHECKDB en advarsel, fejlnummeret 2570 og oplysninger til at identificere den berørte række og manuelt rette fejlen.

Reparationen kan udføres under en brugertransaktion for at lade brugeren rulle de ændringer tilbage, der blev foretaget. Hvis reparationen rulles tilbage, vil databasen stadig indeholde fejl, og den skal gendannes fra en sikkerhedskopi. Når reparationen er afsluttet, skal du sikkerhedskopiere databasen.

Resolving Errors in Database Emergency Mode

Når en database er blevet sat i nødtilstand ved hjælp af ALTER DATABASE-anvisningen, kan DBCC CHECKDB udføre nogle specielle reparationer på databasen, hvis indstillingen REPAIR_ALLOW_DATA_LOSS er angivet. Disse reparationer kan gøre det muligt at bringe databaser, som normalt ikke kan genoprettes, online igen i en fysisk konsistent tilstand. Disse reparationer bør bruges som en sidste udvej og kun når du ikke kan gendanne databasen fra en sikkerhedskopi. Når databasen er sat i nødtilstand, er databasen markeret READ_ONLY, logning er deaktiveret, og adgangen er begrænset til medlemmer af den faste serverrolle sysadmin.

Note

Du kan ikke køre DBCC CHECKDB-kommandoen i nødtilstand inde i en brugertransaktion og rulle transaktionen tilbage efter udførelsen.

Når databasen er i nødtilstand, og DBCC CHECKDB med klausulen REPAIR_ALLOW_DATA_LOSS køres, udføres følgende handlinger:

  • DBCC CHECKDB bruger sider, der er blevet markeret utilgængelige på grund af I/O- eller checksummefejl, som om fejlene ikke var opstået. Derved øges chancerne for datagendannelse fra databasen.
  • DBCC CHECKDB forsøger at gendanne databasen ved hjælp af almindelige logbaserede gendannelsesteknikker.
  • Hvis det ikke lykkes at gendanne databasen på grund af beskadigelse af transaktionsloggen, genopbygges transaktionsloggen igen. Genopbygningen af transaktionsloggen kan resultere i tab af transaktionskonsistens.

Varsling

Optionen REPAIR_ALLOW_DATA_LOSS er en understøttet funktion i SQL Server. Den er dog ikke altid den bedste mulighed for at bringe en database til en fysisk konsistent tilstand. Hvis det lykkes, kan indstillingen REPAIR_ALLOW_DATA_LOSS resultere i et vist datatab. Faktisk kan den resultere i, at der går flere data tabt, end hvis en bruger skulle gendanne databasen fra den sidste kendte gode sikkerhedskopi. Microsoft anbefaler altid, at brugeren genopretter fra den sidste kendte gode sikkerhedskopi som den primære metode til at genoprette fejl, der er rapporteret af DBCC CHECKDB.Indstillingen REPAIR_ALLOW_DATA_LOSS er ikke et alternativ til at genoprette fra en kendt god sikkerhedskopi. Det er en “sidste udvej”, der kun anbefales til brug, hvis det ikke er muligt at gendanne fra en sikkerhedskopi.

Efter genopbygning af loggen er der ingen fuld ACID-garanti.

Efter genopbygning af loggen udføres DBCC CHECKDB automatisk og vil både rapportere og rette fysiske konsistensproblemer.

Logisk datakonsistens og begrænsninger, der håndhæves af forretningslogikken, skal valideres manuelt.

Transaktionslogstørrelsen vil blive efterladt på standardstørrelsen og skal justeres manuelt tilbage til den seneste størrelse.

Hvis DBCC CHECKDB-kommandoen lykkes, er databasen i en fysisk konsistent tilstand, og databasestatus er sat til ONLINE. Databasen kan dog indeholde en eller flere transaktionsmæssige inkonsistenser. Vi anbefaler, at du kører DBCC CHECKCONSTRAINTS for at identificere eventuelle fejl i forretningslogikken og straks sikkerhedskopiere databasen. hvis DBCC CHECKDB-kommandoen mislykkes, kan databasen ikke repareres.

Kørsel af DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS i replikerede databaser

Kørsel af DBCC CHECKDB-kommandoen med indstillingen REPAIR_ALLOW_DATA_LOSS kan påvirke brugerdatabaser (publikations- og abonnementsdatabaser) og den distributionsdatabase, der anvendes ved replikering. Publikations- og abonnementsdatabaser omfatter offentliggjorte tabeller og metadatatabeller for replikation. Vær opmærksom på følgende potentielle problemer i disse databaser:

  • Publicerede tabeller. Handlinger, der udføres af CHECKDB-processen for at reparere korrupte brugerdata, bliver muligvis ikke replikeret:
  • Merge-replikation bruger triggere til at spore ændringer i offentliggjorte tabeller. Hvis rækker indsættes, opdateres eller slettes af CHECKDB-processen, udløses triggere ikke, og derfor replikeres ændringen ikke.
  • Transaktionsreplikation bruger transaktionsloggen til at spore ændringer i offentliggjorte tabeller. Log Reader Agent flytter derefter disse ændringer til distributionsdatabasen. Visse DBCC-reparationer kan ikke replikeres af Log Reader Agent, selv om de er logget, men kan ikke replikeres af Log Reader Agent. Hvis en dataside f.eks. deallokeres af CHECKDB-processen, oversætter Log Reader Agent dette ikke til en DELETE-anvisning; derfor replikeres ændringen ikke.
  • Replikeringsmetadatatabeller. Handlinger, der udføres af CHECKDB-processen for at reparere korrupte replikationsmetadatatabeller, kræver, at replikationen fjernes og omkonfigureres.

Hvis du skal køre DBCC CHECKDB-kommandoen med indstillingen REPAIR_ALLOW_DATA_LOSS på en brugerdatabase eller distributionsdatabase:

  1. Skyld systemet: Stop aktiviteten på databasen og på alle andre databaser i replikeringstopologien, og prøv derefter at synkronisere alle knudepunkter. Du kan finde flere oplysninger i Quiesce a Replication Topology (Replication Transact-SQL Programming).
  2. Udfør DBCC CHECKDB.
  3. Hvis DBCC CHECKDB-rapporten indeholder reparationer for nogen tabeller i distributionsdatabasen eller nogen replikationsmetadatatabeller i en brugerdatabase, skal du fjerne og rekonfigurere replikation. Du kan finde flere oplysninger under Deaktiver udgivelse og distribution.
  4. Hvis DBCC CHECKDB-rapporten indeholder reparationer for replikerede tabeller, skal du udføre datavalidering for at fastslå, om der er forskelle mellem dataene i udgivelses- og abonnementsdatabaserne.

Resultatsæt

DBCC CHECKDB returnerer følgende resultatsæt. Værdierne kan variere, undtagen når indstillingerne ESTIMATEONLY, PHYSICAL_ONLY eller NO_INFOMSGS er angivet:

 DBCC results for 'model'. Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13. Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5. Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3. Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0. DBCC results for 'sys.sysrowsetcolumns'. There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'. DBCC results for 'sys.sysrowsets'. There are 97 rows in 1 pages for object 'sys.sysrowsets'. DBCC results for 'sysallocunits'. There are 195 rows in 3 pages for object 'sysallocunits'. There are 0 rows in 0 pages for object "sys.sysasymkeys". DBCC results for 'sys.syssqlguides'. There are 0 rows in 0 pages for object "sys.syssqlguides". DBCC results for 'sys.queue_messages_1977058079'. There are 0 rows in 0 pages for object "sys.queue_messages_1977058079". DBCC results for 'sys.queue_messages_2009058193'. There are 0 rows in 0 pages for object "sys.queue_messages_2009058193". DBCC results for 'sys.queue_messages_2041058307'. There are 0 rows in 0 pages for object "sys.queue_messages_2041058307". CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB returnerer følgende resultatsæt (meddelelse), når NO_INFOMSGS er angivet:

 The command(s) completed successfully.

DBCC CHECKDB returnerer følgende resultatsæt, når PHYSICAL_ONLY er angivet:

 DBCC results for 'model'. CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB returnerer følgende resultatsæt, når ESTIMATEONLY er angivet: 

 DBCC results for 'model'. CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB returnerer følgende resultatsæt, når ESTIMATEONLY er angivet.

 Estimated TEMPDB space needed for CHECKALLOC (KB) ------------------------------------------------- 13 (1 row(s) affected) Estimated TEMPDB space needed for CHECKTABLES (KB) -------------------------------------------------- 57 (1 row(s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Permissions

Kræver medlemskab af den faste serverrolle sysadmin eller den faste databasefunktion db_owner.

Eksempler

A. Kontrol af både den aktuelle og en anden database

Det følgende eksempel udfører DBCC CHECKDB for den aktuelle database og for AdventureWorks2012-databasen.

-- Check the current database. DBCC CHECKDB; GO -- Check the AdventureWorks2012 database without nonclustered indexes. DBCC CHECKDB (AdventureWorks2012, NOINDEX); GO

B. Kontrol af den aktuelle database, undertrykker informationsmeddelelser

Det følgende eksempel kontrollerer den aktuelle database og undertrykker alle informationsmeddelelser.

DBCC CHECKDB WITH NO_INFOMSGS; GO

Se også

DBCC (Transact-SQL)
Se størrelsen af den sparsomme fil i et øjebliksbillede af en database (Transact-SQL)
sp_helpdb (Transact-SQL)
Systemtabeller (Transact-SQL)

By: adminPosted on

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.