Konsekventa problem med SQL Server-nätverksanslutning

Artikel
12/14/2024

Kommentar

Innan du börjar felsöka rekommenderar vi att du kontrollerar förutsättningarna och går igenom checklistan.

Den här artikeln hjälper dig att felsöka nätverksanslutningsfel i SQL Server. Dessa fel är konsekventa och repeterbara varje gång. De pekar på vissa konfigurationsproblem, till exempel att SQL Server inte aktiverar TCP eller en brandvägg som blockerar anslutningen. Felsökningen fokuserar på fjärranslutna TCP-anslutningar eftersom det är den vanligaste anslutningstypen i de flesta datacenter, men många av teknikerna kan också tillämpas på namngivna pipes.

Vanliga felmeddelanden

De vanligaste felmeddelandena är:

Kommunikationslänkfel.
Allmänt nätverksfel.
Det angivna nätverksnamnet kan inte nås.
SQL Server finns inte eller åtkomst nekas. (Detta kan också vara ett autentiseringsfel)
Ett nätverksrelaterat eller instansspecifikt fel uppstod när en anslutning upprättades till SQL Server. Servern hittades inte eller var inte tillgänglig. Verifiera att instansnamnet är korrekt och att SQL Server är konfigurerat att tillåta fjärranslutningar.
Det gick inte att hitta den angivna servern/instansen.
Det gick inte att öppna en anslutning till SQL Server Microsoft SQL Server, Error:53. Det gick inte att hitta nätverkssökvägen.
Det gick inte att upprätta någon anslutning eftersom måldatorn aktivt nekade den.

Begränsa problemets omfattning till ett fokuserat område

Följande steg hjälper till att begränsa felsökningen till ett fokuserat område:

Klient: program, anslutningssträng, drivrutin (saknar TLS(Transport Layer Security) 1.2), SQL-alias (64/32-bitars), värdfil och felaktigt DNS-suffix (domännamnssystem) (fullständigt namn ansluter; kort namn misslyckas).
SQL Server: databasmotor, aktiverade protokoll och brandvägg.
Nätverk: DNS-alias, gateway, router och brandvägg.

1. Kan du ansluta till SQL Server lokalt med SQL Server Management Studio (SSMS) och TCP?

Använd till exempel anslutningssträng i det här formatet: tcp:<ServerName>.<DomainName>.COM,1433, till exempel tcp:sqlprod01.contoso.com,1433.

Kommentar

tcp innan servernamnet måste vara gemener.

Om ja, fungerar SQL Server bra. Problemet gäller brandväggen, nätverket eller klienten.

Om inte är problemet relaterat till SQL Server Service.

2. Kan du ansluta till SQL Server-porten från klientdatorn med telnet?

Kommandot för att upprätta en telnet-anslutning till SQL Server-instansen är telnet <ServerName>.<DomainName>.COM 1433till exempel .

Om ja är problemet relaterat till drivrutiner/providers, säkerhet/SSL (Secure Sockets Layer), SQL-alias eller program.

Annars är problemet relaterat till din värdfil, ditt nätverk eller din brandvägg när steg 1 fungerar.

Om telnet inte är tillgängligt som ett kommando lägger du till det som en Windows-funktion. Detta kräver ingen omstart.
Nyare versioner av Windows har PowerShell-kommandot Test-NetConnection .

Använd till exempel kommandot Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 för att testa nätverksanslutningen till en SQL Server-instans.

3. Kan du ansluta till servern med en UDL-fil om steg 2 fungerar?

Om ja är problemet relaterat till program, till exempel en felaktig anslutningssträng, eller providern som används av programmet om den skiljer sig från providern som används i UDL-filen (Universal Data Link).

Annars är problemet relaterat till klienter.

4. Kan andra klienter ansluta till SQL Server?

Om ja är problemet relaterat till brandväggen, nätverket, TLS 1.2 eller klienten.

Annars är problemet relaterat till brandväggen eller servern.

5. Kan klienten ansluta till andra servrar?

Om ja är problemet relaterat till brandväggen, nätverket, TLS 1.2 eller servern.

Annars är problemet relaterat till brandväggen, nätverket eller TLS 1.2.

SQL Server-tjänst

Om problemet är relaterat till SQL Server Service följer du dessa steg:

Verifiera att tjänstprocessen (sqlserver.exe) körs i Aktivitetshanteraren. (Eller kontrollera via Konfigurationshanteraren för SQL Server eller services.msc om du har flera instanser installerade.)

Om den inte körs kan du prova att starta instansen. Om det är en speglad eller klustrad konfiguration kontrollerar du att du är på den primära eller aktiva noden. Använd klusterhanteraren för redundans eller alltid i kluster för att kontrollera att resurserna är online.
Kontrollera om programhändelseloggen, klusterloggarna eller SQL Server ERRORLOG-filen indikerar ett åtgärdsbart allvarligt fel.

Verifiera att de förväntade protokollen är aktiverade i Konfigurationshanteraren för SQL Server och SQL Server ERRORLOG-filen (se följande exempel).

Annars aktiverar du dem och startar om SQL Server. TCP bör alltid aktiveras om fjärranslutningar tillåts.

2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv6> 1433].
2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv4> 1433].
2013-11-20 09:42:03.94 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\KJ].
2013-11-20 09:42:03.94 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$KJ\sql\query].

I en anslutning med SSMS, UDL eller ODBC Data Source Administrator kringgår du SQL Server Browser genom att ange servernamnet i formatet : tcp:<ServerName>.<DomainName>.com,1433.

Kommentar

Att använda det fullständigt kvalificerade domännamnet (FQDN), tcp:och portnumret för att skapa en anslutning är den mest tillförlitliga och motståndskraftiga metoden. tcp: måste vara gemener.
- Om anslutningen lyckas:
  - Verifiera att SQL Server Browser körs. Om SQL Server är en standardinstans som lyssnar på port 1433 behöver den inte köras. Du kan ta bort portnumret och låta det fortfarande fungera.
  - Om du tar bort prefixet tcp: misslyckas kan du ansluta via namngivna pipes som standard. Du kan verifiera med hjälp np:hostname\<ServerName> av som servernamn.
  - Om det inte går att använda NetBIOS-namnet kan du ha ett SQL-alias som åsidosätter NetBIOS-namnet eller ett felaktigt DNS-suffix i nätverkskonfigurationen. Kontrollera även 32-bitars alias.
- Om SSMS inte kan ansluta kan du prova att ansluta med en UDL-fil eller via ODBC-datakälladministratören.
  - Prova att använda IP-adressen för servern i stället för värdnamnet. Du kan till och med prova att använda 127.0.0.1 om servern inte är klustrad och lyssnar på "någon".
  - Prova olika drivrutiner. Nyare drivrutiner stöder TLS 1.2 och ger bättre felmeddelanden.
  - Prova olika protokoll: tcp:<ServerName>.<DomainName>.com,1433, np:<ServerName>.<DomainName>.com\<InstanceName>eller lpc:<ServerName>.<DomainName>.com\<InstanceName>. Använd Konfigurationshanteraren för SQL Server för att göra ändringar. Starta sedan om SQL Server och använd ERORLOG-filen för att bekräfta ändringarna.
  - Har SQL Server (2014 eller tidigare) uppgraderats för att stödja TLS 1.2? Har klienten uppgraderats för att stödja TLS 1.2? Är dessa protokoll aktiverade?
  - Sök efter ett SQL-alias i Konfigurationshanteraren för SQL Server eller cliconfg.exe på alla Windows-datorer. Kontrollera 64-bitars och 32-bitars alias.
  - Kontrollera ERRORLOG-filen efter felmeddelanden, till exempel att databasen inte är tillgänglig eller håller på att återställas.
  - Kontrollera utdata för NETSTAT att kontrollera om SQL Server äger den förväntade porten. Kör till exempel NETSTAT -abon > c:\temp\ports.txt från en kommandotolk med administratörsbehörighet.
- Om SQL Server använder en annan port än 1433:
  - Om du kan ansluta genom att ange portnumret, men inte när du utelämnar portnumret, är detta ett SQL Server Browser-problem. Det innebär att SQL Browser-tjänsten inte kan ange rätt portnummer för den SQL Server-instans som du vill ansluta till. Du kan också behöva starta om SQL Browser-tjänsten för att uppdatera informationen.
  - Om du inte kan ansluta även när du anger portnumret, och detta bara händer när du ansluter via fjärranslutning, är det ett brandväggsproblem. Du bör kontrollera brandväggsinställningarna och se till att porten är tillåten för inkommande och utgående anslutningar. Du kan också behöva skapa en brandväggsregel så att SQL Server-programmet eller tjänsten kan kommunicera via brandväggen.
  - Om du använder Always On använder inte anslutning till lyssnaren SQL Server Browser, så du måste ange portnumret i anslutningssträng. Om det inte fungerar kan du prova att ansluta direkt till den primära noden på den vanliga SQL-porten. Om det fungerar är problemet relaterat till lyssnaren.

Om ingen av ovanstående metoder fungerar startar du om SQL Server-datorn.

Det värsta scenariot är att stoppa SQL Server-tjänsten, installera en ny instans eller eventuellt återskapa datorn och sedan återansluta databasen eller återställa från säkerhetskopian. Om du använder transparent datakryptering (TDE), till exempel SSISDB-databasen , kontrollerar du att krypteringsnycklarna sparas innan du gör det här steget. Det erbjuds som ett alternativ eftersom återskapande ibland kan vara snabbare än en rotorsaksanalys av svårlösta problem. För klustrade installationer kan effekten bli mindre eftersom du kan återskapa en nod medan den körs på den alternativa noden.

Brandvägg

I allmänhet är brandväggens standardbeteende att blockera SQL Server- och SQL Server Browser-portarna. I så fall misslyckas fjärranslutningar, medan lokala anslutningar lyckas. Testa det med hjälp Test-NetConnectionav . Den är tillgänglig i alla versioner av Windows som stöds.

Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433

Kontrollera vilken port SQL Server lyssnar på i ERRORLOG-filen . Du kan behöva aktivera telnet genom att lägga till den som en Windows-funktion. Detta kräver ingen omstart. SQL Server måste också lyssna på TCP. PortQry kan laddas ned från Microsofts nedladdningswebbplats. Om du använder SQL Server Browser kontrollerar du att UDP-port 1434 är öppen i brandväggen och SQL Server TCP-porten.

Nätverk

Klienten eller programservern kan ansluta till SQL Server på en annan dator. Kanske har flera klienter i ett visst nätverk eller undernät problem med att ansluta till en server utanför undernätet eller i ett annat specifikt undernät. En nätverksbrandvägg kan blockera en specifik klient från att ansluta till en specifik SQL Server. Klienten kan till exempel ansluta till andra SQL-servrar och andra klienter kan ansluta till problemet med SQL Server.

VPN

Om problemet bara inträffar på ett virtuellt privat nätverk (VPN) och inte när den bärbara datorn tas in internt måste VPN-leverantören lösa problemet. Du kan hämta en klient- och servernätverksspårning, vilket kan hjälpa dig att visa vilken typ av problem VPN orsakar. Till exempel är borttagna paket de mest sannolika. VPN kan också ändra den interna routningen mellan klienten och servern och exponera den för en annan nätverksenhet som blockerar anslutningen. Genom att samla in nätverksspårningar på mellanliggande enheter kan du isolera problemet genom att dela upp nätverket. Spårningskommandot kan avslöja routningen.

Klient

Om problemet är relaterat till klienter kan du se följande indikatorer:

Andra klienter kan ansluta till servern normalt.
Inga program kan ansluta från den här datorn.
Du kan inte ansluta med hjälp av en UDL - eller ODBC-datakällsadministratör.

Detta kan bero på en utgående brandväggsregel eller felaktiga STANDARD-DNS-suffix. Prova att testa med det fullständigt kvalificerade servernamnet, till exempel:
```
Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
```
Detta kan vara ett TLS-problem. Servern använder t.ex. TLS 1.2 och klientdrivrutinerna har inte uppgraderats för den.

Det kan finnas en värdfilpost, ett SQL-alias eller ett DNS-alias som dirigerar anslutningen till en annan server. Använd ping och telnet. Om de fungerar, men drivrutinen misslyckas, misstänker du ett SQL-alias eller TLS-problem.

Drivrutinen

Om problemet gäller drivrutiner kan du prova olika drivrutiner.

Om vissa drivrutiner fungerar och andra misslyckas misstänker du ett TLS-problem. Ladda ned den senaste drivrutinen, till exempel Microsoft OLE DB-drivrutin för SQL Server eller ODBC Driver 17 för SQL Server, och prova det.
Om du använder .NET kontrollerar du att du använder den senaste versionen av ramverket. Om det fortfarande misslyckas bör det ge ett bättre felmeddelande. Du kan också ladda ned den senaste versionen av SQL Server Management Studio som är oberoende av SQL Server och installera den på valfri klient. Då används SqlClient .NET klassen .

User

Om problemet är relaterat till användare måste du ha en annan användare som loggar in på den här datorn.

Om anslutningen lyckas kan du se vad som är annorlunda med den misslyckade användaren. Till exempel är Windows-användarprofilen skadad, eller kanske tillhör användarna en annan organisationsenhet (OU) eller domän.
Om det finns användare från flera domäner kan du prova att använda en användare från samma domän som servern. Vanligtvis resulterar användarproblem i autentiseringsfel och har ett annat arbetsflöde för felsökning.
Om det inte är ett autentiseringsproblem kan en Process Monitor-logg hjälpa dig att identifiera lokala behörighetsproblem som påverkar anslutningen. Användaren har till exempel ett namn på datakällan (DSN) eller någon form av registeromdirigering till en annan drivrutin, en lokal behörighetsbegränsning eller något som kan förklara anslutningsfelet.

Program

Om bara ett visst program misslyckas och en UDL-fil lyckas kan det vara ett drivrutinsfel eller så har programmet en felaktig anslutningssträng. Låt programutvecklingsteamet eller tredjepartsleverantören kontrollera anslutningssträng. Du kan använda Process Explorer från www.sysinternals.com för att se vilken drivrutin som används om kunden är osäker.

Spårningsverktyg som ska avbildas

Samla in en klient- och servernätverksspårning. Kör SQL-spårning på både klienten och servern samtidigt.

Installera WireShark med NCAP-drivrutinen för att spåra när klienten och servern finns på samma dator.

Din organisation kan ha ett eget nätverksinfrastrukturteam som du kan interagera med och kan ha ett föredraget spårningsverktyg för att utföra avbildningen. De kan använda valfritt verktyg så länge det sparas i ett format som är kompatibelt med Network Monitor (NetMon.exe) eller WireShark. PCAP-format är det mest populära.

Kör SQL Network Analyzer (SQLNA) och SQL Network Analyzer UI (SQLNAUI) mot nätverksspårningen för att få en lättläst rapport.

Mer information

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.

Dela via