Dela via

Felsöka tillfälliga eller periodiska problem med att ansluta till SQL Server

  • Artikel

Kommentar

Innan du börjar felsöka rekommenderar vi att du kontrollerar förutsättningarna och går igenom checklistan. Mer information finns i Självhjälpsartiklar.

Nätverksstabilitet är avgörande för en smidig drift av olika tjänster och program. Det finns dock tillfällen då nätverksproblem stör den här stabiliteten. Den här artikeln hjälper dig att förstå och åtgärda tillfälliga eller periodiska nätverksproblem och deras vanliga felmeddelanden. De här problemen kan vara frustrerande, men du kan lösa dem mer effektivt med bättre förståelse och lämpliga felsökningstekniker.

De vanligaste felmeddelandena

Tillfälliga problem uppstår oregelbundet, medan periodiska problem tenderar att inträffa med förutsägbara intervall. Att identifiera typen av problem är det första steget i felsökningen. När tillfälliga eller periodiska nätverksproblem uppstår kan följande felmeddelanden uppstå:

  • Kommunikationslänkfel: Det här felet indikerar ett avbrott i kommunikationen mellan nätverkskomponenter.
  • Tidsgränsen för anslutningen har upphört att gälla: Tidsgränsen för anslutningen till servern uppnåddes, vilket tyder på en fördröjning eller otillgänglighet för servern.
  • Allmänt nätverksfel: Ett allmänt nätverksfel visas ofta som ett ospecificerat problem med nätverket.
  • Fel på transportnivå: Det här felet uppstår på transportlagret, vilket tyder på problem med dataöverföring.
  • Det angivna nätverksnamnet är inte längre tillgängligt: Det här meddelandet innebär att den angivna nätverksresursen inte kan nås.
  • Tidsgräns för semafor: Det här felet pekar på ett timeout-villkor som rör användningen av semaforer i nätverket.
  • Tidsgränsen för vänteåtgärden: En vänteåtgärd har överskridit sin tillåtna tid, vanligtvis på grund av nätverksförseningar.
  • Ett allvarligt fel uppstod när indataströmmen lästes från nätverket: Det här meddelandet tyder på ett kritiskt fel vid läsning av data från nätverket.
  • Protokollfel i TDS-ström: TDS (Tabular Data Stream) är ett protokoll som används av SQL Server. Det här felet indikerar ett problem med protokollet.
  • Servern hittades inte eller var inte tillgänglig: Det här felmeddelandet tyder på att servern som du försöker komma åt inte är tillgänglig eller inte kan hittas.
  • SQL Server finns inte eller åtkomst nekas: Det här felet kan tyda på avsaknad av SQL Server eller ett autentiseringsfel vid försök att komma åt SQL Server.

Orsak

De vanligaste problemen gäller paketförluster på grund av antivirusprogram, nätverksoptimering, äldre nätverksdrivrutiner, felaktiga routrar eller växlar samt anslutningar som inte är poolade i programmet.

Vissa orsaker, till exempel antivirusprogram, kan vara svåra att bevisa, men är fortfarande vanliga. Du kan behöva avinstallera och starta om datorn för att bevisa det, utan tydliga bevis. Det kan också fungera att skapa ett undantag för SQL Server. Men att stänga av antivirusprogrammet fungerar vanligtvis inte eftersom nätverksfilterdrivrutinerna fortfarande läses in även om de inte övervakas.

Felsökningsprocess

Kommentar

Den här processen är utformad för SQL Server-klient- och serveranslutningar. Andra kommunikationer, till exempel SQL Server-spegling, Always-On och Service Broker-synkroniseringstrafik via port 5022, åtgärdas inte.

I allmänhet bör felsökning vara datadriven, vilket kan ge vika för empiriska tester i en mer fokuserad kontext. Om problemet är mycket tillfälligt och nätverksspårningar blir svåra att samla in kan de empiriska metoderna tillämpas först.

Samla in en rapport med SQLCHECK på varje dator

Kör SQLCHECK på varje dator för att skapa en rapport. Det är användbart att avgöra varför en anslutning kan misslyckas.

Samla in nätverksspårningar på klienten och servern

  • På Windows-datorer samlar du in nätverksspårningar med hjälp av SQLTRACE.

    Följ dessa steg för att förbereda och ta spårningen. Steg 2 och 3 behöver bara göras en gång.

    1. Ladda ned den senaste versionen av SQLTRACE och packa upp den till en mapp, till exempel C:\MSDATA.

    2. Öppna filen SQLTrace.ini och inaktivera följande inställningar:

      BIDTrace=no, AuthTrace=no och EventViewer=no

    3. Spara filen.

    4. Öppna PowerShell som administratör och ändra katalogen till mappen som innehåller SQLTrace.ps1.

      CD C:\MSDATA

    5. Starta spårningssamlingen.

      .\SQLTrace.ps1 -start

    6. Återskapa problemet eller vänta tills felet inträffar.

    7. Stoppa spårningen.

      .\SQLTrace.ps1 -stop

    En utdatamapp genereras i den aktuella katalogen och du kan använda den för ytterligare analys.

  • På icke-Windows-datorer använder du TCPDUMP eller WireShark för att samla in en paketinsamling.

Köra SQL Server Network Analyzer

SQL Network Analyzer UI (SQLNAUI) tillhandahåller ett grafiskt gränssnitt för att välja spårningsfiler för parsning och inställningsalternativ. Ladda ned den från SQL Network Analyzer (SQLNA).

Bearbeta klient- och serverspårningar separat. Om du har länkade spårningar kan du bearbeta dem samtidigt. Den totala storleken på dessa filer får inte överstiga 80 % av datorns minne. Se till att du har tillräckligt med minne för att bearbeta alla relaterade spårningsfiler.

Det här verktyget genererar en rapport över misstänkta problem och en CSV-fil som du kan utforska i Excel för alternativ forskning.

Försök att hitta matchade konversationer i klientspårningen och serverspårningen. I allmänhet matchar IP-adresserna och portnumren. Men om anslutningarna går igenom någon form av nätverksadressöversättning eller portmappning kan det vara svårare, och du kan behöva rada upp med IPV4-paket-ID:n och jämföra nyttolasterna.

Mönster att söka efter i nätverksspårningsanalys

Granska hur konversationerna slutar i NETMON eller WireShark. Kontrollera om klienten och servern är överens om samma sak, eller om de berättar en annan historia.

Anslutningen stängdes under SSL-handskakning

Om chiffersviten som används i ServerHello-paketet är en Diffie-Hellman-svit och trafiken är mellan Windows 2012 eller tidigare och Windows 2016 eller senare ändras den här algoritmen från och med Windows 2016-säkerhetskorrigeringar. Du bör inaktivera den här gruppen med chiffersviter. Mer information finns i Program upplever tvångsslutna TLS-anslutningsfel vid anslutning av SQL-servrar i Windows.

Om anslutningen stängs efter ClientHello kontrollerar du om det finns ett TLS 1.0- eller TLS 1.2-matchningsfel mellan klienten och servern. Om de är likadana kontrollerar du de aktiverade chiffersviterna och aktiverade hashvärden på båda datorerna.

Mer information finns i Advanced Secure Sockets Layer-datainsamling.

Borttagna paket

Visa slutet på de matchade konversationerna. Om den ena har många återöverförda paket (eller 10 Keep-Alive-paket, 1 sekund ifrån varandra) följt av en ACK+RESET och den andra inte gör det, eller om en rapporterar ett svar i tid och den andra ser det fördröjt och stänger eller återställer konversationen, tyder detta på att ett problem med nätverksenheten och paketen tas bort eller fördröjs.

Du kan också se klientrapporten som anger att servern återställer konversationen och serverrapporten som anger att klienten återställer konversationen. Detta beror på en felaktig växel eller router som stänger anslutningen från mitten, och de kan ibland konfigureras för att göra det om de upptäcker att anslutningen har varit inaktiv ett tag – ofta ignorerar Keep-Alive-paket.

Mer information om avbrutna anslutningar finns i:

Både serverspårningen och klientspårningen är överens om att problemet finns på klienten

Om båda spårningarna visar en fördröjning eller inget svar på klienten, eller om klienten utfärdar en ACK+RESET efter att ha erkänt ett serversvar, eller på annat sätt stänger anslutningen tidigt under inloggningssekvensen, måste du ta en BID-spårning och en NETSH-spårning på klienten för att titta inuti TCP/IP-stacken och vad drivrutinen tänker. Detta är vanligt om antivirus- eller andra nätverksfilterdrivrutiner fördröjer mottagandet av paketet eller skickar svaret. Tidsgränser för anslutningar kan också bero på ett långsamt DNS-svar eller ett långsamt säkerhets-API som anropades innan det första SYN-paketet skickades via kabeln.

Kontrollera rapporten om tillfälliga portar i SQL Network Analyzer och kontrollera att klienten inte får slut på utgående portar.

Om klienten har en lång fördröjning innan SYN-paketet skickas kan du se ett mönster som endast visar TCP-3-vägs öppna handskakning, följt omedelbart eller ibland efter att ha skickat PreLogin-paketet, av en ACK +FIN som kommer från klienten.

Samla in en nätverksspårning och EN BID-spårning för att isolera klientproblem i Windows

  1. Öppna filen SQLTrace.ini och aktivera följande inställningar igen:

    BIDTrace=Yes, AuthTrace=Yes och EventViewer=Yes

  2. BIDProviderList Konfigurera i SQLTrace.ini så att den matchar den drivrutin som programmet använder.

    .NET System.Data.SqlClient är aktiverat som standard. Om det inte är den drivrutin du använder inaktiverar BIDProviderList du genom att lägga # till längst fram på linjen och ta bort den från början av ODBC- eller OLEDB-listan. Detta samlar in alla drivrutiner som stöds av den typen. Mer information finns i INI-konfiguration.

  3. Spara filen.

  4. Öppna PowerShell som administratör och ändra katalogen till mappen som innehåller SQLTrace.ps1.

    CD C:\MSDATA

  5. Initiera BID Tracing-registret om du samlar in BID-spårningar.

    Kommentar

    BID-spårning är aktiverat som standard.

    .\SQLTrace.ps1 -setup

  6. Starta om den tjänst eller det program som du spårar.

    För vissa program, till exempel SSIS-paket (SQL Server Integration Services), startas en ny instans av DTEXEC eller ISServerExec när paketet körs, så en omstart är inte meningsfull.

  7. Starta spårningssamlingen.

    .\SQLTrace.ps1 -start

  8. Återskapa problemet eller vänta tills felet inträffar.

  9. Stoppa spårningen.

    .\SQLTrace.ps1 -stop

En utdatamapp genereras i den aktuella katalogen och du kan använda den för ytterligare analys.

Information om hur du spårar andra Microsoft SQL Server-drivrutiner finns i följande artiklar. Utför med hjälp av en nätverksspårning.

Information om hur du spårar drivrutiner från tredje part finns i leverantörsdokumentationen.

Både serverspårningen och klientspårningen är överens om att problemet finns på servern

Om båda spårningarna visar en fördröjning eller inget svar på servern, eller om servern stänger anslutningen vid en oväntad tidpunkt i inloggningssekvensen, eller om servern stänger många anslutningar samtidigt, tyder detta på att det finns vissa problem på servern.

De mest sannolika orsakerna är dålig serverprestanda, hög MAXDOP och stora parallella frågor och blockering. Dessa kan orsaka trådsvältning, vilket förhindrar att en inloggningsbegäran hanteras snabbt, särskilt om många tidsgränser för anslutningar slutar samtidigt och kolumnen LoginAck visar "Late". SQL Server ERRORLOG-filen kan visa I/O-åtgärder som tar längre tid än 15 sekunder, vilket är en annan indikator på prestandaproblem. I nätverksspårningen kan du också se många konversationer i återställningsrapporten med sex bildrutor eller färre, vilket indikerar att TCP 3-vägshandskakningen kanske inte har slutförts. Mer information finns i Samla in anslutningsringsbufferten.

Kör frågan RingBufferConnectivity och klistra in resultatet i Excel. Eftersom det här är en historisk lista kan den köras när problemet inträffar. Men för en upptagen server kan det sluta snabbt. För en långsam server kan den ha data i ett par dagar.

Om ditt program använder flera aktiva resultatuppsättningar (MARS) slutar det med en ÅTERSTÄLLNING som en del av den avslutande sekvensen. Detta är godartat om SMP:FIN- och ACK+FIN-paketen redan har skickats från klienten. Serverns SMP:FIN-paket kommer att tas emot efter ACK+FIN från klienten, och Windows utfärdar en ACK+RESET och sedan en ÅTERSTÄLLNING för andra serversvar som en del av anslutningsstängningssekvensen.

Anslutningspooler

Mer information finns i Anslutningspooler.

Om anslutningspooler används blir konversationerna i nätverksspårningen vanligtvis ganska långa. Du kan använda CSV-filen som genereras av SQL Server Network Analyzer för att sortera och filtrera efter protokoll och ramar. Du ser förmodligen inte start- eller slutramarna om nätverksinsamlingen är mindre än en halvtimme. Om många konversationer är kortare än 30 bildrutor från SYN-paketet till ACK+FIN-paketet anger detta anslutningar som inte är poolade. Om dessa blandas med några längre konversationer misstänker du att icke-poolanslutningar i bakgrunden orsakas av att kommandon körs på en icke-MARS-anslutning när du läser en resultatuppsättning.

Den tillfälliga portrapporten visar antalet nya anslutningar under spårningens livslängd. Du kan bedöma anslutningshastigheten efter antalet anslutningar per sekund.

RESET jämfört med ACK+RESET

ACK+RESET visas vanligtvis när programmet eller Windows avbryter en anslutning. Detta beror vanligtvis på ett TCP-fel på låg nivå. Paketet informerar den andra datorn om att sluta skicka omedelbart. Men om servern är mitt i överföringen kan ett eller två paket komma till klienten när ACK+RESET har skickats. Eftersom porten är stängd skickar operativsystemet ett RESET-paket. Detta inträffar också om paket anländer efter ACK+FIN-paketet som inte är en del av det normala avslutande handskakningen.

Vissa drivrutiner från tredje part skickar också ett ACK+RESET-paket för att stänga anslutningen i stället för en ACK+FIN. Vissa avsökningsanslutningar kan också göra detta. Om ACK+RESET-paketet inte föregås av Keep-Alive-paket, Återöverförda paket eller Noll Windows-paket, och det kommer från klienten när en normal stängning av ACK+FIN förväntas, kan det vara godartat.

Använda NETSTAT för att analysera nätverksproblem

NETSTAT samlas in automatiskt när du kör SQLTrace.ps1 för datainsamling.

Du kan också köra NETSTAT -abon > c:\ports.txt kommandotolken som administratör för att samla in information om nätverksproblem.

Filen ports.txt innehåller en lista över alla inkommande och utgående portar, portnummer, process-ID och namn på program som äger portarna. Du kan använda detta för att se de värsta förbrytarna och om portgränsen har nåtts. Aktivera Statusfält i Anteckningar och inaktivera Radbyte i Word. Statusfältet ger ett radantal. Du kan dela med två för att få en ungefärlig portanvändning.

Justera TcpTimedWaitDelay och MaxUserPort

Om ett program överbelastar de utgående portarna på värddatorn och du inte kan göra några omedelbara ändringar i programmet kan du minska TcpTimedWaitDelay från 240 till så lågt som 30 sekunder, vilket gör att utgående portar kan återvinnas snabbare.

För Windows 2003 och senare kan du också öka MaxUserPort. För Windows Vista och senare anger du detta via NETSH kommandot . Den här åtgärden eliminerar inte ineffektiviteten i icke-poolanslutningar eller icke-poolade bakgrundsanslutningar, och utvecklaren bör uppmanas att ändra sina program så att de använder anslutningspooler.

För Windows 2008 och senare har intervallet ökats från cirka 4 000 tillfälliga portar till 16 000 portar som standard.

Mer information finns i Justera inställningarna MaxUserPort och TcpTimedWaitDelay.

Nästan alla paket som skickas från klienten till servern eller servern till klienten besvaras med ett ACK-paket i motsatt riktning. Det TCP.SYS lagret genererar ACK. Om ett paket tas emot på klienten, och klientspårningen visar att det kommer in men ingen ACK returneras till servern, är detta en bra indikation på att antivirusprogrammet eller någon annan nätverksfilterdrivrutin har förlorat eller släppt paketet eller hållit fast vid det under en lång tid (efter slutet av nätverksspårningssamlingen). På samma sätt, om serverspårningen visar ett paket som kommer in från en klient men ingen ACK skickas tillbaka till klienten, tyder detta på att serverns antivirusprogram på servern kan ha ett problem.

Men när du laddar upp eller laddar ned en stor mängd data kan ACK-paketen komma efter en serie datapaket för att hjälpa till med flödeskontroll.

Antivirus- och filterdrivrutinerna är mycket svåra att bevisa som den skyldige. Ett empiriskt test krävs nästan alltid. Skapa ett undantag för programmet eller SQL Server i antivirusprogrammet och övervaka det sedan i 48 timmar för att se om beteendet förbättras. Om ett undantag inte kan anges avinstallerar du antivirusprogrammet och startar om. Det hjälper vanligtvis inte att inaktivera det eftersom drivrutinen för antivirusfilter fortfarande läses in. Gör bara detta som en sista utväg om ditt gränsskydd är på plats.

Kontakta nätverkssäkerhetsadministratörerna. Om situationen förbättras kan du behöva samarbeta med antivirusleverantören för att åtgärda problemet. Om den inte gör det kan andra nätverksfilterdrivrutiner vara den skyldige.

Aktivera granskning av Windows-brandväggen

Om du vill ta reda på om brandväggen har tagit bort några paket aktiverar du brandväggsgranskning i Windows.

För SQL Server kan det här problemet vara relaterat till klienten eller serverdatorn. Nätverksspårningen visar att datorn tog emot ett paket men inte svarade. Paketet kan sedan överföras igen, återigen får inget svar och så småningom återställs anslutningen.

Empiriska och andra åtgärder

Tillfälliga portar

Att få slut på tillfälliga portar är en relativt vanlig orsak till tillfälliga timeouter för anslutningar, särskilt om du inte ser SYN-paketet på kabeln.

För inkommande begäranden på servern kan portar, till exempel 80 eller 1433, ta upp till 64 000 inkommande anslutningar per klientens IP-adress och är i allmänhet "obegränsade" för alla praktiska ändamål.

För utgående anslutningar är å andra sidan antalet portar begränsat och delas mellan alla serveranslutningar. För Windows Vista, Windows 2008 och senare är standardintervallet från port 49152 till 65535 (2^16 = 16 384 portar).

Normalt lagras portar i fyra minuter (240 sekunder) av operativsystemet innan de återanvänds och kan återanvändas av program. Detta för att förhindra portförfalskning genom skadlig programvara eller oavsiktlig omdirigering av en ny anslutning till den tidigare innehavaren av porten. På grund av den här fördröjningen kan ett klientprogram i Windows 2003 bara göra 17 anslutningar per sekund till SQL Server, och det utgående portintervallet är uttömt på mindre än fyra minuter. För Windows Vista ökar antalet till 68 anslutningar per sekund.

För program som IIS kan varje HTTP-klient ha en utgående port till SQL Server. För en upptagen webbserver är det en verklig möjlighet att få slut på utgående portar när belastningen är hög. En webbgrupp kan minimera den här situationen.

Justera maximalt serverminne (MB)

Om du vill lösa problem som rör minnesbrist i kerneln justerar du det maximala serverminnet (MB).)

Inaktivera avlastning

I testsyfte kan du inaktivera viss avlastning via en administrativ kommandotolk:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Låt inte de här inställningarna vara inaktiverade under en längre tid om de inte lindrar ett problem. De bör vara aktiverade som standard i Windows 2008 och senare.

För annan avlastning måste du gå till nätverkskortegenskaperna för att visa och inaktivera dem.

Problem med VMware-nätverksbuffert

ESX-värden som innehåller den virtuella datorn (VM) har en liten nätverksbuffert som kan orsaka tillförlitlighetsproblem om det uppstår trafiktoppar. I följande VMware-artikel beskrivs hur du ökar buffertstorleken. Ingen omstart krävs. Den här åtgärden måste utföras på ESX-värddatorn, inte på den virtuella datorn.

Stor paketförlust i gästoperativsystemet med hjälp av VMXNET3 i ESXi

Prova också att flytta de virtuella datorerna till en annan ESX-värdserver eller flytta klienten och servern till samma ESX-värdserver och se om problemet försvinner. Om det gör det är det ett grundläggande nätverksproblem.

VMware-ögonblicksbilder

Kontrollera om VMware-ögonblicksbilder inträffar under felet och inaktivera dem.

RSS (Receive Side Scaling) har inaktiverats på värddatorn

När RSS är inaktiverat använder SQL Server-värden endast en enda PROCESSOR för att bearbeta alla nätverksbegäranden. Detta kan öka cpu-värdet till 100 % och orsaka problem, även om de andra processorerna (och den totala cpu-nivån) är låga.

Mer information finns i Introduktion till skalning på mottagarsidan och skalning på mottagarsidan version 2 (RSSv2).

Mer information

Tillfälliga eller periodiska autentiseringsproblem i SQL Server

Samla in en nätverksspårning

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.