Momentan sunteți offline, așteptați să vă reconectați la internet

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

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
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ţionline, 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ţiDepanarea Msg 832 în SQL Serverpentru 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 pecomanda 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.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 2015748 - Ultima examinare: 05/07/2014 09:01:00 - Revizie: 1.0

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

  • kbmt KB2015748 KbMtro
Feedback