Dela via

MSSQLSERVER_833

gäller för:SQL ServerAzure SQL Managed Instance

Detaljer

Egenskap Värde
Produktnamn SQL Server
Händelse-ID 833
Händelsekälla MSSQLSERVER
Komponent SQLEngine
Symboliskt namn BUF_LONG_IO
Meddelandetext SQL Server har påträffat %d förekomster av I/O-begäranden som tar längre tid än %d sekunder att slutföra på filen [%ls] i databasen [%ls] (%d). Operativsystemets filreferens är 0x%p. Förskjutningen av den senaste långa I/O är: %#016I64x.

Förklaring

Det här meddelandet anger att SQL Server har utfärdat en läs- eller skrivbegäran från disken och att begäran har tagit längre tid än 15 sekunder att returnera. SQL Server rapporterar det här felet och anger ett problem med I/O-undersystemet. Ett databashanteringssystem (DBMS), till exempel SQL Server, förlitar sig på aktualiteten för filindata- och utdataåtgärder (I/O). Något av följande objekt kan orsaka fastnade eller stoppade I/O-åtgärder och påverka SQL Server-svarstider och prestanda negativt:

  • Felaktig maskinvara
  • Felaktigt konfigurerad maskinvara
  • Inställningar för inbyggd programvara
  • Filtrera drivrutiner
  • Komprimering
  • Buggar
  • Andra villkor i I/O-sökvägen

Dessa I/O-problem kan orsaka följande beteende:

  • Blockering.
  • Spärrkonkurration och tidsgränser.
  • Långsam svarstid.
  • Utströjning av resursgränser.
  • Du kan också märka andra symtom som är associerade med det här meddelandet, till exempel:
    • Höga väntetider för PAGEIOLATCH väntar.
    • Varningar eller fel i systemhändelseloggen.
    • Indikationer på problem med diskfördröjning i systemövervakningsräknare.

När en I/O-åtgärd har varit väntande i 15 sekunder eller längre utför SQL Server följande steg:

  1. Identifierar att en åtgärd har varit väntande.

  2. Skriver ett informationsmeddelande till SQL Server-felloggen enligt beskrivningen i avsnittet Information.

    Förklaring till olika avsnitt i det här informationsmeddelandet ges i följande tabell:

Meddelandetext Beskrivning
< Nummer> förekomster Antalet I/O-begäranden som inte slutförde läs- eller skrivåtgärden på mindre än 15 sekunder.
Filinformation Det fullständiga filnamnet, databasnamnet och databasidentifieringsnumret (DBID).
Handtag Operativsystemets handtag för filen. Du kan använda operativsystemets handtag med felsökningsprogram eller andra verktyg för att spåra I/O-begärandepaketbegäranden (IRP).
Uppväga Förskjutningen av den senaste fastnade I/O-åtgärden eller den senaste stoppade I/O-åtgärden. Du kan använda förskjutningen med felsökningsprogram eller andra verktyg för att spåra IRP-begäranden.


När informationsmeddelandet skrivs till SQL Server-felloggen kanske I/O-åtgärden inte längre fastnar eller stoppas.

Möjliga orsaker

Informationsmeddelandet anger att den aktuella belastningen kan ha något av följande villkor:

  • Arbetsbelastningen överskrider I/O-sökvägsfunktionerna, antingen på grund av felkonfiguration av I/O-undersystemet (SAN, NAS och direktanslutet) eller på grund av att maskinvarukapaciteten har nåtts.
  • Arbetsbelastningen överskrider de aktuella systemfunktionerna, till exempel I/O, processorer och HBA:er.
  • I/O-sökvägen har felaktig programvara. Det kan vara problem med inbyggd programvara eller drivrutinsfel.
  • I/O-sökvägen har felaktiga maskinvarukomponenter.
  • Prestandaproblem på operativsystemnivå.
  • Filterdrivrutinsintervention i I/O-processen eller lagringssökvägen för databasfiler. Till exempel antivirusprogram.

SQL Server registrerar den tid då den initierade en I/O-begäran och registrerar den tid då I/O slutfördes. Om den skillnaden är 15 sekunder eller längre identifieras det här villkoret. Det innebär också att SQL Server inte är orsaken till det fördröjda I/O-villkor som det här meddelandet beskriver och rapporter. Det här villkoret kallas stoppad I/O. De flesta diskbegäranden sker inom diskens normala hastighet. Den här typiska diskhastigheten kallas ofta disksökningstid. Disksökningstiden för de flesta standarddiskar inträffar på 10 millisekunder eller mindre. Därför är 15 sekunder lång tid för systemets I/O-sökväg att återgå till SQL Server. Mer information finns i avsnittet Mer information .

Användaråtgärd

Felsöka det här felet genom att utföra följande steg:

  1. Granska systemhändelseloggen efter maskinvarurelaterade felmeddelanden.
  2. Granska maskinvaruspecifika loggar om de är tillgängliga. Använd de metoder och tekniker som krävs för att fastställa orsaken till fördröjningen i operativsystemet, drivrutinerna eller I/O-maskinvaran.
  3. Uppdatera alla enhetsdrivrutiner och inbyggd programvara eller utför annan diagnostik som är associerad med ditt I/O-undersystem.
  4. Diskåtkomst kan fördröjas av filterdrivrutiner, till exempel ett antivirusprogram. Om du vill öka åtkomsthastigheten undantar du SQL Server-datafilerna som anges i felmeddelandet från de aktiva virusgenomsökningarna. Mer information finns i Så här väljer du antivirusprogram som ska köras på datorer som kör SQL Server (microsoft.com).
    • Använd kommandoradsverktygetfltmc.exe för att köra frågor mot alla filterdrivrutiner som är installerade i systemet och för att förstå vilka funktioner det utför på lagringssökvägen till databasfilerna.
  5. Använd prestandaövervakaren för att undersöka följande räknare:
    • Genomsnittlig disk sek/överföring
    • Genomsnittlig diskkölängd
    • Aktuell diskkölängd
  6. Du kan också använda anläggningar som Storport ETW-loggning för att mäta svarstiden för begäranden som görs till en diskenhet. En annan liknande disk-I/O-felsökningssats är tillgänglig som en inbyggd profil för Windows Performance Recorder.
  7. Övervaka sys.dm_io_virtual_file_stats och välj lämplig lagringsnivå och IOPS för ditt lagringsdataflöde.

En guidad genomgång för att diagnostisera och felsöka prestandaproblem med SQL Server som uppstår på grund av I/O-problem finns i Felsöka långsamma SQL Server-prestanda som orsakas av I/O-problem.

Mer information

Fastnat I/O och stoppad I/O

Fastnat I/O

Fast I/O definieras som en I/O-begäran som inte slutförs. Ofta anger fast I/O en fast IRP. För att lösa ett fast I/O-villkor måste du vanligtvis starta om datorn eller utföra en liknande åtgärd. Ett fast I/O-villkor indikerar vanligtvis något av följande problem:

  • Felaktig maskinvara.
  • En bugg i en I/O-sökvägskomponent.

Stoppad I/O

Stoppad I/O definieras som en I/O-begäran som slutförs, eller som tar för lång tid att slutföra. Ett stoppat I/O-beteende inträffar vanligtvis på grund av någon av följande orsaker:

  • Maskinvarukonfiguration.
  • Inställningar för inbyggd programvara.
  • Ett filterdrivrutinsproblem som kräver hjälp från maskinvaran eller programvaruleverantören för att spåra och lösa problemet.

SQL Server stoppade I/O och fastnade I/O-inspelning och rapportering

SQL Server-supporten hanterar många fall varje år som involverar problem med fastnat eller stoppat I/O. Dessa I/O-problem visas på olika sätt. I/O-problem är några av de svåraste att diagnostisera och felsöka, och de kräver betydande tid och resurser för felsökning från Microsoft och kunden. Rapportering och registrering av I/O-begäranden utformas per fil. Identifiering och rapportering av stoppade och fastnade I/O-begäranden är två separata åtgärder.

inspelning

Det finns två ögonblick när en poståtgärd inträffar i SQL Server. Den första är när I/O-åtgärden slutförs. Det andra ögonblicket är när den lata författaren körs. När den lata skrivaren körs kontrollerar den alla väntande data och väntande I/O-begäranden för loggfilen. Om I/O-begäran överskrider tröskelvärdet på 15 sekunder inträffar en poståtgärd.

Rapportering

Rapportering sker i intervall som är fem minuter eller mer ifrån varandra. Rapportering sker när nästa I/O-begäran görs i filen. Om en poståtgärd har inträffat och fem minuter eller mer har passerat sedan den senaste rapporten inträffade skrivs det informationsmeddelande som nämns i avsnittet Information till SQL Server-felloggen.

Tröskelvärdet på 15 sekunder kan inte justeras. Du kan dock inaktivera stoppad eller fastnad I/O-identifiering med hjälp av spårningsflagga 830, men vi rekommenderar inte att du gör detta.

Du kan inaktivera identifiering för stoppad och fastnad I/O med hjälp av spårningsflagga 830. Om du vill aktivera den här flaggan varje gång SQL Server startas använder du parametern -T830 start. Om du vill inaktivera identifiering för en instans av SQL Server som körs använder du följande instruktion:

    dbcc traceon(830, -1)

Den här inställningen gäller endast för SQL Server-processens livslängd.

Anmärkning

En I/O-begäran som stoppas eller fastnar rapporteras bara en gång. Om meddelandet till exempel rapporterar att 10 I/O-begäranden har stoppats kommer dessa 10 rapporter inte att inträffa igen. Om nästa meddelande rapporterar att 15 I/O-begäranden har stoppats innebär det att 15 nya I/O-begäranden har stoppats.

Spåra I/O-begärandepaketet (IRP)

SQL Server använder microsoft Windows API-standardanrop för att läsa och skriva data. SQL Server använder till exempel följande funktioner:

  • SkrivFil
  • LäsFil
  • WriteFileScatter
  • ReadFileGather

Läs- eller skrivbegäran hanteras av Windows som ett I/O-begärandepaket (IRP). För att fastställa tillståndet för IRP använder du båda följande funktioner::

Vi rekommenderar att du söker efter tillgängliga uppdateringar för följande objekt:

  • The BIOS
  • Den inbyggda programvaran
  • Andra I/O-sökvägskomponenter

Kontakta maskinvaruleverantörerna innan du utför ytterligare felsökningsåtgärder. Felsökningssessionen kommer sannolikt att omfatta en drivrutin från tredje part, inbyggd programvara eller filterdrivrutinskomponent.

Åtgärder för systemprestanda och frågeplan

På det hela taget kan systemprestanda spela en viktig roll vid I/O-bearbetning. Du bör överväga systemets allmänna hälsotillstånd när du undersöker rapporter om stoppade eller fastnade I/O-åtgärder. För stora belastningar kan göra att det övergripande systemet blir långsamt, inklusive I/O-bearbetningen. Systemets beteende när problemet uppstår kan vara en viktig faktor för att fastställa rotorsaken till problemet. Om processoranvändningen till exempel ökar eller förblir hög när problemet uppstår kan det tyda på att en systemprocess använder så mycket CPU att andra processer påverkas negativt.

Prestandaräknare

Om du vill övervaka I/O-prestanda granskar du följande prestandaräknare för specifik I/O-sökvägsinformation:

  • Genomsnittlig disk sek/överföring
  • Genomsnittlig diskkölängd
  • Aktuell diskkölängd

Till exempel är den genomsnittliga diskens sek/överföringstid på en dator som kör SQL Server vanligtvis mindre än 15 millisekunder. Om värdet genomsnittlig disk sek/överföring ökar indikerar det att I/O-undersystemet inte optimalt håller jämna steg med I/O-efterfrågan.

Var försiktig när du använder prestandaräknare eftersom SQL Server drar full nytta av asynkrona I/O-funktioner som kraftigt överför diskkölängderna. Längre diskkölängder tyder därför inte på något problem.

I Windows System Monitor kan du granska räknaren "Fysisk disk: Diskbyte per sekund" för varje berörd disk och jämföra aktivitetshastigheten mot räknarna "Process: IO Data Bytes/Sek" och "Process: IO Other Bytes/sec" för varje process. Du gör detta för att identifiera om en specifik uppsättning processer genererar överdrivna I/O-begäranden. Olika andra I/O-relaterade räknare i processobjektet visar mer detaljerad information. Om du bedömer att en SQL Server-instans ansvarar för överdriven I/O-belastning på servern läser du nästa avsnitt om index och parallellitet. En detaljerad diskussion om hur du identifierar och löser I/O-flaskhalsar finns i Felsöka långsamma SQL Server-prestanda som orsakas av I/O-problem.

Index och parallellitet

Ofta uppstår utbrott av I/O eftersom ett index saknas. Det här beteendet kan kraftigt push-överföra I/O-sökvägen. Ett pass som använder guiden För indexsvängning (ITW) kan hjälpa till att lösa I/O-trycket på systemet. Om en fråga drar nytta av ett index i stället för en tabellgenomsökning, eller om den använder en sortering eller hash, kan systemet få följande fördelar:

  • En minskning görs i det fysiska I/O som krävs för att slutföra åtgärden som direkt skapar prestandafördelar för frågan.
  • Färre sidor i datacachen måste vändas. Därför är de sidor som finns i datacachen fortfarande relevanta för aktiva frågor.
  • Sortering och hashvärden används eftersom ett index kanske saknas eller eftersom statistiken är inaktuell. Du kan minska tempdb-användning och konkurrens genom att lägga till ett eller flera index.
  • En minskning görs i resurser, parallella åtgärder eller både och. Eftersom SQL Server inte garanterar parallell frågekörning och belastningen på systemet beaktas är det bäst att optimera alla frågor för seriekörning. Om du vill optimera en fråga öppnar du Query Analyzer och anger sp_configure värdet för alternativet maximal grad av parallellitet till 1. Om alla frågor är inställda på att köras snabbt som en seriell åtgärd är parallell körning ofta bara ett bättre resultat. Parallell körning väljs dock ofta eftersom mängden data är stor. För ett index som saknas kan en stor sortering behöva utföras. Flera arbetare som utför sorteringsåtgärden skapar ett snabbare svar. Den här åtgärden kan dock dramatiskt öka trycket på systemet. Stora läsbegäranden från många arbetare kan orsaka en I/O-burst tillsammans med ökad CPU-användning. En fråga kan ofta justeras för att köras snabbare och använda färre resurser om ett index läggs till eller om en annan justeringsåtgärd inträffar.

Praktiska exempel från SQL Server-support

Följande exempel har hanterats av SQL Server Support och Windows Escalation Support. De här exemplen är avsedda att ge en referensram och hjälpa dig att ange dina förväntningar om låsta och fastnade I/O-situationer. De tillhandahåller också ett ramverk för att förstå hur ett system kan påverkas eller svara. Ingen specifik maskinvara eller uppsättning drivrutiner utgör någon specifik risk eller ökad risk för någon annan. Alla system är likadana i detta avseende.

Exempel 1: En loggskrivning som har fastnat i 45 sekunder

Ett försök att skriva en SQL Server-loggfil fastnar regelbundet i cirka 45 sekunder. Loggskrivningen slutförs inte i tid. Det här beteendet skapar ett blockeringsvillkor som orsakar tidsgränser för klienten på 30 sekunder.

Programmet skickade en incheckning till SQL Server och incheckningen fastnar när en loggskrivning väntar. Det här beteendet gör att frågan fortsätter att hålla lås och blockera inkommande begäranden från andra klienter. Sedan börjar andra klienter överskrida tidsgränsen. Detta förvärrar problemet eftersom programmet inte återställer öppna transaktioner när en tidsgräns för frågan inträffar. Detta skapar hundratals öppna transaktioner som håller lås. Därför uppstår en allvarlig blockeringssituation.

Mer information om transaktionshantering och blockering finns i följande Microsoft Knowledge Base-artikel: 224453 Förstå och lösa problem med SQL Server-blockering

Programmet servar en webbplats med hjälp av anslutningspooler. När fler anslutningar blockeras skapar webbplatsen fler anslutningar. Dessa anslutningar blockeras och cykeln fortsätter.

Loggskrivningen tar cirka 45 sekunder att slutföra. Men vid den här tiden säkerhetskopieras hundratals anslutningar. Blockeringsproblemen orsakar flera minuters återställningstid för SQL Server och programmet. I kombination med programproblem har det stoppade I/O-villkoret en mycket negativ effekt på systemet.

Lösning

Problemet spåras till en fast I/O-begäran i en HBA-drivrutin (Host Bus Adapter). Datorn har flera HBA-kort med stöd för redundans. När ett HBA ligger bakom eller inte kommunicerar med san-nätverket (Storage Area Network) konfigureras tidsgränsvärdet "försök igen före redundansväxling" till 45 sekunder. När tidsgränsen överskrids dirigeras I/O-begäran till den andra HBA:n. Det andra HBA:et hanterar begäran och slutförs snabbt. För att förhindra sådana stallförhållanden rekommenderar maskinvarutillverkaren inställningen "försök igen före redundans" på fem sekunder.

Exempel 2: Filterdrivrutinsintervention

Många antivirusprogram och säkerhetskopieringsprodukter använder I/O-filterdrivrutiner. Dessa I/O-filterdrivrutiner blir en del av I/O-begärandestacken och har åtkomst till IRP-begäran. Microsoft Product Support Services har sett olika problem från buggar som skapar fastnade I/O-villkor eller stoppade I/O-villkor i en implementering av filterdrivrutiner.

Ett sådant villkor är en filterdrivrutin för säkerhetskopiering som tillåter säkerhetskopiering av de filer som är öppna när säkerhetskopieringen sker. Systemadministratören har inkluderat SQL Server-datafilkatalogen i alternativen för filsäkerhetskopiering. När säkerhetskopieringen sker försöker säkerhetskopian samla in rätt bild av filen när säkerhetskopieringen startades. Detta fördröjer I/O-begäranden. I/O-begäranden kan bara slutföra en i taget när programvaran hanterar dem.

När säkerhetskopieringen startar sjunker SQL Server-prestanda dramatiskt eftersom I/Os för SQL Server tvingas slutföra en i taget. Logiken i taget är sådan att I/O-åtgärden inte kan utföras asynkront, vilket förvärrar problemet. När SQL Server förväntar sig att publicera en I/O-begäran och fortsätta fastnar arbetaren därför i läs- eller skrivanropet tills I/O-begäran har slutförts. Filterdrivrutinens åtgärder inaktiverar effektivt bearbetningsuppgifterna, t.ex. sql server read-ahead. Dessutom lämnar en annan bugg i filterdrivrutinen åtgärderna i taget i processen, även när säkerhetskopieringen är klar. Det enda sättet att återställa SQL Server-prestanda är att starta om SQL Server så att filhandtaget släpps och återskapas utan interaktion med filterdrivrutinen.

Lösning

För att lösa det här problemet tas SQL Server-datafilerna bort från filsäkerhetskopieringsprocessen. Programvarutillverkaren har korrigerat problemet som lämnade filen i läget "en i taget".

Exempel 3: Dolda fel

Många avancerade system har I/O-sökvägar med flera kanaler för att hantera belastningsutjämning eller liknande aktiviteter. Microsofts produktsupport har hittat problem med belastningsutjämningsprogramvaran där en I/O-begäran misslyckas, men programvaran inte hanterar feltillståndet korrekt. Programvaran kan försöka med oändliga återförsök. I/O-åtgärden fastnar och SQL Server kan inte slutföra den angivna åtgärden. Precis som loggskrivningsvillkoret som beskrevs tidigare kan många dåliga systembeteenden inträffa efter att ett sådant villkor kilar systemet.

Lösning

Lös problemet genom att starta om SQL Server. Ibland måste du dock starta om operativsystemet för att återställa bearbetningen. Vi rekommenderar också att du hämtar en programuppdatering från I/O-leverantören.

Exempel 4: Fjärrlagring, spegling och raidenheter

Många system använder spegling eller använder liknande steg för att förhindra dataförlust. Vissa system som använder spegling är programvarubaserade och vissa är maskinvarubaserade. Den situation som vanligtvis identifieras av Microsoft Support för dessa system är ökad svarstid.

En ökning av den totala I/O-tiden inträffar när I/O måste slutföras innan den anses vara klar. För fjärrspeglingsinstallationer kan nätverksförsök bli inblandade. När enhetsfel inträffar och raidsystemet återskapas kan I/O-mönstret också avbrytas.

Lösning

Strikta konfigurationsinställningar krävs för att minska svarstiden för speglingar eller för att utföra en räd för återskapande.

Exempel 5: Komprimering

Microsoft stöder inte SQL Server-datafiler och loggfiler på komprimerade enheter. NTFS-komprimering är inte säkert för SQL Server eftersom NTFS-komprimering bryter wal-protokollet (Write Ahead Logging). NTFS-komprimering kräver också ökad bearbetning för varje I/O-åtgärd. Komprimering skapar "en i taget" som beteende som orsakar allvarliga prestandaproblem.

Lösning

Lös problemet genom att avkomprimera data och loggfilerna.

Mer information finns i Stöd för databaser på komprimerade volymer.

Ytterligare datapunkter

PAGEIOLATCH_* och väntande skrivloggar i sys.dm_os_wait_stats dynamiska hanteringsvyer (DMV) är viktiga indikatorer för att undersöka prestanda för I/O-sökväg. Om du ser betydande PAGEIOLATCH-väntetider innebär det att SQL Server väntar på I/O-undersystemet. En viss mängd PAGEIOLATCH-väntetider är typiskt och förväntat beteende. Men om den genomsnittliga PAGEIOLATCH-väntetiden konsekvent är större än 10 millisekunder bör du undersöka varför I/O-undersystemet är under press. Mer information finns i följande dokument.

Referenser

SQL Server kräver att systemen stöder "garanterad leverans till stabila medier" enligt kraven för SQL Server I/O-tillförlitlighetsprogrammet. Mer information om indata- och utdatakraven för SQL Server-databasmotorn finns i Krav för indata/utdata för databasmotorn.

Mer information om I/O-fel finns i Grunderna för Microsoft SQL Server I/O, kapitel 2.