Freigeben über

Sammeln von Daten zur Behandlung von SQL Server-Konnektivitätsproblemen

  • Artikel

Dieser Artikel hilft Ihnen, die Grundursache von SQL Server-Konnektivitätsproblemen zu ermitteln, indem Sie relevante Fragen basierend auf bestimmten Kategorien stellen. Obwohl der Artikel Empfohlene Voraussetzungen und Prüfliste für die Behandlung von SQL Server-Konnektivitätsproblemen die wichtigsten Punkte enthält, die gesammelt werden müssen, können Die Fragen in diesem Artikel Ihnen helfen, die Ursache der Konnektivitätsprobleme einzugrenzen und diese effektiv zu beheben.

Hinweis

Nicht alle Fragen gelten für alle Probleme. Diese Fragen können Sie jedoch bei der Behandlung von Konnektivitätsproblemen unterstützen.

Wenn Sie anhand der informationen in diesem Artikel die genaue Art des Problems ermitteln können, finden Sie unter Übersicht über probleme bei der konsistenten Authentifizierung in SQL Server informationen zu den Fehlertypen.

Methode zum Sammeln von Daten

Zum Sammeln von Daten können Sie Tools wie Problem steps Recorder (PSR),Netzwerkablaufverfolgung und NETLOGON-Ablaufverfolgung verwenden. Dieser Abschnitt enthält ausführliche Schritte zum Installieren und Konfigurieren einer Kombination aller dieser Tools.

Führen Sie diese Schritte gleichzeitig auf den Client- und Servercomputern aus. Wenn es sich bei der Anwendung um eine Architektur mit drei Ebenen oder n Ebenen handelt, führen Sie die Installation auch auf Zwischenservern aus.

  1. Installieren Sie WireShark auf allen betroffenen Computern, oder verwenden Sie den integrierten NETSH Befehl (Windows 2008 oder höher). Es ist kein Neustart erforderlich.

  2. Aktivieren Sie die NETLOGON-Debugprotokollierung auf dem Client und allen Servern, indem Sie den folgenden Befehl ausführen:

    NLTEST /DBFLAG:2080FFFF

  3. Führen Sie nach Möglichkeit einen der folgenden Schritte aus:

    • Starten Sie den Clientcomputer neu.
    • Bitten Sie den Benutzer, sich abzumelden und sich erneut anzumelden.
    • Schließen Sie die Clientanwendung, und öffnen Sie sie erneut.

  4. Starten Sie auf dem Clientcomputer die Problemschrittaufzeichnung (psr.exe), und wählen Sie dann Datensatz starten aus.

    Dieses Tool erfasst genau alle Benutzeraktionen, die dem Problem vorausgehen, und speichert die Ergebnisse in einer .zip-Datei.

  5. Starten Sie die Netzwerkerfassung auf allen Computern.

  6. Wenn Sie NETSH verwenden, führen Sie den NETSH TRACE START CAPTURE=YES TRACEFILE=C:\TEMP%computername%.ETL Befehl aus (verwenden Sie einen geeigneten Datei- oder Pfadnamen).

  7. Leeren Sie den DNS-Cache (Domain Name System) auf allen Computern, indem Sie den IPCONFIG /FLUSHDNS Befehl ausführen.

  8. Löschen Sie den NETBIOS-Cache auf allen Computern, indem Sie den NBTSTAT /RR Befehl ausführen.

  9. Bereinigen Sie Kerberos-Clienttickets, indem Sie den KLIST purge Befehl ausführen.

  10. Löschen Sie Tickets auf jedem Server, indem Sie den KLIST -li 0x3e7 purge Befehl ausführen.

    Hinweis

    Geben Sie den Befehl ein. Kopieren Sie nicht und fügen Sie ihn nicht in die Befehlszeile ein, da der Bindestrich möglicherweise in einen langen Bindestrich (em) konvertiert wird. KLIST Bei wird die Groß-/Kleinschreibung beachtet.

  11. Reproduzieren Sie das Problem.

  12. Beenden Sie die psr.exe Aufzeichnung.

  13. Beenden Sie die Netzwerkerfassungen. Speichern Sie die aufgezeichnete Datei, indem Sie den Befehl NETSH: NETSH TRACE STOP mit einem aussagekräftigen Namen ausführen. Der Name der Datei kann z. B. SQLProd01.netmon.cap sein.

  14. Warten Sie, bis die Eingabeaufforderung erneut angezeigt wird, und schließen Sie dann das Fenster. Schließen Sie das Eingabeaufforderungsfenster nicht, bevor die Eingabeaufforderung angezeigt wird.

  15. Kopieren Sie das NETLOGON-Protokoll nach C:\windows\debug\netlogon.log , und geben Sie der Datei einen aussagekräftigen Namen. Beispiel: SQLProd01.netlogon.log.

  16. Deaktivieren Sie die Protokollierung, indem Sie den NLTEST /DBFLAG:0x0 Befehl ausführen.

Sammeln von Daten zum Kategorisieren der Probleme

Die folgenden Fragen sollen Ihnen helfen, die Kategorie zu finden, in die ein Problem fällt, und leiten Sie so in die richtige Richtung der Problembehandlung. Wählen Sie jede Dropdownliste für verwandte Fragen aus.

Bevor Sie mit den spezifischen Fragen beginnen, stellen Sie sicher, dass alle voraussetzungen erfüllt sind, die für die SQL Server-Verbindungen erforderlich sind. Weitere Informationen zu den Voraussetzungen finden Sie unter Empfohlene Voraussetzungen und Prüfliste für die Behandlung von SQL Server-Konnektivitätsproblemen.

Allgemeinere Perspektivenfragen
  • Wirkt sich das Problem nur auf Datenbankverbindungen aus, oder betrifft es auch Web- und Dateifreigabeverbindungen? Viele Fälle werden dem SQL Server-Team gemeldet, da sie auf dem Datenbankserver auftreten. Es kann jedoch möglich sein, dass das Problem überhaupt nicht mit der Datenbank zusammenhängt und eine allgemeinere Windows- oder Active Directory-Unterstützung erfordert.
  • Besteht eine Vertrauensstellung zwischen der Benutzer-, Client- oder Serverdomäne, wenn diese unterschiedlich sind? Ist es extern, Gesamtstruktur, unidirektionale, bidirektionale oder keine?
  • Funktioniert die Verbindung ordnungsgemäß, wenn sich alle Ressourcen in derselben Domäne befinden?
  • Ist das Problem zeitweilig oder periodisch, oder ist es konsistent?
  • Tritt das Problem nur auf, wenn mehr als ein Benutzer die Anwendung verwendet? Tritt es häufiger auf, wenn mehr Benutzer es verwenden?
  • Tritt das Problem nur zu bestimmten Tageszeiten oder an bestimmten Wochentagen auf?
  • Tritt das Problem nur auf, wenn eine Sicherung erstellt oder die Datenbank neu indiziert wird?
  • Betrifft das Problem mehrere Server?
  • Betrifft das Problem nur einen Knoten in einem n-Knoten-Cluster? Wenn ja, kann es effizienter sein, die Neuerstellung dieses bestimmten Knotens in Betracht zu ziehen.
  • Betrifft das Problem nur einen oder zwei von mehreren Clients? Wenn ja, wäre der Wiederaufbau vielleicht effizienter.
  • Betrifft das Problem nur Named Pipes und nicht TCP (oder umgekehrt)?
  • Tritt das Problem auf, wenn Sie eine SQL Server-Anmeldung und TCP/IP verwenden?
  • Gibt es einen Arbeitsfall, der mit dem fehlerhaften Fall verglichen werden kann? Wie unterscheiden sich die Systeme?
Clientcomputer

Verwenden Sie die folgenden Fragen, um Daten zu den verschiedenen Komponenten des Clientcomputers zu sammeln. Diese Daten können nützlich sein, um die Probleme zu identifizieren.

  • Wie lautet der Name, die Edition und die Version des Betriebssystems (WinVer)?

  • Wie lautet der Name und die Version des SQL Server-Treibers oder -Anbieters?

  • Wie lautet der Computername und die IP-Adresse?

  • Wie lautet der Domänenstatus des Computers? Wie lautet der Domänenname, wenn es einer Domäne beigetreten ist?

  • Welche Anwendungsruntime-Umgebung wird verwendet? Beispiel: Internetinformationsdienste (IIS), Windows Forms, Web Sphere oder SSIS-Auftrag (SQL Server Integration Services).

  • Welche Anwendungssprache wird verwendet?

  • Welche Verbindungszeichenfolge wird verwendet?

  • Welche Art von Authentifizierung wird verwendet, um eine Verbindung mit dem Server herzustellen? Beispiel: New Technology LAN Manager (NTLM), Kerberos, SQL oder Azure Active Directory (AAD).

  • Wenn es sich bei der Anwendung um einen Server oder Dienst handelt, werden dann Benutzeranmeldeinformationen an die Back-End-Datenbank delegiert?

  • Wird die eingeschränkte Delegierung verwendet?

  • Was sind das Anwendungsdienstkonto und die Domäne?

  • Welcher Diensttyp wird verwendet? Handelt es sich um physische, virtuelle oder cloudbasierte Daten? Beispiel: IaaS, Web-App, Webrolle oder Power BI.

  • Was ist der Clienttreiber? Handelt es sich um Java Database Connectivity (JDBC) oder wird es unter Linux oder Mac ausgeführt?

    Hinweis

    Die Workflows sind derzeit eher windowsorientiert.

  • Betrifft das Problem nur Legacyanbieter wie Provider=SQLOLEBD oder Driver={SQL Server}und nicht SQL Native Client und höhere Treiber (oder umgekehrt)?

  • Tritt das Problem nur in einer oder in mehreren Anwendungen auf?

  • Schlägt eine UDL-Datei (Universal Data Link) fehl, wenn sie versucht, eine Verbindung mit anderen SQL Server-basierten Servern herzustellen, oder schlägt sie nur auf dem Server fehl, auf dem das Problem besteht?

  • Meldet sich der Benutzer beim SQL Server-basierten Server an und versucht, mithilfe von SQL Server Management Studio (SSMS) eine Verbindung herzustellen?

  • Tritt das Problem nur auf, wenn Sie den NETBIOS-Namen des Servers verwenden und nicht, wenn Sie den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) verwenden (oder umgekehrt)? Funktioniert dies mithilfe der IP-Adresse?

  • Ist auf dem Client, auf dem Windows 10 Enterprise Edition ausgeführt wird, das Credential Guard-Feature aktiviert? Wenn ja, kann sich dies auf Szenarien mit vollständiger Delegierung auswirken.

Protokollinformationen

Verwenden Sie die folgenden Fragen, um Daten zu den Protokolldateien zu sammeln:

  • Wie lautet die genaue Fehlermeldung in der Aufrufliste?
  • Wurde das Protokoll aus den SQL Server-Dateien ERRORLOG und ERRORLOG.1 erfasst?
  • Wurden die Anwendungsereignisprotokolle vom Client und Server erfasst?
  • Wurden die Protokolldateien und Konfigurationsdateien der Clientanwendung gesammelt? Beispiel :web.config, rsreportserver.config, *.configoder *.ini.
  • Gibt es eine verfügbare visuelle Darstellung des Netzwerks, die die Computer, Router usw. anzeigt?
Neue oder vorhandene Probleme

Bezieht sich auf die Bestimmung, ob es sich bei dem Problem um eine aktuelle Entwicklung handelt oder ob es eine Weile beibehalten wurde:

  • Gab es das Problem schon immer (Neuinstallation), oder funktionierte die Anwendung einige Zeit richtig, bevor sie kürzlich unterbrochen wurde?
  • Welche Änderungen wurden an der Umgebung vorgenommen, wenn die Anwendung früher ordnungsgemäß funktionierte? Beispiele hierfür sind installierte Updates, aktualisierte Domänencontroller, Änderungen an den Firewalleinstellungen, außer Betrieb gesetzte Domänencontroller oder eine Verschiebung in eine andere Organisationseinheit in der Domäne.
Servercomputer

Sammeln Sie für einen Verbindungsserver Serverinformationen sowohl für den Mid-Tier-Server als auch für den Back-End-Server. Sammeln Sie bei problemen mit der IIS-zu-SQL-Delegierung Informationen auf dem Webserver, einschließlich der web.config - und Authentifizierungseinstellungen.

  • Wie lautet der Name des Betriebssystems, die Edition und die Version (Winver)?
  • Wie lautet der Name und die Version der Datenbank?
  • Wie lautet der Name des Computers?
  • Wie lautet die IP-Adresse?
  • Wie lautet der Domänenname, wenn der Computer in die Domäne eingebunden ist?
  • Was ist das SQL Server-Dienstkonto und die Domäne?
  • Wie lautet der Name der SQL Server-Instanz?
  • Welche Protokolle sind aktiviert?
  • An welchem Port lauscht der Server?
  • Wie lautet der Name der Serverpipe? Diese Informationen finden Sie im Fehlerprotokoll.
  • Welche Art von Umgebung wird verwendet? Handelt es sich um physische, virtuelle oder cloudbasierte Daten? Beispiel: IaaS (SQL auf einem virtuellen Azure-Computer)) oder PaaS (Azure SQL-Datenbank, SQL Managed Instance (MI)).
  • Wird die Datenbank als eigenständig, gruppiert, gespiegelt oder mit Always On bereitgestellt?
  • Wie lautet der Name und die IP-Adresse des Failoverpartners?
  • Wie lautet der Name und Port des virtuellen Clusters oder Listeners?
  • Was ist die virtuelle IP- oder Listener-IP?
  • Auf welchem Betriebssystem ist die Datenbank installiert? Handelt es sich um Windows, Linux oder Mac? Dies kann sich auf die Datensammlung auswirken.
  • Wie lautet der Speicherort der Datenbank? Befindet es sich in Azure?
  • Wie lautet der aktuelle Status des Servers in Bezug auf das neueste Service Pack und das kumulative Update? Es macht keinen Sinn, ein Problem zu debuggen, das bereits behoben ist.
  • Wurde SQL Server kürzlich aktualisiert, um TLS 1.2 (Transport Layer Security) zu unterstützen? Wurden auch die Clients aktualisiert? Wurde TLS 1.0 deaktiviert?
  • Wie lautet der aktuelle Status des SQL Server-Diensts? Wird es ausgeführt?
  • Wie lautet der Status des SQL-Browserdiensts? Wird es ausgeführt?
  • Was ist die Spezifität des Problems für ein Dienstkonto? Wird das Problem durch ausführen des Servers mit einem anderen Dienstkonto behoben?
Benutzerinformationen

Sammeln Sie die folgenden Benutzerdetails:

  • Meldet sich der Benutzer direkt am Clientcomputer an oder greift er remote darauf zu? Verwendet der Benutzer beispielsweise einen Browser?
  • Ist der Benutzer ein Dienst, z. B. SQL-Agent? Wird die Prozessidentität verwendet, oder werden gespeicherte Anmeldeinformationen verwendet?
  • Welche Art der Authentifizierung wird verwendet, um eine Verbindung mit der Clientanwendung herzustellen? Handelt es sich um Die Windows-, Forms- oder AAD-Authentifizierung?
  • Stellt der Benutzer mithilfe der integrierten Sicherheit eine Verbindung mit dem Server her?
  • Wie lautet der Benutzername und domänenname?

Wenn der Benutzer remote zur Clientanwendung ist, sammeln Sie die folgenden Details:

  • Wie lautet der Computername und die IP-Adresse?
  • Ist der Computer in die Domäne eingebunden? Wenn ja, wie lautet der Domänenname?
  • Stellt der Benutzer eine Verbindung über ein VPN oder einen Proxyserver zur Verbindung? Tritt das Problem auf, wenn eine der Methoden direkt verbunden ist?
  • Wenn der Benutzer eine Verbindung mit einem Webserver herstellt, gibt es dann einen Lastenausgleich für den Server?
  • Werden kurzlebige Sitzungen oder Sitzungsaffinität verwendet?
  • Meldet sich der Benutzer bei einem Terminalserver oder einer Jumpbox an und greift auf die Anwendung zu?
  • Betrifft das Problem nur Benutzer in bestimmten Organisationseinheiten?
  • Wurde der Benutzer, Client oder Server in eine andere Organisationseinheit in Active Directory verschoben?
  • Betrifft das Problem nur Benutzer, die keine Administratoren sind?
  • Betrifft das Problem alle oder nur einige Benutzer in einer bestimmten Domäne?

Siehe auch

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.