MSSQLSERVER_605

Gäller för:SQL Server

Detaljer

Explanation

Detta fel indikerar vanligtvis sid- eller allokeringskorruption i den angivna databasen. SQL Server upptäcker korruption när man läser sidor som tillhör en tabell, antingen genom att följa sidlänkarna eller genom att använda Index Allocation Map (IAM). Alla sidor som tilldelas en tabell måste tillhöra en av de allokeringsenheter som är kopplade till tabellen. Om allokeringsenhets-ID:t i sidhuvudet inte matchar ett allokeringsenhets-ID kopplat till tabellen, höjs detta undantag. Det första allokeringsenhets-ID som anges i felmeddelandet är det ID som finns i sidhuvudet, och det andra värdet på allokeringsenheten är det ID som är kopplat till tabellen.

Datakorruptionsfel

En allvarlighetsgrad på 21 indikerar potentiell datakorruption. Möjliga orsaker är en skadad sidkedja, en korrupt IAM eller en ogiltig post i sys.objects-katalogvyn för det objektet. Dessa fel orsakas ofta av fel på hårdvaru- eller diskdrivrutiner.

Tillfälliga fel

En svårighetsgrad på 12 indikerar ett potentiellt övergående fel; det vill säga, den sker i cachen och indikerar inte skada på data på disken. Övergående 605-fel kan orsakas av följande villkor:

• Operativsystemet meddelar SQL Server i förtid att en I/O-operation har slutförts; felmeddelandet visas även om ingen faktisk datakorruption förekommer.

• Köra en fråga med optimeringsledtråden NOLOCK eller sätta transaktionsisoleringsnivån till LÄS OCOMMITTED. När en fråga som använder NOLOCK eller READ UNCOMMITTED transaktionsisoleringsnivå försöker läsa data som flyttas eller ändras av en annan användare, uppstår ett 605-fel. För att verifiera att det är ett tillfälligt 605-fel, kör om frågan senare.

Generellt, om felet uppstår under dataåtkomst men efterföljande DBCC CHECKDB-operationer slutförs utan fel, var 605-felet troligen övergående.

Användaråtgärd

Om 605-felet inte är övergående är problemet allvarligt och måste rättas till genom att utföra följande uppgifter:

1. Identifiera tabellerna som är associerade med de allokeringsenheter som anges i meddelandet genom att köra följande fråga. Ersätt allocation_unit_id med de allokeringsenheter som anges i felmeddelandet.

   USE [database_name];  
   
   GO  
   
   SELECT au.allocation_unit_id, OBJECT_NAME(p.object_id) AS table_name, fg.name AS filegroup_name,  
   
   au.type_desc AS allocation_type, au.data_pages, partition_number  
   
   FROM sys.allocation_units AS au  
   
   JOIN sys.partitions AS p ON au.container_id = p.partition_id  
   
   JOIN sys.filegroups AS fg ON fg.data_space_id = au.data_space_id  
   
   WHERE au.allocation_unit_id = '<allocation_unit_id>' OR au.allocation_unit_id = '<allocation_unit_id>'  
   
   ORDER BY au.allocation_unit_id;  
   
   GO  
   

2. Kör DBCC CHECKTABLE utan en REPAIR-klausul på tabellen som är associerad med det andra allokeringsenhets-ID:t som anges i felmeddelandet.

3. Kör DBCC CHECKDB utan en REPAIR-klausul så snart som möjligt för att fastställa den fulla omfattningen av korruptionen i hela databasen.

4. Kontrollera felloggen för andra fel som ofta följer med ett 605-fel och granska Windows händelselogg för eventuella system- eller hårdvarurelaterade problem. Åtgärda eventuella hårdvarurelaterade problem som finns i loggarna.

Om problemet inte är hårdvarurelaterat, utför en av följande uppgifter:

1. Återställ databasen från en känd ren backup. Du kan använda funktionen för sidåterställning för att bara återställa de skadade sidorna.

2. Kör DBCC CHECKDB med REPAIR-klausulen som rekommenderas av DBCC CHECKDB-operationen som utfördes i steg 3 för att reparera korruptionen. Om det inte löser problemet att köra DBCC CHECKDB med en av REPAIR-klausulerna, kontakta din primära supportleverantör. Ha resultatet från DBCC CHECKDB tillgängligt för granskning.

   Caution

   Om du är osäker på vilken effekt DBCC CHECKDB med en REPAIR-klausul har på dina data, kontakta din primära supportleverantör innan du kör detta uttalande.

Relaterat innehåll

• DBCC-KONTROLLTABELL (Transact-SQL)