Cum se depanează erorile de consistenta de date raportate de DBCC CHECKB

Traduceri articole Traduceri articole
ID articol: 2015748 - View products that this article applies to.
Măriți totul | Reduceți totul

SIMPTOME

Atunci când este executat DBCC CHECKDB (sau alte comenzi similare ca CHECKTABLE), un mesaj de genul următoarele este scris la SQL Server eroare:

2010-03-31 22:07:06.34 spid53 DBCC CHECKDB (mydb) executate de MYDOMAIN\theuser găsit erori 15 și reparate 0 erori. Timp scurs: 0 ore 0 minute 0 secunde. Interne de date instantaneu a împărțit punct LSN = 00000026:0000089 d: 0001 și prima LSN = 00000026:0000089 c: 0001. Acesta este un mesaj informativ numai. Nici un utilizator de acțiune este necesară.

Acest mesaj Arată cât de multe date consistenta erori au fost găsite și cât de multe au fost reparate (în cazul în care o opțiune de reparare a fost folosit cu comanda). Acest mesaj este scris în Jurnalul de evenimente aplicație Windows ca un mesaj de informare nivel cu EventID = 8957 (chiar dacă erorile sunt raportate acest mesaj este un mesaj de nivel de informații).

Informațiile din mesaj incepand cu "interne de date instantaneu..." apare numai dacă DBCC CHECKDB a fost executați online, care este dacă baza de date nu este în modul de SINGLE_USER. Acest lucru este pentru că pentru un online DBCC CHECKDB, o imagine internă de date este utilizat pentru a prezenta un set consistentă de date pentru a verifica.

Acest articol va discuta despre cum se depanează fiecare specifice de eroare raportate de DBCC CHECKDB, dar mai degrabă abordarea generală în cazul în care erorile sunt raportate. Orice trimitere la CHECKDB în acest articol se aplică și DBCC CHECKTABLE și CHECKFILEGROUP cu excepția cazului în mod explicit.

CAUZĂ

DBCC CHECKDB verifică consistența fizică ?i logică de pagini de date, rânduri, alocarea pagini, indicele de relații, systerm tabelul de integritate referen?ială ?i alte controale de structura. Dacă oricare dintre aceste verificări nu (în funcție de opțiunile pe care le-ați ales), erorile vor fi raportate ca parte a comenzii.

Cauza acestor probleme poate varia de la dosar sistem de corupție, care stau la baza probleme de sistem hardware, probleme de driver, pagini corupt în memorie, sau probleme cu motorul SQL Server. Citiți secțiunea rezolvare pentru mai multe informații despre cum să găsiți cauza erori care sunt raportate.

REZOLUȚIE

Soluția primul, cel mai bun dacă DBCC CHECKDB rapoarte de erori de coerență este de a restaura la o copie de rezervă bine cunoscute. Cu toate acestea, în cazul în care nu se pot restaura la o copie de rezervă, apoi CHECKDB oferă o caracteristică pentru a repara erorile. Dacă sistemul de nivel probleme cum ar fi sistemul de fișiere sau hardware pot fi cauza acestor probleme, este recomandat să corecta aceste prima înainte de restabilirea sau execută reparații.

Când executați DBCC CHECKDB o recomandare este prevăzută pentru a indica ce opțiune de minim de reparare ce se cere pentru a repara toate erorile. Aceste mesaje pot arata ceva de genul următoarele:

CHECKDB găsit 0 erori de alocare și 15 coerența erori în baza de date "mydb".
repair_allow_data_loss este nivelul minim de reparare a erorilor găsite de DBCC CHECKDB (mydb

La recomandarea de reparare este nivelul minim de reparații în încercarea de a rezolva toate erorile de CHECKDB. Acest lucru nu înseamnă că această opțiune de reparare de fapt va stabili toate erorile. În plus, nu toate erorile raportate pot solicita acest nivel de reparații pentru a rezolva eroarea. Acest lucru înseamnă că nu toate erorile raportate de CHECKDB când repair_allow_data_loss este recomandat va duce la pierderea de date. Reparații trebuie să ruleze pentru a determina dacă rezoluția de a o eroare va duce la pierderea datelor. O tehnica la spre ajutor narrow jos ce va fi la nivelul de reparare pentru fiecare tabel este de a utiliza DBCC CHECKTABLE pentru orice masă o eroare de raportare. Acest lucru va arăta ce nivelul minim de reparații pentru o anumită masă.

Pentru a găsi cauza de ce au survenit erori de consistenta de date, luați în considerare aceste metode:

  • Verifica?i jurnalul de evenimente System Windows pentru orice nivel de sistem, șofer sau disc legate de erori
  • Verifica integritatea fisierelor de sistem cu comanda chkdsk.
  • Rula orice furnizate de dumneavoastră fabricanții de hardware pentru calculator și/sau sistem de disc de diagnosticare.
  • Lucra cu furnizor de hardware sau producătorul dispozitivului pentru a asigura:
    • Dispozitive hardware și configurare confirmă I/O cerințele de SQL Server
    • Drivere de dispozitiv si alte componente suportate de software-ul de toate dispozitivele din calea de I/O sunt actualizate
  • Luați în considerare utilizarea o utilitate ca SQLIOSim pe aceeași unitate ca bazele de date care au raportat erori de consistență. SQLIOSim este un instrument independent de SQL Server Engine pentru a testa integritatea I/O pentru sistemul de disc. Rețineți că SQLIOSim este livrat cu SQL Server 2008 și nu nu reuiqre o descărcare separată.
  • Verificați pentru orice alte erori raportate de SQL Server, cum ar fi încălcări de acces. Aceste tipuri de probleme pot duce la corupție de date astfel încât să fie sigur de a rezolva aceste erori în primul rând.
  • Asigura bazele de date sunt folosind opțiunea PAGE_VERIFY CHECKSUM. În cazul în care sunt raportate erori de control, acestea sunt indicatori care coerența erori au avut loc după SQL Server a scris pagini disc astfel încât sistemul de disc trebuie verificate temeinic. Consultați Depanarea Msg 824 în SQL Server pentru mai multe informații despre erori de control.
  • Uita-te pentru erori Msg 832 de eroare. Acestea sunt indicatori care pagini mai fi deteriorate în timp ce acestea sunt în cache înainte de scris de disc. Consultați Depanarea Msg 832 în SQL Server pentru mai multe informații.
  • Încercați să restabiliți o copie de rezervă bază de date, știi care este "curat" (fara erori de CHECKDB) și tranzacție jurnal de backup-uri stii span timp când s-a întâlnit eroarea. În cazul în care puteți "relua" această problemă prin restabilirea un backup "curat" de date și tranzacții busteni atunci contactați asistența tehnică Microsoft de asistență.
  • Erori de puritate a datelor poate fi o problemă cu aplicare introducerea sau actualizarea datelor incorecte în tabelele SQL Server. Pentru mai multe informații despre depanarea date puritate erori, consultați următorul articol: depanare DBCC eroare 2570 în SQL server 2005

INFORMAȚII SUPLIMENTARE

Pentru detalii despre sintaxa de informații/opțiuni despre cum să execute comanda și DBCC CHECKDB, citit subiectul SQL Server Books Online pe comanda DBCC CHECKDB.

Dacă orice erori au fost găsite de CHECKDB, mesajele suplimentare cum ar fi următoarele sunt raportate în eroare în sensul eroare de raportare:

2010-03-31 22:07:06.34 spid53 folosind "dbghelp.dll" versiune '4.0.5'
2010-03-31 22:07:06.35 spid53 ** Dump fir - spid = 0, ce = 0x00000000855F5EB0
2010-03-31 22:07:06.35 spid53 *** stiva Dump de a fi trimis la C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\LOG\SQLDump0012.txt
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53 *
spid53 de 22:07:06.35 2010-03-31 * începe stiva DUMP:
spid53 de 22:07:06.35 2010-03-31 * 31/03/10 22:07:06 spid 53
2010-03-31 22:07:06.35 spid53 *
spid53 de 22:07:06.35 2010-03-31 * corupere de date DBCC
2010-03-31 22:07:06.35 spid53 *
spid53 de 22:07:06.35 2010-03-31 * 84 de tampon de intrare de octeți -
spid53 de 22:07:06.35 2010-03-31 * dbcc checkdb(mydb)
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53      * -------------------------------------------------------------------------------
spid53 de 22:07:06.35 2010-03-31 * scurt stivă Dump
2010-03-31 22:07:06.38 spid53 stivă semnătura pentru dump este 0x00000000000001E8
2010-03-31 22:07:07.42 spid53 extern dump procesul returna codul 0x20002001.
Au fost prezentate informa?ii de eroare Watson raportare erori.

Fi?iere utilizate pentru raportarea erorilor includ un fisier .txt SQLDump < Sfanta >. Acest fișier poate fi util pentru scopuri istorice, deoarece conține o listă de erori găsite la CHECKDB într-un format XML.

Pentru a afla când ultima dată DBCC CHECKDB a fost executați fără erori detectate pentru o bază de date (CHECKDB curat cu cunoscut ultima), verifica SQL Server eroare pentru un mesaj ca următoarea pentru baza de date sau sistem de date (acest mesaj este scris ca un mesaj de nivelului de informare în jurnalul evenimentelor Windows cerere cu EventID = 17573):

2010-04-01 10:13:59.80 spid7s CHECKDB pentru baza de date "maestru" terminat fără erori pe 22:11:11.417 2010-03-31 (ora locală). Acesta este un mesaj informativ nici o acțiune de utilizator este necesară

Notă Acesta este un articol „FAST PUBLISH” creat direct în cadrul organizației de asistență Microsoft. Informațiile conținute aici sunt furnizate ca atare, drept răspuns la problemele care apar. Din cauza rapidității cu care sunt puse la dispoziție, materialele pot avea erori tipografice și pot fi revizuite în orice moment, fără înștiințare. Consultați Termeni de utilizare pentru alte considerente.

Proprietă?i

ID articol: 2015748 - Ultima examinare: 7 mai 2014 - Revizie: 1.0
Se aplică la:
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • Microsoft SQL Server 2014 Developer
  • Microsoft SQL Server 2014 Enterprise
  • Microsoft SQL Server 2014 Express
  • Microsoft SQL Server 2014 Standard
  • Microsoft SQL Server 2014 Web
Cuvinte cheie: 
kbmt KB2015748 KbMtro
Traducere automată
IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată ?i poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate ?i articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cuno?tin?e în mai multe limbi. Articolele traduse automat ?i post-editate pot con?ine gre?eli de vocabular, sintaxă ?i/sau gramatică. Microsoft nu este responsabil de inexactită?ile, erorile sau daunele cauzate de traducerea gre?ită a con?inutului sau de utilizarea acestuia de către clien?i. Găsi?i mai multe informa?ii despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.
Face?i clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 2015748

Trimite?i feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com