Delen via

Onregelmatige of periodieke problemen met het maken van verbinding met SQL Server oplossen

  • Artikel

Notitie

Voordat u begint met het oplossen van problemen, raden we u aan de vereisten te controleren en de controlelijst te doorlopen. Zie Zelfhulpartikelen voor meer informatie.

Netwerkstabiliteit is essentieel voor de soepele werking van verschillende services en toepassingen. Er zijn echter momenten waarop netwerkproblemen deze stabiliteit verstoren. Dit artikel helpt u bij het begrijpen en oplossen van onregelmatige of periodieke netwerkproblemen en hun typische foutberichten. Deze problemen kunnen frustrerend zijn, maar u kunt ze effectiever oplossen met een beter begrip en de juiste technieken voor probleemoplossing.

De meest voorkomende foutberichten

Onregelmatige problemen treden onregelmatig op, terwijl periodieke problemen meestal optreden met voorspelbare intervallen. Het identificeren van het type probleem is de eerste stap bij het oplossen van problemen. Wanneer onregelmatige of periodieke netwerkproblemen optreden, kunnen de volgende foutberichten optreden:

  • Communicatiekoppelingsfout: deze fout geeft een onderbreking aan in de communicatie tussen netwerkonderdelen.
  • Time-out voor verbinding verlopen: er is een time-out opgetreden voor de verbinding met de server, wat aangeeft dat de server niet beschikbaar is.
  • Algemene netwerkfout: Een algemeen netwerkfoutbericht duidt vaak op een niet-opgegeven probleem met het netwerk.
  • Fout op transportniveau: deze fout treedt op in de transportlaag, wat problemen met gegevensoverdracht voorstelt.
  • De opgegeven netwerknaam is niet meer beschikbaar: dit bericht impliceert dat de opgegeven netwerkresource niet kan worden bereikt.
  • Time-out van semaphore: deze fout verwijst naar een time-outvoorwaarde met betrekking tot het gebruik van semaphores in het netwerk.
  • Er is een time-out opgetreden voor de wachtbewerking: een wachtbewerking heeft de toegestane tijd overschreden, meestal vanwege netwerkvertragingen.
  • Er is een fatale fout opgetreden tijdens het lezen van de invoerstroom van het netwerk: dit bericht duidt op een kritieke fout bij het lezen van gegevens uit het netwerk.
  • Protocolfout in TDS-stroom: Tabular Data Stream (TDS) is een protocol dat wordt gebruikt door SQL Server. Deze fout geeft een probleem met het protocol aan.
  • De server is niet gevonden of is niet toegankelijk: dit foutbericht geeft aan dat de server die u probeert te openen niet beschikbaar is of niet kan worden gevonden.
  • SQL Server bestaat niet of de toegang is geweigerd: deze fout kan duiden op het ontbreken van de SQL Server of een verificatiefout bij het openen van SQL Server.

Oorzaak

De meest voorkomende problemen zijn gerelateerd aan pakketuitval vanwege antivirus, netwerkoptimalisatie, oudere netwerkstuurprogramma's, slechte routers of switches en niet-gegroepeerde verbindingen in de toepassing.

Sommige oorzaken, zoals antivirus, kunnen moeilijk te bewijzen zijn, maar zijn nog steeds gebruikelijk. Mogelijk moet u de computer verwijderen en opnieuw opstarten om het te bewijzen, zonder duidelijk bewijs. Het maken van een uitzondering voor SQL Server werkt mogelijk ook. Maar het uitschakelen van het antivirusprogramma werkt meestal niet omdat de netwerkfilterstuurprogramma's nog steeds worden geladen, zelfs als ze niet worden bewaakt.

Probleemoplossingsproces

Notitie

Dit proces is ontworpen voor SQL Server-client- en serververbindingen. Andere communicatie, zoals SQL Server Mirroring, Always-On en Service Broker-synchronisatieverkeer via poort 5022, worden niet behandeld.

Over het algemeen moet probleemoplossing gegevensgestuurd zijn, wat een manier kan bieden voor empirische tests in een meer gerichte context. Als het probleem zeer onregelmatig is en netwerktraceringen moeilijk kunnen worden vastgelegd, kunnen de empirische methoden eerst worden toegepast.

Een rapport verzamelen met BEHULP van SQLCHECK op elke computer

Voer SQLCHECK uit op elke computer om een rapport te produceren. Het is handig om te bepalen waarom een verbinding mogelijk mislukt.

Netwerktraceringen verzamelen op de client en server

  • Verzamel netwerktraceringen op Windows-computers met behulp van SQLTRACE.

    Volg deze stappen om de tracering voor te bereiden en uit te voeren. Stap 2 en 3 hoeven slechts één keer te worden uitgevoerd.

    1. Download de nieuwste versie van SQLTRACE en pak deze uit in een map, zoals C:\MSDATA.

    2. Open het bestand SQLTrace.ini en schakel de volgende instellingen uit:

      BIDTrace=no, AuthTrace=no en EventViewer=no

    3. Sla het bestand op.

    4. Open PowerShell als beheerder en wijzig de map in de map met SQLTrace.ps1.

      CD C:\MSDATA

    5. Start de traceringsverzameling.

      .\SQLTrace.ps1 -start

    6. Reproduceer het probleem of wacht tot de fout optreedt.

    7. Stop de tracering.

      .\SQLTrace.ps1 -stop

    Er wordt een uitvoermap gegenereerd in de huidige map en u kunt deze gebruiken voor verdere analyse.

  • Gebruik TCPDUMP of WireShark op niet-Windows-computers om een pakketopname te verzamelen.

SQL Server Network Analyzer uitvoeren

SQL Network Analyzer UI (SQLNAUI) biedt een grafische interface voor het selecteren van traceringsbestanden voor het parseren en instellen van opties. Download deze vanuit SQL Network Analyzer (SQLNA).

Client- en servertraceringen afzonderlijk verwerken. Als u traceringen hebt gekoppeld, verwerkt u deze op hetzelfde moment. De totale grootte van deze bestanden mag niet groter zijn dan 80% van het geheugen van uw computer. Zorg ervoor dat u voldoende geheugen hebt om alle gerelateerde traceringsbestanden te verwerken.

Met dit hulpprogramma wordt een rapport gegenereerd van verdachte problemen en een CSV-bestand dat u in Excel kunt verkennen voor alternatief onderzoek.

Probeer overeenkomende gesprekken te vinden in de clienttracering en de servertracering. Over het algemeen komen de IP-adressen en poortnummers overeen. Als de verbindingen echter door een soort netwerkadresomzetting of poorttoewijzing gaan, kan het lastiger zijn en moet u mogelijk de IPV4-pakket-id's in lijn brengen en de nettoladingen vergelijken.

Patronen om te zoeken in netwerktraceringsanalyse

Bekijk hoe de gesprekken eindigen in NETMON of WireShark. Controleer of de client en server hetzelfde ermee eens zijn of dat ze een ander verhaal vertellen.

Verbinding gesloten tijdens SSL-handshake

Als in het ServerHello-pakket de gebruikte coderingssuite een Diffie-Hellman-suite is en het verkeer tussen Windows 2012 of eerder en Windows 2016 of hoger ligt, verandert dit algoritme vanaf beveiligingspatches voor Windows 2016. U moet deze groep coderingssuites uitschakelen. Voor meer informatie, raadpleeg Toepassingen ondervinden geforceerd gesloten TLS-verbindingsfouten bij het verbinden van SQL Servers in Windows.

Als de verbinding na clientHello is gesloten, controleert u of tls 1.0 of TLS 1.2 niet overeenkomt tussen de client en de server. Als ze hetzelfde zijn, controleert u de ingeschakelde coderingssuites en ingeschakelde hashes op beide computers.

Zie Advanced Secure Sockets Layer-gegevens vastleggen voor meer informatie.

Verwijderde pakketten

Bekijk het einde van de overeenkomende gesprekken. Als één pakket veel opnieuw verzonden pakketten (of 10 Keep-Alive-pakketten, 1 seconde apart) heeft gevolgd door een ACK+RESET en de andere niet, of een rapporteert een tijdige reactie en de andere ziet dat het gesprek is vertraagd en het gesprek wordt gesloten of opnieuw wordt ingesteld, betekent dit dat er een probleem is met het netwerkapparaat en pakketten worden verwijderd of vertraagd.

Mogelijk ziet u ook het clientrapport dat aangeeft dat de server het gesprek opnieuw instelt en het serverrapport dat aangeeft dat de client het gesprek opnieuw instelt. Dit is het gevolg van een slechte switch of router die de verbinding van het midden sluit en ze kunnen soms worden geconfigureerd om dit te doen als ze detecteren dat de verbinding enige tijd niet actief is- vaak negeren Keep-Alive-pakketten.

Zie voor meer informatie over verbroken verbindingen:

Zowel de servertracering als de clienttracering komen overeen dat het probleem zich op de client bevindt

Als beide traceringen een vertraging of geen reactie op de client vertonen, of als de client een ACK+RESET uitgeeft nadat een serverantwoord is erkend, of anderszins, sluit de verbinding vroeg tijdens de aanmeldingsreeks, moet u een BID-trace en een NETSH-trace op de client nemen om te kijken binnen de TCP/IP-stack en wat het stuurprogramma denkt. Dit is gebruikelijk als de antivirus- of andere netwerkfilterstuurprogramma's het ontvangen van het pakket vertragen of het verzenden van het antwoord. Verbindingstime-outs kunnen ook worden veroorzaakt door een trage DNS-reactie of trage beveiligings-API die werd aangeroepen voordat het eerste SYN-pakket via de kabel werd verzonden.

Controleer het tijdelijke poortenrapport van SQL Network Analyzer en controleer of de client geen uitgaande poorten heeft.

Als de client een lange vertraging heeft voordat het SYN-pakket wordt verzonden, ziet u mogelijk een patroon met alleen de TCP 3-weg openen handshake, onmiddellijk gevolgd, of soms nadat het PreLogin-pakket is verzonden, door een ACK+FIN die afkomstig is van de client.

Een netwerktracering en BIED-trace verzamelen om clientproblemen in Windows te isoleren

  1. Open het bestand SQLTrace.ini en schakel de volgende instellingen weer in:

    BIDTrace=Yes, AuthTrace=Yes en EventViewer=Yes

  2. Configureer het BIDProviderList in SQLTrace.ini zodat deze overeenkomt met het stuurprogramma dat uw toepassing gebruikt.

    .NET System.Data.SqlClient is standaard ingeschakeld. Als dat niet het stuurprogramma is dat u gebruikt, schakelt u dit uit BIDProviderList door deze toe te voegen # aan de voorzijde van de regel en het te verwijderen uit het begin van de ODBC- of OLEDB-lijst. Hiermee worden alle ondersteunde stuurprogramma's van dat type vastgelegd. Zie INI-configuratie voor meer informatie.

  3. Sla het bestand op.

  4. Open PowerShell als beheerder en wijzig de map in de map met SQLTrace.ps1.

    CD C:\MSDATA

  5. Initialiseer het bid tracing-register als u BID-traceringen verzamelt.

    Notitie

    BID Tracing is standaard ingeschakeld.

    .\SQLTrace.ps1 -setup

  6. Start de service of toepassing die u volgt opnieuw op.

    Voor sommige toepassingen, zoals SSIS-pakketten (SQL Server Integration Services), wordt een nieuw exemplaar van DTEXEC of ISServerExec gestart wanneer het pakket wordt uitgevoerd, zodat opnieuw opstarten niet zinvol is.

  7. Start de traceringsverzameling.

    .\SQLTrace.ps1 -start

  8. Reproduceer het probleem of wacht tot de fout optreedt.

  9. Stop de tracering.

    .\SQLTrace.ps1 -stop

Er wordt een uitvoermap gegenereerd in de huidige map en u kunt deze gebruiken voor verdere analyse.

Raadpleeg de volgende artikelen om andere Microsoft SQL Server-stuurprogramma's te traceren. Voer deze uit met behulp van een netwerktracering.

Raadpleeg de documentatie van de leverancier om stuurprogramma's van derden te traceren.

Zowel de servertracering als de clienttracering komen overeen dat het probleem zich op de server bevindt

Als beide traceringen een vertraging of geen reactie op de server vertonen, of als de server de verbinding op een onverwacht punt in de aanmeldingsreeks sluit, of als de server veel verbindingen tegelijk sluit, betekent dit dat er enkele problemen zijn op de server.

De meest waarschijnlijke oorzaken zijn slechte serverprestaties, hoge MAXDOP en grote parallelle query's en blokkeren. Dit kan leiden tot threadversterking, waardoor een aanmeldingsaanvraag niet onmiddellijk wordt verwerkt, met name als veel time-outs van de verbinding op hetzelfde moment eindigen en de kolom LoginAck 'Laat' wordt weergegeven. In het SQL Server ERRORLOG-bestand kunnen IO-bewerkingen langer dan 15 seconden worden weergegeven. Dit is een andere indicator van prestatieproblemen. In de netwerktracering ziet u mogelijk ook veel gesprekken in het rapport Opnieuw instellen met zes frames of minder, wat aangeeft dat de TCP 3-weg handshake mogelijk niet is voltooid. Zie De connectiviteitsringsbuffer verzamelen voor meer informatie.

Voer de RingBufferConnectivity query uit en plak de resultaten in Excel. Omdat dit een historische lijst is, kan deze worden uitgevoerd nadat het probleem zich voordoet. Maar voor een drukke server kan het snel eindigen. Voor een trage server kan het enkele dagen gegevens bevatten.

Als uw toepassing gebruikmaakt van Multiple Active Result Sets (MARS), eindigt deze met reset als onderdeel van de afsluitvolgorde. Dit is goedaardig als de SMP:FIN- en ACK+FIN-pakketten al vanaf de client zijn verzonden. Het SMP:FIN-pakket van de server arriveert na ACK+FIN van de client en Windows geeft een ACK+RESET uit en vervolgens een RESET voor alle andere serverreacties als onderdeel van de afsluitende reeks verbindingen.

Groepsgewijze verbinding

Zie Groepsgewijze verbindingen voor meer informatie.

Als groepsgewijze verbindingen worden gebruikt, zijn gesprekken in de netwerktracering doorgaans behoorlijk lang. U kunt het CSV-bestand dat is gegenereerd door SQL Server Network Analyzer gebruiken om te sorteren en filteren op protocollen en frames. U ziet waarschijnlijk geen begin- of eindframes als de netwerkopname minder dan een half uur is. Als veel gesprekken korter zijn dan 30 frames van het SYN-pakket naar het ACK+FIN-pakket, duidt dit op niet-gegroepeerde verbindingen. Als deze worden gemengd met een paar langere gesprekken, vermoedt u dat niet-gegroepeerde achtergrondverbindingen worden veroorzaakt door het uitvoeren van opdrachten op een niet-MARS-verbinding tijdens het lezen van een resultatenset.

Het tijdelijke poortrapport toont het aantal nieuwe verbindingen gedurende de levensduur van de tracering. U kunt de verbindingssnelheid beoordelen op basis van het aantal verbindingen per seconde.

RESET versus ACK+RESET

ACK+RESET wordt meestal gezien wanneer de toepassing of Windows een verbinding afbreekt. Dit komt over het algemeen door een TCP-fout op laag niveau. Het pakket informeert de andere computer om het verzenden onmiddellijk te stoppen. Als de server zich echter midden in de verzending bevindt, kunnen een of twee pakketten bij de client aankomen nadat de ACK+RESET is verzonden. Omdat de poort is gesloten, verzendt het besturingssysteem een RESET-pakket. Dit gebeurt ook als pakketten binnenkomen na het ACK+FIN-pakket dat geen deel uitmaakt van de normale afsluitende handshake.

Sommige stuurprogramma's van derden verzenden ook een ACK+RESET-pakket om de verbinding te sluiten in plaats van een ACK+FIN. Sommige testverbindingen kunnen dit ook doen. Als het ACK+RESET-pakket niet wordt voorafgegaan door Keep-Alive-pakketten, Opnieuw verzonden pakketten of Zero Windows-pakketten, en het afkomstig is van de client wanneer een normale sluiting van ACK+FIN wordt verwacht, is het mogelijk goedaardig.

NETSTAT gebruiken om netwerkproblemen te analyseren

NETSTAT wordt automatisch verzameld bij het uitvoeren van SQLTrace.ps1 voor gegevensverzameling.

U kunt ook als beheerder in opdrachtprompt uitvoeren NETSTAT -abon > c:\ports.txt om informatie over netwerkproblemen te verzamelen.

Het bestand ports.txt bevat een lijst met alle binnenkomende en uitgaande poorten, poortnummers, proces-id's en namen van toepassingen die eigenaar zijn van de poorten. U kunt dit gebruiken om de ergste daders te zien en of de poortlimiet is bereikt. Schakel de statusbalk in Kladblok in en schakel Word Wrap uit. De statusbalk geeft een regelaantal. U kunt delen door twee om een geschat poortgebruik te krijgen.

TcpTimedWaitDelay en MaxUserPort aanpassen

Als een toepassing de uitgaande poorten op de hostcomputer uitput en u geen directe wijzigingen aan de toepassing kunt aanbrengen, kunt u van 240 tot 30 seconden verlagen TcpTimedWaitDelay , waardoor uitgaande poorten sneller kunnen worden gerecycled.

Voor windows 2003 en hoger kunt u ook de MaxUserPort. Voor Windows Vista en hoger stelt u dit in via de NETSH opdracht. Deze actie elimineert niet de inefficiënties van niet-poolverbindingen of niet-gegroepeerde achtergrondverbindingen en de ontwikkelaar moet ten zeerste worden aangemoedigd om hun toepassingen te wijzigen voor het gebruik van groepsgewijze verbindingen.

Voor Windows 2008 en hoger is het bereik standaard verhoogd van ongeveer 4.000 tijdelijke poorten tot 16.000 poorten.

Zie De instellingen maxUserPort en TcpTimedWaitDelay aanpassen voor meer informatie.

Bijna alle pakketten die van de client naar de server of de server naar de client worden verzonden, worden beantwoord met een ACK-pakket dat in omgekeerde richting gaat. De TCP.SYS laag genereert de ACK. Als een pakket wordt ontvangen op de client en de clienttracering laat zien dat het binnenkomt, maar er geen ACK wordt geretourneerd naar de server, is dit een goede indicatie dat het antivirusprogramma of een ander netwerkfilterstuurprogramma het pakket heeft verloren of verwijderd of gedurende een lange tijd is vastgehouden (voorbij het einde van de netwerktraceringsverzameling). Als op de servertracering een pakket wordt weergegeven dat afkomstig is van een client, maar er geen ACK naar de client wordt verzonden, geeft dit aan dat de server antivirus op de server mogelijk een probleem heeft.

Wanneer u echter een grote hoeveelheid gegevens uploadt of downloadt, kunnen de ACK-pakketten na een reeks gegevenspakketten komen om te helpen met stroombeheer.

De antivirus- en filterstuurprogramma's zijn erg moeilijk te bewijzen als de schuldige. Een empirische test is bijna altijd vereist. Maak een uitzondering voor de toepassing of SQL Server in de antivirussoftware en bewaak deze gedurende 48 uur om te zien of het gedrag verbetert. Als een uitzondering niet kan worden ingesteld, verwijdert u het antivirusprogramma en start u opnieuw op. Het uitschakelen ervan helpt meestal niet omdat het stuurprogramma voor antivirusfilters nog steeds wordt geladen. Doe dit alleen als laatste redmiddel als uw randbeveiliging aanwezig is.

Neem contact op met uw netwerkbeveiligingsbeheerders. Als de situatie verbetert, moet u mogelijk samenwerken met de antivirusleverancier om het probleem te verhelpen. Als dit niet het probleem is, kunnen andere netwerkfilterstuurprogramma's de schuld zijn.

Windows Firewall-controle inschakelen

Schakel firewallcontrole in Windows in om te bepalen of de firewall pakketten heeft verwijderd.

Voor SQL Server kan dit probleem betrekking hebben op de client of servercomputer. De netwerktracering geeft aan dat de machine een pakket heeft ontvangen, maar niet heeft gereageerd. Het pakket kan vervolgens opnieuw worden verzonden, opnieuw geen antwoord krijgen en uiteindelijk wordt de verbinding opnieuw ingesteld.

Empirische en andere acties

Tijdelijke poorten

Onvoldoende tijdelijke poorten is een relatief veelvoorkomende oorzaak van onregelmatige verbindingstime-outs, vooral als u het SYN-pakket niet op de kabel ziet.

Voor binnenkomende aanvragen op de server kunnen poorten, zoals 80 of 1433, maximaal 64.000 binnenkomende verbindingen per client-IP-adres duren en zijn over het algemeen "onbeperkt" voor alle praktische doeleinden.

Voor uitgaande verbindingen daarentegen is het aantal poorten beperkt en gedeeld tussen alle serververbindingen. Voor Windows Vista, Windows 2008 en hoger is het standaardbereik van poort 49152 tot 65535 (2^16 = 16.384 poorten).

Normaal gesproken worden poorten vier minuten (240 seconden) door het besturingssysteem bewaard voordat ze worden gerecycled en kunnen worden hergebruikt door toepassingen. Dit is om poortvervalsing door schadelijke software of onbedoelde omleiding van een nieuwe verbinding met de vorige houder van die poort te voorkomen. Vanwege deze vertraging kan een clienttoepassing in Windows 2003 slechts 17 verbindingen per seconde maken met SQL Server en wordt het uitgaande poortbereik in minder dan vier minuten uitgeput. Voor Windows Vista neemt dat aantal toe tot 68 verbindingen per seconde.

Voor toepassingen zoals IIS heeft elke HTTP-client mogelijk één uitgaande poort naar SQL Server. Voor een drukke webserver is het uitvoeren van uitgaande poorten een echte mogelijkheid wanneer de belasting hoog is. Een webfarm kan deze situatie beperken.

Maximaal servergeheugen aanpassen (MB)

Als u problemen met betrekking tot weinig kernelgeheugen wilt oplossen, past u het maximale servergeheugen (MB) aan.

Offloading uitschakelen

Voor testdoeleinden kunt u offloading uitschakelen via een beheeropdrachtprompt:

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

Houd deze instellingen niet lang uitgeschakeld, tenzij ze een probleem oplossen. Ze moeten standaard worden ingeschakeld in Windows 2008 en hoger.

Voor andere offloading moet u naar de eigenschappen van de netwerkadapter gaan om ze weer te geven en uit te schakelen.

Problemen met VMware-netwerkbuffer

De ESX-host die de virtuele machine (VM) bevat, heeft een kleine netwerkbuffer die betrouwbaarheidsproblemen kan veroorzaken als er sprake is van een burst in het verkeer. In het volgende VMware-artikel wordt beschreven hoe u de buffergrootte vergroot. Opnieuw opstarten is niet vereist. Deze bewerking moet worden uitgevoerd op de ESX-hostcomputer, niet op de VM.

Groot pakketverlies in het gastbesturingssystemen met behulp van VMXNET3 in ESXi

Probeer bovendien de VM's naar een andere ESX-hostserver te verplaatsen of de client en server naar dezelfde ESX-hostserver te verplaatsen en te zien of het probleem weggaat. Als dit het geval is, is het een probleem met het basisnetwerk.

VMware-momentopnamen

Controleer of er VMware-momentopnamen optreden tijdens de fout en schakel deze uit.

RSS (Receive Side Scaling) uitgeschakeld op de hostcomputer

Wanneer RSS is uitgeschakeld, gebruikt de SQL Server-host slechts één CPU om alle netwerkaanvragen te verwerken. Dit kan een piek veroorzaken in de CPU tot 100% en problemen veroorzaken, zelfs als de niveaus van de andere CPU's (en de totale CPU) laag zijn.

Zie Inleiding tot schalen aan ontvangstzijde en schalen aan de ontvangstzijde versie 2 (RSSv2) voor meer informatie.

Meer informatie

Onregelmatige of periodieke verificatieproblemen in SQL Server

Een netwerktracering verzamelen

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.