Depanarea DBCC eroare 2570 în SQL Server 2005 şi în versiunile ulterioare

IMPORTANT: Acest articol a fost tradus de software-ul de traducere automată Microsoft, si nu de un traducător. Microsoft vă oferă atât articole traduse de persoane, cât şi articole traduse automat, astfel incat aveti access la toate articolele din Baza noastră de informatii în limba dvs. materna. Totuşi, un articol tradus automat nu este întotdeauna perfect. Acesta poate conţine greşeli de vocabular, sintaxă sau gramatică, la fel cum un vorbitor străin poate face greşeli vorbind limba dvs. materna. Compania Microsoft nu este responsabilă pentru nici o inexactitate, eroare sau daună cauzată de traducerea necorespunzătoare a conţinutului sau de utilizarea traducerii necorespunzătoare de către clienţii nostri. De asemenea, Microsoft actualizează frecvent software-ul de traducere automată.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol:923247
INTRODUCERE
Acest articol descrie SQL Server error 2570, ceea ce cauzează eroare, şi cum să rezolve problema.
INFORMAŢII SUPLIMENTARE

Controalelor DATA_PURITY

În SQL Server 2005, a fost adăugată o nouă opţiune, DATA_PURITY, comenzile DBCC CHECKDB şi DBCC CHECKTABLE. Când executaţi o DBCC CHECKDB sau comanda DBCC CHECKTABLE cu această opţiune activată, comanda va efectua "date puritate" validare pe fiecare valoare coloană în toate rândurile din tabelul sau tabelele din baza acoperire de date. Aceste noi controale sunt efectuate pentru a asigura valorile stocate în coloanele sunt valabile (care este, că valorile nu sunt afară-de-gama pentru domeniu asociat cu tipul acoperire de date din acea coloană). The natura de validare efectuate depinde de tipul acoperire de date al coloanei. The urmează Listă tabel non-exhaustivă oferă câteva exemple:
Tip acoperire de date coloanăTipul de validare a datelor efectuate
Caracterul UnicodeLungimea trebuie să fie un multiplu de 2.
DatetimeCâmpul zile ar trebui să fie între Jan 1 1753 şi 31 decembrie 9999. Câmpul marcă de timp trebuie să fie mai devreme decât "11:59:59:999 PM".
Real şi FloatA verifica pentru existenţa de invalid plutitoare valori ca SNAN, QNAN, NINF, ND, PD, PINF.
Nu toate tipurile acoperire de date sunt verificate pentru valabilitatea coloana date. Numai în cazul în care este posibil să aibă o valoare stocate din gama sunt verificate. De exemplu, tipul acoperire de date tinyint are o gamă valabil de la 0 la 255 şi sunt stocate într-un singur octet (care pot stoca numai valori de la 0 la 255), deci verificarea valorii nu este necesar.

Date puritate validare controalelor nu sunt activate automat pentru toate bazele acoperire de date. Controalele sunt activate în funcţie de pe mai multe factori:
  • Pentru baze acoperire de date create în SQL Server 2005 şi în versiunile ulterioare, aceste controale sunt activate implicit şi nu poate fi dezactivată, astfel încât utilizarea opţiunea de DATA_PURITY atunci când execută o comanda DBCC CHECKDB sau DBCC CHECKTABLE este irelevant.
  • Pentru bazele acoperire de date care au fost create în versiuni anterioare ale SQL Server, cum ar fi SQL Server 2000, SQL Server 7.0 şi versiuni upgraded la spre SQL Server 2005, aceste controale nu sunt activate implicit. Pentru ca aceste controale să fie efectuate, trebuie să specificaţi opţiunea DATA_PURITY în DBCC CHECKDB sau Comanda DBCC CHECKTABLE. Acest lucru poate duce la două lucruri:
    • Comanda DBCC finisaje şi raportează că baza acoperire de date este curat, inclusiv toate datele puritate controale. Acest fapt se înregistrează în date antet. Toate comanda DBCC CHECKDB sau DBCC CHECKTABLE ulterioare execuţiile observa această informaţie şi va efectua automat datele puritate verifică, s-ar întâmpla pentru baze acoperire de date create pe SQL Server 2005. În alte cuvinte, odată ce o bază acoperire de date este cunoscută ca fiind "curat", controalele de puritate date sunt întotdeauna realizată.
    • Comanda DBCC finisaje dar rapoartele de probleme despre date incoerenţă. Dacă este cazul, va trebui să curăţaţi baza acoperire de date Eliminaţi inconsecvenţele şi apoi încearcă să execute comanda DBCC din nou. Va trebui să specificaţi opţiunea DATA_PURITY pentru comanda DBCC până la baza acoperire de date este raportat a fi curat.
  • Dacă se specifică opţiunea de PHYSICAL_ONLY atunci când DBCC Comandă CHECKDB sau DBCC CHECKTABLE este executat, date puritate verificările nu efectuate.

SIMPTOME

Date nevalide sau afară-de-gama poate au fost stocate în SQL Server bază acoperire de date din versiunile din următoarele motive:
  • Date incorecte a fost prezentă în sursa în marcă de timp ce folosind vrac Inserare metode, cum ar fi utilitarul bcp.
  • Date incorecte a fost trecut prin RPC eveniment apelurile efectuate la SQL Server.
  • Potenţialul de alte cauze de corupţie datelor fizice stânga valoarea din coloana într-o stare nevalidă.
Dacă aveţi date incorecte într-o coloană a unui tabel, care pot apărea probleme în funcţie de tipul de operațiune se efectuează împotriva date nevalide. Cu toate acestea, este de asemenea posibil ca va apărea nici o problemă, şi date incorecte nu vor fi descoperite până când executaţi o comanda DBCC CHECKDB sau DBCC CHECKTABLE pe SQL Server 2005 şi în versiunile ulterioare.

Unele dintre simptomele vă poate observa datorită prezenţei acoperire de date incorecte includ (dar nu sunt limitate la):
  • Încălcări de acces sau alte tipuri de excepţii în marcă de timp ce executarea interogărilor împotriva coloana afectate.
  • Rezultate incorecte returnate de interogări executate împotriva coloana afectate.
  • Erori sau probleme atunci când statisticile sunt construite împotriva coloanele afectate.
  • Mesajele de eroare cum ar fi următoarele:
    Msg 9100, Nivel 23, stat 2, linia 1 posibil index corupţia detectat. DBCC a alerga CHECKDB.

Raport de problemă DATA_PURITY

Când executaţi o comanda DBCC CHECKDB sau DBCC CHECKTABLE cu opţiunea DATA_PURITY activat (sau date puritate controalele sunt rulate automat), şi există date incorecte în tabelele verificate de DBCC comenzi, producția DBCC include mesaje suplimentare care indică probleme cu datele. Unele mesaje de eroare probă care indică date puritate probleme sunt prezentate mai jos:
DBCC rezultatele pentru "account_history".
Msg 2570, nivel 16, stat 2, linia 1
Pagina (1:1073), slot 33 în obiect ID 1977058079, ID-ul index 0, partiţia ID 129568478265344, unitate de permise ID 129568478265344 (tip "în rândul date"). Coloana "account_name_japan" valoarea este din gama pentru tipul acoperire de date "nvarchar". Actualizare coloană la o valoare entitate juridică.
Msg 2570, nivel 16, stat 2, linia 1
Pagina (1:1156), slot 120 în obiect ID 1977058079, ID-ul index 0, partition ID 129568478265344, permise unitate ID 129568478265344 (tip "Datele în rând"). Coloana "account_name_japan" valoarea este în afara intervalului pentru tipul acoperire de date "nvarchar". Actualizare coloană la o valoare entitate juridică.
Acolo sunt 153137 rânduri în 1080 pagini pentru obiect "account_history".
CHECKDB găsit 0 alocarea erori şi 338 coerența erori în tabelul "account_history" (ID 1977058079 obiect).
CHECKDB găsit erori de alocare 0 şi 338 coerența erori în baza acoperire de date 'BadUnicodeData'.
DBCC executarea completat. If DBCC printed error messages, contact your system administrator.
DBCC rezultatele pentru 'table1'.
Msg 2570, nivel 16, Statul 3, linia Către 1
Pagina (1:154), slot 0 în obiect ID 2073058421, ID-ul index 0, partition ID 72057594038321152, permise unitate ID 72057594042318848 (tip "În rândul date"). Coloana "col2" valoarea este din gama pentru tipul acoperire de date "reale". Actualizare coloană la o valoare entitate juridică.
Există 4 rânduri în 2 pagini pentru obiect "table1".
CHECKDB găsit erori de alocare 0 şi 1 coerența erori în tabelul 'table1' (ID 2073058421 obiect).
CHECKDB găsit erori de alocare 0 şi coerenţa 1 erori în baza acoperire de date 'realdata'. DBCC executarea completat. Dacă DBCC printed error mesaj, contactaţi administrator de sistem.
DBCC rezultatele pentru 'table2'.
Msg 2570, nivel 16, Statul 3, linia Către 1
Pagina (1:155), slot 0 în obiect ID 2105058535, ID-ul index 0, partition ID 72057594038452224, permise unitate ID 72057594042449920 (tip "În rândul date"). Coloana "col2" valoarea este din gama pentru tipul acoperire de date "zecimal". Actualizare coloană la o valoare entitate juridică.
Există 4 rânduri în paginile 1 pentru obiect "table2".
CHECKDB găsit erori de alocare 0 şi 1 coerența erori în tabelul 'table2' (ID 2105058535 obiect).
CHECKDB găsit erori de alocare 0 şi coerenţa 1 erori în baza acoperire de date 'realdata'. DBCC executarea completat. Dacă DBCC printed error mesaj, contactaţi administrator de sistem.
DBCC rezultatele pentru 'Tabel3'.
Msg 2570, nivel 16, Statul 3, linia Către 1
Pagina (1:157), slot 0 în obiect ID 2121058592, ID-ul index 0, partition ID 72057594038517760, permise unitate ID 72057594042515456 (tip "În rândul date"). Coloana "col2" valoarea este din gama pentru tipul acoperire de date "datetime". Actualizare coloană la o valoare entitate juridică.
Există 3 rânduri în paginile 1 pentru obiect „Tabel3".
CHECKDB găsit erori de alocare 0 şi 1 coerența erori în tabelul 'Tabel3' (ID 2121058592 obiect).
CHECKDB găsit erori de alocare 0 şi coerenţa 1 erori în baza acoperire de date 'realdata'. DBCC executarea completat. Dacă DBCC printed error mesaj, contactaţi administrator de sistem.
Pentru fiecare rând care conţine o valoare incorectă coloana, o eroare de 2570 este generat.

Stabilirea problemei de puritate date

Erorile 2570 nu pot fi reparate utilizând oricare din repararea DBCC Opţiuni. Acest lucru este pentru că este imposibil pentru DBCC pentru a determina ce valoare ar trebui să folosit la replace valoarea din coloana nevalid. Astfel, trebuie să fie valoarea din coloana actualizat manual.

Pentru a efectua o actualizare manuală, aveţi pentru a găsi rândul care are problema. Există două moduri de a realiza acest lucru.
  • Executaţi o interogare împotriva tabelul care conţine valori incorecte pentru a găsi rândurile care conţin valorile nevalid.
  • Utilizaţi informaţiile de eroare 2570 pentru a identifica rândurile care au o valoare nevalidă.
Vom discuta ambele aceste metode în detaliu mai jos, folosind exemple pentru a găsi rândurile care au date nevalide.

Odată ce aţi găsit rând corectă, o decizie trebuie să se facă pe valoarea nouă, care va fi utilizat pentru înlocui datele incorecte existente. Prezenta decizie trebuie să se facă cu grijă bazate pe zona de valori care locul de muncă de aplicare, precum şi ceea ce are sens logic pentru că special rând acoperire de date. Opţiunile aveţi sunt:
  • Dacă ştiţi ce valoare ar trebui să fie, setaţi-l la care valoare specifice.
  • Setaţi-l la o valoare acceptabilă implicit.
  • Setaţi valoarea din coloana la NULL.
  • Setaţi valoarea din coloana cu valoarea maximă sau minimă pentru că tipul acoperire de date al coloanei.
  • Dacă vă simţiţi că rândul specifice nu este orice utilizare fără o valoare validă pentru coloană, aveţi posibilitatea să ştergeţi acel rând cu totul.

Găsirea rânduri cu valori incorecte folosind T-SQL Queries

Tipul de interogare care aveţi nevoie pentru a executa pentru a găsi rândurile care au valori incorecte depinde de tipul acoperire de date al coloanei a raportat o problemă. Dacă te uiţi la mesajul de eroare 2570, veţi observa două piese importante informații care vă va ajuta cu acest lucru. În exemplul următor, coloana valoarea "account_name_japan" este din gama pentru tipul acoperire de date "nvarchar." Putem identifica cu uşurinţă coloana care are problema, precum şi tipul acoperire de date al coloana implicate. Astfel, o dată ştii date tip şi coloana implicate, vă poate formula interogarea pentru a găsi rândurile care conţin valori incorecte pentru care coloană, selectaţi coloanele necesare pentru identificarea acel rând (ca predicate în o clauză WHERE) pentru orice continuare actualizare sau şterge.

Tip acoperire de date Unicode:
SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan FROM account_historyWHERE DATALENGTH(account_name_japan) % 2 != 0

Tip acoperire de date float:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB outputSELECT col1, col2 FROM table1WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)

Tip acoperire de date reale:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB outputSELECT col1, col2 FROM testReal WHERE col2<>0.0 AND (col2 < CONVERT(real,1.18E-38) OR col2 > CONVERT(real,3.40E+38)) AND (col2 < CONVERT(real,-3.40E+38) OR col2 > CONVERT(real,-1.18E-38)) ORDER BY col1; -- checks for real out of range
Zecimal şi numerice tip de date:
SELECT col1 FROM table2WHERE col2 > 9999999999.99999 OR col1 < -9999999999.99999
Reţineţi că aveţi nevoie pentru a ajusta valori bazate pe precizia și scară cu care le-aţi definit coloana zecimal sau numerică. În exemplul de mai sus, coloana a fost definit ca col2 decimal(15,5).

Data marcă de timp date tip:
Aveţi nevoie pentru a executa două interogări diferite pentru a identifica rândurile care conţin valori incorecte pentru data marcă de timp coloană.
SELECT col1 FROM table3WHERE col2 < '1/1/1753 12:00:00 AM' OR col2 > '12/31/9999 11:59:59 PM'SELECT col1 FROM table3 WHERE((DATEPART(ms,col2)+ (1000*DATEPART(s,col2)) + (1000*60*DATEPART(mi,col2)) + (1000*60*60*DATEPART(hh,col2)))/(1000*0.00333)) > 25919999

Găsirea rânduri cu valoare nevalidă utilizând locaţia fizică:

Utilizaţi această metodă dacă sunteţi în imposibilitatea de a găsi rândurile interes, utilizând metoda de T-SQL discutate mai sus. În mesajul de eroare 2570, locaţia fizică a rândul care conţine valoarea incorectă este imprimat. Pentru exemplu, uita-te la următorul mesaj:
Pagina (1:157), slot 0 în obiect ID 2121058592, ID-ul index 0, partiţia ID 72057594038517760, unitate de permise ID 72057594042515456 (tip "în rândul date"). Valoare coloană "col2" din gama pentru tipul acoperire de date "datetime". Actualizare coloana juridice valoarea.
În acest mesaj, veţi observa informațiile: pagină (1:157), slot 0. Acest lucru este informaţii aveţi nevoie pentru a identifica pe rând. FileId este 1, PageInFile este 157, şi SlotId este 0. Odată ce aveţi aceste informaţii, aveţi va trebui să execute comanda, după cum urmează:
DBCC TRACEON ( 3604 )DBCC PAGE ( realdata , 1 , 157 , 3 )
Această comandă va imprima întregul conţinut al unei pagini. Parametri Comanda DBCC pagină sunt:
  • nume de sign-in bazei acoperire de date
  • FileId
  • PageInFile
  • opţiune de imprimare
După ce executaţi această comandă, veţi observa că de ieşire conţine informaţii similare cu următorul format:
Slot 0 Offset 0x60 Length 19 Record Type = PRIMARY_RECORD Record		  Attributes = NULL_BITMAP Memory Dump @0x44D1C060 00000000: 10001000 01000000		  ffffffff ffffffff †................ 00000010:		  0200fc†††††††††††††††††††††††††††††††... Slot 0 Column 0 Offset 0x4 Length 4 col1 = 1Slot 0 Column 1 Offset 0x8 Length 8 col2 = Dec 31 1899 19:04PM Slot 1 Offset 0x73 Length 19 Record Type = PRIMARY_RECORD Record		  Attributes = NULL_BITMAP Memory Dump @0x44D1C073 00000000: 10001000 02000000		  0ba96301 f8970000 †..........c..... 00000010:		  0200fc†††††††††††††††††††††††††††††††... Slot 1 Column 0 Offset 0x4 Length 4		  col1 = 2 Slot 1 Column 1 Offset 0x8 Length 8 col2 = Jul 8 2006 9:34PM Slot 2		  Offset 0x86 Length 19 Record Type = PRIMARY_RECORD Record Attributes =		  NULL_BITMAP Memory Dump @0x44D1C086 00000000: 10001000 03000000 0ba96301		  f8970000 †..........c..... 00000010: 0200fc†††††††††††††††††††††††††††††††...		  Slot 2 Column 0 Offset 0x4 Length 4 col1 = 3 Slot 2 Column 1 Offset 0x8 Length		  8 col2 = Jul 8 2006 9:34PM 
În această producție puteţi vedea în mod clar valorile coloanelor pentru rândul de interes pentru tine. În acest caz, vă nevoie de rând stocate în slot 0 a paginii. Din mesajul de eroare, ştii col2 că este una cu problema. Deci puteţi lua valoarea col1 pentru Slot 0 şi folos it as Predicatul în clauza WHERE de declaraţie de update sau ştergeţi instrucţiunea.

Avertizare Vă recomandăm să utilizaţi metoda primul (care este, utilizaţi T-SQL interogări pentru a găsi informaţiile necesare). Utilizarea paginii DBCC comanda doar ca o ultimă instanţă. Ia cea mai mare grijă, în marcă de timp ce utilizaţi această comandă într-o producţie mediu. Se recomandă să Restabilire bază acoperire de date de producţie pe un test server, apoi obţine toate informaţiile necesare folosind pagina DBCC, şi apoi face actualizări de pe serverul de producție. Ca întotdeauna, vă rugăm să păstraţi o copiere de rezervă gata în cazul în care ceva nu merge bine şi aveţi nevoie pentru a reveni la o copie anterioară a bază acoperire de date.
REFERINŢE
Pentru mai multe informaţii despre instrucţiunea DBCC CHECKDB, vedea subiect "DBCC CHECKDB (Transact-SQL)" pe următoarele Microsoft Developer site web Network (MSDN): Pentru mai multe informaţii despre cunoscute probleme în SQL Server 2000, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
900335FIX: Operația de recuperare automată acoperire de date SQL Server 2000 poate nu reuşesc în cazul în care un index conţine un tip acoperire de date FLOAT sau un tip acoperire de date reale, şi acest tip acoperire de date conţine o valoare NaN
Pentru mai multe informaţii despre evenimente RPC, vedea "Calling o procedură stocată (OLE DB)" subiect de pe următorul site MSDN Web:Pentru mai multe informaţii despre tipurile diferite acoperire de date, consultaţi "Calling o procedură stocată (OLE DB)" subiect de pe următorul site MSDN Web:Pentru mai multe informaţii despre plutitoare punctul valoarea convențiile, următorul site Intel Web: Microsoft oferă informaţii de contact terţe pentru a vă ajuta să găsiţi suport tehnic. Aceste informaţii de contact pot fi modificate fără preaviz. Microsoft nu garantează precizia acestor informaţii de contact terţe.

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 923247 - Ultima examinare: 03/22/2012 20:50:00 - Revizie: 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Express Edition with Advanced Services, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems, Microsoft SQL Server 2005 Enterprise X64 Edition, Microsoft SQL Server 2005 Standard Edition for Itanium Based Systems, Microsoft SQL Server 2005 Standard X64 Edition, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Express with Advanced Services, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2008 Standard Edition for Small Business

  • kbtshoot kbexpertiseadvanced kbsql2005engine kbinfo kbmt KB923247 KbMtro
Feedback