DBCC CHECKDB (Transact-SQL)SQL)

• 12/14/2017
• 22 minuter att läsa
• • p
  • M
  • m
  • M
  • P
  • +3

Gäller: SQL Server (alla versioner som stöds) Azure SQL Database

Kontrollerar den logiska och fysiska integriteten för alla objekt i den angivna databasen genom att utföra följande åtgärder:

• Kör DBCC CHECKALLOC på databasen.
• Kör DBCC CHECKTABLE på varje tabell och vy i databasen.
• Kör DBCC CHECKCATALOG på databasen.
• Validerar innehållet i varje indexerad vy i databasen.
• Verifierar konsistens på länknivå mellan tabellmetadata och kataloger och filer i filsystemet när varbinär(max)-data lagras i filsystemet med hjälp av FILESTREAM.
• Validerar Service Broker-data i databasen.

Detta innebär att kommandona DBCC CHECKALLOC, DBCC CHECKTABLE eller DBCC CHECKCATALOG inte behöver köras separat från DBCC CHECKDB. Mer detaljerad information om de kontroller som dessa kommandon utför finns i beskrivningarna av dessa kommandon.

Konventioner för Transact-SQL-syntax

Syntax

DBCC CHECKDB ) ] } ] ] 

Argument

database_name | database_id | 0
Är namnet eller ID:et på den databas för vilken integritetskontroller ska utföras. Om inget anges, eller om 0 anges, används den aktuella databasen. Databasnamn måste följa reglerna för identifierare.

NOINDEX
Anger att intensiva kontroller av icke klustrade index för användartabeller inte ska utföras. Detta minskar den totala exekveringstiden. NOINDEX påverkar inte systemtabeller eftersom integritetskontroller alltid utförs på index för systemtabeller.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Anger att DBCC CHECKDB ska reparera de funna felen. Använd alternativen REPAIR endast som en sista utväg. Den angivna databasen måste vara i enanvändarläge för att kunna använda något av följande reparationsalternativ.

REPAIR_ALLOW_DATA_LOSS
Försöker reparera alla rapporterade fel. Dessa reparationer kan orsaka viss dataförlust.

REPAIR_FAST
Behåller syntaxen endast för bakåtkompatibilitet. Inga reparationsåtgärder utförs.

REPAIR_REBUILD
Gör reparationer som inte innebär någon risk för dataförlust. Detta kan inkludera snabba reparationer, t.ex. reparation av saknade rader i icke klustrade index, och mer tidskrävande reparationer, t.ex. återuppbyggnad av ett index.
Detta argument reparerar inte fel som involverar FILESTREAM-data.

ALL_ERRORMSGS
Visar alla rapporterade fel per objekt. Som standard visas alla felmeddelanden. Att ange eller utelämna det här alternativet har ingen effekt. Felmeddelanden sorteras efter objekt-ID, med undantag för de meddelanden som genereras från tempdb-databasen.

EXTENDED_LOGICAL_CHECKS
Om kompatibilitetsnivån är 100 ( SQL Server 2008) eller högre, utförs logiska konsistenskontroller på en indexerad vy, XML-index och spatiala index, där sådana finns.
För mer information, se Utföra logiska konsistenskontroller på index, i avsnittet Anmärkningar längre fram i det här avsnittet.

NO_INFOMSGS
Undertrycker alla informationsmeddelanden.

TABLOCK
Föranleder DBCC CHECKDB att hämta lås i stället för att använda en intern ögonblicksbild av databasen. Detta inkluderar ett kortsiktigt exklusivt (X) lås på databasen. TABLOCK gör att DBCC CHECKDB körs snabbare på en databas med hög belastning, men minskar den tillgängliga samtidigheten i databasen medan DBCC CHECKDB körs.

ESTIMATEONLY
Anger den uppskattade mängden tempdb-utrymme som krävs för att köra DBCC CHECKDB med alla andra angivna alternativ. Själva databaskontrollen utförs inte.

PHYSICAL_ONLY
Begränsar kontrollen till integriteten hos den fysiska strukturen för sid- och registerhuvudena och till databasens allokeringskonsistens. Den här kontrollen är utformad för att ge en liten overheadkontroll av databasens fysiska konsistens, men den kan också upptäcka rivna sidor, fel på kontrollsumman och vanliga maskinvarufel som kan äventyra en användares data.
En fullständig körning av DBCC CHECKDB kan ta betydligt längre tid att genomföra än tidigare versioner. Detta beteende beror på att:

• De logiska kontrollerna är mer omfattande.
• En del av de underliggande strukturer som ska kontrolleras är mer komplexa.
• Många nya kontroller har införts för att inkludera de nya funktionerna.
  Därför kan användning av alternativet PHYSICAL_ONLY ge upphov till en mycket kortare körtid för DBCC CHECKDB på stora databaser och rekommenderas för frekvent användning på produktionssystem. Vi rekommenderar fortfarande att en fullständig körning av DBCC CHECKDB utförs regelbundet. Frekvensen av dessa körningar beror på faktorer som är specifika för enskilda företag och produktionsmiljöer.
  Detta argument innebär alltid NO_INFOMSGS och är inte tillåtet med något av reparationsalternativen.

DATA_PURITY
Föranleder DBCC CHECKDB att kontrollera databasen för kolumnvärden som inte är giltiga eller utanför intervallet. DBCC CHECKDB upptäcker till exempel kolumner med datum- och tidsvärden som är större eller mindre än det acceptabla intervallet för datatypen datetime, eller kolumner av decimal- eller approximativt numerisk datatyp med skal- eller precisionsvärden som inte är giltiga.
Kolumnvärdesintegritetskontroller är aktiverade som standard och kräver inte alternativet DATA_PURITY. För databaser som uppgraderats från tidigare versioner av SQL Server aktiveras inte kolumnvärdeskontroller som standard förrän DBCC CHECKDB WITH DATA_PURITY har körts felfritt i databasen. Därefter kontrollerar DBCC CHECKDB kolumnvärdesintegriteten som standard. Mer information om hur CHECKDB kan påverkas av att uppgradera en databas från tidigare versioner av SQL Server finns i avsnittet Anmärkningar längre fram i det här avsnittet.

Valideringsfel som rapporteras av det här alternativet kan inte åtgärdas med hjälp av DBCC:s reparationsalternativ. Information om hur du korrigerar dessa fel manuellt finns i kunskapsbasartikel 923247: Felsökning av DBCC-fel 2570 i SQL Server 2005 och senare versioner.

MAXDOP
Gäller: SQL Server ( SQL Server 2014 (12.x) SP2 och senare).

Overrider konfigurationsalternativet för maximal grad av parallellitet i sp_configure för uttalandet. MAXDOP kan överstiga det värde som konfigurerats med sp_configure. Om MAXDOP överstiger det värde som konfigurerats med Resource Governor använder SQL Server Database Engine Resource Governor MAXDOP-värdet, som beskrivs i ALTER WORKLOAD GROUP. Alla semantiska regler som används med konfigurationsalternativet max grad av parallellitet är tillämpliga när du använder frågetipset MAXDOP. Mer information finns i Konfigurera serverkonfigurationsalternativet max grad av parallellitet.

Remarks

DBCC CHECKDB undersöker inte inaktiverade index. Mer information om inaktiverade index finns i Inaktivera index och begränsningar.

Om en användardefinierad typ är markerad som byteordnad får det bara finnas en serialisering av den användardefinierade typen. Om det inte finns en konsekvent serialisering av byteordnade användardefinierade typer orsakas fel 2537 när DBCC CHECKDB körs. Mer information finns i Krav på användardefinierade typer.

Då resursdatabasen endast kan ändras i enanvändarläge kan kommandot DBCC CHECKDB inte köras direkt på den. När DBCC CHECKDB körs mot huvuddatabasen körs dock även en andra CHECKDB internt på Resource-databasen. Detta innebär att DBCC CHECKDB kan ge extra resultat. Kommandot returnerar extra resultatuppsättningar när inga alternativ är inställda, eller när antingen alternativet PHYSICAL_ONLY eller ESTIMATEONLY är inställt.

Med början med SQL Server 2005 (9.x) SP2 rensar utförandet av DBCC CHECKDB inte längre plancachen för instansen av SQL Server. Före SQL Server 2005 (9.x) SP2 rensar DBCC CHECKDB plancachen om du utför DBCC CHECKDB. Rensning av plancachen leder till att alla senare exekveringsplaner kompileras på nytt och kan orsaka en plötslig, tillfällig minskning av frågeprestandan.

Uppförande av logiska konsistenskontroller på index

Logiska konsistenskontroller på index varierar beroende på databasens kompatibilitetsnivå enligt följande:

• Om kompatibilitetsnivån är 100 (SQL Server 2008) eller högre:
• Om inte NOINDEX har angetts utför DBCC CHECKDB både fysiska och logiska konsistenskontroller på en enskild tabell och på alla dess icke-klusterade index. På XML-index, spatiala index och indexerade vyer utförs dock som standard endast fysiska konsistenskontroller.
• Om WITH EXTENDED_LOGICAL_CHECKS anges utförs logiska kontroller på en indexerad vy, XML-index och spatiala index, om sådana finns. Som standard utförs fysiska konsistenskontroller före logiska konsistenskontroller. Om NOINDEX också anges utförs endast de logiska kontrollerna.

Dessa logiska konsistenskontroller dubbelkontrollerar indexobjektets interna indextabell med den användartabell som det hänvisar till. För att hitta avvikande rader konstrueras en intern fråga för att utföra en fullständig korsning av de interna tabellerna och användartabellerna. Att köra denna fråga kan ha en mycket stor effekt på prestandan, och dess framsteg kan inte spåras. Därför rekommenderar vi att du endast anger WITH EXTENDED_LOGICAL_CHECKS om du misstänker indexproblem som inte är relaterade till fysisk korruption, eller om kontrollsummor på sidnivå har stängts av och du misstänker hårdvarukorruption på kolumnnivå.

• Om indexet är ett filtrerat index utför DBCC CHECKDB konsistenskontroller för att verifiera att indexposterna uppfyller filterpredikatet.
• Om kompatibilitetsnivån är 90 eller lägre, såvida inte NOINDEX har angetts, utför DBCC CHECKDB både fysiska och logiska konsistenskontroller på en enskild tabell eller indexerad vy och på alla dess icke klustrade och XML-index. Rumsliga index stöds inte.
• Från och med SQL Server 2016 kommer ytterligare kontroller av persisterade beräknade kolumner, UDT-kolumner och filtrerade index inte att köras som standard för att undvika dyra utvärderingar av uttryck. Den här ändringen minskar kraftigt CHECKDB:s varaktighet mot databaser som innehåller dessa objekt. De fysiska konsistenskontrollerna av dessa objekt avslutas dock alltid. Endast när EXTENDED_LOGICAL_CHECKS-alternativet anges kommer uttrycksutvärderingarna att utföras utöver de redan befintliga logiska kontrollerna (indexerad vy, XML-index och spatiala index) som en del av EXTENDED_LOGICAL_CHECKS-alternativet.

För att få reda på kompatibilitetsnivån för en databas

• Visa eller ändra kompatibilitetsnivån för en databas

Internt databas-snapshot

DBCC CHECKDB använder ett internt databas-snapshot för att få den transaktionsmässiga konsistens som behövs för att utföra dessa kontroller. Detta förhindrar blockering och samtidighetsproblem när dessa kommandon utförs. Mer information finns i Visa storleken på den sparsamma filen för en ögonblicksbild av en databas (Transact-SQL) och i avsnittet DBCC Internal Database Snapshot Usage i DBCC (Transact-SQL). Om en ögonblicksbild inte kan skapas eller om TABLOCK har angetts förvärvar DBCC CHECKDB lås för att uppnå den nödvändiga konsistensen. I det här fallet krävs en exklusiv databaslås för att utföra allokeringskontrollerna och delade bordslås för att utföra tabellkontrollerna.DBCC CHECKDB misslyckas när den körs mot master om en snapshot av den interna databasen inte kan skapas.När DBCC CHECKDB körs mot tempdb utförs inga allokerings- eller katalogkontroller och måste förvärva delade bordslås för att utföra tabellkontrollerna. Detta beror på att det av prestandaskäl inte finns några ögonblicksbilder av databaser på tempdb. Detta innebär att den nödvändiga transaktionskonsistensen inte kan uppnås. i Microsoft SQL Server 2012 eller en tidigare version av SQL Server kan du få felmeddelanden när du kör kommandot DBCC CHECKDB för en databas vars filer finns på en ReFS-formaterad volym. Mer information finns i kunskapsbasartikel 2974455: DBCC CHECKDB behavior when the SQL Server database is located on an ReFS volume.

Kontrollera och reparera FILESTREAM-data

När FILESTREAM är aktiverat för en databas och tabell kan du valfritt lagra varbinary(max) binary large objects (BLOBs) i filsystemet. När du använder DBCC CHECKDB på en databas som lagrar BLOBs i filsystemet kontrollerar DBCC konsistensen på länknivå mellan filsystemet och databasen. om en tabell till exempel innehåller en varbinary(max)-kolumn som använder FILESTREAM-attributet kontrollerar DBCC CHECKDB att det finns en en-till-en-mappning mellan filsystemets kataloger och filer och tabellens rader, kolumner och kolumnvärden. DBCC CHECKDB kan reparera korruption om du anger alternativet REPAIR_ALLOW_DATA_LOSS. För att reparera FILESTREAM-korruption raderar DBCC alla tabellrader som saknar filsystemdata.

Bästa praxis

Vi rekommenderar att du använder alternativet PHYSICAL_ONLY för frekvent användning på produktionssystem. Användning av PHYSICAL_ONLY kan kraftigt förkorta körtiden för DBCC CHECKDB på stora databaser. Vi rekommenderar också att du regelbundet kör DBCC CHECKDB utan alternativ. Hur ofta du bör utföra dessa körningar beror på enskilda företag och deras produktionsmiljöer.

Kontroll av objekt parallellt

Som standard utför DBCC CHECKDB parallell kontroll av objekt. Graden av parallellitet bestäms automatiskt av frågeprocessorn. Den maximala graden av parallellitet konfigureras precis som parallella frågor. Om du vill begränsa det maximala antalet processorer som är tillgängliga för DBCC-checkning använder du sp_configure. Mer information finns i Konfigurera maximal grad av parallellism Serverkonfigurationsalternativ. Parallell kontroll kan inaktiveras med hjälp av spårningsflagga 2528. Mer information finns i Spårningsflaggor (Transact-SQL).

Förståelse av DBCC-felmeddelanden

När kommandot DBCC CHECKDB avslutas skrivs ett meddelande till SQL Server-felloggen. Om DBCC-kommandot utförs framgångsrikt anger meddelandet framgång och hur länge kommandot kördes. Om DBCC-kommandot slutar innan kontrollen är klar på grund av ett fel, anger meddelandet att kommandot avslutades, ett statusvärde och hur länge kommandot kördes. Följande tabell listar och beskriver de statusvärden som kan ingå i meddelandet.

State	Description
0	Felnummer 8930 uppstod. Detta indikerar en skada i metadata som avslutade DBCC-kommandot.
1	Felnummer 8967 uppstod. Ett internt DBCC-fel uppstod.
2	Ett fel inträffade under reparation av databasen i nödläge.
3	Det här indikerar att metadata var skadade och att DBCC-kommandot avslutades.
4	Ett assert- eller åtkomstbrott upptäcktes.
5	Ett okänt fel inträffade som avslutade DBCC-kommandot.

Felrapportering

En dumpfil (SQLDUMP*nnnn*.txt) skapas i SQL Server LOG-katalogen när DBCC CHECKDB upptäcker ett korruptionsfel. När funktionerna Feature Usage datainsamling och Error Reporting är aktiverade för instansen av SQL Server skickas filen automatiskt vidare till Microsoft. De insamlade uppgifterna används för att förbättra SQL Servers funktionalitet.Dumpfilen innehåller resultaten av DBCC CHECKDB-kommandot och ytterligare diagnostiska utdata. Åtkomsten är begränsad till SQL Server-tjänstkontot och medlemmar i rollen sysadmin. Som standard innehåller sysadmin-rollen alla medlemmar i gruppen Windows BUILTIN\Administrators och den lokala administratörsgruppen. DBCC-kommandot misslyckas inte om datainsamlingsprocessen misslyckas.

Lösning av fel

Om några fel rapporteras av DBCC CHECKDB rekommenderar vi att du återställer databasen från databasens säkerhetskopia istället för att köra REPAIR med något av REPAIR-alternativen. Om det inte finns någon säkerhetskopia rättar reparationen de rapporterade felen. Det reparationsalternativ som ska användas anges i slutet av listan över rapporterade fel. För att korrigera felen med hjälp av alternativet REPAIR_ALLOW_DATA_LOSS kan det dock krävas att vissa sidor, och därmed vissa data, raderas.

Under vissa omständigheter kan det hända att värden matas in i databasen som inte är giltiga eller som ligger utanför intervallet baserat på kolumnens datatyp. DBCC CHECKDB kan upptäcka kolumnvärden som inte är giltiga för alla kolonnens datatyper. Om du kör DBCC CHECKDB med alternativet DATA_PURITY på databaser som har uppgraderats från tidigare versioner av SQL Server kan det därför hända att du upptäcker redan existerande kolumnvärdesfel. Eftersom SQL Server inte kan reparera dessa fel automatiskt måste kolumnvärdet uppdateras manuellt. Om CHECKDB upptäcker ett sådant fel returnerar CHECKDB en varning, felnummer 2570 och information för att identifiera den berörda raden och manuellt rätta till felet.

Reparationen kan utföras under en användartransaktion så att användaren kan återkalla de ändringar som gjorts. Om reparationen rullas tillbaka kommer databasen fortfarande att innehålla fel och måste återställas från en säkerhetskopia. Säkerhetskopiera databasen när reparationen är klar.

Lösning av fel i databasens nödläge

När en databas har satts i nödläge med hjälp av ALTER DATABASE-anvisningen kan DBCC CHECKDB utföra vissa speciella reparationer av databasen om alternativet REPAIR_ALLOW_DATA_LOSS har angetts. Dessa reparationer kan göra att databaser som normalt sett inte kan återställas kan återställas online i ett fysiskt konsistent tillstånd. Dessa reparationer bör användas som en sista utväg och endast när du inte kan återställa databasen från en säkerhetskopia. När databasen sätts i nödläge markeras databasen som READ_ONLY, loggning inaktiveras och åtkomsten är begränsad till medlemmar i den fasta serverrollen sysadmin.

När databasen är i nödläge och DBCC CHECKDB med klausulen REPAIR_ALLOW_DATA_LOSS körs, vidtas följande åtgärder:

• DBCC CHECKDB använder sidor som har markerats som otillgängliga på grund av I/O- eller kontrollsummafel, som om felen inte hade uppstått. Detta ökar chanserna för dataåterställning från databasen.
• DBCC CHECKDB försöker återställa databasen med vanliga loggbaserade återställningstekniker.
• Om återställningen av databasen misslyckas på grund av att transaktionsloggen är skadad, byggs transaktionsloggen om. Ombyggnaden av transaktionsloggen kan resultera i förlust av transaktionskonsistens.

Om DBCC CHECKDB-kommandot lyckas är databasen i ett fysiskt konsistent tillstånd och databasens status är satt till ONLINE. Databasen kan dock innehålla en eller flera transaktionsinkonsistenser. Vi rekommenderar att du kör DBCC CHECKCONSTRAINTS för att identifiera eventuella brister i affärslogiken och omedelbart säkerhetskopiera databasen. om DBCC CHECKDB-kommandot misslyckas kan databasen inte repareras.

Körning av DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS i replikerade databaser

Körning av DBCC CHECKDB-kommandot med alternativet REPAIR_ALLOW_DATA_LOSS kan påverka användardatabaserna (publikations- och prenumerationsdatabaser) och den distributionsdatabas som används vid replikering. Publikations- och prenumerationsdatabaser innehåller publicerade tabeller och metadatatabeller för replikering. Var uppmärksam på följande potentiella problem i dessa databaser:

• Publicerade tabeller. Åtgärder som utförs av CHECKDB-processen för att reparera korrupta användardata kanske inte replikeras:
• Merge replication använder triggers för att spåra ändringar i publicerade tabeller. Om rader infogas, uppdateras eller tas bort av CHECKDB-processen aktiveras inte utlösare och ändringen replikeras därför inte.
• Transaktionsreplikering använder transaktionsloggen för att spåra ändringar i publicerade tabeller. Loggningsläsningsagenten flyttar sedan dessa ändringar till distributionsdatabasen. Vissa DBCC-reparationer kan inte replikeras av Log Reader Agent, även om de loggas. Om till exempel en datasida avallokeras av CHECKDB-processen översätter Log Reader Agent inte detta till ett DELETE-meddelande; därför replikeras inte ändringen.
• Metadatatabeller för replikering. Åtgärder som utförs av CHECKDB-processen för att reparera korrupta metadatatabeller för replikering kräver att replikering tas bort och konfigureras på nytt.

Om du måste köra kommandot DBCC CHECKDB med alternativet REPAIR_ALLOW_DATA_LOSS på en användardatabas eller distributionsdatabas:

1. Skydda systemet: Stoppa aktiviteten i databasen och i alla andra databaser i replikeringstopologin och försök sedan att synkronisera alla noder. Mer information finns i Quiesce a Replication Topology (Replication Transact-SQL Programming).
2. Exekvera DBCC CHECKDB.
3. Om DBCC CHECKDB-rapporten innehåller reparationer för tabeller i distributionsdatabasen eller för metadatatabeller för replikering i en användardatabas ska du ta bort och konfigurera replikering på nytt. Mer information finns i Avaktivera publicering och distribution.
4. Om DBCC CHECKDB-rapporten innehåller reparationer för replikerade tabeller utför du datavalidering för att avgöra om det finns skillnader mellan data i publikations- och prenumerationsdatabaserna.

Resultatuppsättningar

DBCC CHECKDB returnerar följande resultatuppsättning. Värdena kan variera utom när alternativen ESTIMATEONLY, PHYSICAL_ONLY eller NO_INFOMSGS anges:

 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 returnerar följande resultatuppsättning (meddelande) när NO_INFOMSGS anges:

 The command(s) completed successfully.

DBCC CHECKDB returnerar följande resultatuppsättning när PHYSICAL_ONLY anges:

 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 returnerar följande resultatuppsättning när ESTIMATEONLY anges.

 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.

Myndigheter

Kräver medlemskap i den fasta serverrollen sysadmin eller den fasta databasrollen db_owner.

Exempel

A. Kontrollera både den aktuella och en annan databas

Följande exempel utför DBCC CHECKDB för den aktuella databasen och för AdventureWorks2012-databasen.

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

B. Kontrollera den aktuella databasen och undertrycka informationsmeddelanden

Följande exempel kontrollerar den aktuella databasen och undertrycker alla informationsmeddelanden.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Se även

DBCC (Transact-SQL)
Visa storleken på den sparsamma filen för en ögonblicksbild av en databas (Transact-SQL)
sp_helpdb (Transact-SQL)
Systemtabeller (Transact-SQL)

.