Freigeben über

Netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server

  • Artikel

Gilt für: SQL Server

Beim Herstellen einer Verbindung mit einem SQL Server instance kann eine oder mehrere der folgenden Fehlermeldungen auftreten. Dieser Artikel enthält einige Schritte, mit denen Sie diese Fehler beheben können, die in der Reihenfolge der Probleme von einfach bis komplex bereitgestellt werden.

Fehlermeldungen

Die vollständigen Fehlermeldungen variieren je nach Clientbibliothek, die in der Anwendung und in der Serverumgebung verwendet wird. Sie können die folgenden Details überprüfen, um festzustellen, ob eine der folgenden Fehlermeldungen auftritt:

Anbieter: Named Pipes-Anbieter, Fehler: 40 – Verbindung mit SQL Server konnte nicht geöffnet werden (Microsoft SQL Server, Fehler: 53) Ein netzwerkbezogener oder instanzspezifischer Fehler ist beim Herstellen einer Verbindung mit SQL Server aufgetreten. Der Server wurde nicht gefunden oder war nicht zugänglich. Stellen Sie sicher, dass der Instanzname korrekt ist und dass SQL Server so konfiguriert ist, dass Remoteverbindungen zugelassen werden.
Anbieter: Named Pipes-Anbieter, Fehler: 40 – Verbindung mit SQL Server konnte nicht geöffnet werden (Microsoft SQL Server, Fehler: 53)
Anbieter: TCP-Anbieter, Fehler: 0 – Kein solcher Host ist bekannt. (Microsoft SQL Server, Fehler: 11001)

Anbieter: SQL Network Interfaces, Fehler: 26 – Fehler beim Auffinden des angegebenen Servers/der angegebenen Instanz Ein netzwerkbezogener oder instanzspezifischer Fehler ist beim Herstellen einer Verbindung mit SQL Server aufgetreten. Der Server wurde nicht gefunden oder war nicht zugänglich. Stellen Sie sicher, dass der Instanzname korrekt ist und dass SQL Server so konfiguriert ist, dass Remoteverbindungen zugelassen werden.
Anbieter: SQL Network Interfaces, Fehler: 26 – Fehler beim Auffinden des angegebenen Servers/der angegebenen Instanz

Anmeldetimeout abgelaufen SQL Server Native Client-Datenverknüpfungsfehler
[Microsoft SQL Server Native Client 10.0]: Anmeldetimeout abgelaufen.
[Microsoft SQL Server Native Client 10.0]: Beim Herstellen einer Verbindung zu SQL Server ist ein netzwerk- oder instanzspezifischer Fehler aufgetreten. Der Server wurde nicht gefunden oder ist nicht erreichbar. Überprüfen Sie, ob der Instanzname korrekt ist und ob SQL Server so konfiguriert ist, dass Remoteverbindungen zugelassen werden. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation.
[Microsoft SQL Server Native Client 10.0]: SQL Server-Netzwerkschnittstellen: Fehler beim Auffinden des angegebenen Servers/der angegebenen Instanz [xFFFFFFFF].

              
              
                             Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht ordnungsgemäß reagiert hat, oder die hergestellte Verbindung ist gescheitert, da der verbundene Host nicht reagiert hat. Ein netzwerkbezogener oder instanzspezifischer Fehler ist beim Herstellen einer Verbindung mit SQL Server aufgetreten. Der Server wurde nicht gefunden oder war nicht zugänglich. Stellen Sie sicher, dass der Instanzname korrekt ist und dass SQL Server so konfiguriert ist, dass Remoteverbindungen zugelassen werden.
Anbieter: TCP-Anbieter, Fehler: 0
Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht ordnungsgemäß reagiert hat, oder die hergestellte Verbindung konnte nicht aufrechterhalten werden, da der verbundene Host nicht reagiert hat.
Microsoft SQL Server, Fehler: 10060

              
              
                             Anbieter: Named Pipes-Anbieter, Fehler: 40 – Es konnte keine Verbindung zu SQL Server geöffnet werden Ein netzwerkbezogener oder instanzspezifischer Fehler ist beim Herstellen einer Verbindung mit SQL Server aufgetreten. Der Server wurde nicht gefunden oder war nicht zugänglich. Stellen Sie sicher, dass der Instanzname korrekt ist und dass SQL Server so konfiguriert ist, dass Remoteverbindungen zugelassen werden.
Anbieter: Named Pipes-Anbieter, Fehler: 40 – Es konnte keine Verbindung zu SQL Server geöffnet werden
Microsoft SQL Server, Fehler: 53
Der Netzwerkpfad wurde nicht gefunden

              
              
                             [Microsoft] [SQL Server Native Client 11.0]TCP-Anbieter: Es konnte keine Verbindung hergestellt werden, weil der Zielcomputer sie aktiv abgelehnt hat SQL Server Native Client-Datenverknüpfungsfehler
[Microsoft] [SQL Server Native Client 11.0]TCP-Anbieter: Es konnte keine Verbindung hergestellt werden, weil der Zielcomputer sie aktiv abgelehnt hat.
[Microsoft][SQL Server Native Client 11.0]Anmeldetimeout abgelaufen.
[Microsoft][SQL Server Native Client 11.0]Beim Herstellen einer Verbindung zu SQL Server ist ein netzwerk- oder instanzspezifischer Fehler aufgetreten. Der Server wurde nicht gefunden oder ist nicht erreichbar. Überprüfen Sie, ob der Instanzname korrekt ist und ob SQL Server so konfiguriert ist, dass Remoteverbindungen zugelassen werden. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation.

„SQL Server ist nicht vorhanden oder Zugriff verweigert“

Dieser Fehler bedeutet in der Regel, dass der Client die SQL Server-Instanz nicht finden kann. Dieses Problem tritt auf, wenn eines oder mehrere der folgenden Probleme vorhanden sind:

  • Der Name des Computers, auf dem SQL Server gehostet wird, ist falsch.
  • Die Instanz löst nicht die richtige IP auf.
  • Die TCP-Portnummer ist nicht richtig angegeben.

Hinweis

Informationen zur Behandlung von Verbindungsproblemen in Szenarien mit hoher Verfügbarkeit finden Sie in den folgenden Artikeln:

Windows-Fehler 233: Kein Prozess befindet sich am anderen Ende der Pipe

Die vollständige Meldung lautet:

Eine Verbindung mit dem Server wurde erfolgreich hergestellt, aber dann ist während des Anmeldevorgangs ein Fehler aufgetreten. (Anbieter: Shared Memory Provider, Fehler: 0 – Kein Prozess befindet sich am anderen Ende der Pipe.) (Microsoft SQL Server, Fehler: 233)

Diese Meldung bedeutet, dass SQL Server nicht auf dem Shared Memory- oder Named Pipes-Protokoll lauscht.

Sammeln von Informationen zur Problembehandlung des Fehlers

Es wird empfohlen, die in diesem Abschnitt aufgeführten Informationen mithilfe einer der folgenden Optionen zu sammeln, bevor Sie mit den eigentlichen Schritten zur Problembehandlung des Fehlers fortfahren.

Option 1: Verwenden des SQL-Überprüfungstools zum Sammeln der erforderlichen Informationen

Wenn Sie sich lokal am SQL Server Computer anmelden können und Administratorzugriff haben, verwenden Sie SQLCHECK. Dieses Tool enthält die meisten Informationen, die für die Problembehandlung erforderlich sind, in einer einzigen Datei. Weitere Informationen zur Verwendung des Tools und der gesammelten Informationen finden Sie auf der Startseite des Tools. Sie können auch die Seite mit den empfohlenen Voraussetzungen und Prüflisten konsultieren.

Option 2: Sammeln der Daten einzeln mithilfe der folgenden Verfahren

Abrufen des Instanznamens aus Configuration Manager

Verwenden Sie auf dem Server, auf dem die SQL Server-Instanz gehostet wird, den SQL Server-Konfigurations-Manager, um den Instanznamen zu überprüfen:

Hinweis

Der Konfigurations-Manager wird automatisch auf dem Computer installiert, wenn SQL Server installiert wird. Die Anweisungen zum Starten des Konfigurations-Managers variieren geringfügig je nach Versionen von SQL Server und Windows. Versionsspezifische Details finden Sie unter SQL Server-Konfigurations-Manager.

  1. Melden Sie sich bei dem Computer an, auf dem die Instanz von SQL Server gehostet wird.

  2. Starten Sie den SQL Server-Konfigurations-Manager.

  3. Klicken Sie im linken Bereich auf SQL Server-Dienste.

  4. Überprüfen Sie im rechten Bereich den Namen der Instanz des Datenbankmoduls.

    • SQL SERVER (MSSQLSERVER) gibt eine Standardinstanz von SQL Server an. Der Name der Standardinstanz lautet <Computername>.
    •               SQL SERVER (<instance name>) gibt eine benannte Instanz von SQL Server an. Der Name der benannten Instanz lautet <Computername><Instanzname>.

Bestimmen der IP-Adresse des Servers

Mit den folgenden Schritten können Sie die IP-Adresse des Computers abrufen, auf dem die Instanz von SQL Server gehostet wird.

  1. Klicken Sie im Menü Datei auf Ausführen. Geben Sie in das Feld Ausführen die Zeichenfolge cmd ein, und klicken Sie dann auf OK.

  2. Geben Sie im Eingabeaufforderungsfenster die Zeichenfolge ipconfig/all ein, und drücken Sie dann die Eingabetaste. Notieren Sie sich die IPv4-Adresse und die IPv6-Adresse.

    Hinweis

    SQL Server kann eine Verbindung mithilfe des IP-Protokolls der Version 4 oder des IP-Protokolls der Version 6 herstellen. Ihr Netzwerk kann eines oder beide zulassen.

Abrufen des TCP-Ports der Instanz

In den meisten Fällen stellen Sie eine Verbindung mit dem Datenbankmodul auf einem anderen Computer mithilfe des TCP-Protokolls her. Um den TCP-Port der Instanz zu ermitteln, gehen Sie wie folgt vor:

  1. Verwenden Sie SQL Server Management Studio auf dem Computer, auf dem SQL Server ausgeführt wird, und stellen Sie eine Verbindung mit der Instanz von SQL Server her. Erweitern Sie im Objekt-Explorer den Eintrag Verwaltung, erweitern Sie den Eintrag SQL-Server-Protokolle, und doppelklicken Sie dann auf das aktuelle Protokoll.

  2. Wählen Sie in der Protokolldateianzeige auf der Symbolleiste Filtern aus. Geben Sie in das Feld Meldung enthält Text den Text Server lauscht an ein, wählen Sie Filter anwenden, und klicken Sie dann auf OK.

  3. Eine Meldung wie "Server lauscht an [ 'any' <ipv4> 1433]" sollte aufgelistet werden.

    Diese Meldung gibt an, dass die Instanz von SQL Server alle IP-Adressen auf diesem Computer (für IP-Version 4) und TCP-Port 1433 überwacht. (TCP-Port 1433 ist normalerweise der Port, der von der Datenbank-Engine oder der Standardinstanz von SQL Server verwendet wird. Nur eine Instanz von SQL Server kann diesen Port verwenden. Wenn mehr als eine Instanz von SQL Server installiert ist, müssen einige Instanzen andere Portnummern verwenden). Notieren Sie sich die Portnummer, die von der SQL Server-Instanz verwendet wird, mit der Sie sich verbinden wollen.

    Hinweis

    • Die IP-Adresse 127.0.0.1 ist wahrscheinlich aufgeführt. Sie wird als Loopbackadapteradresse bezeichnet. Nur Prozesse auf demselben Computer können zum Herstellen einer Verbindung die IP-Adresse verwenden.
    • Sie können das SQL Server-Fehlerprotokoll auch mithilfe eines Text-Editors anzeigen. Das Fehlerprotokoll befindet sich standardmäßig in den Dateien Programme\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG und ERRORLOG.n. Weitere Informationen finden Sie unter Anzeigen des SQL Server-Fehlerprotokolls.

Schritt 1: Überprüfen, ob die Instanz ausgeführt wird

Option 1: Verwenden der SQLCHECK-Ausgabedatei

  1. Search die SQLCHECK-Ausgabedatei für "SQL Server Information" aus.
  2. Suchen Sie im Abschnitt „Dienste von Interesse“ Ihre SQL Server-Instanz in den Spalten Name und Instanz (für benannte Instanzen), und überprüfen Sie ihren Status anhand der Spalte Gestartet. Wenn der Wert True ist, sind die Dienste gestartet. Andernfalls wird der Dienst derzeit nicht ausgeführt.
  3. Wenn der Dienst nicht ausgeführt wird, starten Sie den Dienst mithilfe von SQL Server Management Studio, des SQL Server-Konfigurations-Managers, der PowerShell oder des Services-Applets.

Option 2: Verwenden des SQL Server-Konfigurations-Managers

Um zu überprüfen, ob die Instanz ausgeführt wird, wählen Sie SQL Server-Dienste im SQL Server-Konfigurations-Manager aus, und überprüfen Sie das Symbol neben der SQL Server-Instanz.

  • Ein grüner Pfeil zeigt an, dass eine Instanz ausgeführt wird.
  • Ein rotes Quadrat gibt an, dass eine Instanz gestoppt ist.

Wenn die Instanz gestoppt ist, klicken Sie mit der rechten Maustaste auf die Instanz, und wählen Sie Starten aus. Dann wird die Serverinstanz gestartet, und der Indikator wird zu einem grünen Pfeil.

Option 3: Verwenden von PowerShell-Befehlen

Sie können in PowerShell den folgenden Befehl verwenden, um den Status von SQL Server-Diensten im System zu überprüfen:

Get-Service | Where {$_.status -eq 'running' -and $_.DisplayName -like "sql server*"}

Sie können den folgenden Befehl verwenden, um die Fehlerprotokolldatei nach der spezifischen Zeichenfolge zu durchsuchen: „SQL Server ist jetzt für Clientverbindungen bereit. Dies ist eine Informationsnachricht; es ist keine Benutzeraktion erforderlich.“:

Get-ChildItem -Path "c:\program files\microsoft sql server\mssql*" -Recurse -Include Errorlog | Select-String "SQL Server is now ready for client connections."

Schritt 2: Überprüfen, ob der SQL Server-Browserdienst ausgeführt wird

Hinweis

Dieser Schritt ist nur für die Behandlung von Verbindungsproblemen mit benannten Instanzen erforderlich.

Option 1: Verwenden der SQLCHECK-Ausgabedatei

  1. Search die SQLCHECK-Ausgabedatei für "SQL Server Information" aus.
  2. Suchen Sie im Abschnitt „Dienste von Interesse“ in der Spalte Name nach „SQLBrowser“ und überprüfen Sie dessen Status in der Spalte Gestartet. Wenn der Wert „True“ ist, ist der Dienst gestartet. Andernfalls wird der Dienst derzeit nicht ausgeführt, und Sie müssen ihn starten. Weitere Informationen finden Sie unter SQL Server-Dienste starten, stoppen, pausieren, fortsetzen, neu starten.

Option 2: Verwenden des SQL Server-Konfigurations-Managers

Um eine Verbindung mit einer benannten Instanz herzustellen, muss der SQL Server-Browserdienst ausgeführt werden. Suchen Sie im SQL Server-Konfigurations-Manager den SQL Server-Browserdienst, und überprüfen Sie, ob er ausgeführt wird. Wenn er nicht ausgeführt wird, starten Sie den Dienst. Der SQL Server-Browserdienst ist für Standardinstanzen nicht erforderlich.

Weitere Informationen zur Verwendung des SQL Server-Browserdiensts in Ihrer Umgebung finden Sie unter SQL Server-Browserdienst.

Weitere Informationen zum Stoppen und Starten von SQL Services finden Sie unter SQL Server-Dienste starten, stoppen, pausieren, fortsetzen, neu starten.

Hinweis

Wenn der SQL Server-Browserdienst in Ihrer Umgebung nicht ausgeführt werden kann, finden Sie weitere Informationen unter Herstellen einer Verbindung mit der benannten SQL Server-Instanz ohne den SQL Server-Browserdienst.

Schritt 3: Überprüfen des Servernamens in der Verbindungszeichenfolge

Häufig treten Fehler auf, wenn ein falscher Servername in der Verbindungszeichenfolge angegeben wird. Stellen Sie sicher, dass der Servername dem Servernamen entspricht, den Sie in den vorherigen Schritten abgerufen haben.

Hinweis

Wenn Sie das SQLCHECK-Tool verwenden, überprüfen Sie die NetBios-Werte für Name/FQDN im Abschnitt Computerinformationen der Ausgabedatei.

Schritt 4: Überprüfen der Aliase auf den Client-Rechnern

Aliase werden häufig in Clientumgebungen verwendet, wenn eine Verbindung zu SQL Server mit einem alternativen Namen hergestellt wird oder wenn es Probleme bei der Namensauflösung im Netzwerk gibt. Sie werden mithilfe des SQL Server-Konfigurations-Managers oder des Clientkonfigurationsprogramms erstellt. Ein falscher Alias kann dazu führen, dass die Verbindungen aus Ihren Anwendungen eine Verbindung mit dem falschen Server herstellen, was zu einem Fehler führt. Führen Sie die nachstehenden Schritte aus, um fehlerhafte Aliase zu ermitteln. Sie können auch ein Tool (z. B. SQLCHECK) auf dem Clientcomputer verwenden, um nach Aliasen und verschiedenen anderen Verbindungseinstellungen auf einem Clientcomputer zu suchen.

Hinweis

Die folgenden Optionen gelten nur für die Anwendungen, die SQL Server Native Client zum Herstellen einer Verbindung mit SQL Server verwenden.

Option 1: Verwenden der SQLCHECK-Ausgabedatei

  1. Suchen Sie in der SQLCHECK-Ausgabedatei nach der Zeichenfolge SQL-Aliase. (Diese Zeichenfolge befindet sich im Abschnitt Clientsicherheit und Treiberinformationen der Datei.)
  2. Überprüfen Sie die Einträge in der Tabelle. Wenn keine vorhanden sind, sind keine Aliase auf dem Computer vorhanden. Wenn ein Eintrag vorhanden ist, überprüfen Sie die Informationen, um sicherzustellen, dass der Servername und die Portnummer auf die richtigen Werte festgelegt sind.

Beispiel für die Ausgabe:
SQL-Aliase:

Alias Name   Protocol   Server Name     Port   32-bit 

----------   --------   ------------    ----   ------ 

prodsql      TCP        prod_sqlserver  1430

Die Ausgabe gibt an, dass prodsql ein Alias für eine SQL Server namens prod_sqlserver ist, die an Port 1430 ausgeführt wird.

Option 2: Überprüfen von Aliasen im SQL Server-Konfigurations-Manager

  1. Erweitern Sie im SQL Server-Konfigurations-Manager die SQL Server Native Client-Konfiguration, und wählen Sie Aliase.

  2. Überprüfen Sie, ob Aliase für den Server definiert sind, mit dem Sie eine Verbindung herstellen möchten.

    Wenn die Aliase vorhanden sind, folgen Sie diesen Schritten:

    1. Öffnen Sie den Bereich Eigenschaften des Alias.
    2. Benennen Sie den Wert im Feld Aliasname um (wenn Ihr Servername zum Beispiel MySQL lautet, benennen Sie ihn in MySQL_test um), und versuchen Sie die Verbindung erneut. Wenn die Verbindung jetzt funktioniert, ist Ihr Alias falsch und stammt möglicherweise aus einer alten Konfiguration, die nicht mehr benötigt wird. Wenn die Verbindung nicht funktioniert, benennen Sie den Alias wieder in den ursprünglichen Namen um, und fahren Sie mit dem nächsten Schritt fort.
    3. Überprüfen Sie die Verbindungsparameter für den Alias, und stellen Sie sicher, dass sie korrekt sind. Die folgenden häufig vorkommenden Szenarien können Verbindungsprobleme verursachen:
      • Falsche IP-Adresse für das Feld Server. Stellen Sie sicher, dass die IP-Adresse mit dem Eintrag in der SQL Server-Fehlerprotokolldatei übereinstimmt.
      • Falscher Servername im Feld Server. Ihr Serveralias verweist z. B. auf den richtigen Namen des Servers. Die Verbindungen schlagen jedoch fehl, wenn der Wert des Servernamenparameters falsch ist.
      • Falsches Format des Pipenamen (vorausgesetzt, Sie verwenden einen Named Pipes-Alias).
        • Beim Herstellen einer Verbindung mit einer Standardinstanz namens Mydefaultinstance sollte der Pipename Mydefaultinstance\pipe\sql\query lauten.
        • Beim Herstellen einer Verbindung zu einer benannten Instanz MySQL\Named sollte der Pipename MySQL\pipe\MSSQL$Named\sql\query lauten.

Option 3: Überprüfen von Aliasen im SQL Server-Clientkonfigurationsprogramm

  1. Öffnen Sie das SQL Server-Clientkonfigurationsprogramm, indem Sie im Feld „Ausführen“ cliconfg.exe eingeben.
  2. Befolgen Sie Schritt 2 in Option 2: Überprüfen von Aliasen im SQL Server-Konfigurations-Manager.

Schritt 5: Überprüfen der Firewallkonfiguration

Sie können die Firewallkonfiguration abhängig von der Standardinstanz oder benannten Instanz überprüfen.

Hinweis

Wenn Sie Firewalls von Drittanbietern in Ihrem Netzwerk verwenden, gelten die Konzepte weiterhin. Möglicherweise müssen Sie jedoch mit Ihrem Netzwerkadministrator zusammenarbeiten oder die Dokumentation des Firewallprodukts lesen, um weitere Informationen zum Konfigurieren der Firewall zu erhalten, damit Sie den erforderlichen Ports die Kommunikation mit SQL Server ermöglichen.

Standardinstanz von SQL Server

Eine Standardinstanz wird in der Regel auf Port 1433 ausgeführt. Einige Installationen verwenden ebenfalls einen nicht standardmäßigen Port (also nicht 1433), um SQL-Instanzen auszuführen. Die Firewall kann beide Ports blockieren. Gehen Sie folgendermaßen vor, um die Portnummer weiter zu überprüfen:

  1. Ermitteln Sie den Port, an dem Ihre SQL-Instanz ausgeführt wird. Weitere Informationen finden Sie unter Abrufen des TCP-Ports der Instanz.
    • Wenn Ihr SQL Server so konfiguriert ist, dass Port 1433 überwacht wird, stellen Sie sicher, dass Firewalls im Netzwerk zwischen dem Client und dem Server Datenverkehr an diesem Port zulassen. Lesen Sie Konfigurieren einer Windows-Firewall für den Zugriff auf das Datenbankmodul und arbeiten Sie mit Ihrem Netzwerkadministrator zusammen, um die erforderlichen Lösungen zu implementieren.
    • Wenn Ihre SQL Server-Standardinstanz nicht 1433 verwendet, versuchen Sie, die Portnummer von SQL Server mithilfe des Formats <servername>,<portnumber> an den Servernamen anzufügen und zu prüfen, ob dies funktioniert. Nehmen wir beispielsweise an, der Name Ihrer SQL-Instanz lautet MySQLDefaultinstance, und sie wird an Port 2000 ausgeführt. Geben Sie dann den Servernamen als MySQLServer, 2000 an, und überprüfen Sie, ob dies funktioniert.
      • Wenn es nicht funktioniert, bedeutet dies, dass die Firewall den Port blockiert. Sie können die Anweisungen unter Konfigurieren einer Windows-Firewall für Datenbankmodulzugriff befolgen oder mit Ihrem Netzwerkadministrator zusammenarbeiten, um den Port zur Firewall-Ausschlussliste hinzuzufügen.
      • Wenn dies funktioniert, weist dies darauf hin, dass die Firewall die Kommunikation über diesen Port zulässt. Sie müssen die Verbindungszeichenfolge ändern, um die Portnummer und den Servernamen in der Verbindungszeichenfolge Ihrer Anwendung zu verwenden.

Benannte Instanz von SQL Server

Wenn ihre SQL-Instanz eine benannte Instanz ist, kann sie für die Verwendung dynamischer Ports oder eines statischen Ports konfiguriert werden. In beiden Fällen fragen die zugrunde liegenden Netzwerkbibliotheken den SQL Server-Browserdienst, der auf Ihrem SQL Server-Computer ausgeführt wird, über UDP-Port 1434 ab, um die Portnummer für die benannte Instanz aufzuzählen. Wenn eine Firewall zwischen dem Client und dem Server diesen UDP-Port blockiert, kann die Clientbibliothek den Port (eine Verbindungsanforderung) nicht ermitteln, und die Verbindung schlägt fehl. Um die Verbindung zu überprüfen, können Sie eine der folgenden Methoden verwenden:

  • Methode 1: Überprüfen Sie die Verbindung, indem Sie die Portnummer in der Verbindungszeichenfolge angeben.

    1. Ermitteln Sie den Port, an dem Ihre SQL-Instanz ausgeführt wird. Weitere Informationen finden Sie unter Abrufen des TCP-Ports der Instanz.
    2. Versuchen Sie, eine Verbindung mit der benannten Instanz herzustellen, indem Sie die an den Servernamen angehängte Portnummer im Format <servername\instancename>,<portnumber> verwenden, und überprüfen Sie, ob dies funktioniert. Wenn der Name Ihrer SQL-Instanz zum Beispiel MySQL\Namedinstance lautet und sie an Port 3000 läuft, geben Sie den Servernamen als MySQL\Namedinstance,3000 an.
      • Wenn dies funktioniert, bedeutet das, dass die Firewall den UDP-Port 1434 blockiert oder die Instanz vor dem SQL Server-Browser versteckt ist.
      • Wenn es nicht funktioniert, bedeutet das, dass eine der folgenden Situationen zutrifft:
        • Entweder ist UDP-Port 1434 blockiert, oder der statische Port ist blockiert, oder beides. Verwenden Sie Portqry, um zu bestätigen, ob es sich um den UDP-Port oder den statischen Port handelt.
        • Die Instanz ist vor dem SQL Server-Browserdienst versteckt.

  • Methode 2: Überprüfen Sie die Verbindung mithilfe des PortQryUI-Tools.

    Verwenden Sie das PortQryUI-Tool mit Ihrer benannten Instanz, und beobachten Sie die resultierende Ausgabe. Möglicherweise wird eine Meldung angezeigt, dass der UDP-Port 1434 gefiltert ist. Diese Meldung zeigt, dass der Port im Netzwerk blockiert ist. Anweisungen zur Verwendung des Tools finden Sie unter Verwenden des PortQryUI-Tools mit SQL Server.

    Stellen Sie fest, ob die SQL Server-Instanz dynamische oder statische Ports überwacht. Verwenden Sie dann die folgende Methode, die für Ihr Szenario relevant ist. Wenn Sie sich nicht sicher sind, lesen Sie So prüfen Sie, ob SQL Server einen dynamischen Port oder einen statischen Port überwacht.

    • Szenario 1: Dynamische Ports. Stellen Sie in diesem Fall sicher, dass der SQL Server-Browserdienst gestartet ist und UDP-Port 1434 nicht in der Firewall zwischen dem Client und dem Server blockiert wird. Wenn Sie keines dieser Dinge tun können, sollten Sie Ihre SQL Server-Instanz auf einen statischen Port umstellen und das in Konfigurieren eines Servers zum Lauschen auf einem bestimmten TCP-Port beschriebene Verfahren verwenden.
    • Szenario 2: Konfiguration des statischen Ports. Entweder wird SQL Server-Browser nicht ausgeführt, oder UDP 1434 kann nicht in der Firewall geöffnet werden. Stellen Sie in diesem Fall sicher, dass Sie den statischen Port in der Verbindungszeichenfolge angeben, und dass die Firewall den Port nicht blockiert. Weitere Informationen erhalten Sie unter Konfigurieren einer Windows-Firewall für den Zugriff auf das Datenbankmodul.

Schritt 6: Überprüfen der aktivierten Protokolle auf SQL Server

In einigen Installationen von SQL Server werden Verbindungen mit dem Datenbankmodul von einem anderen Computer nicht aktiviert, es sei denn, ein Administrator aktiviert sie manuell. Sie können eine der folgenden Optionen verwenden, um die erforderlichen Protokolle zu überprüfen und zu aktivieren, um Remoteverbindungen mit dem SQL Server-Datenbankmodul zu ermöglichen.

Option 1: Verwenden der SQLCHECK-Ausgabedatei

  1. Search die SQLCHECK-Ausgabedatei für den Abschnitt "Details für SQL Server instance" aus, und suchen Sie den Informationsabschnitt für Ihre SQL Server instance.

  2. Suchen Sie im Abschnitt die in der folgenden Tabelle aufgeführten Werte, um zu ermitteln, ob die SQL Server-Protokolle aktiviert sind:

    Wertname Auswirkung Weitere Informationen
    Freigegebener Speicher aktiviert Kann entweder „true“ oder „false“ sein – wirkt sich nur auf lokale Verbindungen aus. Erstellen einer gültigen Verbindungszeichenfolge mithilfe des Shared Memory-Protokolls
    Named Pipes aktiviert Bei „false“ schlagen sowohl lokale als auch Remoteverbindungen mit Named Pipes fehl. Auswählen eines Netzwerkprotokolls
    TCP aktiviert Bei „false“ schlagen sowohl lokale als auch Remoteverbindungen mit TCP/IP fehl.
    Hinweis: Die meisten SQL Server-Installationen verwenden TCP/IP als Kommunikationsprotokoll zwischen Server und Client.    		 Auswählen eines Netzwerkprotokolls

  3. Aktivieren Sie erforderliche Protokolle mithilfe des SQL Server-Konfigurations-Managers oder der SQL Server-PowerShell. Weitere Informationen finden Sie unter Aktivieren oder Deaktivieren eines Servernetzwerkprotokolls.

    Hinweis

    Nach dem Aktivieren eines Protokolls muss das Datenbankmodul angehalten und neu gestartet werden, damit die Änderung wirksam wird.

Option 2: Verwenden des SQL Server-Konfigurations-Managers

Führen Sie die folgenden Schritte aus, um Verbindungen von einem anderen Computer mithilfe des SQL Server-Konfigurations-Managers zu aktivieren:

  1. Starten Sie den SQL Server-Konfigurations-Manager.
  2. Erweitern Sie im linken Bereich SQL Server-Netzwerkkonfiguration, und wählen Sie die Instanz von SQL Server aus, mit der Sie eine Verbindung herstellen möchten. Im rechten Bereich sind die verfügbaren Verbindungsprotokolle aufgeführt. Freigegebener Speicher ist normalerweise aktiviert. Er kann nur von demselben Computer verwendet werden, weshalb die meisten Installationen den freigegebenen Speicher aktiviert lassen. Verwenden Sie TCP/IP, um eine Verbindung mit SQL Server von einem anderen Computer herzustellen. Wenn TCP/IP nicht aktiviert ist, klicken Sie mit der rechten Maustaste auf TCP/IP, und wählen Sie Aktivieren aus.
  3. Wenn Sie die Aktivierungseinstellung für ein beliebiges Protokoll ändern, starten Sie das Datenbankmodul neu. Klicken Sie im linken Bereich auf SQL Server-Dienste. Klicken Sie im rechten Fensterbereich mit der rechten Maustaste auf die Instanz des Datenbankmoduls, und wählen Sie Neu starten.

Schritt 7: Testen der TCP/IP-Konnektivität

Eine Verbindung mit SQL Server mithilfe von TCP/IP erfordert, dass Windows die Verbindung herstellt. Mit den folgenden Schritten können Sie die TCP-Konnektivität mithilfe des Ping-Tools testen.

  1. Klicken Sie im Menü Datei auf Ausführen. Geben Sie im Feld Ausführen die Zeichenfolge cmd ein, und klicken Sie auf OK.
  2. Geben Sie im Eingabeaufforderungsfensterping sowie die IP-Adresse des Computers ein, auf dem SQL Server ausgeführt wird. Beispiel:
    • IPv4: ping 192.168.1.101
    • IPv6: ping fe80::d51d:5ab5:6f09:8f48%11
  3. Wenn Ihr Netzwerk richtig konfiguriert ist, gibt pingReply from <IP address> gefolgt von einigen zusätzlichen Informationen zurück. Wenn ping dagegen Destination host unreachable oder Request timed out zurückgibt, ist TCP/IP nicht ordnungsgemäß konfiguriert. Fehler an diesem Punkt deuten auf ein Problem mit dem Clientcomputer, dem Servercomputer oder etwas mit dem Netzwerk hin, z. B. einem Router. Informationen zur Behandlung von Netzwerkproblemen finden Sie unter Erweiterte Problembehandlung für TCP/IP-Probleme.
  4. Wenn der ping-Test mithilfe der IP-Adresse erfolgreich ist, testen Sie, ob der Computername in die TCP/IP-Adresse aufgelöst werden kann. Geben Sie im Eingabeaufforderungsfenster auf dem Clientcomputer ping und den Namen des Computers ein, auf dem SQL Server ausgeführt wird. Beispiel: ping newofficepc.
  5. Wenn ein Ping an die IP-Adresse erfolgreich ist, aber bei einem Ping an den Computernamen Destination host unreachable oder Request timed out zurückgegeben wird, haben Sie möglicherweise alte (veraltete) Informationen zur Namensauflösung auf dem Clientcomputer zwischengespeichert. Geben Sie ipconfig /flushdns ein, um den DNS-Cache (Dynamic Name Resolution) zu löschen. Pingen Sie den Computer dann erneut anhand des Namens. Wenn der DNS-Cache leer ist, überprüft der Clientcomputer die neuesten Informationen über die IP-Adresse des Servercomputers.
  6. Wenn Ihr Netzwerk richtig konfiguriert ist, gibt pingReply from <IP address> gefolgt von einigen zusätzlichen Informationen zurück. Wenn Sie den Servercomputer erfolgreich per IP-Adresse pingen können, aber beim Pingen nach dem Computernamen einen Fehler erhalten, z. B. Destination host unreachable oder Request timed out, ist die Namensauflösung nicht ordnungsgemäß konfiguriert. Weitere Informationen finden Sie unter Beheben grundlegender TCP/IP-Probleme. Eine erfolgreiche Namensauflösung ist nicht zwingend erforderlich, um eine Verbindung mit SQL Server herzustellen. Wenn der Computername jedoch nicht in eine IP-Adresse aufgelöst werden kann, müssen Verbindungen hergestellt werden, um die IP-Adresse anzugeben. Die Namensauflösung kann später behoben werden.

Hinweis

Sie können auch, entsprechend der auf dem Computer installierten PowerShell-Version, das Cmdlet Test-NetConnection oder Test-Connection verwenden, um die TCP-Konnektivität zu testen. Weitere Informationen zum PowerShell-Cmdlet finden Sie in der Cmdlet-Übersicht.

Schritt 8: Testen der lokalen Verbindung

Testen Sie vor der Behandlung eines Verbindungsproblems von einem anderen Computer aus, ob Sie eine Verbindung von einer Clientanwendung aus herstellen können, die lokal auf dem Computer installiert ist, auf dem SQL Server ausgeführt wird. Die lokale Verbindung vermeidet Probleme mit Netzwerken und Firewalls.

Für dieses Verfahren ist SQL Server Management Studio erforderlich. Wenn Sie Management Studio nicht installiert haben, lesen Sie Herunterladen von SQL Server Management Studio (SSMS).

Wenn Sie Management Studio nicht installieren können, können Sie die Verbindung mithilfe des Dienstprogramms sqlcmd.exe testen. sqlcmd.exe wird mit dem Datenbankmodul installiert. Informationen zu sqlcmd.exe finden Sie unter sqlcmd-Dienstprogramm.

  1. Melden Sie sich bei dem Computer an, auf dem SQL Server installiert ist, indem Sie einen Benutzernamen verwenden, der auf SQL Server zugreifen kann. Während der Installation muss bei SQL Server mindestens ein Benutzername als SQL Server-Admin angegeben werden. Wenn Sie keine Admins kennen, lesen Sie Herstellen einer Verbindung mit SQL Server wenn Systemadmins gesperrt sind.

  2. Geben Sie auf der StartseiteSQL Server Management Studio ein, oder wählen Sie im Startmenü der älteren Versionen von Windows Alle Programme, dann Microsoft SQL Server und dann SQL Server Management Studio aus.

  3. Wählen Sie im Dropdownmenü Verbinden die Option Datenbankmodul aus. Wählen Sie im Feld Authentifizierung die Option Windows-Authentifizierung aus. Geben Sie im Feld Servername einen der folgenden Verbindungstypen ein:

    Herstellen einer Verbindung mit Typ Beispiel
    Standardinstanz <computer name> ACCNT27
    Benannte Instanz <computer name\instance name> ACCNT27\PAYROLL

    Hinweis

    Beim Herstellen einer Verbindung mit SQL Server von einer Clientanwendung auf demselben Computer wird das Protokoll für den gemeinsam genutzten Speicher verwendet. Freigegebener Speicher ist eine Art von lokalem Named Pipe, daher treten manchmal Fehler im Zusammenhang mit Pipes auf.

  4. Wenn an dieser Stelle ein Fehler angezeigt wird, müssen Sie ihn beheben, bevor Sie fortfahren. Ihre Anmeldung ist möglicherweise nicht berechtigt, eine Verbindung herzustellen. Ihre Standarddatenbank fehlt möglicherweise.

    Hinweis

    Sie können das Problem nicht ohne genügend Informationen beheben, da einige Fehlermeldungen absichtlich an den Client übergeben werden. Dies ist ein Sicherheitsfeature, um zu vermeiden, dass ein Angreifer Informationen über SQL Server erhält. Informationen zum Fehler finden Sie im SQL Server-Fehlerprotokoll.

  5. Wenn Sie Fehler 18456 Anmeldung für Benutzer fehlgeschlagen erhalten, finden Sie im Artikel MSSQLSERVER_18456 der Onlinedokumentation weitere Informationen zu den Fehlercodes. Der Blog von Aaron Bertrand verfügt ebenfalls über eine umfangreiche Liste der Fehlercodes unter Problembehandlung Fehler 18456 (externer Link). Sie können das Fehlerprotokoll mithilfe von SSMS (wenn Sie eine Verbindung herstellen können) im Abschnitt Verwaltung des Objekt-Explorers anzeigen. Andernfalls können Sie das Fehlerprotokoll mit dem Editor-Programm von Windows anzeigen. Der Standardspeicherort variiert je nach Version und kann während des Setups geändert werden. Der Standardspeicherort für SQL Server 2019 (15.x) ist C:\Programme\Microsoft SQL Server\MSSQL15. MSSQLSERVER\MSSQL\Log\ERRORLOG.

  6. Wenn Sie eine Verbindung über gemeinsam genutzten Speicher herstellen können, testen Sie das Verbinden mithilfe von TCP. Sie können eine TCP-Verbindung erzwingen, indem Sie tcp: vor dem Namen angeben. Hier sind die Beispiele:

    Herstellen einer Verbindung mit: Typ: Beispiel:
    Standardinstanz tcp:<computer name> tcp:ACCNT27
    Benannte Instanz tcp:<computer name/instance name> tcp:ACCNT27\PAYROLL

  7. Wenn Sie eine Verbindung mithilfe des freigegebenen Speichers, aber nicht mit TCP herstellen können, müssen Sie das TCP-Problem beheben. Das wahrscheinlichste Problem ist, dass TCP einfach nicht aktiviert ist. Informationen zum Aktivieren von TCP finden Sie in Schritt 6: Überprüfen der aktivierten Protokolle auf SQL Server.

  8. Wenn Sie eine Verbindung mit einem anderen Konto als einem Administratorkonto herstellen möchten, können Sie zunächst eine Verbindung als Administrator herstellen. Versuchen Sie dann erneut, eine Verbindung mit der Windows-Authentifizierungsanmeldung oder der SQL Server-Authentifizierungsanmeldung herzustellen, die von der Clientanwendung verwendet wird.

Schritt 9: Testen der Remoteverbindung

Sobald Sie eine Verbindung über TCP auf demselben Computer herstellen können, sollten Sie versuchen, die Verbindung vom Clientcomputer aus herzustellen. Sie können eine beliebige Clientanwendung verwenden, aber um es nicht unnötig komplex zu machen, installieren Sie die SQL Server-Verwaltungstools auf dem Client. Versuchen Sie nach der Installation, SQL Server Management Studio zu verwenden.

  1. Verwenden Sie SQL Server Management Studio auf dem Clientcomputer, und versuchen Sie, eine Verbindung herzustellen, indem Sie die IP-Adresse mit der TCP-Portnummer durch das Format „IP-Adresse, Komma, Portnummer“ kombinieren. Beispiel: 192.168.1.101,1433. Wenn diese Verbindung fehlschlägt, haben Sie wahrscheinlich eines der folgenden Probleme:
  2. Nachdem Sie die Verbindung über die IP-Adresse und Portnummer herstellen konnten, überprüfen Sie die folgenden Szenarien:
    • Wenn Sie eine Verbindung mit einer Standardinstanz herstellen, die auf einem anderen Port als 1433 lauscht, müssen Sie entweder die Portnummer in der Verbindungszeichenfolge verwenden oder einen Alias auf dem Clientcomputer erstellen, um eine Verbindung mit der Standardinstanz herzustellen. Der SQL Server-Browserdienst kann keine Ports der Standardinstanz auflisten.
    • Wenn Sie eine Verbindung mit einer benannten Instanz herstellen, versuchen Sie, eine Verbindung mit der Instanz im Format IP-Adresse Backslash Instanzname herzustellen. (Beispiel 192.168.1.101\<instance name>.) Wenn diese Aktion nicht funktioniert, bedeutet dies, dass die Portnummer nicht an den Client zurückgegeben wird. Das Problem bezieht sich auf den SQL Server Browserdienst, der die Portnummer einer benannten Instanz für den Client bereitstellt. Hier sind die Lösungen:
      • Starten Sie den SQL Server-Dienst. Lesen Sie die Anweisungen zum Starten des Browsers in SQL Server-Konfigurations-Manager.
      • Der SQL Server Browserdienst wird vom Firewall blockiert. Öffnen Sie den UDP-Port 1434 im Firewall. Zurück zum Abschnitt Schritt 5: Überprüfen der Firewallkonfiguration. Stellen Sie sicher, dass Sie einen UDP-Port und keinen TCP-Port öffnen.
      • Die UDP-Port 1434-Informationen werden von einem Router blockiert. Die UDP-Kommunikation (Benutzerdatengrammprotokoll) ist nicht für das Durchlaufen von Routern konzipiert und verhindert, dass das Netzwerk mit Datenverkehr mit niedriger Priorität gefüllt wird. Sie können Ihren Router so konfigurieren, dass UDP-Datenverkehr weitergeleitet wird, oder Sie können die Portnummer bei jeder Verbindung angeben.
      • Wenn der Clientcomputer Windows 7, Windows Server 2008 oder ein neueres Betriebssystem verwendet, kann das Clientbetriebssystem den UDP-Datenverkehr löschen, da die Antwort vom Server von einer anderen IP-Adresse zurückgegeben wird als der, die abgefragt wurde. Weitere Informationen finden Sie im Abschnitt Mehrere Server-IP-Adressen im „Bücher Online“-Artikel Problembehandlung: Timeout abgelaufen. (Dieser Artikel stammt von SQL Server 2008 R2, aber die Grundsätze gelten immer noch. Sie können den Client so konfigurieren, dass er bei jeder Verbindung die richtige IP-Adresse verwendet oder die Portnummer angibt).
  3. Sobald Sie eine Verbindung mithilfe der IP-Adresse (oder der IP-Adresse und des Instanznamens für eine benannte Instanz) herstellen können, versuchen Sie, die Verbindung mithilfe des Computernamens (oder des Computer- und Instanznamens für eine benannte Instanz) herzustellen. Fügen Sie tcp: vor den Computernamen ein, um eine TCP/IP-Verbindung zu erzwingen. Verwenden Sie beispielsweise tcp:ACCNT27 für die Standardinstanz auf einem Computer mit dem Namen ACCNT27. Verwenden Sie tcp:ACCNT27\PAYROLL für eine benannte Instanz namens PAYROLL auf diesem Computer. Wenn Sie eine Verbindung über die IP-Adresse, aber nicht über den Computernamen herstellen können, liegt ein Namensauflösungsproblem vor. Gehen Sie in dem Fall zurück zum Abschnitt Schritt 7: Testen der TCP/IP-Konnektivität.
  4. Sobald Sie eine Verbindung mithilfe des Computernamens herstellen können, der TCP erzwingt, versuchen Sie, die Verbindung mithilfe des Computernamens herzustellen, ohne TCP zu erzwingen. Beispielsweise verwenden Sie für eine Standardinstanz einfach einen Computernamen wie CCNT27. Verwenden Sie für eine benannte Instanz den Computernamen und den Instanznamen wie ACCNT27\PAYROLL. Wenn Sie mit Erzwingen von TCP eine Verbindung herstellen können, aber nicht, ohne TCP zu erzwingen, verwendet der Client wahrscheinlich ein anderes Protokoll, z. B. Named Pipes. Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
    1. Verwenden Sie auf dem Clientcomputer den SQL Server-Konfigurations-Manager. Erweitern Sie im linken Bereich SQL Native Client > Konfiguration, und wählen Sie dann Clientprotokolle aus.
    2. Stellen Sie im rechten Bereich sicher, dass TCP/IP aktiviert ist. Wenn TCP/IP deaktiviert ist, klicken Sie mit der rechten Maustaste auf TCP/IP, und wählen Sie Aktivieren aus.
    3. Stellen Sie sicher, dass die Protokollreihenfolge für TCP/IP eine kleinere Zahl als die Named Pipes-Protokolle (oder VIA bei älteren Versionen) ist. Im Allgemeinen sollten Sie freigegebenen Speicher in der Reihenfolge als 1 und TCP/IP als 2 belassen. Freigegebener Speicher wird nur verwendet, wenn der Client und SQL Server auf demselben Computer ausgeführt werden. Alle aktivierten Protokolle werden in der Reihenfolge versucht, bis eines erfolgreich ist, aber freigegebener Speicher wird übersprungen, wenn sich die Verbindung nicht auf demselben Computer befindet.

Schritt 10: Überprüfen von Benutzerberechtigungen

Wenn Sie Named Pipes zum Herstellen einer Verbindung verwenden, überprüfen Sie, ob ein Benutzer über Berechtigungen zum Anmelden bei Windows verfügt. Weitere Informationen finden Sie unter Problembehandlung für Named Pipes-Verbindungen.

Siehe auch