DBCC CHECKDB (Transact-)SQL)

• 14/12/2017
• 22 minute de citit
• • p
  • M

  .

  • m
  • M
  • P
  • +3

Se aplică la: SQL Server (toate versiunile acceptate) Azure SQL Database

Verifică integritatea logică și fizică a tuturor obiectelor din baza de date specificată prin efectuarea următoarelor operații:

• Execută DBCC CHECKALLOC pe baza de date.
• Execută DBCC CHECKTABLE pe fiecare tabel și vizualizare din baza de date.
• Execută DBCC CHECKCATALOG pe baza de date.
• Validează conținutul fiecărei vizualizări indexate din baza de date.
• Validează consistența la nivel de legătură între metadatele tabelelor și directoarele și fișierele din sistemul de fișiere atunci când se stochează date varbinare(max) în sistemul de fișiere utilizând FILESTREAM.
• Validează datele Service Broker din baza de date.

Aceasta înseamnă că comenzile DBCC CHECKALLOC, DBCC CHECKTABLE sau DBCC CHECKCATALOG nu trebuie să fie executate separat de DBCC CHECKDB. Pentru informații mai detaliate despre verificările pe care le efectuează aceste comenzi, consultați descrierile acestor comenzi.

Convenții de sintaxă Transact-SQL

Sintaxa

DBCC CHECKDB ) ] } ] ] 

Argumente

database_name | database_id | 0
Este numele sau ID-ul bazei de date pentru care se execută verificările de integritate. Dacă nu este specificat sau dacă este specificat 0, se utilizează baza de date curentă. Numele bazelor de date trebuie să respecte regulile pentru identificatori.

NOINDEX
Specifică faptul că nu trebuie efectuate verificări intensive ale indexurilor neaglomerate pentru tabelele utilizatorilor. Acest lucru scade timpul total de execuție. NOINDEX nu afectează tabelele de sistem deoarece verificările de integritate sunt întotdeauna efectuate pe indicii tabelelor de sistem.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Specifică faptul că DBCC CHECKDB repară erorile găsite. Utilizați opțiunile REPAIR numai în ultimă instanță. Baza de date specificată trebuie să fie în modul mono-utilizator pentru a utiliza una dintre următoarele opțiuni de reparare.

REPAIR_ALLOW_DATA_LOSS
Încearcă să repare toate erorile raportate. Aceste reparații pot cauza unele pierderi de date.

REPAIR_FAST
Mărește sintaxa numai pentru compatibilitate retroactivă. Nu se efectuează nicio acțiune de reparare.

REPAIR_REBUILD
Realizează reparații care nu au nicio posibilitate de pierdere de date. Acest lucru poate include reparații rapide, cum ar fi repararea rândurilor lipsă în indexuri neaglomerate, și reparații care necesită mai mult timp, cum ar fi reconstruirea unui index.
Acest argument nu repară erorile care implică date FILESTREAM.

ALL_ERRORMSGS
Afișează toate erorile raportate per obiect. În mod implicit, sunt afișate toate mesajele de eroare. Specificarea sau omiterea acestei opțiuni nu are niciun efect. Mesajele de eroare sunt sortate în funcție de ID-ul obiectului, cu excepția mesajelor generate din baza de date tempdb.

EXTENDED_LOGICAL_CHECKS
Dacă nivelul de compatibilitate este 100 ( SQL Server 2008) sau mai mare, efectuează verificări de consistență logică asupra unei vizualizări indexate, a indexurilor XML și a indexurilor spațiale, dacă sunt prezente.
Pentru mai multe informații, consultați Performing Logical Consistency Checks on Indexes (Efectuarea de verificări ale consistenței logice asupra indexurilor), în secțiunea Remarks (Observații), mai târziu în acest subiect.

NO_INFOMSGS
Suprimă toate mesajele informative.

TABLOCK
Causa DBCC CHECKDB să obțină blocaje în loc să utilizeze un instantaneu intern al bazei de date. Aceasta include o blocare exclusivă (X) pe termen scurt asupra bazei de date. TABLOCK va face ca DBCC CHECKDB să ruleze mai rapid pe o bază de date supusă unei sarcini mari, dar scade concurența disponibilă pe baza de date în timp ce DBCC CHECKDB rulează.

ESTIMATEONLY
Afișează cantitatea estimată de spațiu tempdb care este necesară pentru a executa DBCC CHECKDB cu toate celelalte opțiuni specificate. Nu se efectuează verificarea efectivă a bazei de date.

PHYSICAL_ONLY
Limitează verificarea la integritatea structurii fizice a capetelor de pagină și de înregistrare și la consistența alocării bazei de date. Această verificare este concepută pentru a oferi o mică verificare a consistenței fizice a bazei de date, dar poate detecta, de asemenea, pagini rupte, eșecuri ale sumelor de control și defecțiuni hardware comune care pot compromite datele unui utilizator.
O execuție completă a DBCC CHECKDB poate dura considerabil mai mult decât versiunile anterioare. Acest comportament apare deoarece:

• Verificările logice sunt mai cuprinzătoare.
• Câteva dintre structurile subiacente care trebuie verificate sunt mai complexe.
• Multe verificări noi au fost introduse pentru a include noile caracteristici.
  De aceea, utilizarea opțiunii PHYSICAL_ONLY poate determina un timp de execuție mult mai scurt pentru DBCC CHECKDB pe baze de date mari și este recomandată pentru utilizarea frecventă pe sistemele de producție. Recomandăm în continuare efectuarea periodică a unei rulări complete a DBCC CHECKDB. Frecvența acestor rulări depinde de factori specifici întreprinderilor individuale și mediilor de producție.
  Acest argment implică întotdeauna NO_INFOMSGS și nu este permis cu niciuna dintre opțiunile de reparare.

DATA_PURITY
Caută DBCC CHECKDB să verifice baza de date pentru valorile coloanelor care nu sunt valide sau sunt în afara intervalului. De exemplu, DBCC CHECKDB detectează coloanele cu valori de dată și oră care sunt mai mari sau mai mici decât intervalul acceptabil pentru tipul de date datetime; sau coloanele de tip date zecimale sau de tip date numerice aproximative cu valori de scală sau de precizie care nu sunt valide.
Controalele de integritate a valorilor coloanelor sunt activate în mod implicit și nu necesită opțiunea DATA_PURITY. Pentru bazele de date actualizate de la versiuni anterioare ale SQL Server, verificările valorilor coloanelor nu sunt activate în mod implicit până când DBCC CHECKDB WITH DATA_PURITY nu a fost rulat fără erori pe baza de date. După aceasta, DBCC CHECKDB verifică integritatea valorilor coloanelor în mod implicit. Pentru mai multe informații despre modul în care CHECKDB ar putea fi afectat de actualizarea bazei de date de la versiuni anterioare ale SQL Server, consultați secțiunea Observații mai târziu în acest subiect.

Erorile de validare raportate de această opțiune nu pot fi reparate prin utilizarea opțiunilor de reparare DBCC. Pentru informații despre corectarea manuală a acestor erori, consultați articolul din baza de cunoștințe 923247: Depanarea erorii DBCC 2570 în SQL Server 2005 și versiunile ulterioare.

MAXDOP
Se aplică la: SQL Server ( SQL Server 2014 (12.x) SP2 și versiunile ulterioare).

Înlocuiește opțiunea de configurare a gradului maxim de paralelism din sp_configure pentru instrucțiunea. MAXDOP poate depăși valoarea configurată cu sp_configure. Dacă MAXDOP depășește valoarea configurată cu Resource Governor, motorul de baze de date SQL Server utilizează valoarea MAXDOP a Resource Governor, descrisă în ALTER WORKLOAD GROUP. Toate regulile semantice utilizate cu opțiunea de configurare a gradului maxim de paralelism se aplică atunci când utilizați indicația de interogare MAXDOP. Pentru mai multe informații, consultați Configurarea opțiunii de configurare a gradului maxim de paralelism a serverului.

Observații

DBCC CHECKDB nu examinează indexurile dezactivate. Pentru mai multe informații despre indexurile dezactivate, consultați secțiunea Indexuri și restricții dezactivate.

Dacă un tip definit de utilizator este marcat ca fiind ordonat pe octeți, trebuie să existe o singură serializare a tipului definit de utilizator. Faptul că nu există o serializare consecventă a tipurilor definite de utilizator ordonate pe octeți cauzează eroarea 2537 atunci când se execută DBCC CHECKDB. Pentru mai multe informații, consultați Cerințe privind tipurile definite de utilizator.

Pentru că baza de date Resource este modificabilă numai în modul single-user, comanda DBCC CHECKDB nu poate fi executată direct pe aceasta. Cu toate acestea, atunci când DBCC CHECKDB este executată față de baza de date principală, o a doua comandă CHECKDB este, de asemenea, executată intern pe baza de date Resource. Aceasta înseamnă că DBCC CHECKDB poate returna rezultate suplimentare. Comanda returnează seturi de rezultate suplimentare atunci când nu este setată nicio opțiune sau atunci când este setată opțiunea PHYSICAL_ONLY sau ESTIMATEONLY.

Începând cu SQL Server 2005 (9.x) SP2, executarea DBCC CHECKDB nu mai șterge memoria cache a planului pentru instanța de SQL Server. Înainte de SQL Server 2005 (9.x) SP2, executarea DBCC CHECKDB șterge memoria cache a planului. Ștergerea memoriei cache a planurilor determină recompilarea tuturor planurilor de execuție ulterioare și poate cauza o scădere bruscă și temporară a performanței interogărilor.

Realizarea verificărilor de consistență logică a indicilor

Verificarea consistenței logice a indicilor variază în funcție de nivelul de compatibilitate al bazei de date, după cum urmează:

• Dacă nivelul de compatibilitate este 100 (SQL Server 2008) sau mai mare:
• Dacă nu este specificat NOINDEX, DBCC CHECKDB efectuează atât verificări de consistență fizică, cât și logică pe o singură tabelă și pe toți indicii săi neaglomerate. Cu toate acestea, pe indicii XML, indicii spațiali și vizualizările indexate se efectuează în mod implicit numai verificări de consistență fizică.
• Dacă este specificat WITH EXTENDED_LOGICAL_CHECKS, se efectuează verificări logice pe o vizualizare indexată, pe indicii XML și pe indicii spațiali, dacă sunt prezenți. În mod implicit, verificările de consistență fizică sunt efectuate înaintea verificărilor de consistență logică. Dacă este specificat și NOINDEX, se efectuează numai verificările logice.

Aceste verificări de coerență logică verifică încrucișat tabelul de index intern al obiectului de index cu tabelul utilizatorului la care face referire. Pentru a găsi rândurile aberante, se construiește o interogare internă pentru a efectua o intersecție completă a tabelelor interne și de utilizator. Rularea acestei interogări poate avea un efect foarte mare asupra performanței, iar progresul acesteia nu poate fi urmărit. Prin urmare, vă recomandăm să specificați WITH EXTENDED_LOGICAL_CHECKS numai dacă suspectați probleme legate de indici care nu au legătură cu corupția fizică sau dacă sumele de control la nivel de pagină au fost dezactivate și suspectați o corupție hardware la nivel de coloană.

• Dacă indexul este un index filtrat, DBCC CHECKDB efectuează controale de consistență pentru a verifica dacă intrările indexului satisfac predicatul de filtrare.
• Dacă nivelul de compatibilitate este 90 sau mai mic, cu excepția cazului în care este specificat NOINDEX, DBCC CHECKDB efectuează atât verificări de consistență fizică, cât și logică pe o singură tabelă sau vizualizare indexată și pe toți indicii săi neaglomerate și XML. Indicii spațiali nu sunt suportați.
• Începând cu SQL Server 2016, verificările suplimentare privind coloanele calculate persistate, coloanele UDT și indicii filtrați nu se vor executa în mod implicit pentru a evita evaluările costisitoare ale expresiilor. Această modificare reduce foarte mult durata de funcționare a CHECKDB împotriva bazelor de date care conțin aceste obiecte. Cu toate acestea, verificările de consistență fizică a acestor obiecte se finalizează întotdeauna. Numai atunci când este specificată opțiunea EXTENDED_LOGICAL_CHECKS, evaluările expresiilor vor fi efectuate în plus față de verificările logice deja prezente (vizualizare indexată, indici XML și indici spațiali) ca parte a opțiunii EXTENDED_LOGICAL_CHECKS.

Pentru a afla nivelul de compatibilitate al unei baze de date

• Vizualizați sau modificați nivelul de compatibilitate al unei baze de date

Internal Database Snapshot

DBCC CHECKDB utilizează un instantaneu intern al bazei de date pentru consistența tranzacțională necesară pentru a efectua aceste verificări. Acest lucru previne blocarea și problemele de concurență atunci când sunt executate aceste comenzi. Pentru mai multe informații, consultați secțiunea View the Size of the Sparse File of a Database Snapshot (Transact-SQL) și secțiunea DBCC Internal Database Snapshot Usage din DBCC (Transact-SQL). Dacă nu se poate crea un instantaneu sau dacă se specifică TABLOCK, DBCC CHECKDB achiziționează blocaje pentru a obține consistența necesară. În acest caz, este necesară o blocare exclusivă a bazei de date pentru a efectua verificări de alocare și sunt necesare blocări partajate ale tabelelor pentru a efectua verificări ale tabelelor.DBCC CHECKDB eșuează atunci când este rulat împotriva master dacă nu poate fi creat un instantaneu al bazei de date interne.Rularea DBCC CHECKDB împotriva tempdb nu efectuează nicio verificare de alocare sau de catalog și trebuie să achiziționeze blocări partajate ale tabelelor pentru a efectua verificări ale tabelelor. Acest lucru se datorează faptului că, din motive de performanță, instantaneele bazei de date nu sunt disponibile pe tempdb. Acest lucru înseamnă că nu se poate obține consistența tranzacțională necesară.În Microsoft SQL Server 2012 sau într-o versiune anterioară a SQL Server, este posibil să întâmpinați mesaje de eroare atunci când executați comanda DBCC CHECKDB pentru o bază de date ale cărei fișiere sunt localizate pe un volum formatat ReFS. Pentru mai multe informații, consultați articolul din baza de cunoștințe 2974455: Comportamentul DBCC CHECKDB atunci când baza de date SQL Server este localizată pe un volum ReFS.

Verificarea și repararea datelor FILESTREAM

Când FILESTREAM este activat pentru o bază de date și o tabelă, puteți stoca opțional obiecte mari binare (BLOB) varbinare(max) în sistemul de fișiere. Atunci când se utilizează DBCC CHECKDB pe o bază de date care stochează BLOB-uri în sistemul de fișiere, DBCC verifică coerența la nivel de legătură între sistemul de fișiere și baza de date. de exemplu, dacă o tabelă conține o coloană varbinary(max) care utilizează atributul FILESTREAM, DBCC CHECKDB va verifica dacă există o corespondență unu la unu între directoarele și fișierele sistemului de fișiere și rândurile, coloanele și valorile coloanelor din tabelă. DBCC CHECKDB poate repara corupția dacă specificați opțiunea REPAIR_ALLOW_DATA_LOSS. Pentru a repara corupția FILESTREAM, DBCC va șterge orice rânduri de tabel în care lipsesc date din sistemul de fișiere.

Best Practices

Vă recomandăm să folosiți opțiunea PHYSICAL_ONLY pentru utilizare frecventă pe sistemele de producție. Utilizarea PHYSICAL_ONLY poate scurta foarte mult timpul de execuție pentru DBCC CHECKDB pe baze de date mari. De asemenea, vă recomandăm să rulați periodic DBCC CHECKDB fără opțiuni. Frecvența cu care ar trebui să efectuați aceste rulări depinde de întreprinderile individuale și de mediile lor de producție.

Verificarea obiectelor în paralel

În mod implicit, DBCC CHECKDB efectuează verificarea paralelă a obiectelor. Gradul de paralelism este determinat automat de către procesorul de interogare. Gradul maxim de paralelism este configurat la fel ca în cazul interogărilor paralele. Pentru a restricționa numărul maxim de procesoare disponibile pentru verificarea DBCC, utilizați sp_configure. Pentru mai multe informații, consultați Configurarea gradului maxim de paralelism Opțiunea de configurare a serverului (Configure the max degree of parallelism Server Configuration Option). Verificarea paralelă poate fi dezactivată prin utilizarea indicatorului de urmărire 2528. Pentru mai multe informații, consultați Flags de urmărire (Transact-SQL).

Înțelegerea mesajelor de eroare DBCC

După ce comanda DBCC CHECKDB se termină, se scrie un mesaj în jurnalul de erori SQL Server. În cazul în care comanda DBCC se execută cu succes, mesajul indică succesul și durata de timp în care s-a executat comanda. Dacă comanda DBCC se oprește înainte de finalizarea verificării din cauza unei erori, mesajul indică faptul că comanda a fost terminată, o valoare de stare și durata de timp în care s-a executat comanda. Tabelul următor enumeră și descrie valorile de stare care pot fi incluse în mesaj.

Stare	Descriere
0	A fost generată eroarea numărul 8930. Acest lucru indică o corupție în metadate care a încheiat comanda DBCC.
1	A fost ridicată eroarea cu numărul 8967. A existat o eroare internă DBCC.
2	A avut loc un eșec în timpul reparării bazei de date în modul de urgență.
3	Aceasta indică o corupție în metadate care a încheiat comanda DBCC.
4	A fost detectată o încălcare de aserțiune sau de acces.
5	A apărut o eroare necunoscută care a încheiat comanda DBCC.

Error Reporting

Un fișier de vidare (SQLDUMP*nnnn*.txt) este creat în directorul SQL Server LOG ori de câte ori DBCC CHECKDB detectează o eroare de corupție. Atunci când funcțiile de colectare a datelor de utilizare a caracteristicilor și de raportare a erorilor sunt activate pentru instanța de SQL Server, fișierul este transmis automat către Microsoft. Datele colectate sunt utilizate pentru a îmbunătăți funcționalitatea SQL Server. fișierul de descărcare conține rezultatele comenzii DBCC CHECKDB și rezultate suplimentare de diagnosticare. Accesul este limitat la contul de serviciu SQL Server și la membrii rolului sysadmin. În mod implicit, rolul sysadmin conține toți membrii grupului Windows BUILTIN\Administrators și ai grupului administratorului local. Comanda DBCC nu eșuează dacă procesul de colectare a datelor eșuează.

Rezolvarea erorilor

Dacă DBCC CHECKDB raportează erori, vă recomandăm să restaurați baza de date de la copia de rezervă a bazei de date în loc să rulați REPAIR cu una dintre opțiunile REPAIR. Dacă nu există o copie de rezervă, rularea reparării corectează erorile raportate. Opțiunea de reparare care trebuie utilizată este specificată la sfârșitul listei de erori raportate. Cu toate acestea, corectarea erorilor prin utilizarea opțiunii REPAIR_ALLOW_DATA_LOSS ar putea necesita ștergerea unor pagini și, prin urmare, a unor date.

În anumite circumstanțe, în baza de date pot fi introduse valori care nu sunt valide sau care sunt în afara intervalului de valori pe baza tipului de date al coloanei. DBCC CHECKDB poate detecta valorile coloanelor care nu sunt valide pentru toate tipurile de date ale coloanelor. Prin urmare, rularea DBCC CHECKDB cu opțiunea DATA_PURITY pe baze de date care au fost actualizate de la versiuni anterioare ale SQL Server ar putea dezvălui erori preexistente privind valorile coloanelor. Deoarece SQL Server nu poate repara automat aceste erori, valoarea coloanei trebuie actualizată manual. Dacă CHECKDB detectează o astfel de eroare, CHECKDB returnează un avertisment, numărul de eroare 2570 și informații pentru a identifica rândul afectat și a corecta manual eroarea.

Repararea poate fi efectuată în cadrul unei tranzacții de utilizator pentru a permite utilizatorului să anuleze modificările efectuate. Dacă reparațiile sunt anulate, baza de date va conține în continuare erori și trebuie să fie restaurată dintr-o copie de rezervă. După ce reparațiile sunt finalizate, efectuați o copie de rezervă a bazei de date.

Rezolvarea erorilor în modul de urgență al bazei de date

Când o bază de date a fost setată în modul de urgență prin utilizarea instrucțiunii ALTER DATABASE, DBCC CHECKDB poate efectua unele reparații speciale asupra bazei de date dacă este specificată opțiunea REPAIR_ALLOW_DATA_LOSS. Aceste reparații pot permite ca bazele de date în mod normal irecuperabile să fie repuse online într-o stare fizic consistentă. Aceste reparații trebuie utilizate în ultimă instanță și numai atunci când nu puteți restaura baza de date dintr-o copie de rezervă. Când baza de date este setată în modul de urgență, baza de date este marcată READ_ONLY, jurnalizarea este dezactivată, iar accesul este limitat la membrii rolului de server fix sysadmin.

Când baza de date se află în modul de urgență și se execută comanda DBCC CHECKDB cu clauza REPAIR_ALLOW_DATA_LOSS, se întreprind următoarele acțiuni:

• DBCC CHECKDB utilizează paginile care au fost marcate ca inaccesibile din cauza erorilor de I/O sau a erorilor de sumă de control, ca și cum erorile nu ar fi apărut. Făcând acest lucru, cresc șansele de recuperare a datelor din baza de date.
• DBCC CHECKDB încearcă să recupereze baza de date utilizând tehnicile obișnuite de recuperare bazate pe jurnal.
• Dacă, din cauza corupției jurnalului de tranzacții, recuperarea bazei de date nu reușește, jurnalul de tranzacții este reconstruit. Reconstrucția jurnalului de tranzacții poate avea ca rezultat pierderea consistenței tranzacționale.

Dacă comanda DBCC CHECKDB reușește, baza de date se află într-o stare de consistență fizică și starea bazei de date este setată la ONLINE. Cu toate acestea, este posibil ca baza de date să conțină una sau mai multe inconsecvențe tranzacționale. Vă recomandăm să rulați DBCC CHECKCONSTRAINTS pentru a identifica orice defecte de logică de afaceri și să efectuați imediat o copie de rezervă a bazei de date. în cazul în care comanda DBCC CHECKDB eșuează, baza de date nu poate fi reparată.

Rularea comenzii DBCC CHECKDB cu opțiunea REPAIR_ALLOW_DATA_LOSS în bazele de date replicate

Rularea comenzii DBCC CHECKDB cu opțiunea REPAIR_ALLOW_DATA_LOSS poate afecta bazele de date ale utilizatorilor (baze de date de publicații și abonamente) și baza de date de distribuție utilizată prin replicare. Bazele de date de publicare și de abonament includ tabelele publicate și tabelele de metadate de replicare. Fiți atenți la următoarele probleme potențiale în aceste baze de date:

• Tabele publicate. Este posibil ca acțiunile efectuate de procesul CHECKDB pentru a repara datele corupte ale utilizatorilor să nu fie replicate:
• Replicarea prin replicare utilizează declanșatori pentru a urmări modificările tabelelor publicate. Dacă rândurile sunt inserate, actualizate sau șterse de către procesul CHECKDB, declanșatoarele nu se declanșează; prin urmare, modificarea nu este replicată.
• Replicarea tranzacțională utilizează jurnalul de tranzacții pentru a urmări modificările aduse tabelelor publicate. Agentul de citire a jurnalului mută apoi aceste modificări în baza de date de distribuție. Unele reparații DBCC, deși sunt înregistrate, nu pot fi replicate de către Log Reader Agent. De exemplu, dacă o pagină de date este dezalocată de către procesul CHECKDB, Log Reader Agent nu traduce acest lucru într-o instrucțiune DELETE; prin urmare, modificarea nu este replicată.
• Tabele de metadate de replicare. Acțiunile efectuate de procesul CHECKDB pentru a repara tabelele de metadate de replicare corupte necesită eliminarea și reconfigurarea replicării.

Dacă trebuie să executați comanda DBCC CHECKDB cu opțiunea REPAIR_ALLOW_DATA_LOSS pe o bază de date de utilizator sau pe o bază de date de distribuție:

1. Căutați sistemul: Opriți activitatea pe baza de date și la toate celelalte baze de date din topologia de replicare, apoi încercați să sincronizați toate nodurile. Pentru mai multe informații, consultați Quiesce a Replication Topology (Programare Transact-SQL de replicare).
2. Executați DBCC CHECKDB.
3. Dacă raportul DBCC CHECKDB include reparații pentru orice tabel din baza de date de distribuție sau orice tabel de metadate de replicare dintr-o bază de date de utilizator, eliminați și reconfigurați replicarea. Pentru mai multe informații, consultați Dezactivarea publicării și distribuției.
4. Dacă raportul DBCC CHECKDB include reparații pentru orice tabel replicat, efectuați validarea datelor pentru a determina dacă există diferențe între datele din bazele de date de publicare și de abonament.

Seturi de rezultate

DBCC CHECKDB returnează următorul set de rezultate. Valorile pot varia, cu excepția cazului în care sunt specificate opțiunile ESTIMATEONLY, PHYSICAL_ONLY sau NO_INFOMSGS:

 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 returnează următorul set de rezultate (mesaj) atunci când este specificat NO_INFOMSGS:

 The command(s) completed successfully.

DBCC CHECKDB returnează următorul set de rezultate atunci când este specificat PHYSICAL_ONLY:

 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 returnează următorul set de rezultate atunci când este specificat ESTIMATEONLY:

 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 returnează următorul set de rezultate atunci când este specificat ESTIMATEONLY.

 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

Requires membership in the sysadmin fixed server role or the db_owner fixed database role.

Examples

A. Verificarea atât a bazei de date curente, cât și a unei alte baze de date

Exemplul următor execută DBCC CHECKDB pentru baza de date curentă și pentru baza de date AdventureWorks2012.

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

B. Verificarea bazei de date curente, suprimarea mesajelor informative

Exemplul următor verifică baza de date curentă și suprimă toate mesajele informative.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Vezi și

DBCC (Transact-SQL)
Vezi dimensiunea fișierului de dispersie al unui instantaneu al bazei de date (Transact-SQL)
sp_helpdb (Transact-SQL)
Tabele de sistem (Transact-SQL)

.