Behandeln vorübergehender Verbindungsfehler in SQL-Datenbank und SQL Managed Instance

  • Artikel

Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics

In diesem Artikel wird beschrieben, wie Sie Verbindungsfehler und vorübergehende Fehler verhindern, behandeln, diagnostizieren und beheben, die bei Ihrer Clientanwendung während der Interaktion mit Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse Analytics auftreten. Erfahren Sie, wie Sie die Wiederholungslogik konfigurieren, die Verbindungszeichenfolge erstellen und andere Verbindungseinstellungen anpassen.

Vorübergehender Fehler

Bei einem vorübergehenden Fehler liegt ein Problem zugrunde, das sich nach kurzer Zeit von selbst löst. Wenn das Azure-System Hardwareressourcen für einen besseren Lastenausgleich bei verschiedenen Workloads rasch verschiebt, treten gelegentlich vorübergehende Fehler auf. Die meisten dieser Neukonfigurationsereignisse dauern weniger als 60 Sekunden. Während der Neukonfiguration kann es beim Herstellen von Verbindungen mit der Datenbank in SQL-Datenbank zu Problemen kommen. Anwendungen, die eine Verbindung mit der Datenbank herstellen, sollten dafür ausgelegt sein, vorübergehende Fehler zu tolerieren. Behandeln Sie diese Fehler, indem Sie Wiederholungslogik im Code implementieren und vermeiden, dass sie Benutzern als Anwendungsfehler gemeldet werden.

Wenn Ihr Clientprogramm ADO.NET verwendet, wird eine SqlException-Ausnahme ausgelöst, um das Programm über den vorübergehenden Fehler zu informieren.

Vorübergehende Fehler beim Herstellen einer Verbindung und bei Befehlen

Sie können je nach Situation versuchen, die Verbindung mit SQL-Datenbank und SQL Managed Instance wiederzuverwenden oder erneut herzustellen:

  • Beim Versuch, eine Verbindung herzustellen, tritt ein vorübergehender Fehler auf.

Wiederholen Sie den Verbindungsversuch nach einigen Sekunden.

  • Während eines SQL-Datenbank- und SQL Managed Instance-Abfragebefehls tritt ein vorübergehender Fehler auf.

Versuchen Sie nicht sofort, den Befehl erneut auszuführen. Stellen Sie stattdessen nach einiger Zeit eine neue Verbindung her, und führen Sie den Befehl erneut aus.

Wiederholungslogik für vorübergehende Fehler

Clientprogramme, bei denen gelegentlich ein vorübergehender Fehler auftritt, sind stabiler, wenn sie Wiederholungslogik enthalten. Wenn Ihr Programm über Middleware eines Drittanbieters mit der Datenbank in SQL-Datenbank kommuniziert, erkundigen Sie sich beim Anbieter, ob die Middleware Wiederholungslogik für vorübergehende Fehler enthält.

Prinzipien für Wiederholungsversuche

  • Falls ein vorübergehender Fehler auftritt, wiederholen Sie den Verbindungsversuch.
  • Wenn bei einer SELECT-Anweisung in SQL-Datenbank oder SQL Managed Instance ein vorübergehender Fehler auftritt, sollte diese nicht sofort wiederholt werden. Stellen Sie stattdessen eine neue Verbindung her, und führen Sie dann die SELECT-Anweisung erneut aus.
  • Wenn bei einer UPDATE-Anweisung in SQL-Datenbank oder SQL Managed Instance ein vorübergehender Fehler auftritt, stellen Sie eine neue Verbindung her, bevor Sie die UPDATE-Anweisung wiederholen. Die Wiederholungslogik muss sicherstellen, dass entweder die gesamte Datenbanktransaktion vollständig ausgeführt wurde oder dass für die gesamte Transaktion ein Rollback ausgeführt wird.

Weitere Überlegungen für Wiederholungsversuche

  • Bei einem Batchprogramm, das nach Ende der Geschäftszeiten automatisch gestartet und vor Beginn des nächsten Tags beendet wird, sind lange Intervalle zwischen den Wiederholungsversuchen unproblematisch.
  • Bei Benutzeroberflächenprogrammen sollte jedoch berücksichtigt werden, dass die Benutzer bei zu langen Wartezeiten dazu tendieren, das Programm zu beenden. Wiederholungen nach wenigen Sekunden sollten vermieden werden, da das System durch zu viele Anforderungen überlastet werden kann.

Steigerung der Intervalle zwischen Wiederholungsversuchen

Es wird empfohlen, vor dem ersten Wiederholungsversuch fünf Sekunden zu warten. Wiederholungsversuche nach weniger als fünf Sekunden können den Clouddienst überfordern. Für jeden nachfolgenden Wiederholungsversuch sollte die Verzögerung exponentiell steigen, bis zu einem Maximum von 60 Sekunden.

Die Sperrfrist für Clients, die ADO.NET verwenden, wird unter Verbindungspooling (ADO.NET) erörtert.

Darüber hinaus kann es sinnvoll sein, eine maximale Anzahl von Wiederholungsversuchen festzulegen, bevor das Programm beendet wird.

Codebeispiele mit Wiederholungslogik

Codebeispiele mit Wiederholungslogik finden Sie unter:

Testen der Wiederholungslogik

Um Ihre Wiederholungslogik zu testen, müssen Sie einen Fehler simulieren oder verursachen, der behandelt werden kann, während Ihr Programm weiterhin ausgeführt wird.

Testen der Logik, indem der Computer vom Netzwerk getrennt wird

Eine Möglichkeit, um Ihre Wiederholungslogik zu testen, besteht darin, Ihren Clientcomputer vom Netzwerk zu trennen, während das Programm ausgeführt wird. Der Fehler lautet:

  • SqlException.Number = 11001
  • Meldung: „Es ist kein solcher Host bekannt.“

Im Rahmen des ersten Wiederholungsversuchs können Sie Ihren Clientcomputer wieder mit dem Netzwerk verbinden und dann versuchen, eine Verbindung herzustellen.

Um diesen Test in der Praxis umzusetzen, trennen Sie Ihren Computer vom Netzwerk, bevor Sie das Programm starten. Als Folge erkennt Ihr Programm einen Laufzeitparameter, der folgende Auswirkungen hat:

  • 11001 wird zeitweilig zur Liste der Fehler hinzugefügt, die als vorübergehend betrachtet werden.
  • Das Programm führt den ersten Verbindungsversuch durch.
  • Nachdem der Fehler ermittelt wurde, wird 11001 aus der Liste entfernt.
  • Eine Meldung fordert den Benutzer auf, den Computer an das Netzwerk anzuschließen.
  • Die weitere Ausführung wird angehalten (über die Console.ReadLine -Methode oder über ein Dialogfeld mit der Schaltfläche „OK“). Nachdem der Computer mit dem Netzwerk verbunden wurde, drückt der Benutzer die EINGABETASTE.
  • Es wird erneut versucht, eine Verbindung herzustellen (dieser Versuch sollte erfolgreich sein).

Testen der Logik, indem beim Herstellen der Verbindung ein falscher Benutzername eingegeben wird

Ihr Programm kann vor dem ersten Verbindungsversuch mit Absicht einen falschen Benutzernamen verwenden. Der Fehler lautet:

  • SqlException.Number = 18456
  • Meldung: „Fehler bei der Anmeldung für den Benutzer 'WRONG_MyUserName'.“

Beim ersten Wiederholungsversuch kann Ihr Programm den Namen korrigieren und erneut versuchen, eine Verbindung herzustellen.

Um diesen Test in der Praxis umzusetzen, erkennt Ihr Programm einen Laufzeitparameter, der folgende Auswirkungen hat:

  • 18456 wird zeitweilig zur Liste der Fehler hinzugefügt, die als vorübergehend betrachtet werden.
  • Der Benutzername wird mit Absicht um „WRONG_“ ergänzt.
  • Nachdem der Fehler ermittelt wurde, wird 18456 aus der Liste entfernt.
  • „WRONG_“ wird vom Benutzernamen entfernt.
  • Es wird erneut versucht, eine Verbindung herzustellen (dieser Versuch sollte erfolgreich sein).

SqlConnection-Parameter von .NET für wiederholte Verbindungsversuche

Wenn Ihr Clientprogramm mithilfe der .NET Framework-Klasse System.Data.SqlClient.SqlConnection eine Verbindung mit der Datenbank in Azure SQL-Datenbank herstellt, sollten Sie .NET 4.6.1 oder eine höhere Version (oder .NET Core) verwenden, damit Sie das Feature für wiederholte Verbindungsversuche nutzen können. Weitere Informationen zu diesem Feature finden Sie unter SqlConnection.ConnectionString-Eigenschaft.

Beim Erstellen der Verbindungszeichenfolge für Ihr SqlConnection-Objekt sollten Sie die Werte der folgenden Parameter abstimmen:

  • ConnectRetryCount: Der Standardwert ist 1. Der Bereich erstreckt sich von 0 bis 255.
  • ConnectRetryInterval: Der Standardwert beträgt 10 Sekunden. Der Bereich erstreckt sich von 1 bis 60.
  • Verbindungstimeout: Der Standardwert beträgt 15 Sekunden. Der Bereich erstreckt sich von 0 bis 2147483647.
  • Befehlstimeout: Der Standardwert beträgt 30 Sekunden. Der Bereich erstreckt sich von 0 bis 2147483647.

Die Einstellungen für die Verbindungswiederholung (ConnectRetryCount und ConnectRetryInterval) gelten für die Verbindungsresilienz. Die Verbindungsresilienz umfasst die folgenden verschiedenen Typen:

  • Offene Verbindungsresilienz bezieht sich auf die anfängliche Methode SqlConnection.Open oder OpenAsync(). Der erste Verbindungsversuch wird als Versuch 0 gezählt. ConnectRetryCount bezieht sich auf nachfolgende Versuche. Wenn Verbindung 0 fehlschlägt (dies geschieht möglicherweise nicht sofort), wird zuerst ConnectRetryInterval angewendet, gefolgt von nachfolgenden ConnectRetryCount- (und ConnectRetryInterval-) Versuchen. Damit alle Wiederholungsversuche genutzt werden können, muss die Eigenschaft Verbindungstimeout Zeit für alle Versuche zur Verfügung stellen.

  • Die Resilienz von Verbindungen im Leerlauf bezieht sich auf die automatische Erkennung und erneute Verbindung vorhandener Verbindungen im Leerlauf, die unterbrochen wurden. Der erste Versuch, eine unterbrochene Verbindung im Leerlauf wiederherzustellen, wie als erster Wiederholungsversuch gezählt. Damit alle Wiederholungsversuche genutzt werden können, muss die Eigenschaft Befehlstimeout Zeit für alle Versuche zur Verfügung stellen.

Beispiel: Gehen Sie von den folgenden Werten für die Parameter ConnectRetryCount und ConnectRetryInterval aus:

ConnectRetryCount: 3 ConnectRetryInterval: 10 Sekunden

Sehen Sie, wie diese Werte in den folgenden Szenarien verwendet werden:

Szenario: Neue Verbindung

4:10:00 – Connection.Open() – Nullversuch

4:10:01 – Verbindungsfehler erkannt

4:10:11 – Wiederholung 1 – > Der erste Wiederholungsversuch erfolgt nach ConnectRetryInterval

4:10:21 – Wiederholung 2

4:10:31 = Wiederholung 3

Für dieses Szenario sollten Ihre gewählten Werte die folgende Bedingung erfüllen:
Connection Timeout > = ConnectRetryCount * ConnectionRetryInterval

Beispiel: Wenn die Anzahl 3 ist und das Intervall 10 Sekunden beträgt, hätte das System bei einem Timeout von nur 29 Sekunden nicht genügend Zeit für den dritten und letzten Verbindungsversuch:

29 < 3 * 10

Szenario: Verbindung im Leerlauf

ConnectRetryCount: 3 ConnectRetryInterval: 10 Sekunden

4:10:00 – Unterbrochene Verbindung, die bei der Ausführung von Befehlen erkannt wurde

4:10:00 – Wiederholung 1 – >Der erste Wiederholungsversuch erfolgt sofort

4:10:10 – Wiederholung 2

4:10:20 – Wiederholung 3

Dies ist nicht die anfängliche Verbindung. Daher gilt der Verbindungstimeout nicht. Da die Verbindungswiederherstellung jedoch während der Befehlsausführung auftritt, gilt die Einstellung Befehlstimeout. Der Standardwert für den Befehlstimeout beträgt 30 Sekunden. Obwohl die Verbindungswiederherstellung unter typischen Umständen schnell erfolgt, könnte ein intermittierender Ausfall dazu führen, dass die Wiederherstellung einen Teil der Ausführungszeit des Befehls dauert.

Wenn Sie in diesem Szenario die Wiederherstellungsversuche von Leerlaufverbindungen in vollem Umfang nutzen möchten, sollten die von Ihnen gewählten Werte die folgende Bedingung erfüllen:
Command Timeout > (ConnectRetryCount - 1) * ConnectionRetryInterval

Wenn die Anzahl beispielsweise 3 ist und das Intervall 10 Sekunden beträgt, würde ein Befehlstimeoutwert unter 20 Sekunden nicht genügend Zeit für den dritten und letzten Wiederholungsversuch lassen, um die Verbindung herzustellen: (3 - 1) * 10 = 20'

Berücksichtigen Sie außerdem, dass auch für die Ausführung des eigentlichen Befehls nach der Wiederherstellung der Verbindung Zeit erforderlich ist.

Hinweis

Die Werte für die Dauer, die in diesen Szenarien angegeben sind, dienen nur zu Demozwecken. Die tatsächlichen Erkennungszeiten in beiden Szenarien hängen von der zugrunde liegenden Infrastruktur ab.

Vorübergehende Fehler beim Herstellen einer Verbindung und bei Befehlen

Mit den Parametern ConnectRetryCount und ConnectRetryInterval kann Ihr SqlConnection-Objekt den Verbindungsversuch wiederholen, ohne Ihr Programm zu unterbrechen, sodass das Programm die Steuerung behält. Die Wiederholungen können in folgenden Situationen auftreten:

  • SqlConnection.Open-Methodenaufruf
  • SqlConnection.Execute-Methodenaufruf

Es gibt eine Besonderheit. Wenn ein vorübergehender Fehler auftritt, während Ihre Abfrage ausgeführt wird, wiederholt das SqlConnection-Objekt weder den Verbindungsversuch noch Ihre Abfrage. Allerdings überprüft SqlConnection sehr schnell die Verbindung, bevor die Abfrage für die Ausführung gesendet wird. Wenn bei der schnellen Überprüfung ein Verbindungsproblem festgestellt wird, wiederholt SqlConnection den Verbindungsvorgang. Ist die Wiederholung erfolgreich, wird die Abfrage zur Ausführung gesendet.

Sollte „ConnectRetryCount“ mit der Wiederholungslogik der Anwendung kombiniert werden?

Angenommen, Ihre Anwendung verfügt über eine zuverlässige benutzerdefinierte Wiederholungslogik. Sie könnte den Verbindungsversuch viermal wiederholen. Wenn Sie ConnectRetryInterval und ConnectRetryCount = 3 zur Verbindungszeichenfolge hinzufügen, erhöhen Sie die Anzahl der Wiederholungsversuche auf 4 * 3 = 12 Wiederholungen. Möglicherweise ist eine so hohe Anzahl von Wiederholungsversuchen nicht erwünscht.

Verbindungen mit Ihrer Datenbank in SQL-Datenbank

Verbindung: Verbindungszeichenfolge

Die Zeichenfolge für Verbindungen mit der Datenbank unterscheidet sich etwas von der Zeichenfolge, über die Verbindungen mit SQL Server hergestellt werden. Sie können die Verbindungszeichenfolge für Ihre Datenbank aus dem Azure-Portal kopieren.

Abrufen der Verbindungszeichenfolge aus dem Azure-Portal

Nutzen Sie das Azure-Portal zum Abrufen der Verbindungszeichenfolge, die für die Interaktion des Clientprogramms mit Azure SQL-Datenbank benötigt wird.

  1. Wählen Sie Alle Dienste>SQL-Datenbanken aus.

  2. Geben Sie in das Textfeld „Filter“ nahe der oberen linken Ecke des Bereichs SQL-Datenbanken den Namen der Datenbank ein.

  3. Wählen Sie die Zeile für die Datenbank aus.

  4. Nachdem der Bereich für die Datenbank angezeigt wird, können Sie der visuellen Einfachheit halber die Schaltflächen zum Minimieren auswählen, um die Blätter auszublenden, die Sie zum Durchsuchen und Filtern verwendet haben.

  5. Wählen Sie im Bereich für die Datenbank Datenbankverbindungszeichenfolgen anzeigen aus.

  6. Kopieren Sie die entsprechende Verbindungszeichenfolge. Wenn Sie also die ADO.NET-Verbindungsbibliothek verwenden möchten, kopieren Sie die entsprechende Zeichenfolge von der Registerkarte ADO.NET.

    Kopieren der ADO-Verbindungszeichenfolge für die Datenbank

  7. Bearbeiten Sie Verbindungszeichenfolge nach Bedarf. Fügen Sie Ihr Kennwort in die Verbindungszeichenfolge ein, oder entfernen Sie „@<Servername>“ aus dem Benutzernamen, wenn der Benutzer- oder Servername zu lang ist.

  8. Fügen Sie in dem ein oder anderen Format die Informationen der Verbindungszeichenfolge in den Clientcode für die Anwendung ein.

Weitere Informationen finden Sie unter Verbindungszeichenfolgen und Konfigurationsdateien.

Verbindung: IP-Adresse

SQL-Datenbank muss so konfiguriert werden, dass Verbindungen von der IP-Adresse des Computers akzeptiert werden, auf dem Ihr Clientprogramm gehostet wird. Um diese Konfiguration vorzunehmen, bearbeiten Sie die Firewalleinstellungen über das Azure-Portal.

Wenn Sie die IP-Adresse nicht konfigurieren, tritt bei Ihrem Programm ein Fehler auf, und in einer Fehlermeldung wird die erforderliche IP-Adresse angezeigt.

  1. Melden Sie sich beim Azure-Portal an.

  2. Wählen Sie in der Liste links Alle Dienste aus.

  3. Scrollen Sie und wählen Sie SQL-Server aus.

    Suchen Sie Ihren Azure SQL-Datenbank-Server im Portal

  4. Geben Sie im Filtertextfeld zunächst den Namen des Servers ein. Die Zeile wird angezeigt.

  5. Wählen Sie die Zeile für den Server aus. Ein Bereich für den Server wird angezeigt.

  6. Wählen Sie im Serverbereich Einstellungen aus.

  7. Wählen Sie Firewall aus.

    Auswahl von „Einstellungen“ > „Firewall“

  8. Wählen Sie Client-IP hinzufügen aus. Geben Sie einen Namen für die neue Regel in das erste Textfeld ein.

  9. Geben Sie die niedrigen und hohen IP-Adresswerte für den Bereich ein, den Sie aktivieren möchten.

    • Es kann praktisch sein, wenn der niedrige Wert auf .0 und der hohe Wert auf .255 endet.

  10. Wählen Sie Speichern aus.

Weitere Informationen finden Sie unter Konfigurieren von Firewalleinstellungen in SQL-Datenbank.

Verbindung: Ports

Normalerweise muss auf dem Computer, auf dem Ihr Clientprogramm gehostet wird, sichergestellt werden, dass lediglich Port 1433 für die ausgehende Kommunikation geöffnet ist.

Wenn Ihr Clientprogramm z. B. auf einem Windows-Computer gehostet wird, kann Port 1433 über die Windows-Firewall auf dem Host geöffnet werden.

  1. Öffnen Sie die Systemsteuerung.
  2. Wählen Sie Alle Systemsteuerungselemente>Windows-Firewall>Erweiterte Einstellungen>Ausgehende Regeln>Aktionen>Neue Regel aus.

Wenn Ihr Clientprogramm auf einem virtuellen Azure-Computer gehostet wird, lesen Sie Andere Ports als 1433 für ADO.NET 4.5 und SQL-Datenbank.

Hintergrundinformationen zur Konfiguration von Ports und IP-Adressen in Ihrer Datenbank finden Sie in den Erläuterungen zur Firewall für Azure SQL-Datenbank.

Verbindung: ADO.NET 4.6.2 oder höher

Wenn Ihr Programm ADO.NET-Klassen wie System.Data.SqlClient.SqlConnection für Verbindungen mit SQL-Datenbank verwendet, sollten Sie .NET Framework, Version 4.6.2 oder höher, verwenden.

Ab ADO.NET 4.6.2

  • Der Versuch zum Öffnen der Verbindung sollte für Azure SQL sofort wiederholt werden, wodurch die Leistung cloudfähiger Apps verbessert wird.

Ab ADO.NET 4.6.1

  • Die Zuverlässigkeit von SQL-Datenbank lässt sich verbessern, wenn Sie eine Verbindung mit der SqlConnection.Open-Methode öffnen. Die Open-Methode umfasst jetzt bestmögliche Wiederholungsmechanismen, die bei bestimmten vorübergehenden Fehlern innerhalb des Verbindungstimeouts ausgeführt werden.
  • Das Verbindungspooling wird unterstützt und umfasst einen effizienten Mechanismus, der überprüft, ob das für Ihr Programm bereitgestellte Verbindungsobjekt funktionsfähig ist.

Bei Verwendung eines Verbindungsobjekts aus einem Verbindungspool sollte Ihr Programm die Verbindung vorübergehend schließen, wenn diese nicht umgehend verwendet wird. Eine Verbindung erneut zu öffnen, ist nicht aufwendig, eine neue Verbindung zu erstellen, schon.

Wenn Sie ADO.NET 4.0 oder eine frühere Version verwenden, sollten Sie ein Upgrade auf die aktuelle ADO.NET-Version durchführen. Ab August 2018 können Sie ADO.NET 4.6.2 herunterladen.

Diagnose

Diagnose: Testen, ob Hilfsprogramme eine Verbindung herstellen können

Wenn Ihr Programm keine Verbindung mit der Datenbank in SQL-Datenbank herstellen kann, können Sie zu Diagnosezwecken versuchen, eine Verbindung mit einem Hilfsprogramm herzustellen. Idealerweise verwendet das Hilfsprogramm für die Verbindung dieselbe Bibliothek wie Ihr Programm.

Auf einem Windows-Computer können Sie die folgenden Hilfsprogramme nutzen:

  • SQL Server Management Studio (ssms.exe), das ADO.NET für die Verbindung nutzt, oder
  • sqlcmd.exe, das ODBC für die Verbindung nutzt

Sobald Ihr Programm verbunden ist, testen Sie, ob eine kurze SQL-SELECT-Abfrage erfolgreich ausgeführt wird.

Diagnose: Überprüfen der offenen Ports

Wenn Sie annehmen, dass Verbindungsversuche aufgrund von Portproblemen fehlschlagen, können Sie ein Hilfsprogramm auf Ihrem Computer ausführen, das die Portkonfigurationen angibt.

Unter Linux können die folgenden Hilfsprogramme nützlich sein:

  • netstat -nap
  • nmap -sS -O 127.0.0.1: Ändern Sie den Beispielwert in Ihre IP-Adresse.

Unter Windows kann das Hilfsprogramm PortQry.exe nützliche Informationen liefern. Nachfolgend eine Beispielabfrage für die Portinformationen einer Datenbank in SQL-Datenbank, die auf einem Laptop ausgeführt wurde:

[C:\Users\johndoe\]
>> portqry.exe -n johndoesvr9.database.windows.net -p tcp -e 1433

Querying target system called: johndoesvr9.database.windows.net

Attempting to resolve name to IP address...
Name resolved to 23.100.117.95

querying...
TCP port 1433 (ms-sql-s service): LISTENING

[C:\Users\johndoe\]
>>

Diagnose: Protokollieren der Fehler

Periodisch auftretende Probleme lassen sich mitunter am besten diagnostizieren, indem Sie über mehrere Tage oder Wochen hinweg ein allgemeines Muster ermitteln.

Dabei kann es hilfreich sein, sämtliche Fehler auf dem Client zu protokollieren. Möglicherweise lassen sich die Protokolleinträge mit den Fehlerdaten in Zusammenhang bringen, die SQL-Datenbank intern protokolliert.

Enterprise Library 6 (EntLib60) bietet verwaltete .NET-Klassen zur Unterstützung der Protokollierung. Weitere Informationen finden Sie unter 5 – Protokollierung leicht gemacht: mit dem Protokollierungsanwendungsblock.

Diagnose: Überprüfen der Systemprotokolle auf Fehler

Nachfolgend finden Sie einige Transact-SQL-SELECT-Anweisungen, mit denen Fehlerprotokolle und andere Informationen abgefragt werden.

Protokollabfrage BESCHREIBUNG
SELECT e.*
FROM sys.event_log AS e
WHERE e.database_name = 'myDbName'
AND e.event_category = 'connectivity'
AND 2 >= DateDiff
  (hour, e.end_time, GetUtcDate())
ORDER BY e.event_category,
  e.event_type, e.end_time;		 Die sys.event_log-Ansicht bietet Informationen zu einzelnen Ereignissen, einschließlich solcher, die vorübergehende Fehler oder Verbindungsfehler verursachen können.

Idealerweise können Sie die Werte start_time oder end_time den Zeiten zuordnen, zu denen in Ihrem Clientprogramm Probleme aufgetreten sind.

Sie müssen eine Verbindung mit der Masterdatenbank herstellen, um diese Abfrage auszuführen.
SELECT c.*
FROM sys.database_connection_stats AS c
WHERE c.database_name = 'myDbName'
AND 24 >= DateDiff
  (hour, c.end_time, GetUtcDate())
ORDER BY c.end_time;		 Die sys.database_connection_stats-Ansicht bietet aggregierte Werte der Ereignistypen für die weitere Diagnose.

Sie müssen eine Verbindung mit der Masterdatenbank herstellen, um diese Abfrage auszuführen.

Diagnose: Suche nach Problemereignissen im Protokoll von SQL-Datenbank

Sie können im Protokoll von SQL-Datenbank Einträge zu Problemereignissen suchen. Führen Sie die folgende Transact-SQL-SELECT-Anweisung in der Masterdatenbank aus:

SELECT
   object_name
  ,CAST(f.event_data as XML).value
      ('(/event/@timestamp)[1]', 'datetime2')                      AS [timestamp]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="error"]/value)[1]', 'int')             AS [error]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="state"]/value)[1]', 'int')             AS [state]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="is_success"]/value)[1]', 'bit')        AS [is_success]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="database_name"]/value)[1]', 'sysname') AS [database_name]
FROM
  sys.fn_xe_telemetry_blob_target_read_file('el', null, null, null) AS f
WHERE
  object_name != 'login_event'  -- Login events are numerous.
  and
  '2015-06-21' < CAST(f.event_data as XML).value
        ('(/event/@timestamp)[1]', 'datetime2')
ORDER BY
  [timestamp] DESC
;

Zurückgegebene Zeilen aus „sys.fn_xe_telemetry_blob_target_read_file“

Das folgende Beispiel zeigt, wie eine zurückgegebene Zeile aussehen könnte. Die gezeigten Nullwerte sind in anderen Zeilen häufig keine Nullwerte.

object_name                   timestamp                    error  state  is_success  database_name

database_xml_deadlock_report  2015-10-16 20:28:01.0090000  NULL   NULL   NULL        AdventureWorks

Enterprise Library 6

Bei Enterprise Library 6 (EntLib60) handelt es sich um ein Framework aus .NET-Klassen, mit denen Sie stabile Clouddienstclients implementieren können, wobei einer der Dienste SQL-Datenbank ist. Unter Enterprise Library 6 finden Sie Themen zu den verschiedenen Bereichen, in denen EntLib60 hilfreich sein kann.

EntLib60 kann beispielsweise für Wiederholungslogik zur Behandlung von vorübergehenden Fehlern hilfreich sein. Weitere Informationen finden Sie unter 4 – Hartnäckigkeit, das Geheimnis aller Erfolge: Anwendungsblock zum Behandeln vorübergehender Fehler.

Hinweis

Der Quellcode für EntLib60 steht im Download Center zum öffentlichen Download bereit. Microsoft plant keine weiteren Funktions- oder Wartungsupdates für EntLib.

EntLib60-Klassen für vorübergehende Fehler und Wiederholungsversuche

Die folgenden EntLib60-Klassen sind besonders nützlich für Wiederholungslogik. All diese Klassen befinden sich im Namespace Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling oder einem untergeordneten Namespace.

Im Namespace Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling:

  • RetryPolicy-Klasse
    • ExecuteAction
  • ExponentialBackoff
  • SqlDatabaseTransientErrorDetectionStrategy
  • ReliableSqlConnection-Klasse
    • ExecuteCommand

Im Namespace Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.TestSupport:

  • AlwaysTransientErrorDetectionStrategy
  • NeverTransientErrorDetectionStrategy

Unter folgenden Links finden Sie weitere Informationen zu EntLib60:

EntLib60: Der Protokollierungsblock

  • Der Protokollierungsblock ist eine äußerst flexible und umfassend konfigurierbare Lösung, die Folgendes ermöglicht:
    • Erstellen und Speichern von Protokollmeldungen an diversen Speicherorten.
    • Kategorisieren und Filtern von Meldungen.
    • Erfassen von Kontextinformationen für Debugging und Ablaufverfolgung sowie für Überwachung und allgemeine Protokollierungsanforderungen.
  • Der Protokollierungsblock abstrahiert die Protokollierungsfunktionalität vom Protokollziel, sodass der Anwendungscode unabhängig von Speicherort und Typ des Zielprotokollspeichers einheitlich ist.

Weitere Informationen finden Sie unter 5 – Protokollierung leicht gemacht: mit dem Protokollierungsanwendungsblock.

Quellcode der IsTransient-Methode von EntLib60

Nachfolgend wird der C#-Quellcode für die Methode IsTransient der Klasse SqlDatabaseTransientErrorDetectionStrategy gezeigt. Anhand dieses Quellcodes wird ermittelt, welche Fehler als vorübergehend eingestuft werden und einen Wiederholungsversuch rechtfertigen.

public bool IsTransient(Exception ex)
{
  if (ex != null)
  {
    SqlException sqlException;
    if ((sqlException = ex as SqlException) != null)
    {
      // Enumerate through all errors found in the exception.
      foreach (SqlError err in sqlException.Errors)
      {
        switch (err.Number)
        {
            // SQL Error Code: 40501
            // The service is currently busy. Retry the request after 10 seconds.
            // Code: (reason code to be decoded).
          case ThrottlingCondition.ThrottlingErrorNumber:
            // Decode the reason code from the error message to
            // determine the grounds for throttling.
            var condition = ThrottlingCondition.FromError(err);

            // Attach the decoded values as additional attributes to
            // the original SQL exception.
            sqlException.Data[condition.ThrottlingMode.GetType().Name] =
              condition.ThrottlingMode.ToString();
            sqlException.Data[condition.GetType().Name] = condition;

            return true;

          case 10928:
          case 10929:
          case 10053:
          case 10054:
          case 10060:
          case 40197:
          case 40540:
          case 40613:
          case 40143:
          case 233:
          case 64:
            // DBNETLIB Error Code: 20
            // The instance of SQL Server you attempted to connect to
            // does not support encryption.
          case (int)ProcessNetLibErrorCode.EncryptionNotSupported:
            return true;
        }
      }
    }
    else if (ex is TimeoutException)
    {
      return true;
    }
    else
    {
      EntityException entityException;
      if ((entityException = ex as EntityException) != null)
      {
        return this.IsTransient(entityException.InnerException);
      }
    }
  }

  return false;
}

Nächste Schritte