SQL Server diagnostik identifierar orapporterade I/O-problem på grund av inaktuella läsningar eller förlorade skrivningar

Den här artikeln beskriver hur SQL Server Diagnostik hjälper till att identifiera problem med orapporterade indata eller utdata som uppstår på grund av inaktuella läsningar eller förlorade skrivningar.

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 826433

Symptom

Om operativsystem-, drivrutins- eller maskinvaruproblem orsakar förlorade skriv- eller inaktuella läsvillkor i I/O-sökvägen kan du se dataintegritetsrelaterade felmeddelanden som felen 605, 823, 3448 och 3456 i SQL Server. Du kan få felmeddelanden som liknar följande exempel:

2003-07-24 16:43:04.57 spid63 Getpage: bstat=0x9, sstat=0x800, cache
2003-07-24 16:43:04.57 spid63 pageno is/should be: objid is/should be:
2003-07-24 16:43:04.57 spid63 (1:7040966)/(1:7040966) 2093354622/2039782424
2003-07-24 16:43:04.57 spid63 ... IAM indicates that page is allocated to this object
2003-07-24 16:52:37.67 spid63 Error: 605, Severity: 21, State: 1
2003-07-24 16:52:37.67 spid63 Attempt to fetch logical page (1:7040966) in database 'pubs' belongs to object 'authors', not to object 'titles'..
2003-07-24 16:52:40.99 spid63 Error: 3448, Severity: 21, State: 1
2003-07-24 16:52:40.99 spid63 Could not undo log record (63361:16876:181), for transaction ID (0:159696956), on page (1:7040977), database 'pubs' (database ID 12). Page information: LSN = (63192:958360:10), type = 2. Log information: OpCode = 2, context 1..
2003-07-09 14:31:35.92 spid66 Error: 823, Severity: 24, State: 2
2003-07-09 14:31:35.92 spid66 I/O error (bad page ID) detected during read at offset 0x00000016774000 in file 'h:\sql\MSSQL\data\tempdb.mdf'..
2010-02-06 15:57:24.14 spid17s Error: 3456, Severity: 21, State: 1.
2010-02-06 15:57:24.14 spid17s Could not redo log record (58997:5252:28), for transaction ID (0:109000187), on page (1:480946), database 'MyDatabase' (database ID 17). Page: LSN = (58997:5234:17), type = 3. Log: OpCode = 2, context 5, PrevPageLSN: (58997:5243:17). Restore from a backup of the database, or repair the database.

Nya I/O-diagnostikfunktioner i SQL Server

SQL Server introducerade nya I/O-diagnostikfunktioner från och med SQL Server 2000 Service Pack 4 och den här diagnostiken har varit en del av produkten sedan dess. De här funktionerna är utformade för att identifiera externa I/O-relaterade problem och felsöka de felmeddelanden som beskrivs i avsnittet Symptom .

Om du får något av de felmeddelanden som visas i avsnittet Symptom och de inte förklaras av en händelse som ett fel på en fysisk enhet granskar du eventuella kända problem med SQL Server, operativsystemet, drivrutinerna och maskinvaran. Diagnostiken försöker ge information om följande två villkor:

• Förlorad skrivning: Ett lyckat anrop till WriteFile-API:et, men operativsystemet, en drivrutin eller cachelagringskontrollanten rensar inte data korrekt till det fysiska mediet trots att SQL Server informeras om att skrivning lyckades.

• Inaktuell läsning: Ett lyckat anrop till ReadFile-API:et, men operativsystemet, en drivrutin eller cachelagringsstyrenheten returnerar felaktigt en äldre version av data.

För att illustrera har Microsoft bekräftat scenarier där ett WriteFile API-anrop returnerar statusen lyckad, men en omedelbar, lyckad läsning av samma datablock returnerar äldre data, inklusive data som sannolikt lagras i en maskinvaruläsningscache. Ibland uppstår det här problemet på grund av ett problem med läscachen. I andra fall skrivs aldrig skrivdata till den fysiska disken.

Så här aktiverar du diagnostiken

I SQL Server 2017 och senare versioner är den här diagnostikfunktionen aktiverad som standard. I SQL Server 2016 och tidigare versioner kan den här diagnostiken endast aktiveras med hjälp av spårningsflagga 818. Du kan ange spårningsflagga 818 som startparameter, -T818, för den SQL Server instansen, eller så kan du köra följande T-SQL-instruktion för att aktivera dem vid körning:

DBCC TRACEON(818, -1)

Spårningsflagga 818 aktiverar en minnesintern ringbuffert som används för att spåra de senaste 2 048 lyckade skrivåtgärderna som utförs av den dator som kör SQL Server, inte inklusive I/Os för sortering och arbetsfil. När fel som 605, 823 eller 3448 inträffar jämförs den inkommande buffertens värde för loggsekvensnummer (LSN) med den senaste skrivlistan. Om det LSN som hämtas under läsåtgärden är äldre än det som används i skrivåtgärden loggas ett nytt felmeddelande i SQL Server felloggen. De flesta SQL Server skrivåtgärder utförs som kontrollpunkter eller som lata skrivningar (en lat skrivning är en bakgrundsaktivitet som använder asynkron I/O). Implementeringen av ringbufferten är enkel och prestandaeffekten på systemet är försumbar.

Information om meddelandet i felloggen

Följande meddelande visar inga explicita fel från WriteFile-API:et eller ReadFile API-anrop som SQL Server. I stället visas ett logiskt I/O-fel som resulterade när LSN granskades och det förväntade värdet var inte korrekt:

Från och med SQL Server 2005 visas felmeddelandet:

SQL Server identifierat ett logiskt konsekvensbaserat I/O-fel: Inaktuell läsning. Det inträffade under en <Read/Write> sida <PAGEID> i databas-ID <DBID> vid förskjutning <PHYSICAL OFFSET> i filen <FILE NAME>. Ytterligare meddelanden i SQL Server fellogg eller systemhändelselogg kan ge mer information. Det här är ett allvarligt feltillstånd som hotar databasintegriteten och som måste åtgärdas omedelbart. Slutför en fullständig kontroll av databaskonsekvens (DBCC CHECKDB). Det här felet kan orsakas av många faktorer. Mer information finns i SQL Server Books Online.

Mer information om fel 824 finns i MSSQLSERVER_824.

När det här felet rapporteras innehåller antingen läscachen en äldre version av sidan eller så har data inte skrivits korrekt till den fysiska disken. I båda fallen (en förlorad skrivning eller en inaktuell läsning) rapporterar SQL Server ett externt problem med operativsystemet, drivrutinen eller maskinvarulagren.

Om fel 3448 inträffar när du försöker återställa en transaktion med fel 605 eller 823 stänger SQL Server instans automatiskt databasen och försöker öppna och återställa den. Den första sidan som får fel 605 eller 823 anses vara en felaktig sida och sid-ID:t behålls av den dator som kör SQL Server. Under återställningen (före omdateringsfasen) när det felaktiga sid-ID:t läss loggas den primära informationen om sidhuvudet i SQL Server felloggen. Den här åtgärden är viktig eftersom den hjälper till att skilja mellan scenarier med förlorad skrivning och inaktuell läsning.

Beteende som observeras med inaktuella läsningar och förlorade skrivningar

Du kan se följande två vanliga beteenden i inaktuella lässcenarier:

• Om databasfilerna stängs och sedan öppnas returneras rätt och senast skrivna data under återställningen.

• När du utfärdar en kontrollpunkt och kör -instruktionen DBCC DROPCLEANBUFFERS (för att ta bort alla databassidor från minnet) och sedan kör -instruktionen DBCC CHECKDB på databasen returneras de senast skrivna data.

De beteenden som nämns i föregående stycke anger ett problem med cachelagring av läsning och de löses ofta genom att inaktivera läscachen. De åtgärder som beskrivs i föregående stycke framtvingar vanligtvis en cache-ogiltighet och de lyckade läsningarna som inträffar visar att det fysiska mediet uppdateras korrekt. Det förlorade skrivbeteendet inträffar när sidan som läss tillbaka fortfarande är den äldre versionen av data, även efter en tvingad rensning av cachelagringsmekanismerna.

Ibland kanske problemet inte är specifikt för en maskinvarucache. Det kan vara ett problem med en filterdrivrutin. I sådana fall granskar du din programvara, inklusive säkerhetskopieringsverktyg och antivirusprogram, och ser sedan om det finns problem med filterdrivrutinen.

Beskrivning av olika inaktuella läsningar och förlorade skrivningar

Microsoft har också noterat villkor som inte uppfyller kriterierna för fel 605 eller 823, men som orsakas av samma inaktuella läs- eller förlorade skrivaktivitet. I vissa fall verkar en sida uppdateras två gånger men med samma LSN-värde. Det här beteendet kan inträffa om objekt-ID och sid-ID är korrekta (sidan har redan allokerats till objektet) och en ändring görs på sidan och rensas till disken. Nästa sidhämtning returnerar en äldre bild och sedan görs en andra ändring. Den SQL Server transaktionsloggen visar att sidan uppdaterades två gånger med samma LSN-värde. Den här åtgärden blir ett problem när du försöker återställa en transaktionsloggsekvens eller med datakonsekvensproblem, till exempel fel med sekundärnyckel eller saknade dataposter. Följande felmeddelande illustrerar ett exempel på det här villkoret:

Fel: 3456, Allvarlighetsgrad: 21, Tillstånd: 1 Det gick inte att göra om loggposten (276666:1664:19), för transaktions-ID (0:825853240), på sidan (1:1787100), databasens författare (7). Sida: LSN = (276658:4501:9), skriv = 1. Logg: OpCode = 4, kontext 2, PrevPageLSN: (275565:3959:31)..

Vissa scenarier beskrivs mer detaljerat i följande listor:

LSN SequenceAction
1   Checkpoint
2   Begin Transaction
3   Table created or truncated
4   Inserts (Pages allocated)
5   Newly allocated page written to disk by Lazy Writer
6   Select from table - Scans IAM chain, newly allocated page read back from disk (LRU | HASHED = 0x9 in getpage message), encounters Error 605 - Invalid Object ID
7   Rollback of transaction initiated

LSN SequenceAction
1   Checkpoint
2   Begin Transaction
3   Page Modification
4   Page written to disk by Lazy Writer
5   Page read in for another modification (stale image returned)
6   Page Modified for a second time but because of stale image does not see first modification 
7   Rollback - Fails - Transaction Log shows two different log records with the same PREV LSN for the page

sort SQL Server operatorer utför I/O-aktiviteter, vanligtvis i tempdb databasen. Dessa I/O-åtgärder liknar buffert-I/O-åtgärderna. De har dock redan utformats för att använda logik för återförsök för att försöka lösa liknande problem. Den ytterligare diagnostik som beskrivs i den här artikeln gäller inte för dessa I/O-åtgärder.

Microsoft har noterat att rotorsaken till följande fel vid sorteringsläsning vanligtvis är en inaktuell läsning eller förlorad skrivning:

2003-04-01 20:13:31.38 spid122 SQL Server Assertion: File: <p:\sql\ntdbms\storeng\drs\include\record.inl>, line=1447 Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
2003-03-29 09:51:41.12 spid57 Sort read failure (bad page ID). pageid = (0x1:0x13e9), dbid = 2, file = e:\program files\Microsoft SQL Server\mssql\data\tempdb.mdf. Retrying.
2003-03-29 09:51:41.13 spid57 Error: 823, Severity: 24, State: 7
2003-03-29 09:51:41.13 spid57 I/O error (bad page ID) detected during read at offset 0x000000027d2000 in file 'e:\program files\Microsoft SQL Server\mssql\data\tempdb.mdf'..
* 00931097 Module(sqlservr+00531097) (utassert_fail+000002E3)
* 005B1DA8 Module(sqlservr+001B1DA8) (RecBase::Resize+00000091)
* 00407EE7 Module(sqlservr+00007EE7) (RecBase::LocateColumn+00000012)
* 00852520 Module(sqlservr+00452520) (mergerow+000000A4)
* 008522B3 Module(sqlservr+004522B3) (merge_getnext+00000285)
* 0085207D Module(sqlservr+0045207D) (mergenext+0000000D)
* 004FC5FB Module(sqlservr+000FC5FB) (getsorted+00000021)

Eftersom inaktuell läsning eller förlorad skrivning resulterar i datalagring som inte är förväntat kan en mängd olika beteenden uppstå. Det kan visas som saknade data, men några av de vanligaste effekterna av saknade data visas som skadade index, till exempel fel 644 eller 625:

Fel 644 Meddelandetext på allvarlighetsgrad 21 Det gick inte att hitta indexposten för RID %.*hs på indexsidan %S_PGID, index-ID %d, databasen %.*ls.

Fel 625 Allvarlighetsgrad 21 Meddelandetext Det går inte att hämta raden från sidan %S_PGID av RID eftersom slotid (%d) inte är giltigt.

Vissa kunder har rapporterat saknade rader efter att de har gjort radantalsaktiviteter. Det här problemet uppstår på grund av en förlorad skrivning. Kanske skulle sidan vara länkad till den klustrade indexsidans kedja. Om skrivning har förlorats fysiskt går även data förlorade.

Observera att Microsoft har bekräftat att under sällsynta och tunga I/O-belastningar kan vissa maskinvaruplattformar returnera en inaktuell läsning. Om den utökade diagnostiken anger ett möjligt inaktuellt läs- eller förlorat skrivvillkor kontaktar du maskinvaruleverantören för omedelbar uppföljning och testning med SQLIOSim-verktyget .

SQL Server kräver att system stöder garanterad leverans till stabila medier enligt SQL Server krav för I/O-tillförlitlighetsprogram. Mer information om indata- och utdatakraven för SQL Server-databasmotorn finns i Microsoft SQL Server Database Engine Input/Output Requirements (Krav för in- och utdata för databasmotorn i Microsoft SQL Server Database Engine).