Comanda din consola bazei de date CHECKDB (DBCC CHECKDB)este utilizată pentru a verifica integritatea (fizică & logică) a obiectelor dintr-o bază de date SQL Server.Comanda este suportată în bazele de date care conțin tabele optimizate pentru memorie, dar validarea este suportată numai în tabelele bazate pe disc. Opțiunea de reparare DBCC nu este disponibilă în tabelele cu memorie optimizată și, prin urmare, conduce la necesitatea efectuării regulate a unui backup al bazei de date. în cazul în care apare o problemă într-un tabel cu memorie optimizată, datele pot fi restaurate de la ultimul backup efectuat.
Diversele operații care sunt efectuate de CHECKDB sunt:
- DBCC CHECKALLOC execuție pe baza de date SQL.
- DBCC CHECKTABLE execuție pe fiecare tabel și vizualizare a bazei de date SQL.
- DBCC CHECKCATALOG execuție pe baza de date SQL.
- Validarea conținutului în vizualizarea indexată a bazei de date.
- Validarea consistenței la nivel de legătură între directoarele de fișiere și metadatele tabelelor.
- Validarea datelor brokerului de servicii.
Din moment ce DBCC CHECKDB execută toate celelalte comenzi, nu va fi necesară executarea separată a comenzilor CHECKALLOC, CHECKTABLE și CHECKCATALOG.
DBCC CHECKDB Sintaxa
Argumentele utilizate în sintaxa de mai sus semnifică următoarele:
database_name | database_id | 0 Acesta este numele bazei de date.În cazul în care numele nu este semnificat sau este scris doar 0, atunci se utilizează baza de date curentă. NOINDEX Specifică faptul că nu trebuie efectuată verificarea integrității tabelelor cu indici care nu sunt grupate în clustere. Această sintaxă nu afectează datele care se află în tabele. REPAIR_ALLOW_DATA_LOSS Această sintaxă repară erorile care se găsesc în baza de date, ceea ce poate duce la pierderea unor date.
Nota: Această sintaxă este susținută de Microsoft și nu de fiecare dată se dovedește a fi o soluție ideală pentru a transforma baza de date într-o stare fizică bună. Acest lucru se datorează faptului că șterge toate datele care se constată a fi corupte și poate duce la pierderea mai multor date, decât s-a făcut inițial în baza de date. prin urmare, ar trebui să fie adoptată ca o ultimă soluție.
REPAIR_FAST Acest argument menține doar compatibilitatea retroactivă și nu efectuează nicio reparație. REPAIR REBUILD Acest argument include un proces de reparare mai rapid care nu impune amenințarea vreunei pierderi de date. ALL_ERRORMSGS Acesta afișează toate erorile care sunt generate în toate obiectele. Includerea sau excluderea acestei sintaxe nu va avea niciun efect, deoarece mesajele de eroare sunt, de obicei, sortate în funcție de ID-ul obiectului. Numărul maxim de mesaje de eroare care sunt generate poate ajunge până la 1000. EXTENDED_LOGICAL_CHECKS Acest argument execută o verificare a consecvenței logice a vizualizărilor și indicilor, numai dacă nivelul de compatibilitate este 100. NO_INFOMSGS Elimină toate mesajele informative. TABLOCK Această sintaxă obține un blocaj exclusiv asupra bazei de date și va crește viteza DBCC CHECKDB pe o bază de date în momentele de mare încărcare. Dar scade disponibilitatea bazei de date pentru operațiuni concurente. ESTIMATEONLY Aceasta specifică sau estimează cantitatea de spațiu de care ar avea nevoie baza de date pentru a executa comanda CHECKDB. PHYSICAL_ONLY Aceasta impune o limitare pentru verificarea numai a structurii fizice a bazei de date. O scurtă verificare a bazei de date fizice este însoțită de detectarea paginilor rupte, a eșecurilor și a problemelor comune cu care se confruntă utilizatorii. DATA PURITY Această sintaxă verifică valorile coloanelor care fie sunt în afara intervalului, fie nu sunt valide. Verificările de integritate ale valorilor coloanelor sunt activate în mod implicit și nu au nevoie de sintaxa DATA_PURITY.
Elemente de reținut
- Indexurile dezactivate nu pot fi verificate de DBCC CHECKDB.
- Tipurile definite de utilizator și cele ordonate pe octeți trebuie să fie serializate dacă DBCC CHECKDB trebuie să fie executat. În orice alt caz, apare eroarea 2537.
- DBCC CHECKDB nu poate fi executat direct pe baza de date Resource, deoarece poate fi modificat doar în mod unic.
Mesaje de eroare generate de DBCC CHECKDB
Când comanda CHECKDB se termină de executat, se scrie un mesaj în jurnalul de erori SQL. În caz de succes, se generează un mesaj care indică succesul și timpul total în care s-a executat comanda. În caz de eșec, procesul se încheie din cauza apariției unor erori, indicate printr-un mesaj. Diferitele valori de stare care reprezintă mesajul de eroare sunt:
Raport de eroare
De fiecare dată când este detectată o corupție de către comanda CHECKDB, se creează un fișier de vidare numit SQLDUMPNNNNNN.txt în directorul de jurnal al serverului SQL. În cazul în care Feature Usage Data Collection and Error Reporting (Colectarea datelor de utilizare a caracteristicilor și raportarea erorilor) sunt activate în SQL, raportul de eroare este trimis către Microsoft în scopul îmbunătățirii.
Restaurarea bazei de date
În scenariul generării de erori în SQL server, se recomandă restaurarea bazei de date de la ultima copie de rezervă creată în loc de repararea bazei de date. în cazul în care nu există nicio copie de rezervă, puteți opta pentru opțiunile de reparare. Dar optarea pentru repararea cu REPAIR_ALLOW_DATA_LOSS poate duce la ștergerea unor date.
Rezolvare alternativă pentru recuperarea bazei de date
În principiu, comanda DBCC CHECKDB verifică consistențele bazei de date, inclusiv cele fizice sau logice. Această comandă verifică paginile, indexul și unele alte componente ale bazei de date SQL server, dar în unele puncte critice aceasta optează pentru a refuza recuperarea bazei de date SQL. În cazul absenței unei copii de rezervă a bazei de date MS SQL server, opțiunile de reparare optate pot șterge o cantitate apreciabilă de date. prin urmare, pentru a recupera baza de date fără a compromite integritatea datelor, puteți opta pentru soluția de recuperare a bazei de date Microsoft SQL. Acestea garantează recuperarea completă a bazei de date fără a șterge nicio cantitate de date.