Konsistente Probleme mit sql Server-Netzwerkkonnektivität
Notiz
Bevor Sie mit der Problembehandlung beginnen, sollten Sie die Voraussetzungen überprüfen und die Checkliste durchgehen.
Dieser Artikel hilft bei der Problembehandlung von Netzwerkkonnektivitätsfehlern in SQL Server. Diese Fehler sind jedes Mal konsistent und wiederholbar. Sie verweisen auf einige Konfigurationsprobleme, z. B. SQL Server, die tcp nicht aktivieren oder eine Firewall die Verbindung blockieren. Die Problembehandlung konzentriert sich auf Remote-TCP-Verbindungen, da es sich um den gängigsten Verbindungstyp in den meisten Rechenzentren handelt, aber viele der Techniken können auch auf Named Pipes angewendet werden.
Typische Fehlermeldungen
Die häufigsten Fehlermeldungen sind:
-
Kommunikationslinkfehler.
-
Allgemeiner Netzwerkfehler.
-
Der angegebene Netzwerkname ist nicht erreichbar.
-
SQL Server ist nicht vorhanden oder der Zugriff verweigert. (Dies kann auch ein Authentifizierungsfehler sein)
-
Ein netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Stellen Sie sicher, dass der Instanzname richtig und SQL Server so konfiguriert ist, das Remoteverbindungen zulässig sind.
-
Fehler beim Auffinden von Server/Instanz angegeben.
-
Es konnte keine Verbindung mit SQL Server Microsoft SQL Server geöffnet werden, Fehler:53. Der Netzwerkpfad wurde nicht gefunden.“
-
Es konnte keine Verbindung hergestellt werden, da der Zielcomputer sie aktiv abgelehnt hat.
Einschränken des Umfangs des Problems auf einen fokussierten Bereich
Die folgenden Schritte helfen, die Problembehandlung auf einen fokussierten Bereich einzugrenzen:
- Client: Anwendung, Verbindungszeichenfolge, Treiber (fehlende Transport Layer Security (TLS) 1.2), SQL-Alias (64/32-Bit), Hostdatei und falsches DNS-Suffix (Domain Name System) (vollständige Namensverbindungen; Kurzname schlägt fehl).
- SQL Server: Datenbankmodul, aktivierte Protokolle und Firewall.
- Netzwerk: DNS-Alias, Gateway, Router und Firewall.
1. Können Sie eine lokale Verbindung mit SQL Server mit SQL Server Management Studio (SSMS) und TCP herstellen?
Verwenden Sie z. B. die Verbindungszeichenfolge in diesem Format: tcp:<ServerName>.<DomainName>.COM,1433
, ztcp:sqlprod01.contoso.com,1433
. B. .
Notiz
tcp
hinzugefügt, bevor der Servername klein geschrieben werden muss.
Wenn ja, funktioniert SQL Server gut. Das Problem bezieht sich auf Ihre Firewall, Ihr Netzwerk oder Ihren Client.
Wenn nicht, bezieht sich das Problem auf SQL Server Service.
2. Können Sie über Telnet eine Verbindung mit dem SQL Server-Port vom Clientcomputer herstellen?
Der Befehl zum Herstellen einer Telnetverbindung mit der SQL Server-Instanz lautet telnet <ServerName>.<DomainName>.COM 1433
z. B. .
Wenn ja, bezieht sich das Problem auf Treiber/Anbieter, Sicherheit/Secure Sockets Layer (SSL), SQL-Aliase oder Anwendungen.
Andernfalls bezieht sich das Problem auf Die Hostdatei, das Netzwerk oder die Firewall , wenn Schritt 1 funktioniert.
Wenn
telnet
sie nicht als Befehl verfügbar ist, fügen Sie ihn als Windows-Feature hinzu. Dies erfordert keinen Neustart.Neuere Versionen von Windows verfügen über den PowerShell-Befehl "Test-NetConnection ".
Verwenden Sie beispielsweise den Befehl
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
, um die Netzwerkverbindung mit einer SQL Server-Instanz zu testen.
3. Können Sie eine Verbindung mit dem Server mithilfe einer UDL-Datei herstellen, wenn Schritt 2 funktioniert?
Wenn ja, bezieht sich das Problem auf Anwendungen, z. B. eine falsche Verbindungszeichenfolge oder den von der Anwendung verwendeten Anbieter, wenn es sich von dem Anbieter unterscheidet, der in der UDL-Datei (Universal Data Link) verwendet wird.
Wenn nicht, hängt das Problem mit Clients zusammen.
4. Können andere Clients eine Verbindung mit SQL Server herstellen?
Wenn ja, hängt das Problem mit Ihrer Firewall, Ihrem Netzwerk, TLS 1.2 oder Client zusammen.
Andernfalls bezieht sich das Problem auf Ihre Firewall oder Ihren Server.
5. Kann der Client eine Verbindung mit anderen Servern herstellen?
Wenn ja, ist das Problem mit Ihrer Firewall, Ihrem Netzwerk, TLS 1.2 oder Server verbunden.
Andernfalls ist das Problem im Zusammenhang mit Ihrer Firewall, Ihrem Netzwerk oder TLS 1.2.
SQL Server-Dienst
Wenn das Problem mit SQL Server Service verknüpft ist, führen Sie die folgenden Schritte aus:
Überprüfen, ob der Dienstprozess (sqlserver.exe) im Task-Manager ausgeführt wird. (Oder überprüfen Sie über SQL Server-Konfigurations-Manager oder services.msc, wenn mehrere Instanzen installiert sind.)
Wenn sie nicht ausgeführt wird, versuchen Sie, die Instanz zu starten. Wenn es sich um eine gespiegelte oder gruppierte Konfiguration handelt, stellen Sie sicher, dass Sie sich auf dem primären oder aktiven Knoten befinden. Verwenden Sie den Cluster-Manager für Failover oder immer auf Clustern, um sicherzustellen, dass die Ressourcen online sind.
Überprüfen Sie, ob das Anwendungsereignisprotokoll, clusterprotokolle oder die SQL Server ERRORLOG-Datei einen schwerwiegenden Fehler mit Aktionen angibt.
Überprüfen Sie, ob die erwarteten Protokolle in SQL Server-Konfigurations-Manager und der SQL Server ERRORLOG-Datei aktiviert sind (siehe das folgende Beispiel).
Falls nicht, aktivieren Sie sie, und starten Sie SQL Server neu. TCP sollte immer aktiviert werden, wenn Remoteverbindungen zulässig sind.
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].
Umgehen Sie in einer SSMS-, UDL- oder ODBC-Datenquellenadministratorverbindung den SQL Server-Browser, indem Sie den Servernamen im Format angeben:
tcp:<ServerName>.<DomainName>.com,1433
.Notiz
Die Verwendung des vollqualifizierten Domänennamens (Fully Qualified Domain Name, FQDN)
tcp:
und der Portnummer zum Erstellen einer Verbindung ist die zuverlässigste und robusteste Methode.tcp:
muss Kleinbuchstaben sein.Wenn die Verbindung erfolgreich ist:
- Überprüfen, ob der SQL Server-Browser ausgeführt wird. Wenn SQL Server eine Standardinstanz ist, die auf Port 1433 lauscht, muss sie nicht ausgeführt werden. Sie können die Portnummer entfernen und trotzdem funktionieren.
- Wenn das Entfernen des
tcp:
Präfixes dazu führt, dass das Präfix fehlschlägt, stellen Sie möglicherweise standardmäßig eine Verbindung über Named Pipes bereit. Sie können überprüfen, indem Sie den Servernamen verwendennp:hostname\<ServerName>
. - Wenn die Verwendung des NetBIOS-Namens fehlschlägt, verfügen Sie möglicherweise über einen SQL-Alias, der den NetBIOS-Namen oder ein falsches DNS-Suffix in der Netzwerkkonfiguration überschreibt. Überprüfen Sie auch 32-Bit-Aliase.
Wenn SSMS keine Verbindung herstellen kann, versuchen Sie , eine Verbindung mit einer UDL-Datei oder über den ODBC-Datenquellenadministrator herzustellen.
- Versuchen Sie, die IP-Adresse des Servers anstelle des Hostnamens zu verwenden. Sie können sogar versuchen, 127.0.0.1 zu verwenden, wenn der Server nicht gruppiert ist und auf "any" lauscht.
- Probieren Sie verschiedene Treiber aus. Neuere Treiber unterstützen TLS 1.2 und geben bessere Fehlermeldungen.
- Probieren Sie verschiedene Protokolle aus:
tcp:<ServerName>.<DomainName>.com,1433
, ,np:<ServerName>.<DomainName>.com\<InstanceName>
oderlpc:<ServerName>.<DomainName>.com\<InstanceName>
. Verwenden Sie die SQL Server-Konfigurations-Manager, um Änderungen vorzunehmen. Starten Sie dann SQL Server neu, und verwenden Sie die ERORLOG-Datei , um die Änderungen zu bestätigen. - Wurde sql Server (2014 oder früher) aktualisiert, um TLS 1.2 zu unterstützen? Wurde der Client aktualisiert, um TLS 1.2 zu unterstützen? Sind diese Protokolle aktiviert?
- Suchen Sie auf allen Windows-Computern nach einem SQL-Alias in SQL Server-Konfigurations-Manager oder cliconfg.exe. Überprüfen Sie 64-Bit- und 32-Bit-Aliase.
- Überprüfen Sie die ERRORLOG-Datei auf Fehlermeldungen, z. B. auf die Nichtverfügbarkeit der Datenbank oder in der Wiederherstellung.
- Überprüfen Sie die
NETSTAT
Ausgabe, um zu überprüfen, ob SQL Server den erwarteten Port besitzt. Führen SieNETSTAT -abon > c:\temp\ports.txt
z. B. über eine Eingabeaufforderung mit Administratorberechtigungen aus.
Wenn SQL Server einen anderen Port als 1433 verwendet:
Wenn Sie eine Verbindung herstellen können, indem Sie die Portnummer angeben, aber nicht, wenn Sie die Portnummer weglassen, ist dies ein SQL Server-Browserproblem. Dies bedeutet, dass der SQL-Browserdienst nicht in der Lage ist, die richtige Portnummer für die SQL Server-Instanz bereitzustellen, mit der Sie eine Verbindung herstellen möchten. Möglicherweise müssen Sie auch den SQL-Browserdienst neu starten, um seine Informationen zu aktualisieren.
Wenn Sie keine Verbindung herstellen können, auch wenn Sie die Portnummer angeben, und dies geschieht nur, wenn Sie remote eine Verbindung herstellen, handelt es sich um ein Firewallproblem. Überprüfen Sie die Firewalleinstellungen, und stellen Sie sicher, dass der Port für eingehende und ausgehende Verbindungen zulässig ist. Möglicherweise müssen Sie auch eine Firewallregel erstellen, damit die SQL Server-Anwendung oder der Dienst über die Firewall kommunizieren kann.
Wenn Sie Always On verwenden, verwendet die Verbindung mit dem Listener keinen SQL Server-Browser, sodass Sie die Portnummer im Verbindungszeichenfolge angeben müssen. Wenn dies nicht funktioniert, versuchen Sie, eine direkte Verbindung mit dem primären Knoten auf dem regulären SQL-Port herzustellen. Wenn dies funktioniert, bezieht sich das Problem auf den Listener.
Wenn keine der oben genannten Methoden funktioniert, starten Sie den SQL Server-Computer neu.
Im schlimmsten Fall beenden Sie den SQL Server-Dienst, installieren Sie eine neue Instanz, oder erstellen Sie den Computer möglicherweise neu, und verbinden Sie dann die Datenbank erneut oder stellen Sie sie aus der Sicherung wieder her. Wenn Sie die transparente Datenverschlüsselung (TDE) verwenden, z. B. die SSISDB-Datenbank , stellen Sie sicher, dass die Verschlüsselungsschlüssel gespeichert werden, bevor Sie diesen Schritt ausführen. Es wird als Option angeboten, da die Neuerstellung manchmal schneller sein kann als eine Ursachenanalyse von unlösbaren Problemen. Bei gruppierten Installationen kann die Auswirkung geringer sein, da Sie einen Knoten neu erstellen können, während er auf dem alternativen Knoten ausgeführt wird.
Firewall
Im Allgemeinen besteht das Standardverhalten der Firewall darin, die SQL Server- und SQL Server-Browserports zu blockieren. Wenn ja, schlagen Remoteverbindungen fehl, während lokale Verbindungen erfolgreich sind. Testen Sie es mithilfe von Test-NetConnection
. Es ist für alle unterstützten Versionen von Windows verfügbar.
Test-NetConnection <ServerName> -Port 1433
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
Überprüfen Sie, welcher Port SQL Server in der ERRORLOG-Datei überwacht. Möglicherweise müssen Sie es aktivieren telnet
, indem Sie es als Windows-Feature hinzufügen. Dies erfordert keinen Neustart. SQL Server muss auch auf TCP lauschen. PortQry
kann von der Microsoft-Downloadwebsite heruntergeladen werden. Stellen Sie bei Verwendung des SQL Server-Browsers sicher, dass der UDP-Port 1434 in der Firewall und im SQL Server-TCP-Port geöffnet ist.
Network
Der Client- oder Anwendungsserver kann eine Verbindung mit SQL Server auf einem anderen Computer herstellen. Möglicherweise haben mehrere Clients in einem bestimmten Netzwerk oder Subnetz Probleme beim Herstellen einer Verbindung mit einem Server außerhalb des Subnetzes oder in einem anderen bestimmten Subnetz. Eine Netzwerkfirewall kann verhindern, dass ein bestimmter Client eine Verbindung mit einem bestimmten SQL Server herstellt. Beispielsweise kann der Client eine Verbindung mit anderen SQL-Servern herstellen, und andere Clients können eine Verbindung mit dem Problem MIT SQL Server herstellen.
VPN
Wenn das Problem nur in einem virtuellen privaten Netzwerk (VPN) auftritt und nicht, wenn der Laptop ins Haus gebracht wird, muss der VPN-Anbieter das Problem beheben. Sie können eine Client- und Servernetzwerkablaufverfolgung abrufen, die dazu beitragen kann, die Art der Probleme anzuzeigen, die das VPN verursacht. Verworfene Pakete sind z. B. die wahrscheinlichsten. Das VPN kann auch das interne Routing zwischen Client und Server ändern und es einem anderen Netzwerkgerät verfügbar machen, das die Verbindung blockiert. Durch das Sammeln von Netzwerkablaufverfolgungen auf Zwischengeräten können Sie das Problem isolieren, indem sie das Netzwerk unterteilen. Der Tracert-Befehl kann das Routing anzeigen.
Client
Wenn das Problem mit Clients verbunden ist, werden möglicherweise die folgenden Indikatoren angezeigt:
Andere Clients können normal eine Verbindung mit dem Server herstellen.
Keine Anwendungen können von diesem Computer aus eine Verbindung herstellen.
Sie können keine Verbindung mit einem UDL - oder ODBC-Datenquellenadministrator herstellen.
Dies kann durch eine ausgehende Firewallregel oder falsche Standard-DNS-Suffixe verursacht werden. Testen Sie den vollqualifizierten Servernamen, z. B.:
Test-NetConnection <ServerName> -Port 1433 Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
Dies kann ein TLS-Problem sein. Beispielsweise verwendet der Server TLS 1.2, und die Clienttreiber wurden dafür nicht aktualisiert.
Möglicherweise gibt es einen Hostdateieintrag, einen SQL-Alias oder einen DNS-Alias, der die Verbindung zu einem anderen Server leitet. Verwenden Sie Ping und
telnet
. Wenn sie funktionieren, aber der Treiber fehlschlägt, vermuten Sie, dass ein SQL-Alias oder TLS-Problem auftritt.
Treiber
Wenn das Problem mit Treibern zusammenhängt, probieren Sie unterschiedliche Treiber aus.
Wenn einige Treiber funktionieren und andere fehlschlagen, vermuten Sie ein TLS-Problem. Laden Sie den neuesten Treiber herunter, z. B. Microsoft OLE DB-Treiber für SQL Server oder ODBC-Treiber 17 für SQL Server, und probieren Sie es aus.
Stellen Sie bei Verwendung von .NET sicher, dass Sie die neueste Version des Frameworks verwenden. Wenn sie immer noch fehlschlägt, sollte eine bessere Fehlermeldung angezeigt werden. Sie können auch die neueste Version von SQL Server Management Studio herunterladen, die unabhängig von SQL Server ist, und sie auf jedem Client installieren. Dies verwendet die
SqlClient .NET
Klasse.
Benutzer
Wenn das Problem mit Benutzern zusammenhängt, melden Sie sich bei diesem Computer an einem anderen Benutzer an.
Wenn die Verbindung erfolgreich ist, sehen Sie, was bei dem fehlerhaften Benutzer anders ist. Beispielsweise ist das Windows-Benutzerprofil beschädigt, oder vielleicht gehören die Benutzer zu einer anderen Organisationseinheit (OE) oder Domäne.
Wenn Benutzer aus mehreren Domänen vorhanden sind, versuchen Sie, einen Benutzer aus derselben Domäne wie der Server zu verwenden. In der Regel führen Benutzerprobleme zu Authentifizierungsfehlern und weisen einen anderen Workflow zur Problembehandlung auf.
Wenn es sich nicht um ein Authentifizierungsproblem handelt, kann ein Prozessüberwachungsprotokoll dazu beitragen, lokale Berechtigungsprobleme zu identifizieren, die sich auf die Konnektivität auswirken. Beispielsweise verfügt der Benutzer über einen Datenquellennamen (Data Source Name, DSN) oder eine Art Von Registrierungsumleitung an einen anderen Treiber, eine lokale Berechtigungseinschränkung oder etwas, das den Verbindungsfehler erklären kann.
Application
Wenn nur eine bestimmte Anwendung fehlschlägt und eine UDL-Datei erfolgreich ist, kann es sich um ein Treiberproblem handeln, oder die Anwendung hat eine falsche Verbindungszeichenfolge. Lassen Sie das Anwendungsentwicklungsteam oder den Drittanbieter die Verbindungszeichenfolge überprüfen. Sie können den Prozess-Explorer www.sysinternals.com
verwenden, um festzustellen, welcher Treiber verwendet wird, wenn der Kunde nicht sicher ist.
Zu erfassende Ablaufverfolgungstools
Erfassen Sie eine Client- und Servernetzwerkablaufverfolgung. Führen Sie die SQL-Ablaufverfolgung sowohl auf dem Client als auch auf dem Server gleichzeitig aus.
Installieren Sie WireShark mit dem NCAP-Treiber, um nachzuverfolgen, wann sich der Client und der Server auf demselben Computer befinden.
Ihre Organisation verfügt möglicherweise über ein eigenes Netzwerkinfrastrukturteam, mit dem Sie interagieren können, und möglicherweise über ein bevorzugtes Ablaufverfolgungstool zum Ausführen der Erfassung verfügen. Sie können jedes Tool verwenden, solange es in einem Format gespeichert wird, das mit Network Monitor (NetMon.exe) oder WireShark kompatibel ist. DAS PCAP-Format ist das beliebteste.
Führen Sie sql Network Analyzer (SQLNA) und die SQL Network Analyzer UI (SQLNAUI) anhand der Netzwerkablaufverfolgung aus, um einen einfach zu lesenden Bericht zu erhalten.
Weitere Informationen
Informationen zum Haftungsausschluss von Drittanbietern
Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.