O tabelă sau o vizualizare indexată pentru care doriți să efectuați verificări de integritate. Numele tabelelor și al vizualizărilor trebuie să respecte regulile pentru identificatorii clădirilor.
Indică faptul că nu ar trebui să se efectueze verificarea atentă a indexurilor care nu sunt grupate pentru tabelele utilizatorilor. Aceasta reduce timpul total de execuție. Argumentul NOINDEX nu afectează validarea tabelelor de sistem, deoarece verificările de integritate pentru indecșii tuturor tabelelor de sistem sunt întotdeauna efectuate.
Indicele indexului pentru care sunt efectuate verificări de integritate. Dacă este specificat argumentul index_id. instruciunea DBCC CHECKTABLE efectuează verificări de integritate numai pentru acest index, inclusiv indexul de heap sau cluster.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Indică faptul că instrucțiunea DBCC CHECKTABLE ar trebui să remedieze erorile detectate. Pentru a utiliza parametrul fix, baza de date trebuie să fie deschisă în modul pentru un singur utilizator.
Încercările de a remedia toate erorile detectate. Aceste remedii pot duce la pierderea parțială a datelor.
Sintaxa este reținută numai pentru scopuri de compatibilitate înapoi. Acțiunile de recuperare nu sunt efectuate.
Efectuează acțiuni pentru a restabili datele care pot fi efectuate fără risc de pierdere. Aceasta poate fi o restaurare rapidă (de exemplu, recuperarea rândurilor lipsă în indici nonclustered) sau mai multe operațiuni intensive (de exemplu, reconstruirea unui index).
REPAIR_REBUILD nu remediază erorile legate de datele FILESTREAM.
Utilizați argumentele REPAIR doar ca o ultimă soluție. Pentru a remedia erorile, vă recomandăm să restaurați dintr-o copie de rezervă. Operațiile de recuperare nu iau în considerare restricțiile care ar putea exista pentru tabele sau între tabele. Dacă tabela specificată participă la una sau mai multe constrângeri, se recomandă ca după operația de eliminare a erorilor să se execute instrucțiunea CHECKCONSTRAINTS DBCC. Dacă doriți să utilizați argumentele REPAIR, executați instrucțiunea DBCC CHECKTABLE fără opțiunea de recuperare pentru a determina nivelul de recuperare necesar. Când utilizați nivelul REPAIR_ALLOW_DATA_LOSS, este recomandat să efectuați o copie de rezervă a bazei de date înainte de a executa instrucțiunea DBCC CHECKTABLE cu acest parametru.
Afișează un număr nelimitat de erori. Toate mesajele de eroare sunt afișate în mod implicit. Specificarea sau omiterea acestui parametru nu are ca rezultat modificări.
Pentru mai multe informații, consultați "Efectuarea verificărilor logice de integritate integrată" din subsecțiunea "Note" din această secțiune.
Suprimă ieșirea tuturor mesajelor de informare.
Specifică instrucțiunile DBCC CHECKTABLE pentru a utiliza o blocare de tabelă partajată în loc să creeze un instantaneu de bază de date internă. Argumentul TABLOCK vă permite să accelerați instrucțiunea DBCC CHECKTABLE într-un mediu de încărcare ridicată, dar reduce coerența curentă a datelor pentru tabel în timpul executării acestei instrucțiuni.
Afișează dimensiunea estimată a bazei de date tempdb necesară pentru a executa instrucțiunea DBCC CHECKTABLE cu parametrii specificați.
Limitează scopul verificării integrității structurii fizice a paginilor, a anteturilor de înregistrare și a structurii fizice a copacilor echilibrați. Parametrul este conceput pentru a efectua o verificare ușoară a consistenței fizice a tabelului și poate identifica, de asemenea, pagini corupte și defecțiuni hardware generale care pot duce la pierderea datelor. Lansarea completă a declarației DBCC CHECKTABLE poate dura mult mai mult decât în versiunile anterioare. Acest lucru este cauzat de următoarele motive.
Verificările logice au devenit mai complexe.
A complicat o serie de structuri de bază care necesită verificare.
Au fost adăugate multe verificări noi pentru a susține funcții noi.
Cu alte cuvinte, specificarea argumentului PHYSICAL_ONLY poate reduce semnificativ timpul de execuție al instrucțiunii DBCC CHECKTABLE pentru tabele mari și, prin urmare, este recomandat pentru utilizarea frecventă în sistemele de producție. De asemenea, este recomandat să executați periodic declarația completă DBCC CHECKTABLE. Frecvența lansării depinde de factorii care sunt individuali pentru fiecare întreprindere și pentru fiecare mediu de producție. Argumentul PHYSICAL_ONLY include întotdeauna implicit argumentul NO_INFOMSGS și nu ar trebui să fie specificat împreună cu parametrii de corecție a erorii.
Specificând argumentul PHYSICAL_ONLY provoacă declarația DBCC CHECKTABLE pentru a sări peste toate verificările de date FILESTREAM.
Specificarea unei valori a argumentului determină instrucțiunea DBCC CHECKTABLE pentru a verifica tabelul pentru invalidare sau pentru a ieși din intervalul valid al valorii coloanelor. De exemplu, instrucțiunea DBCC CHECKTABLE detectează coloane cu valori de dată și oră care ies din intervalul valabil al valorii tipului datetime datetime. fie coloane de tip zecimal, fie coloane de tipuri aproximative de date numerice cu valori sau precizie inacceptabile.
Dacă este specificat argumentul PHYSICAL_ONLY, verificarea integrității nu este efectuată pe coloane.
Raport de eroare
Fișierul cu memorie conține rezultatele executării instrucțiunii DBCC CHECKTABLE și a informațiilor suplimentare privind diagnosticarea. Accesul la acest fișier este restricționat la liste de control acces la nivel de utilizator. Accesul este limitat la contul de servicii SQL Server și la membrii rolului sysadmin. În mod implicit, rolul sysadmin conține toți membrii grupului Windows BUILTIN \ Administrators și grupurile de administratori locali. În cazul unei erori în procesul de colectare a datelor, comanda DBCC nu eșuează.
Rezolvarea erorilor
Dacă instrucțiunea DBCC CHECKTABLE afișează erori, este recomandat să restabiliți baza de date dintr-o copie de siguranță, mai degrabă decât să executați parametrul REPAIR cu setările de corectare a erorilor. Dacă copia de rezervă nu este disponibilă, puteți corecta erorile generate de rularea parametrului REPAIR. La sfârșitul listei de erori, specificați care dintre parametrii REPAIR utilizați. Cu toate acestea, erorile de remediere cu parametrul REPAIR_ALLOW_DATA_LOSS pot necesita ștergerea unor pagini care pot conține date.
Corecția de eroare poate fi efectuată într-o tranzacție de utilizator, permițându-vă să răsturnați modificările efectuate. După revocarea remedierilor, baza de date va conține în continuare erori și va trebui să fie restaurată din copia de rezervă. După ce ați rezolvat toate erorile, creați o copie de rezervă a bazei de date.