Felsökning DBCC 2570 i SQL Server 2005 och senare

PROGRAMFEL #: 60178 (Innehållsunderhåll)

Introduktion

Den här artikeln beskrivs SQL-serverfel 2570, vad som orsakar felet och hur du löser problemet.

Mer Information

DATA_PURITY-kontroller

Ett nytt alternativ, DATA_PURITY, har lagts till kommandona DBCC CHECKDB och DBCC CHECKTABLE i SQL Server 2005. När du kör ett kommando DBCC CHECKDB eller DBCC CHECKTABLE med det här alternativet aktiveras utför kommandot valideringar "data renhet" på varje kolumnvärde på alla rader i tabellen eller tabellerna i databasen. Dessa nya kontroller utförs för att säkerställa att de värden som lagras i kolumnerna är giltiga (det vill säga att värdena inte är utanför intervallet för domänen associerad med datatypen för kolumnen). Arten av valideringen utförs beror på datatypen för kolumnen. Följande icke uttömmande förteckning ger några exempel:

Kolumnens datatyp

Typ av validering

Unicode-tecken

Datalängd bör vara en multipel av 2.

Datum/tid

Fältet måste vara mellan 1 Jan-1753 och 31 december 9999. Fältet måste vara tidigare än "11:59:59:999 PM".

Verkliga och flytande

Kontrollera om ogiltig flyttalsvärden som SNAN, QNAN, NINF, ND, PD, PINF.

Inte alla datatyper kontrolleras för kolumndata. Endast de kontrolleras om det är möjligt att ha ett lagrat värde som ligger utanför intervallet. Till exempel datatypen tinyint har intervallet 0 till 255 och lagras i en enda byte (som bara kan lagra värden från 0 till 255), så kontrollera värdet är inte nödvändigt.

Valideringskontroller för data renhet aktiveras inte automatiskt för alla databaser. Kontroller är aktiverade beroende på flera faktorer:

  • Dessa kontroller är aktiverade som standard för databaser som har skapats i SQL Server 2005 och senare versioner och kan inte inaktiveras, så att alternativet DATA_PURITY när du kör ett kommando DBCC CHECKDB eller DBCC CHECKTABLE är irrelevant.

  • Dessa kontroller är inte aktiverat som standard för databaser som har skapats i tidigare versioner av SQL Server, till exempel SQL Server 2000 och SQL Server 7.0 versioner uppgraderas till SQL Server 2005. Du måste ange alternativet DATA_PURITY i kommandot DBCC CHECKDB eller DBCC CHECKTABLE för dessa kontroller skall utföras. Detta kan resultera i två saker:

    • Kommandot DBCC avslutas och rapporterar att databasen är ren, inklusive alla data renhet kontroller. Detta registreras i databasen huvudet. Alla efterföljande DBCC CHECKDB eller DBCC CHECKTABLE kommandot körningar ser denna information och utför automatiskt data renhet kontroller, vilket skulle hända för databaser som har skapats i SQL Server 2005. Med andra ord utförs alltid data renhet kontroller när en databas är känt som "ren".

    • Kommandot DBCC avslutas, men rapporterar problem om inkonsekventa data. Om så är fallet kommer du har att rensa databasen och ta bort inkonsekvenser och sedan försöka köra kommandot DBCC igen. Du måste ange DATA_PURITY-alternativ för kommandot DBCC tills databasen har rapporterats vara ren.

  • Om alternativet PHYSICAL_ONLY anges när kommandot DBCC CHECKDB eller DBCC CHECKTABLE körs utförs data renhet kontroller inte.

SYMPTOM

Ogiltigt eller utanför giltigt intervall data kanske har lagrats i SQL Server-databas i tidigare versioner av följande skäl:

  • Ogiltiga data fanns i källan när du använder bulk insert metoder, till exempel bcp-verktyget.

  • Ogiltiga data har skickats via RPC-händelse anrop till SQL Server.

  • Andra potentiella orsaker fysiska skador vänster värdet i kolumnen i ett ogiltigt tillstånd.

Om du har ogiltiga data i en kolumn i en tabell, kan det uppstå problem beroende på vilken typ av operation som utförs mot ogiltiga data. Men är det också möjligt att inga problem visas och ogiltiga data inte att upptäckas förrän du köra ett kommando DBCC CHECKDB eller DBCC CHECKTABLE i SQL Server 2005 och senare versioner.

Del av de problem du kan upptäcka på grund av ogiltiga data inkluderar (men är inte begränsat till):

  • Åtkomstfel eller andra typer av undantag vid körning av frågor mot den aktuella kolumnen.

  • Felaktiga resultat som returneras av frågor som körs mot den aktuella kolumnen.

  • Fel eller problem när statistiken byggs mot de berörda kolumnerna.

  • Följande felmeddelanden:

    Msg 9100 nivå 23, läge 2, rad 1 möjliga index är skadat. Köra DBCC CHECKDB.

Problemrapport DATA_PURITY

När du kör en DBCC CHECKDB eller DBCC CHECKTABLE med alternativet DATA_PURITY aktiverat (eller data renheten kontroller körs automatiskt) och ogiltiga data finns i tabellerna som kontrolleras av kommandona DBCC, DBCC utdata innehåller ytterligare meddelanden som indikerar problem med data. Vissa exempel felmeddelanden som anger data renhet problem visas nedan:

DBCC resultat för "account_history".
Msg 2570, nivå 16, tillstånd 2, rad 1
Sida (1:1073) kortplats 33 i objekt-ID 1977058079 index-ID 0, partition-ID 129568478265344, alloc a-ID 129568478265344 (typ "data i rad"). Kolumnen "account_name_japan" värdet ligger utanför intervallet för datatypen "nvarchar". Uppdatera kolumnen till ett giltigt värde.

Msg 2570, nivå 16, tillstånd 2, rad 1
Sida (1:1156) kortplats 120 i objekt-ID 1977058079 index-ID 0, partition-ID 129568478265344, alloc a-ID 129568478265344 (typ "data i rad"). Kolumnen "account_name_japan" värdet ligger utanför intervallet för datatypen "nvarchar". Uppdatera kolumnen till ett giltigt värde.
Det finns 153137 rader i 1080 sidor för objektet "account_history".
CHECKDB finns 0 allokering fel och 338 konsekvens fel i tabellen "account_history" (objekt-ID 1977058079).
CHECKDB finns 0 allokering fel och 338 konsekvens fel i databasen 'BadUnicodeData'.
DBCC-körningen har slutförts. Om DBCC ut felmeddelanden, kontaktar du din systemadministratör.

DBCC resultat för tabell '1'.
Msg 2570, nivå 16, tillstånd 3, rad 1
Sidan (1:154), kortplats 0 i objekt-ID 2073058421, index-ID 0, partition-ID 72057594038321152, alloc a-ID 72057594042318848 (typ "data i rad"). Kolumnen "col2" värdet ligger utanför intervallet för datatypen "verkliga". Uppdatera kolumnen till ett giltigt värde.
Det finns 4 rader i 2 sidor för objektet "tabell1".
CHECKDB hittade 0 fel fördelning och 1 konsekvens fel i tabell 'tabell 1' (objekt-ID 2073058421).
CHECKDB finns 0 allokering fel och 1 konsekvens fel i databasen 'realdata'. DBCC-körningen har slutförts. Om DBCC ut felmeddelanden, kontaktar du din systemadministratör.

DBCC resultat för "tabell2".
Msg 2570, nivå 16, tillstånd 3, rad 1
Sidan (1:155), kortplats 0 i objekt-ID 2105058535, index-ID 0, partition-ID 72057594038452224, alloc a-ID 72057594042449920 (typ "data i rad"). Kolumnen "col2" värdet ligger utanför intervallet för datatypen "decimal". Uppdatera kolumnen till ett giltigt värde.
Det finns 4 rader i 1 sidor för objektet "tabell2".
CHECKDB hittade 0 fel fördelning och 1 konsekvens fel i tabell "tabell2" (objekt-ID 2105058535).
CHECKDB finns 0 allokering fel och 1 konsekvens fel i databasen 'realdata'. DBCC-körningen har slutförts. Om DBCC ut felmeddelanden, kontaktar du din systemadministratör.

DBCC resultat för tabell '3'.
Msg 2570, nivå 16, tillstånd 3, rad 1
Sidan (1:157), kortplats 0 i objekt-ID 2121058592, index-ID 0, partition-ID 72057594038517760, alloc a-ID 72057594042515456 (typ "data i rad"). Kolumnen "col2" värdet ligger utanför intervallet för datatypen "datetime". Uppdatera kolumnen till ett giltigt värde.
Det finns 3 rader i 1 sidor för objektet "tabell 3".
CHECKDB hittade 0 fel fördelning och 1 konsekvens fel i tabell 'Tabell3' (objekt-ID 2121058592).
CHECKDB finns 0 allokering fel och 1 konsekvens fel i databasen 'realdata'. DBCC-körningen har slutförts. Om DBCC ut felmeddelanden, kontaktar du din systemadministratör.

Ett 2570-fel genereras för varje rad som innehåller ett ogiltigt värde.

Fastställande av renhet dataproblem

2570 fel kan inte repareras med något av alternativen för reparationsstatus DBCC. Detta beror på att det är omöjligt för DBCC att avgöra vilket värde bör användas för att ersätta ogiltiga kolumnvärdet. Alltså måste värdet i kolumnen uppdateras manuellt.

Du måste leta upp den rad som har problemet för att utföra en manuell uppdatering. Det finns två sätt att göra detta.

  • Köra en fråga mot en tabell som innehåller ogiltiga värden om du vill söka efter rader som innehåller ogiltiga värden.

  • Använd informationen från 2570 fel för att identifiera de rader som har ett ogiltigt värde.

Vi diskuterar båda dessa metoder i detalj nedan, hitta rader som innehåller ogiltiga data med hjälp av exempel.

När du har hittat rätt rad måste ett beslut göras på det nya värdet som ska användas för att ersätta befintliga ogiltiga data. Detta beslut måste göras mycket noggrant baserat på intervallet av värden som arbetar för programmet och vad passar logiska för den raden med data. Alternativen du har är:

  • Om du vet vilket värde bör man ange specifika värdet.

  • Ange ett standardvärde som godtagbara.

  • Ange värdet i kolumnen som NULL.

  • Ange värdet i kolumnen högsta eller lägsta värde för datatypen för kolumnen.

  • Om du tycker att den specifika raden inte är någon användning utan ett giltigt värde för kolumnen kan du ta bort raden helt.

Söka efter rader med ogiltiga värden med hjälp av T-SQL-frågor

Typ av fråga som du behöver köra om du vill hitta rader som innehåller ogiltiga värden beror på datatypen för kolumnen som rapporterade ett problem. Om du tittar på felmeddelandet 2570 ser du två viktiga delar av information som hjälper dig med detta. I följande exempel är värdet i kolumnen "account_name_japan" utanför intervallet för datatypen "nvarchar." Vi kan enkelt identifiera den kolumn som har problemet som datatypen för kolumnen som är inblandade. Alltså när du känner till datatypen och kolumnen berörda formulera frågan om du vill söka efter rader som innehåller ogiltiga värden för kolumnen, välja kolumner som krävs för att identifiera raden (som predikat i en WHERE-sats) för någon ytterligare uppdatera eller ta bort.

Unicode-datatyp:

SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan FROM account_history
WHERE DATALENGTH(account_name_japan) % 2 != 0


Float, datatyp:

-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB output
SELECT col1, col2 FROM table1
WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)


Real, datatyp:

-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB output
SELECT 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

Decimal och numerisk datatyp:

SELECT col1 FROM table2WHERE col2 > 9999999999.99999 
OR col1 < -9999999999.99999

Kom ihåg att du måste justera värden baserat på precision och skala som du har definierat decimal eller numerisk kolumn. I exemplet ovan har kolumnen definieras som col2 decimal(15,5).

Datum tid typ:
Du måste köra två olika frågor för att identifiera de rader som innehåller ogiltiga värden för kolumnen för datum-tid.

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

Söka efter rader med ogiltigt värde med den fysiska placeringen:

Du kan använda den här metoden om du inte vill söka efter rader av intresse med T-SQL-metoden som beskrivs ovan. Den fysiska platsen för den rad som innehåller det ogiltiga värdet i felmeddelandet 2570 skrivs ut. Titta till exempel på följande meddelande:

Sidan (1:157), kortplats 0 i objekt-ID 2121058592, index-ID 0, partition-ID 72057594038517760, alloc a-ID 72057594042515456 (typ "data i rad"). Kolumnen "col2" värdet ligger utanför intervallet för datatypen "datetime". Uppdatera kolumnen till ett giltigt värde.

I det här meddelandet ser du informationen: sida (1:157) kortplats 0. Detta är den information du behöver att identifiera raden. FileId är 1, PageInFile är 157 och FackID är 0. När du har den här informationen måste du köra kommandot på följande sätt:

DBCC TRACEON ( 3604 )DBCC PAGE ( realdata , 1 , 157 , 3 )

Det här kommandot skrivs ut hela innehållet på en sida. Parametrar för kommandot DBCC PAGE är:

  • databasens namn

  • FileId

  • PageInFile

  • möjlighet att skriva ut

När du kör kommandot ser utdata som innehåller information som liknar följande 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 = 1 Slot 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

I det här resultatet kan du tydligt se kolumnvärden för raden som intresserar dig. I det här fallet måste du raden lagras i 0-facket på sidan. I felmeddelandet vet du att col2 är med problemet. Så du ta värdet i Kol1 för 0-kortplatsen och användas som predikat i WHERE-satsen i update-sats eller delete-uttryck.

Varning Vi rekommenderar att du använder den första metoden (dvs använda T-SQL-frågor att hitta informationen som krävs). Använd kommandot DBCC PAGE endast som en sista utväg. Ta största möjliga försiktighet när du använder det här kommandot i en produktionsmiljö. Det är lämpligt att återställa produktionsdatabasen på en testserver och sedan få all nödvändig information med DBCC PAGE och gör uppdateringar på produktionsservern. Som alltid se till att spara en säkerhetskopia klar om något går fel och du vill återställa till en tidigare kopia av databasen.

Referenser

Mer information om instruktionen DBCC CHECKDB finns i avsnittet "DBCC CHECKDB (Transact-SQL)" på följande Microsoft Developer Network (MSDN)-webbplats:

http://msdn2.microsoft.com/en-us/library/ms176064.aspxMer information om kända problem i SQL Server 2000 klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:

900335 KORRIGERA: återställning med automatisk databas i SQL Server 2000 kan misslyckas om ett index innehåller datatypen FLOAT eller en REAL, datatyp och den här datatypen innehåller ett NaN-värde

Mer information om RPC-händelser finns i avsnittet "Anropa en lagrad procedur (OLE DB)" på följande MSDN-webbplats:

http://msdn2.microsoft.com/en-us/library/aa198358(SQL.80).aspxMer information om olika datatyper finns i avsnittet "Anropa en lagrad procedur (OLE DB)" på följande MSDN-webbplats:

http://msdn2.microsoft.com/en-us/library/ms187752.aspxMer information om flytande punkt värde konventioner finns på följande Intel-webbplats:

http://www.intel.com/design/pentiumii/manuals/243191.htmMicrosoft tillhandahåller kontaktinformation för tredje part för att hjälpa dig att hitta teknisk support. Denna information kan ändras utan föregående meddelande. Microsoft kan inte garantera riktigheten av denna information från tredje part.

Behöver du mer hjälp?

Utöka dina kunskaper
Utforska utbildning
Få nya funktioner först
Anslut till Microsoft Insiders

Hade du nytta av den här informationen?

Tack för din feedback!

Tack för din feedback! Det låter som att det kan vara bra att koppla dig till en av våra Office-supportrepresentanter.

×